本文最后更新于 超过 1 年前，文中所描述的信息可能已发生改变。
我在洛杉矶的VPS上搭建了Emby，并通过伦敦CN2上的OpenResty反代实现国内加速。但是在播放视频时，遇到了加载速度从正常的10-20mb/s降至40-50kb/s的问题。具体表现为：开始播放电影时，加载速度正常，但经过1-2分钟后，速度会降至40-50kb/s。除非手动打断连接，否则速度将一直保持在低速。
为了解决这个问题，我进行了以下分析：
在本文中，Emby服务器简称为A，用于反向代理的CN2 VPS简称为B。
1. A和B的网络连接是否通畅？
由于A和B之间的距离较远，我首先怀疑网络连接是否通畅。经过简单的pierf3测试，确认A和B之间的最低速度也能稳定在500Mbps左右。
2. CN2的性能是否达标？
在晚高峰时段进行速度测试，结果显示速度仍能维持在100Mbps以上，排除了CN2的问题。
3. Nginx配置文件是否存在问题？
为了改善视频拖动的播放体验，我先前使用了nginx slice，并参考了相关教程。但经过排查，发现slice并非导致播放速度缓慢的原因。然而，删除slice后，刚开始的加载速度的确由之前4MB/s左右提升至10Mb/s以上，但主要问题仍未解决。因此，我删除了自己的配置文件，并尝试了从网上复制一份新的配置文件，但问题依旧存在。
经过观察发现，几乎每次问题出现都是在60秒左右，而nginx配置文件中有一行keepalive_timeout 65;与长连接相关。柄着不知道是什么 不瞎改的原则，我去问了问chatGPT，回答如下：
这行配置是指定在HTTP长连接中，服务器和客户端之间的保持活动状态（keep-alive）的超时时间。在Nginx配置中，keepalive_timeout用于控制服务器在客户端请求完成后保持打开的连接的时间。
具体来说，当一个客户端向Nginx服务器发送一个HTTP请求，并且在请求处理完成后，服务器可以选择保持连接打开以便后续的请求复用同一个连接。这种保持连接的机制称为HTTP keep-alive，它有助于减少连接建立和断开的开销，并提高性能。
keepalive_timeout指定了服务器在没有收到新请求的情况下保持打开连接的时间。在这个配置中，65表示超时时间为65秒。如果在该时间内没有新的请求到达服务器，服务器将关闭连接。怀疑这可能是问题所在，我将超时时间改为300秒进行再次测试，但结果依然相同。
为了进一步确定问题，我尝试查看openresty的日志。由于我的openresty是通过docker安装的，我使用命令docker exec -it nginx /bin/sh进入容器内部，打算查看/var/log/nginx下的error.log文件，但却发现/var/log目录下根本没有nginx文件夹。然而，我的配置文件明确写着error_log /var/log/nginx/error.log;，于是我发现了下一个问题：openresty的docker镜像的配置文件路径与nginx不同。
回想起我最初安装nginx时的情况，为了避免加载模块的麻烦，我从nginx镜像切换到了openresty镜像。但是，docker-compose.yml文件中的配置文件映射目录并没有相应更改，导致nginx.conf中的修改没有生效。
经过nginx -t命令检查后，发现openresty的配置文件目录在/usr/local/openresty/nginx/conf/nginx.conf，日志目录在/usr/local/openresty/nginx/logs/。检查了 error_log，并没有发现问题，只是一些常规的报错信息。
这个时候 我陷入了深深的自我怀疑之中，并把整个问题发给了ChatGPT想寻找一些思路。
在ChatGPT回复的第五条中提到了：
5. OpenResty版本问题：考虑升级OpenResty到最新版本，以确保您使用的是最新的修复和改进。有时旧版本可能存在某些问题，更新到最新版本可能有助于解决问题。这给了我一丝希望，也许是OpenResty的一些奇怪bug，升级一下可能会解决问题。
docker compose pull && docker compose up -d然而，问题仍然存在。无奈之下，我使用Surge抓包，看能否找到问题所在。每次问题出现时，情况都是这样的：在Emby的 /stream 长TCP连接建立后，最初加载速度稳定，经过60-70秒后，下载了200-700MB的资源后，速度急剧下降至40-50kb/s，并出现卡顿。视频资源仍能正常加载，只要等待足够长的时间，仍然可以播放一秒钟。因此，可以排除Emby本身的问题。
具体分析，整个播放流程如下：手机-Emby客户端-伦敦CN2-Cloudflare-洛杉矶-Emby服务器-Rclone-云盘。到目前为止，问题只能确定在Emby客户端和伦敦CN2之间。我开始有点怀疑是防火墙的问题。通过iperf3进行长连接测试：
iperf3 -c xxx.xxx.xxx.xxx -t 200 -b 20M测试稳定运行，因此问题可能出在OpenResty上。
解决
我将镜像从OpenResty切换到Nginx并重新测试。播放一个大型视频，观察连接300秒，下载了1.7GB以上的数据，速度保持稳定。至此，这个莫名其妙的问题终于解决了。