GTX690战术核显卡导弹 - Web
type: channel
link: https://www.nekopara.uk/category/Web/
description: Web
items: MediaPages：一键在Cloudflare Pages存放媒体库
items: 【开发】NekoIPinfo：基于GO语言的高性能IP查询服务端
items: 家里云服务优化：统一Web服务端口，减小攻击面
items: 超可爱！FileBrowser 2.57.1 界面美化记录
items: 主题开发日志03：在Manjaro上搭建Nginx+PHP环境
items: 主题开发日志02：前端界面开发基本完成
items: 主题开发日志01：优化NekoWebShow加载速度
items: 阿里云 ESA 回源 IP 段分享，可用于源站保护
items: 调用API实现Typecho博客VisitorLoggerPro插件IP信息更新
items: V100 GPU 初体验：AlmaLinux 8.10 快速部署 ComfyUI

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…

家里云服务优化：统一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，我已经在不少位置都做了注释，想自己按需修改的话看注释照着改也不难。

主题开发日志03：在Manjaro上搭建Nginx+PHP环境
type: item
date: 2026-01-26T13:38:10+08:00
description: 在Manjaro Linux上部署Typecho开发环境因为后面主题的开发就需要实时修改php文件查看效果了，为了方便开发，我决定在自己的电脑上面设置一个基本的Nginx+PHP环境。对于数据库就使用sqlite好了，只是为了搭建一个本地的typecho作为测试平台。在配置期间踩了几个坑，记录一下。软件的安装非常简单，一条命令梭哈：pacman -S nginx php php-fpm php-sqlite php-gd配置软件因为manjaro和其他发行版不太一样，并且我需要这个web服务器以我的用户权限进行运行，方便我更新文件，所以我们需要做出一些更改。php.ini首先是php的配置文件，文件位于/etc/php/php.ini找到下面的部分进修改：上传大小限制：upload_max_filesize = 2M改为upload_max_filesize = 16M然后启用必要的模块，找到以下部分取消注释：extension=curl extension=gd extension=gettext extension=pdo_sqlitewww.conf然后是php的另一个配置文件，让php-fpm以用户身份运行，文件位于/etc/php/php-fpm.d/www.conf找到下面的部分进修改：user = chocola ; <--- 修改这里 group = chocola ; <--- 修改这里 listen.owner = chocola ; <--- 修改这里，确保 Nginx 能和 PHP 通讯 listen.group = chocola ; <--- 修改这里nginx.conf将Nginx的配置文件修改为如下所示： user chocola; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; # Load all installed modules include modules.d/*.conf; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; gzip on; server { listen 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; root /run/media/chocola/DATA/wwwroot; index index.php index.html index.htm; #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ .*\.php(\/.*)*$ { # 你的网站根目录 (如果 server 块里已经写了 root，这行可以省略，但加上保险) root /run/media/chocola/DATA/wwwroot; fastcgi_pass unix:/run/ph…

主题开发日志02：前端界面开发基本完成
type: item
date: 2026-01-24T12:26:14+08:00
description: 博客主题前端界面开发工作基本完成经过一个多星期与Gemini 3 Pro的反复拉扯，终于是把主要的三个部分样式做完了：首页+文章列表+独立页面，文章阅读页面，后台管理页面。感觉还是相当不错的！因为还没开发完成，我这里只放截图。文章首页效果对，没错，我将会把动态立绘放在首页！不过因为立绘很吃性能，所以我特地做了优化，当不在首页浏览时，立绘渲染会暂停节省性能。文章列表效果独立页面效果文章页面效果细心的同学应该已经发现了，对话框是贯穿始终的，而且还是nekopara的风格。没错！对话框将会是主题的一大特色，作用相当于网站的导航栏，同时也会在特定的按钮和链接给出相关的提示，让你感觉像是在玩galgame!后台效果后台页面就完全按照nekopara的设置界面风格来制作了。目前主题的前端开发工作做的差不多了，接下来就是怎么缝合到typecho上面了。

主题开发日志01：优化NekoWebShow加载速度
type: item
date: 2026-01-14T20:43:24+08:00
description: 给NekoWebShow加载提速为期三个月的实习结束了，准备迎来寒假了，我在想要不要做一些有意思的事情。受到Bhao小姐姐博客的启发，我萌生了想要重新装修博客的想法，主题也很明确——猫娘乐园主题。但是，如果还是像我现在这样，用别人的主题改一改，个性化一下，或许还是太没意思了。于是乎，我就想看看能不能自己从零开始做一个主题。真正驱动我做这件事的，是半年前我搞出来了那个NekoWebShow项目，我希望把巧克力的动态立绘直接放在博客首页，只有首页有这种持续的动画效果，其他页面就是静态展示，这样子的话就不会像现在那样打开我的网站后一直占用性能。我希望可以做到只在首页占用一些性能展示动态立绘，而往下浏览查看其他内容的时候，就没有活动的元素了。一方面可以凸显重点，保持整套主题风格的连贯性，另一方面节省访客电脑的性能。当时还是有点犹豫要不要搞，在Bhao小姐姐的群里问了一下，她坚定地回了一个字——“做！”她随后说其实用框架的话就和搭积木差不多，不是很难，于是我下定决心，开干。而今天完成的工作则算是这个主题正式开工之前的前置工作——优化NekoWebShow加载速度为什么需要优化尽管目前的猫娘展示网页运行正常，但是由于模型文件较大，达到了32MB或者64MB，会导致较长的加载时间，如果网速慢那更是雪上加霜。对于纯粹的猫娘展示网页还是可以接受，但是对于个人博客那就是致命的——访客可能会嫌打开太久离开。所以说，这个是必须要优化的。还有一点是，虽然这些专有格式体积庞大，但是转换前的文件却不算大——3-4MB左右的png纹理文件+3MB左右的json定义文件，很明显应该是有办法可以压缩下来的。优化传输的探索——碰壁asm.js一开始，我是希望逆向JS，顺着模型文件的传输路径去找到对应的处理代码，然后求助于AI解决。但是，可悲的是，我千辛万苦挖了半个小时，结果挖出来一段奇怪的js代码，例如：// EMSCRIPTEN_END_FUNCS var vd=[uB,Be,Ke,Fp,Iz,Pz,fA,uB];var wd=[vB,$e,df,ff,hf,eg,jg,lg];var xd=[wB,re,te,Ee,Fe,Qe,Re,We,Xe,Lf,bg,cg,dg,gg,wv,xg,Ji,Gp,yg,zg,Ne,Ag,Iu,Cg,Ki,Dg,Np,Hg,Qp,Rp,Li,an,bn,un,vn,Ln,Mn,Sn,Tn,bo,co,jo,ko,Co,Do,Xo,Yo,lp,mp,vp,wp,hz,Dp,Ep,Op,Ju,xv,Ew,Fw,Cz,Dz,Ez,Fz,Nz,Xz,Yz,$z,bA,dA,ly,Tz,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB,wB];var yd=[xB,ch];var zd=[yB,we,ye,Ce,Ge,He,Ie,Ve,Ze,bf,uf,Xf,hg,ng,zv,Ip];var Ad=[zB,Xg,vi,zB];var Bd=[AB,ue,ve,vg,xe,ze,De,Se,Te,wg,Ue,Ye,_e,cf,rf,vf,xf,Mf,Of,Qf,ag,fg,ig,og,pg,rg,Hp,gz,gy,Zz,sh,th,uh,Qg,oh,qh,Jh,Ch,Dh,Fh,Eh,xi,ci,zi,yh,xh,Bh,Bi,zh,_h,$h,wh,AB,AB,AB,AB,AB,AB,AB,AB,AB,AB,AB,AB];var Cd=[BB,jh];var Dd=[CB,Yf];var Ed=[DB,hi];var Fd=[EB,qf,_f,$f];var Gd=[FB,gi];var Hd=[GB,Gf];var Id=[HB,mf,of,sf,If,HB,HB,HB];var Jd=[IB,bh];var Kd=[JB,fh,wi,JB];var Ld=[KB,ih];var Md=[LB,Af,Eg,Mi,hy,iy,ny,Ny,Gz,aA,cA,Ng,Rg,Yg,Zg,_g,di,ah,Wh,LB,LB,LB,LB,LB,LB,LB,LB,LB,LB,LB,LB,LB];var Nd=[MB,ui];var Od=[NB,Wg,li,NB];var Pd=[OB,Hz,Oz,eA];var Qd=[PB,Hh,Ih,PB];var Rd=[QB,Je,lf,Vf,Bg,Pp,QB,QB];var Sd=[RB,Kf];var Td=[SB,af,e…

阿里云 ESA 回源 IP 段分享，可用于源站保护
type: item
date: 2025-12-18T17:04:00+08:00
description: 分享阿里云 ESA 回源 IP 段因为阿里云的源站防护功能，在免费版用不了，而我需要在源站设置访问白名单，于是就需要找一份阿里云 ESA 回源 IP 段列表。Cloudflare和EdgeOne都是公开回源IP段的，同样是属于CDN的ESA居然不公开，有点离谱，不过看样子应该是想作为增值服务，付费才能开源站保护（）好巧不巧，这段时间基础版ESA都可以免费领取一个月，而基础版ESA是可以开启源站保护的，所以自然也就拿到了回源的IP段列表。虽然文档说这是收敛后的IP段列表，但是得到的回源IP估摸着大概有1700+个，而且我和群友交叉验证过，得到的IP段是一模一样的。应该是收敛之前的完整IP段。估计可能的原因是我没有添加任何要加速的子域名，直接先开源站保护，导致返回了全量的IP段——这是好事啊！连统计和汇总都省了。（后记补充：打脸了，后面进一步测试后发现，免费版和基础版回源IP段是分开的，不用白费力气了）现在我就分享出来，给需要的站长参考。IP段可以用来设置源服务器的访问白名单，避免源服务器被扫描。具体如何使用，懂得人自然会懂，如果不知道的话，可以看一下这篇文章：绕过黑洞！利用VPC内网互通低成本实现DDoS攻击下网站高可用中的代理服务器安全组设置（可选）这一小节。请注意，文中获取到的IP段很有可能是有时效性的，不保证未来可用！获取的时间为2025年12月18日，如果时间过去的太久，需要使用请先验证！测试后补充：免费版和基础版回源IP段是分开的，所以想白嫖源站保护是不太可能的，后续也不要白费力气了。这篇文章就当作教训挂在这里了。全部 IPv4 回源 IP 段39.96.151.128/25 111.13.222.128/25 111.206.190.0/25 49.7.41.128/25 111.7.71.0/25 117.49.24.96/27 183.131.47.64/26 117.49.26.96/27 27.128.150.128/25 222.138.192.0/25 111.63.174.128/25 123.149.174.0/25 39.173.24.0/26 117.49.24.128/26 117.49.173.192/26 117.49.26.128/26 101.69.215.128/26 163.181.67.128/25 175.4.42.0/25 183.215.56.0/25 116.163.14.128/25 157.255.137.128/25 117.49.181.0/25 183.60.170.128/25 120.241.64.0/25 8.147.217.48/29 8.147.217.32/28 114.250.55.64/26 106.38.245.128/26 221.179.212.0/26 8.147.217.0/27 163.181.122.128/25 36.156.79.0/25 183.136.179.64/26 120.222.205.128/25 60.188.139.0/26 163.181.15.128/25 120.241.14.64/26 112.90.140.64/26 120.241.13.128/26 163.181.89.128/25 61.241.9.128/25 124.95.162.128/25 222.141.35.128/25 42.96.222.128/25 117.49.152.64/26 106.38.189.128/25 117.49.153.0/25 39.156.171.128/25 111.7.83.128/25 219.144.87.0/25 117.49.3.128/26 8.152.80.0/25 114.232.93.0/25 150.139.146.128/25 123.126.111.128/25 140.249.255.128/25 39.173.42.128/25 59.36.91.0/26 120.222.200.128/25 111.19.142.0/25 113.201.176.0/25 122.193.247.0/25 183.36.45.64/26 139.129.78.0/25 183.240.195.128/25 117.49.179.0/25 36.99.21.0/25 27.221.6.128/25 42.248.141.128/25 124.160.142.128/26 112.17.15.224/27 115.238.4.128/25 8.147.211.128/25 101.67.60.128/25 58.251.89.64/26 120.201.61.128/25 112.13.103…

调用API实现Typecho博客VisitorLoggerPro插件IP信息更新
type: item
date: 2025-12-17T23:30:06+08:00
description: 利用B站IP查询API更新访客记录IP地理信息偶然的一次机会，在群里面聊天的时候，群友指出纯真数据库的数据并不准确，并且说有一个可以免费调用的IP地理信息库——B站的IP查询API。据说还是用的ipip.net的企业版，这下得狠狠白嫖了。前置任务：修复VisitorLoggerPro插件BUG如果使用过这个插件一段时间，你就应该发现了，在国家统计图表这项，非常的混乱，似乎是只要记录的字符不一致，就会被当作不同的国家处理，例如美国加利福尼亚洛杉矶和美国纽约就被当作不同的国家列在上面。经过深挖代码斗智斗勇，我发现这个问题我无法从根本解决，因为整个代码太奇怪了，而且用的本地IP数据库也都是乱七八糟的，根本没有做好国家的细分地区分类，一股脑返回，导致所有的信息被集中在一起写进了国家字段。于是，我放弃治疗，直接在后面的调用代码中，增加分类逻辑进行分类：这是原来的代码，单独处理和提取了国内省份： foreach ($countryCountsResult as $row) { $countryName = $row['country'] ?: '未知'; $count = $row['count']; if (!isset($countryData[$countryName])) { $countryData[$countryName] = 0; $totalCountries++; } $countryData[$countryName] += $count; if (strpos($countryName, '中国') !== false) { foreach ($provinces as $province) { if (strpos($countryName, $province) !== false) { if (!isset($provinceData[$province])) { $provinceData[$province] = 0; } $provinceData[$province] += $count; break; } } } }我决定在返回国家信息的时候，进行提取合并并返回： foreach ($countryCountsResult as $row) { $rawCountry = $row['country'] ?? ''; $count = (int)($row['count'] ?? 0); if ($rawCountry === '') { $stdCountry = '未知'; } elseif (strpos($rawCountry, '中国') !== false) { // 所有含“中国”的都归为“中国” $stdCountry = '中国'; // 同时尝试提取省份 foreach ($provinces as $province) { if (strpos($rawCountry, $province) !== false) { if (!isset($provinceData[$province])) { $provinceData[$province] = 0; } $provinceData[$province] += $count; break; // 匹配到第一个即停止 } } } else { // 非中国：尝试匹配标准国家名（用于归一化，如“美国加州”→“美国”） $stdCountry = $rawCountry; // 默认保留原值 foreach ($countries as $country) { if (strpos($rawCountry, $country) !== false) { $stdCountry = $country; break; // 匹配到即停止（因列表已按长优先排序） } } } // 累计国家统计 if (!isset($countryData[$stdCountry])) { $countryData[$stdCountry] = 0; $totalCountries++; } $countryData[$stdCountry] += $count; }当然了，需要补上完整的国家地区列表： $countries = [ // 长名称国家（必须放前面） '波斯尼亚和黑塞哥维那', '赤道几内亚', '圣文森特和格林纳丁斯', '特立尼达和多巴哥', '圣多美和普林西比', '阿拉伯联合酋长国', '沙特阿拉伯', '巴布亚新几内亚', '所罗门群岛', '马绍尔群岛', '密克罗尼西亚联邦', '帕劳共和国', '瓦努阿图共和国', '基里巴斯共和国', '瑙鲁共和国', '图瓦卢', '美属萨摩亚', '英属维尔京群岛', '美属维尔京群…

V100 GPU 初体验：AlmaLinux 8.10 快速部署 ComfyUI
type: item
date: 2025-12-05T23:21:00+08:00
description: 在 AlmaLinux 8.10 上部署 ComfyUI最近买了一张 V100，为了爽玩 AI 绘图，我单独组装了一台 X99 平台主机来运行 ComfyUI。操作系统方面，我选择了 AlmaLinux 8.10，看中的是其稳定性以及对多版本 Python 的良好支持。硬件介绍显卡本体Tesla V100 显卡展示（和RTX2080Ti同框）：安装到转接板上：转接板是200买的，虽然比最便宜的99元转接板贵了一倍，但用的是原装座子，原装座子的转接板就算是10X10CM的小板子都170+了。我加多30，买个带温控的，尺寸大一点的板，还自带螺栓孔位固定，完美安装，他不香吗？装上散热器后的样子：我为了尽可能降低温度，延长使用寿命，买了最大的散热器，到手发现确实巨大无比，比想象中的要大得多。但是其实现在看，买小一号的9CM高度的可能更合适，因为更好安装8CM风扇，不会浪费散热面积。我最后还是选择了8CM的风扇来散热，放弃了之前使用12CM风扇的想法——因为没办法彻底吹透散热器，温度还高。装上风扇Be Like:因为两边会漏风，导致无法彻底吹透散热器，所以搞了一张纸包了一下，迫使气流贯穿散热器。配套硬件平台开头我先说一下我踩到的坑，首先平台选择就先栽了一头：一开始我想用我闲置的H61平台来带这个玩意，而且也确认看过那个主板有Above 4G Decoding选项，也打开了，但是就是死活没办法驱动这个显卡，系统识别到了这个设备，但是NVIDIA驱动无法初始化设备，导致无法使用。这个问题折磨了我很久，检查日志具体表现是：[root@Neko-P104 ~]# dmesg | tail -100 | grep -i -E 'nvidia|nvrm|gpu|bar' [ 3.121900] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: NVRM: BAR4 is 0M @ 0x0 (PCI:0000:01:00.0) [ 3.121902] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: NVRM: BAR5 is 0M @ 0x0 (PCI:0000:01:00.0) [ 3.322080] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 580.105.08 Tue Apr 8 12:41:17 UTC 2025 [ 3.369648] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 580.105.08 Tue Apr 8 12:09:34 UTC 2025 [ 3.376189] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver [ 3.376192] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 0 [ 112.149308] caller _nv041720rm+0x3a/0xb0 [nvidia] mapping multiple BARs [ 112.163383] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x24:0x72:1568) [ 112.163415] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0 [ 112.285687] nvidia-uvm: Loaded the UVM driver, major device number 237. [ 379.801748] caller _nv041720rm+0x3a/0xb0 [nvidia] mapping multiple BARs [ 379.815873] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x24:0x72:1568) [ 379.815912] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0这表明：BAR 分配失败：GPU 的某些地址空间没有正确映射到系统内存中。RmInitAdapter 失败：驱动尝试初始化 GPU 时遇到了错误，无法完成初始化。所以这是平台限制，必须换平台了。后…