Technology on Shiro

修复Nginx反代飞牛相册卡顿、视频无法加载

Mon, 08 Dec 2025 18:53:00 +0000

问题分析

最近在使用飞牛的时候遇到了一个很奇怪的问题，通过域名可以正常进入飞牛首页，文件管理也正常，但是一旦访问飞牛相册，只有一开始加载正常，稍微刷一下瀑布流加载就会卡住，F12 打开控制台发现很多请求卡在了Pending。

一开始以为是服务器性能跟不上，预览图没来得及生成，但是想了想也不对，普通的相册列表请求不应该卡成这个样子，于是我绕过 Nginx 通过 Tailscale 直接访问飞牛，这时候相册加载就是正常的，同时我发现飞牛相册的请求量非常大，那么既然直接访问没问题，那问题就出在公网服务器上的反代配置了。

下面是博主简化后的网络架构。

解决问题

解决相册加载卡顿

Nginx 在进行反向代理时，默认使用HTTP/1.0协议连接后端服务器，并发送Connection: close头。这意味着 Nginx 与 NAS 之间无法复用 TCP 连接，导致大量 TIME_WAIT 状态和握手开销。不仅仅是浏览器端的限制，Nginx 到后端也是瓶颈。

解决办法：

清空Connection头，强制长连接

1
2
3
4


map $http_upgrade $connection_upgrade {
 default upgrade; # 如果是 WebSocket 请求，Connection 值为 upgrade
 '' ''; # 如果是普通请求，Connection 值为空（保留 HTTP/1.1 默认的 keep-alive）
}

设置长连接池

1
2
3
4
5
6
7


upstream backend {
 # 替换为你的飞牛 IP:端口
 server 192.168.x.x:5666;

 # 核心配置：保持与后端的长连接数量，减少 TCP 握手开销
 keepalive 64;
}

在反代中添加配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


location / {
 proxy_pass http://backend;

 # 强制使用 HTTP/1.1 并清除 Connection 头，从而激活长连接
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;

 # 优化：上传/下载不启用 Nginx 缓冲，直接转发数据
 proxy_request_buffering off;
 proxy_buffering off;
}

按照以上设置即可解决Nginx反代飞牛相册后瀑布流加载卡住的问题。

解决视频无法加载

视频播放卡住无法点播通常是忘记了配置 Nginx 当中的Range。如果反代不传递Range，后端会发送整个文件，反代服务器会尝试把整个文件缓存下来再发给客户端，这就会导致看起来无法加载。

💡 Tip

Nginx中的Range（范围）请求是HTTP协议允许客户端（如浏览器、下载器）指定只获取文件的一部分内容，主要用于实现断点续传、多线程下载、视频流媒体、实现视频播放进度条等功能；当服务器支持Range请求时，会在响应头中包含Accept-Ranges:bytes，Nginx通过处理客户端的Range头部来发送指定字节范围数据，并返回206 Partial Content状态码。

所以在反代部分中加入Range即可（非完整配置）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


location / {
 # ...其他配置...

 # 支持视频流拖拽与断点续传
 proxy_set_header Range $http_range;
 proxy_set_header If-Range $http_if_range;

 # 关闭缓冲，让数据流实时通过
 proxy_request_buffering off;
 proxy_buffering off;
}

完整配置参考

下面是基于修改后的完整 Nginx 配置，博主已经测试，欢迎评论区反馈。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


# WebSocket和长连接配置
map $http_upgrade $connection_upgrade {
 default upgrade;
 '' '';
}

# 后端服务器配置
upstream backend {
 # 替换为你的飞牛IP:端口（因为我流量全程在隧道，所以这里默认http）
 server 192.168.x.x:5666;

 keepalive 64;
}

server {
 listen 80;
 listen [::]:80;
 server_name example.com; # 替换为你的域名
 
 # HTTP 自动跳转 HTTPS
 return 301 https://$server_name$request_uri;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name example.com; # 替换为你的域名
 
 # ========== SSL 证书配置 ==========
 ssl_certificate /path/to/fullchain.pem; # 替换证书路径
 ssl_certificate_key /path/to/privkey.pem; # 替换密钥路径
 
 # SSL 安全配置
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 10m;
 
 # ========== 反向代理配置 ==========
 location / {
 proxy_pass http://backend;
 
 # 传递客户端真实信息
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 
 # http1.1提供长连接和WebSocket支持
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 
 # 视频流支持 (解决视频无法点播的问题)
 proxy_set_header Range $http_range;
 proxy_set_header If-Range $http_if_range;
 
 # 大文件上传/下载优化
 proxy_request_buffering off; # 上传不缓冲
 proxy_buffering off; # 下载不缓冲
 
 # 超时配置
 proxy_connect_timeout 600s;
 proxy_send_timeout 600s;
 proxy_read_timeout 600s;
 
 # 上传大小限制 (0为无限)
 client_max_body_size 0;
 }
}

低功耗家里云升级记

Wed, 22 Jan 2025 17:37:00 +0000

缘由

↑上图是博主家里云早期形态，咱自己知道很抽象，就别吐槽了（QAQ）

在最近一次断电后，家里的老服务器便未能再次成功启动。此前家里的软路由、HA和咱自用的容器服务器等设施都运行在这上面。于是购置一台新的服务器就成了需要马上解决的问题。

老服务器是博主在高中的时候用可怜的预算组的，由一块退役X8DTL-3F主板搭配双路X5680和混插的32G内存组成，硬盘在后期也只有一块英睿达MX500，电源在搬出准系统后用的是一款捡废品的不知名老电源，待机功耗达到了相当恐怖的100-110w。（一年下来电费都够买一台全新的服务器了）

有了之前的经验，这次选购新平台的时候博主就非常注重能耗问题，毕竟博主身处19线小县城，当地私人电力公司从国网购电后再销售给当地居民，电价>0.6/度。可惜当前arm洋垃圾价格仍然不够便宜，在群友的建议下，咱准备从d1581和d-2143it中选择一套。

采购

板U + 内存

逛了两天咸鱼后博主选择了火神革命D-1581 Q3板U套装，虽然知道寨板问题挺多的，但是它胜在便宜啊。主板+U套装咸鱼二手只要300出头，而且还有2.5G网口x2，并且D-1581拥有16核32线程，采用14nm工艺，TDP仅仅只有65w，相比之前老平台上单颗130w的X5680能耗不知道甩了几条街，完美符合咱对家里云的想象。

内存是咸鱼卖家一起打包出售的4根16GB DDR3L低压1666Mhz三星内存条。

::: grid {cols=2,rows=1,type=images} :::

硬盘

硬盘方面系统盘依旧使用原有的英睿达MX500，在此基础上咱又从淘宝店家“上海浦东服务器”购买了一块店保1年的6TB SAS盘作为数据写入盘。

::: grid {cols=2,rows=1,type=images}

:::

电源&机箱

一开始咱用的老服务器上捡垃圾来的杂牌电源，结果加上新硬盘后硬盘供电线不够了，索性直接把家里闲置的直出线长城电源换上了。机箱也是用的之前买的航嘉￥99机箱。

部署

拆掉旧主板，然后水洗散热器里的灰尘，不停歇的跑了整整两三年还是积了不少灰。

::: grid {cols=2,rows=1,type=images} :::

寨板内存问题

安装散热器到新主板测试一次点亮进入BIOS，但是一进入Ventoy引导的WinPE就死机重启，数显管故障码42。插上原来的系统盘进入PVE系统的时候也出现了问题，在启动过程中PVE会卡死机在Loading initial ramdisk，重启后问题稳定复现。

通过在网上对这块寨板的搜索，最终在v2ex论坛找到一个有用的答复。

V2EX › 问与答 https://www.v2ex.com/t/908551#; zeze0556 2023-01-13 16:29:59 +08:00 @xuxuxu123 我目前在用的是这个方案。感觉不稳定。头一次，vmware 中开鲁大师跑分，到 cpu 测试的某一项，3/10 的概率整台电脑（不是单独虚拟机）定屏死机。后来换了主板，就是目前在用的，vmware 中跑鲁大师无问题了，然后发现，有时候正常关机后，再次开机鼠标+键盘可能就失效了（连电都不供的那种），重启无效，除非把电源断开 10 秒以上，然后开机就又回来了，这个问题只是一个使用麻烦的问题，另外一个问题就实在太无语了，我内存加满到 4x16G,有时候几天都不出问题，有时候突然来个定屏死机，不频繁+我自己太忙，就先凑活着。前几天稍闲，决定看看到底是什么问题，根据 windows 的日志，有很多内存相关的错误，但定屏死机没有错误日志，这个真的靠猜测了。联系客服，反馈内存问题，然后沟通测试单条，看是否内存的问题。这两天我晚上一回家就测试，一个晚上多加一根内存，目前测试到第三根内存，结果都没有出现死机。但昨天完场发现另外一个问题，==四个内存槽，从 cpu 侧往电源侧数，1-3 内存槽，如果插了的话，电脑开机就是黑的，连 bios 自检画面都不出来，如果隔开第 3 个内存槽，则正常开机。==但目前还没发现死机，因为死机无规律，只能看运气。理论上将，可能 4 根内存插上也可以开机，毕竟之前就这么用的，只是会死机。目前过年要回老家了，注定要年后去骚扰客服了。

博主按照这位网页的插法去掉一根内存果然顺利进入系统，并且后续测试稳定不死机，不过这样很可惜的就是白白浪费掉一根内存条，总内存从64G下降到48G，心里在滴血。

随后装入机箱，并加装SAS直通卡和硬盘，通过显示器上的终端修改PVE网卡绑定。

::: grid {cols=2,rows=1,type=images} :::

内存问题分析

博主咨询了卖家此前的运行情况，了解到原主人安装ESXI 8U3的时候内存插满运行正常，也就是说这块板子一开始是正常的，同时网上另一家D-1581主板厂子（米多贝克）的主板不存在内存插满死机问题，因此也可以排除设计缺陷。

博主猜测由于主板走线设计问题，内存插槽可能在运输途中受损所以出现了工作不稳定的情况。

测试

来电自启测试

好在该寨板本就为AIO（All in one，all in boom）设计，所以板载了来电开机跳线，经过几次人为意外断电测试，机器均能稳定启动并进入PVE。

为了避免以外发生，咱又在咸鱼购入一台Pikvm（基于onekvm的ipmi系统，能通过网络远程控制主机，可连接被控显示器输出和鼠标输入，并模拟usb设备插入和控制开机重启跳线），目前已经下单在途还未收到货。

Geekbench 6测试

测试结果：https://browser.geekbench.com/v6/cpu/10055850

被测主机信息：

单核&多核测试结果：

::: grid {cols=2,rows=1,type=images} :::

单核可以说是惨不忍睹，但是家里云这种场景来说，完全够用了。希望这台机器能够稳定使用5个年头吧，到时候估计就能玩上arm洋垃圾了。

完结撒花，感谢阅读🌸

Nginx单端口HTTP自动跳转HTTPS

Fri, 06 Dec 2024 21:04:00 +0000

场景分析

通常情况下，HTTP 和 HTTPS 无法共用同一个端口，因为两者使用不同的协议，无法在同一端口上完成握手通信，除非 Web 服务器能够根据协议类型进行智能分流。然而，为了提升用户体验，我们应该实现当用户使用 HTTP 协议访问网站时，自动跳转到 HTTPS 协议。例如，当用户访问 http://192.168.1.1:2233 时，服务器自动重定向到 https://192.168.1.1:2233。

PS：起初我认为 Nginx 是做不到的，需要基于 HAProxy 实现协议分流，但实际情况是，Nginx 已经内置支持了，只需要我们合理利用 Nginx 的 497 错误响应。

常见的一些平台，例如 Proxmox VE (PVE)、 VMware ESXi Web Client都采用了单端口跳转机制，既确保了管理界面的安全性，又提供了无需手动输入协议头的良好用户体验。

效果如下：

实验测试

为了验证上述场景，基于 Nginx 配置一个纯 HTTPS 网站，并使用curl工具分别通过 HTTP 和 HTTPS 协议进行请求。

初始配置（未配置 `error_page 497`）

Nginx 配置文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


server {
 listen 2233 ssl;
 server_name 192.168.1.1;

 ssl_certificate /path/to/cert.pem;
 ssl_certificate_key /path/to/key.pem;

 location / {
 root /var/www/html;
 index index.html;
 }
}

测试结果

HTTP 请求

使用curl发送 HTTP 请求：
1

curl -v http://192.168.1.1:2233
服务器响应：
1

HTTP/1.1 400 Bad Request
说明：由于未配置 HTTP 处理，Nginx 在接收到 HTTP 请求时返回了 400 错误。
HTTPS 请求

使用curl发送 HTTPS 请求：
1

curl -v https://192.168.1.1:2233
服务器正常响应网站内容。

配置 `error_page 497` 实现自动重定向

为了实现 HTTP 请求自动重定向到 HTTPS，我们需要配置 Nginx 处理错误码 497，并返回 302 重定向。

修改后的 Nginx 配置文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


server {
 listen 2233 ssl;
 server_name 192.168.1.1;

 ssl_certificate /path/to/cert.pem;
 ssl_certificate_key /path/to/key.pem;

 location / {
 root /var/www/html;
 index index.html;
 }

 # 捕获HTTP请求发送到HTTPS端口的错误497，并重定向到HTTPS
 error_page 497 = @redirect_to_https;

 location @redirect_to_https {
 return 302 https://$host:$server_port$request_uri;
 }
}

测试结果

HTTP 请求

使用curl发送 HTTP 请求：
1

curl -v http://192.168.1.1:2233
服务器响应：
1 2

HTTP/1.1 302 Found Location: https://192.168.1.1:2233/
说明：配置error_page 497后，Nginx 检测到 HTTP 请求发送到 HTTPS 端口，返回了 302 重定向，自动将请求引导至 HTTPS。
HTTPS 请求

使用curl发送 HTTPS 请求：
1

curl -v https://192.168.1.1:2233
服务器正常响应网站内容。

利用 497 响应

1. 什么是 HTTP 状态码 497？

HTTP 状态码 497，“HTTP 请求发送到 HTTPS 端口”，是 Nginx 特有的错误代码。当客户端尝试使用 HTTP 协议连接到预期为 HTTPS 的端口时，Nginx 会返回此错误。此错误表示协议不匹配，服务器拒绝了该请求。

理解 497 错误有助于诊断协议不匹配的问题，并确保 Nginx 正确配置和强制执行 HTTPS 连接。

2. 497 错误码的常见原因

URL 协议错误：客户端使用 HTTP 而非 HTTPS 协议，可能由于书签过时或链接错误导致。
服务器配置问题：服务器在特定端口上配置为处理 HTTPS 请求，但误收到 HTTP 请求。
手动输入错误：用户在手动输入 URL 时，忘记添加“https://”，默认使用“http://”导致协议不匹配。

结论

通过上述配置，当用户通过 HTTP 协议访问 http://192.168.1.1:2233 时，Nginx 服务器会响应一个 302 重定向，将用户自动引导至 https://192.168.1.1:2233。这种配置不仅提升了安全性，确保所有通信都通过加密的 HTTPS 进行，还优化了用户体验，避免了因协议不匹配而产生的错误。

参考资料

1. Understanding and Steps to Resolve the 497 Error Code

Technology on Shiro

修复Nginx反代飞牛相册卡顿、视频无法加载

问题分析

解决问题

解决相册加载卡顿

解决视频无法加载

完整配置参考

低功耗家里云升级记

缘由

采购

板U + 内存

硬盘

电源&机箱

部署

寨板内存问题

内存问题分析

测试

来电自启测试

Geekbench 6测试

Nginx单端口HTTP自动跳转HTTPS

场景分析

实验测试

初始配置（未配置 error_page 497）

Nginx 配置文件

测试结果

配置 error_page 497 实现自动重定向

修改后的 Nginx 配置文件

测试结果

利用 497 响应

1. 什么是 HTTP 状态码 497？

2. 497 错误码的常见原因

结论

参考资料

初始配置（未配置 `error_page 497`）

配置 `error_page 497` 实现自动重定向