GTX690战术核显卡导弹
type: channel
link: https://www.nekopara.uk/
description: GTX690战术核显卡导弹的猫窝
items: Linux下NVIDIA计算卡打游戏指南，以V100为例
items: ComfyUI对接Ollama——让AI全自动出图
items: MediaPages：一键在Cloudflare Pages存放媒体库
items: 【开发】NekoIPinfo：基于GO语言的高性能IP查询服务端
items: 利用Python配合Blender把CAD高程点转化为3D地形模型
items: 小米CR8809路由器OpenWrt刷机指南
items: 家里云服务优化：统一Web服务端口，减小攻击面
items: 超可爱！FileBrowser 2.57.1 界面美化记录
items: 使用Systemd代替Mcsmanager管理挂机服务
items: 【日常】并夕夕购入巧克力手办日记

Linux下NVIDIA计算卡打游戏指南，以V100为例
type: item
date: 2026-03-20T22:49:00+08:00
description: 无头N卡Linux打游戏指南前段时间我把内存卖了，然后V100就自然而然吃灰了。偶然的机会，我在并夕夕刷到了便宜的PCIe延长线，x4转x16接口，只需要28包邮，还是30cm的。很快啊，啪的一下，我就下单了。我打算还是之前玩V100那个配方，直接外接电源同步启动来解决V100的供电问题（因为这次电脑已经有了一个RTX1080Ti电老虎了），和之前的玩法一样。到祸后，我赶紧上机测试，启动倒是没有任何问题，没想到这个X99寨板马上就给我来了个下马威。主板设置开机的时候，电脑先运行了一会，然后就掉电了，大概两秒后重新上电，然后直接给我来了一个贴脸报错：大概意思是：PCIe MMIO（内存映射输入输出）空间不足，只能禁用一部分PCIe设备进入系统后，果不其然V100初始化失败了。需要解决这个问题的话，要开启主板的Above 4G Decoding和Re-size BAR Support（可选），并且禁用主板的CSM。搞定之后，进系统，两张显卡都正常识别了：[chocola@Neko-X99 ~]$ nvidia-smi Fri Mar 20 16:34:32 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.82.09 Driver Version: 580.82.09 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 Tesla V100-SXM2-16GB Off | 00000000:01:00.0 Off | 0 | | N/A 37C P0 24W / 300W | 8MiB / 16384MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | 1 NVIDIA GeForce RTX 2080 Ti Off | 00000000:03:00.0 On | N/A | | 40% 40C P0 18W / 250W | 897MiB / 11264MiB | 1% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+也是感慨啊，当时刚拿到V100的时候，给它和RTX2080Ti拍了一张同框的照片，现在这下是电脑同框了（）驱动版本提醒：如果是Turing以下的架构，例如Volta架构，Pascal架构和Maxwell架构，驱动版本建议使用580，575，570这几个版本，550也不错。至于更老的Kepler架构，最后支持的是470版本，太老了，很多东西可能都没法玩了，就不太建议了。Turing及以上，可以试试看新驱动。Xorg 下游戏性能测试这里先说一个有趣的现象，我在测试的时候，发现了一个非常玄学的问题：如果是Wayland，默认调用的是GPU0，也就是V100。对！你没听错，默认就给你调用无头卡，估计可能是因为设备顺序问题。但是如果Xorg，那就是默认调用GPU1，也就是当前的显示设备。我这里先说一下Xorg下的性能表现，然后再去喷有大病的Wayland。调用V100跑游戏首先，如前所述，在Xorg环境下，游戏是默认调用显示的显卡进行渲染的，这时候我们就需要手动去指定渲染设备。在steam的游戏属性里面的启动选项，加上这个启动参数：DXVK_FILTER_DEVICE_NAME="Tesla V100" VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json __NV_PR…

ComfyUI对接Ollama——让AI全自动出图
type: item
date: 2026-03-19T16:05:00+08:00
description: 让AI指挥AI画图我玩了一段时间的ComfyUI之后，突然有一个想法：既然都是生成提示词来绘制画面，为什么我不能让LLM全自动为我生成提示词，然后生成画面后再让模型进行审核呢？我很早之前就了解到ComfyUI是有API接口的，只需要调用就可以，而Ollama本身就支持调用。这意味着，我只需要写一个中间沟通的桥梁。让两个AI对接互撕就可以了。说干就干，我打算用我之前拿来跑SheepIt的P104-100双卡渲染机来做这件事情。毕竟矿卡嘛，就应该有矿卡的样子——没日没夜高强度工作，直到寿终正寝。都是哥布林洞穴里面出来的玩意，RTX2080Ti我会让她好好当作正常的显卡用，至于职业矿渣P104-100，你就做一辈子矿卡吧！模型选型由于P104-100的显存只有8GB，所以太大的模型是跑不了的。所幸，我想玩的NetaYume v4画图模型，是有分体版本的，可以在8G显存的显卡上面完美运行，那接下来选型的重点，就是多模态模型的选择了：主要是能输入图片的模型，毕竟需要模型对图片进行把关。由于显存限制，模型应该选择 7B-8B 的模型会比较合适，因为既能充分利用显存，又能提供还可以的智商，不至于太傻。看了一下Ollama官网上带视觉功能的最近的模型，比较适合的，主要有这几个选择：Qwen3.5 4B (9B试过了，显存不够用，会卸载到CPU导致速度奇慢）Qwen3-VL 8BGemma3 4BMinistral-3 8BMinicpm-V 8B目前我只尝试使用了Qwen3-VL 8B进行测试，效果还可以，提示词要求的格式服从性尚可，虽然也会偶尔给你发癫乱来导致产生一些废图。另外，我还尝试了一下MiniCPM-V 8B，这个是最开始Gemini推荐的，发现这个模型对画面的评审能力，似乎确实是要比Qwen3-VL 8B要强得多，很多画面崩坏的细节都能察觉到。对接ComfyUI API至于如何部署ComfyUI和Ollama，我就不再赘述了，前面的文章都有讲过，让我们直接步入正题。踩大坑记录一开始我以为给API提交的JSON文件，就是保存在ComfyUI的user/default/workflows/目录下的JSON，然后发现这么尝试提交都是失败。后面去问了Gemini，才知道是不一样的。对于提交给API的JSON，需要打开高级设置，然后在文件中导出工作流。具体的开启流程是：点击ComfyUI面板右侧的齿轮图标（设置），勾选开启 ‘Enable Dev mode Options’（启用开发者模式选项）。开启后，面板上才会多出一个 ‘Save (API Format)’ 的按钮。点击它导出的 JSON 才是能给 API 用的。步骤如图所示：正确的JSON应该是长这样的：{ "1": { "inputs": { "vae_name": "vae.safetensors" }, "class_type": "VAELoader", "_meta": { "title": "加载VAE" } }, "2": { "inputs": { "clip_name": "gemma_2_2b_fp16.safetensors", "type": "stable_diffusion", "device": "default" }, "class_type": "CLIPLoader", "_meta": { "title": "加载CLIP" } }, "3": { "inputs": { "unet_name": "NetaYumev4_unet.safetensors", "weight_dtype": "default" }, "class_type": "UNETLoader", "_meta": { "title": "UNet加载器" } }, "4": { "inputs": { "shift": 4, "model": [ "3", 0 ] }, "class_type": "ModelSamplingAuraFlow", "_meta": { "title": "采样算法（AuraFlow）" } }, "8": { "inputs": { "seed": 927904769887424, "steps": 30, "cfg": 4.0, "sampler_name": "res_multistep", "scheduler": "linear_quadratic", "denoise": 1, "model": [ "4", 0 ], "positive": [ "6:7", 0 ], "negative": [ "7:7", 0 ], "latent_image": [ "9", 0 ] }, "class_type": "KSampler"…

MediaPages：一键在Cloudflare Pages存放媒体库
type: item
date: 2026-03-11T22:34:00+08:00
description: 利用Cloudflare Pages搭建媒体库实战前段时间极客湾因为公开揭露手机厂商的龌龊行径——媒体特调机内幕，导致其视频被全网下架。随后极客湾开放视频转载权限，全网随即上演了补档大战，来表达对厂商捂嘴的不满。我也是拿到了极客湾的视频原文件，看了一眼，好家伙，8.4GB，还是4K 60FPS的视频，这要分享还有点费流量。在平常的一次去吃午饭的路上，我走在校园的道路上，突然灵光一闪：如果我能把这个视频放到Cloudflare Pages，岂不美哉？！但是，我突然想起来了Cloudflare Pages免费版的限制：25MB单文件大小——这几乎无法放大型的视频。不过，有一句诗说得好：“山穷水尽疑无路，柳暗花明又一村。”那既然限制文件大小，那我把视频文件切开，每一个块符合大小限制，不就行了吗？！而免费版的Cloudflare Pages单个项目文件数量限制为20000个，也就是理论上可以放20000x25MB=5000000MB，也就是大约488GB——这已经比一个500G机械硬盘的实际可用空间465GB还大了！最重要的是，Cloudflare并不限制项目数量，理论上对于个人来说约等于无限容量了！说干就干，我随即开始了理论的验证。验证想法可行性通过查阅资料，我了解到现代的浏览器可以利用hls.js实现对切分后视频的播放，目前早就有了成熟的方案，且各种视频平台就在用。需要的视频形态是一个.m3u8的视频索引文件，外加一大堆视频切割的碎片.ts文件，而把普通的视频转成这样的工作，ffmpeg就能干！这下不就把技术路线跑通了嘛，赶紧验证一下想法：ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i 零售机_游戏性能大横评_2026.mp4 \ -c:v h264_nvenc -preset p6 -profile:v high -level:v 5.2 \ -rc vbr -b:v 18M -maxrate 24M -bufsize 36M \ -g 180 -keyint_min 180 -sc_threshold 0 \ -c:a aac -b:a 192k \ -hls_time 3 -hls_playlist_type vod -hls_segment_filename "chunk_%04d.ts" \ video-0.m3u8通过调整每个块的时间，确保每个块都不超过25MB，符合Cloudflare Pages的文件大小限制。然后再写一个html用于播放： 极客湾-手机2026游戏性能大横评（补档）4K 60FPS 准备加载视频... 把转化后的视频碎片放到html同目录下的video-data文件夹，本地启动Nginx设定好网站目录，浏览器打开，果然可以正常播放。这下就好玩了！这里还有极客湾的测试视频，也是我方案验证阶段的效果，可以去看看：极客湾-手机2026游戏性能大横评（补档）4K 60FPS重要提醒需要注意的是，执行下面的程序之前，需要把你的Cloudflare账户的ID和令牌导入到命令行环境中，例如：export CLOUDFLARE_API_TOKEN="www.nekopara.uk" export CLOUDFLARE_ACCOUNT_ID="www.nekopara.uk"请替换为你自己的真实 Token 和 Account ID。其中创建API Token时，正确的选择权限选项是：账户 > Cloudflare Pages > 编辑还有一个最重要的提醒，这些操作其实不是正常的Pages产品使用方式，存在账户封禁或限制使用等风险，请务必使用新创建的独立账号进行操作，以免造成不必要的损失！尝试把成果上传Pages但是，在这一步，我就踩坑了，还是踩了大坑！正当我尝试把转化好的文件夹通过Cloudflare Pages的部署页面上传时，我遇到了大坑：上传大概进行半个小时后，网页疯狂弹出API 403报错。一开始我还以为是网络的问题，开启了魔法网络环境，结果问题依旧。这时我意识到，上传的API应该是有临时Token超时机制的，当文件数量太多，体积太大，上传的时间变长了，就会触发这个问题。似乎这一切无解了？我能做出来符合文件大小限制的静态网页目录，却无法完整上传。但是，在看了Cloudflare的提示后，我发现了一个可能的路径：用wrangler进行部署——这个可以支持上传20000个文件的项目。而网页上传限制为1000个文件。于是乎，我就安装了wrangler进行尝试：因为wrangler需要nodejs环境，我们先安装nodejs:pacman -S nodejs npm然后在安装wrangler，系统级安装命令如下：npm install -g wrangler…

【开发】NekoIPinfo：基于GO语言的高性能IP查询服务端
type: item
date: 2026-03-05T22:17:14+08:00
description: 高性能IP查询服务端开发日志之前使用IP信息查询的服务也不少了，观察了不少的接口，大部分返回的数据都是json格式的数据，于是我就在想，我能不能也自己开发一个类似的查询工具玩一下？说干就干，在想清楚了软件的架构设计后，我决定开工。架构设计与编程语言选型在架构设计方面，我打算进行前后端彻底解耦，前端为静态网页，后端为纯API程序。对于前端，我计划利用JS来从API获取信息并更新页面对于后端，就做最纯粹的API服务，根据查询请求响应JSON字符串在亲眼见证过PHP，Python这类动态解释型语言的效率噩梦后，我打算使用GO语言进行开发，理由很简单：GO是编译型语言，运行效率比解释型语言要高得多。GO天生就适合开发后端，抗并发能力强。相比于C语言，GO语言要更适合上手。构建前端不得不说，就目前的情况，Gemini仍然是前端之神，我直接让Gemini根据我的想法设计了一套网页，还是相当不错的：代码如下： 猫娘IP地址查询 🐱 🐾 猫娘IP地址查询 您的 IP 地址为 正在获取喵... 🔍 <input type="text" id="ip-input" placeholder="请输入要查询的 IP 地址喵~" class="w-full bg-white/90 backdrop-blur-sm border-2 border-pink-200 text-pink-700 placeholder-pink-300 px-14 py-4 rounded-full md:rounded-r-none focus:outline-none focus:border-pink-400 focus:bg-white transition-all duration-300" > <button id="search-btn" class="w-full md:w-auto mt-4 md:mt-0 bg-gradient-to-r from-pink-400 to-rose-400 hover:from-pink-500 hover:to-rose-500 text-white font-bold text-lg px-8 py-4 rounded-full md:rounded-l-none md:rounded-r-full shadow-md hover:shadow-pink-300/50 transform hover:-translate-y-0.5 transition-all duration-300 whitespace-nowrap active:scale-95" > 查询喵 🐾 🌍 国家 - 🗺️ 省份 - 🏙️ 城市 - 🏢 ISP 运营商 - 🧭 经纬度 - 💡 开发者 API 说明 🛠️ API 调用说明 × 您可以通过发送 GET 请求到我们的接口来获取 IP 详细信息喵： GET https://api.maoniang.example/v1/ip?address={ip} 📦 返回数据格式示例 (JSON): { "code": 200, "msg": "success", "data": { "country": "美国", "province": "加利福尼亚州", "city": "圣克拉拉", "isp": "阿里云", "latitude": "37.355701", "longitude": "-121.955002" } } 我知道了喵 🐾 但是仔细观察，你会发现使用了实时构建的 Tailwind CSS ，其实这样做对于一个静态页面不太友好，于是我让他按照 Tailwind CSS 的样式，原生帮我写了一版样式。因为处理后代码变多了，我就不在这里放出来了。最后静态文件就三个：[chocola@Neko-X99 static]$ tree . ├── favicon.png ├── index.html └── main.css 1 directory, 3 files后续还有界面的美化，目前确定是这样了：变可爱了，有没有？后端设计因为项目的定位是轻量，所以我不打算依赖外部的数据库。再加上IP查询这个业务场景几乎全是读操作，所以使用SQLite是没问题的，读取这方面没有瓶颈。为了实现高效的 IP 查询，数据库表结构的设计至关重要。核心思路是将文本格式的 IP 地址转换为无符号 32 位整数（uint32），这样不仅运算效率高，也便于进行范围比较。数据库表（例如 ip_info）主要包含三个字段：network_start (INTEGER): 存储该 IP 段的起始地址，以 uint32 格式保存。这是查询的核心，我们会根据这个字段建立索引（CREATE INDEX idx_network_sta…

利用Python配合Blender把CAD高程点转化为3D地形模型
type: item
date: 2026-03-04T13:20:27+08:00
description: 使用Python把CAD高程图实体化为3D模型因为设计课程的需要，我需要为场地建立一个直观的3D模型进行形体推敲。但是这次老师给的CAD图纸只有高程点，等高线是缺失的，所以我希望是利用这些高程点的信息进行自动化建模，快速生成场地地形模型。转换CAD首先，因为CAD比较凌乱，我们需要整理出一个只包含了高程点的CAD图，并且导出为DXF格式，方便后续的Python程序进行对接。原CAD：处理后的CAD:处理完成后，导出DXF格式的文件，为Python程序化建模做准备。转化程序因为blender的Python环境不方便安装别的库，所以处理程序分为两个部分：第一部分使用系统安装的Python环境进行处理，使用json格式保存转好后的中间结果，也就是每个点的坐标.第二部分使用Blender的Python环境，读取已经处理好的地形信息json文件，进行建模。首先是第一部分的处理dxf文件：import ezdxf import json import re import os # --- 配置文件路径 --- DXF_FILE_PATH = "Drawing2.dxf" JSON_OUTPUT_PATH = "topography.json" def dxf_to_json(dxf_path, json_path): print(f"正在读取 DXF 文件: {dxf_path} ...") if not os.path.exists(dxf_path): print(f"错误：找不到文件 '{dxf_path}'。") return try: doc = ezdxf.readfile(dxf_path) except Exception as e: print(f"读取 DXF 失败: {e}") return msp = doc.modelspace() points = [] # 用于存储坐标的列表 for entity in msp.query('TEXT MTEXT'): try: text_str = entity.dxf.text # 提取数字（支持负数和小数） match = re.search(r'[-+]?\d*\.?\d+', text_str) if match: z = float(match.group()) x = entity.dxf.insert.x y = entity.dxf.insert.y # 将坐标作为一个小列表存入总列表 points.append([x, y, z]) except Exception: continue if points: # 将数据转储为 JSON 格式 with open(json_path, 'w', encoding='utf-8') as f: json.dump(points, f, indent=2) # indent=2 让 JSON 文件格式化，方便人类阅读 print(f"✅ 成功！共提取了 {len(points)} 个坐标点。") print(f"数据已保存为 JSON 文件: {json_path}") else: print("❌ 提取失败：未找到有效数据。") # 运行脚本 dxf_to_json(DXF_FILE_PATH, JSON_OUTPUT_PATH)以上代码在系统的Python环境运行，记得安装对应的Python库ezdxf。然后是在Blender里面运行的Python代码：import bpy import json import mathutils # --- 配置参数 --- JSON_FILE_PATH = "/run/media/chocola/3T-DATA02/设计/场地模型/topography.json" def create_terrain_from_json(filepath): # 1. 读取 JSON 数据 try: with open(filepath, 'r', encoding='utf-8') as f: points = json.load(f) except Exception as e: print(f"❌ 读取 JSON 失败: {e}") return if not points: print("❌ JSON 文件中没有数据！") return print(f"成功读取 {len(points)} 个坐标点，开始处理...") # 2. 计算边界框中心，处理坐标过大导致的浮点精度问题 min_x = min(p[0] for p in points) max_x = max(p[0] for p in points) min_y = min(p[1] for p in points) m…

小米CR8809路由器OpenWrt刷机指南
type: item
date: 2026-02-20T00:48:18+08:00
description: CR8809路由器刷机记录在用爱快的Q6000路由器替换掉小米CR8809路由器后，CR8809就一直是吃灰状态。这几天突然心血来潮，想给这玩意刷个机，体验体验OpenWrt。对于这个路由器的刷机指南，各种论坛已经有不少，特别是恩山无线论坛，有很多教程。可惜现在这个论坛感觉对没有注册的访客越来越封闭，不好获取信息了，现在的情况是连图片都不能显示了。而且注册还要钱，我寻思着你网站广告也不少啊，怎么敢要钱的？哎，不说废话了，教程开始。根据论坛的信息：CR880X系列：联通的CR8806、移动的CR8808、电信的CR8809。三个运营商的硬件大差不差一样的，固件有点区别但是能互刷。主板按发售时间分为M81、M79 A版、M79 B版三种。M79 B版的CPU为IPQ5018，其他两款是IPQ5000。M79 B版无法刷大分区uboot。 TTL在右上角的是IPQ5000，在底部的是IPQ5018。并且这个系列的路由器可以和Redmi AX3000路由器的刷机包通刷，因为使用的硬件方案是一样的，就是运营商定制换皮罢了。我的路由器是CR8809，通过观察主板丝印发现是M79的主板。丝印位于主板重置按钮右侧，上网查一下拆机图就知道在那了。可以免拆看到，但是有点费劲：用手机的手电筒照进最靠近重置按钮的网口，然后通过正面的散热孔观察主板重置按钮右侧的区域，就能看到丝印了。很不幸，我这个路由器是M79的主板，但是不幸中的万幸是方案是IPQ5000，可以刷大分区！爆开小米路由器的SSH我们需要用到的工具是：xmir-patcher也可以从github下载：git clone https://github.com/openwrt-xiaomi/xmir-patcher下载完成后，进入工具目录，执行run.sh./run.sh Looking in indexes: https://pypi.mirrors.ustc.edu.cn/simple/ Ignoring ssh2-python312: markers 'python_version >= "3.12"' don't match your environment Requirement already satisfied: charset_normalizer in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 1)) (3.3.2) Requirement already satisfied: idna in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 2)) (3.7) Requirement already satisfied: urllib3 in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 3)) (2.2.2) Requirement already satisfied: certifi in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 4)) (2024.6.2) Requirement already satisfied: requests in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 5)) (2.32.3) Requirement already satisfied: pyftpdlib in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 6)) (1.5.10) Requirement already satisfied: ssh2-python>=1.0.0 in ./venv/lib/python3.10/site-packages (from -r requirements.txt (line 7)) (1.0.0) [notice] A new release of pip available: 22.3.1 -> 24.1.1 [notice] To update, run: pip install --upgrade pip ========================================================== Xiaomi MiR Patcher 1 - Set IP-address…

家里云服务优化：统一Web服务端口，减小攻击面
type: item
date: 2026-02-14T17:00:00+08:00
description: 统一家里云的Web服务端口之前很长的一段时间，我的家里云部署的服务都是一个服务监听一个端口，管理相对比较混乱一点，而且因为监听的端口较多，且服务直接暴露，安全风险会更高一些。例如9898端口由Jellyfin监听提供服务，8848端口由Filebrowser监听提供服务，8086端口由NextCloud监听提供服务...这样子虽然在内网访问的情况下方便管理，但是也带来了多端口，多个后端服务直接暴露，管理相对混乱。而且还有一个问题，就是Filebrowser直接监听端口，如果浏览器发送的是http请求，也就是默认在地址栏输入域名+端口时的请求，会直接返回一段文字：client sent an HTTP request to an HTTPS server，然后需要再去地址栏在http后面加上个s，就很操蛋。而对于nginx服务器，则可以直接加上这条规则error_page 497 https://$host:8848$request_uri;即可实现自动跳转，体验要好不少。外加上我家里云其实有专门解析的域名，可以设置不同的子域名用于区分服务，并且我因为我一年多在网站上面的实践，也有了实操经验。所以，我决定把我家里云的Web服务全部统一服务端口，通过vhost进行区分，也就是利用https的sni进行区分，顺带再做一个回落的默认页面来防止低级的IP地址扫描器，还有可能存在的运营商对用户运行的服务的扫描。回落页面设置首先是回落页面设置，这也就是用于掩人耳目的设置，当域名不匹配时，就会返回这个内容。配置文件为/etc/nginx/conf.d/default.conf listen 8848 ssl default_server; listen [::]:8848 ssl default_server; server_name _; # 这是一个通配符，表示任何未匹配的主机名 ssl_certificate /home/chocola/data/certs/bt_cert.pem; ssl_certificate_key /home/chocola/data/certs/bt_cert.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384'; root /var/www/; # 静态文件的位置 index index.html; # 默认主页 location / { try_files $uri $uri/ =404; # 尝试提供请求的文件或目录，如果不存在则返回404 } # 处理错误页面 error_page 404 /404.html; location = /404.html { internal; } error_page 497 /index.html; location = /index.html { internal; # 只允许内部重定向访问 root /var/www; add_header Content-Type text/html; } }记得在对应的目录放置回落页面index.html和修改证书路径位置。以及在虚拟机安装宝塔面板后，拿宝塔面板的自签名证书文件和宝塔的回落页面放到你的服务器上做回落页面，让别人误以为你是个笨蛋在用宝塔（误）进行反代配置安装好Nginx后，我们就可以开始配置各种服务的反代配置了，只需要确保原始IP可以正常传递，并且后端服务支持使用传递的真实IP。Jellyfin这官方给了详细的Nginx反代配置模板，只需要稍加改动就可以正常使用。配置文件为/etc/nginx/conf.d/jellyfin-proxy.confserver { listen 8848 ssl http2; #IPV4 listen [::]:8848 ssl http2; #IPv6 server_name jellyfin.nekopara.uk; error_page 497 https://$host:8848$request_uri; ## The default `client_max_body_size` is 1M, this might not be enough for some posters, etc. client_max_body_size 32M; # Comment next line to al…

超可爱！FileBrowser 2.57.1 界面美化记录
type: item
date: 2026-02-12T16:08:13+08:00
description: 萌化FileBrowser随着FileBrowser的版本逐渐迭代到2.57.1，我发现我当初写的版本不少地方效果已经失效，于是我打算优化自定义的样式表代码来适配新版的FileBrowser。因为跨的版本比较大，改动也是比较大的，甚至这个个性化自定义配置都有不小的改变。于是我打算重新彻底优化一下。果然，事情总是动态发展的，上一版我调教的终极美化，这次要进行修补更新了。文件目录结构说明新版的filebrowser页面风格定制化style文件夹目录结构如下：[chocola@Neko-X99 linux-amd64-filebrowser]$ tree . ├── CHANGELOG.md ├── filebrowser ├── filebrowser.db ├── LICENSE ├── README.md └── style ├── custom.css ├── img │ ├── background.jpg │ ├── icons │ │ ├── android-chrome-192x192.png │ │ ├── android-chrome-512x512.png │ │ ├── apple-touch-icon.png │ │ ├── favicon.ico │ │ └── favicon.svg │ ├── JCuYuan.woff2 │ ├── login.jpg │ └── logo.svg ├── index.html └── manifest.json 4 directories, 17 filesfilebrowser相比于之前的版本，主要是图标数量进行了简化。而我这次的改进，有以下几点：使用了woff2格式的字体，减少页面加载流量和等待时间增加了提示框样式设置为文件预览添加了毛玻璃背景效果为新增的数值条增加样式适配优化弹窗背景，增加毛玻璃效果为文本编辑器添加半透明背景效果为新增的文件邮件菜单添加主题样式优化登陆界面信息提示的样式大概就这些吧，还有一些细枝末节的部分，我没有详细列出，有一些效果是因为代码改动牵一发动全身，修改反反复复搞了快一天，总之这个filebrowser主题改动不小。效果展示接下来我会用图片逐个展示修改后的效果。登陆界面：这个改动不算大，只是适配了一下新版的消息框。文件页面：适配了右键菜单的效果。文件选择效果（这部分没变）：下载弹窗背景毛玻璃模糊化：新建文件操作也是同理：优化后的文本编辑器样式：优化后的图片预览效果：对新的数字选择器进行样式适配：优化信息提示框：萌化方法萌化方法并不困难，只需要下载我准备好的style.zip压缩包，解压到filebrowser的目录后应用自定义样式就可以了，前文也有目录树说明了，详细操作可以去看这篇文章：个性化Filebrowser界面，NAS也要Kawaii~~~!唯一要注意的是需要下载FileBrowser的2.57.1版本，因为这版界面美化是针对这个版本写的。对于custom.css，我已经在不少位置都做了注释，想自己按需修改的话看注释照着改也不难。

使用Systemd代替Mcsmanager管理挂机服务
type: item
date: 2026-02-11T13:33:00+08:00
description: 使用Systemd托管挂机服务随着我对Linux系统的理解逐渐加深，外加上这一年来管理服务器越来越习惯命令行，我逐渐感觉我之前在家里云部署的Mcsmanager应用管理面板是多余的，因为Tmux和Systemd都可以做到，并且因为不需要运行一个nodejs，还更省资源。所以，我下定决心把服务迁移到Systemd。让Systemd以普通用户身份运行服务之前我使用Mcsmanager而不是Systemd的原因，就是觉得Systemd配置比较麻烦，并且默认以root身份运行服务，我感觉很不安全。于是进行多次配置后，用以下的配置文件启动了Mcsmanager：/etc/systemd/system/mcsm-web.service[Unit] Description=MCSManager Web [Service] WorkingDirectory=/opt/mcsmanager/web ExecStart=/usr/bin/node app.js ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" User=chocola [Install] WantedBy=multi-user.target /etc/systemd/system/mcsm-daemon.service[Unit] Description=MCSManager Daemon [Service] WorkingDirectory=/opt/mcsmanager/daemon ExecStart=/usr/bin/node app.js ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" User=chocola [Install] WantedBy=multi-user.target本来配置用的就是用户身份，我在想，为什么不直接就用Systemd以用户身份帮我挂着服务，这样既节省了性能，而且省去了Mcsmanager也可以减少潜在的攻击面。既然目前面板能这样运行，说明未来应用应该也可以。为应用设置Systemd配置文件在经历了QQ机器人封号，MC服务器没人玩，DDNS的工作实际上已经由路由器承担后，之前使用Mcsmanager挂着的服务就只剩下了这几个：两个Filebrowser文件管理，Jellyfin媒体服务器，以及偶尔需要启动的qBittorrent。除此之外，其他服务都是长期关闭的状态，这也为我做出转变提供了契机。并且使用Systemd管理服务还有一个优势：可以让应用隔离开敏感数据，即使应用本身存在漏洞沦陷了，也不会影响到核心的敏感数据，这点是Mcsmanager给不了的。那，接下来我们来进行配置吧！Filebrowser因为这个服务算是我这个家里云最核心的服务了，也就是对应的自建NAS服务，所以我把程序本体迁移到了/opt目录下，并且做好隔离。实际上有两个Filebrowser实例，一个是管理一般文件，一个是管理重要文件，是分开的。/etc/systemd/system/filebrowser.service这个配置文件对应的是管理一般文件的实例：[Unit] Description=Filebrowser01 [Service] WorkingDirectory=/opt/filebrowser ExecStart=/opt/filebrowser/filebrowser ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" User=chocola Group=chocola # 严格沙盒 ProtectSystem=strict ProtectHome=tmpfs NoNewPrivileges=true ReadWritePaths=/opt/filebrowser/ ReadWritePaths=/home/chocola/data/files/ # 显式禁止访问核心敏感路径 Inaccessibl…

【日常】并夕夕购入巧克力手办日记
type: item
date: 2026-02-06T15:07:17+08:00
description: 在并夕夕购入猫娘乐园巧克力手办偶然的机会，刷并夕夕的时候，我发现了一个无盒的巧克力手办，原价200多，我看到的时候，只需要90。说是微瑕，但是保证是正版的手办，我当时买的时候大意了，没细看商品图，啪一下就下单了。结果到货后，发现少了头发一边的丝带。。。《微瑕》，嗯，《微瑕》（不过除此之外，好像真没什么问题，整体挺好的，确实是正品的手办，细节没什么大问题。果然，价格腰斩是有原因的（贴几张图吧！