服务器封锁救援记录
April 1, 2025
Table of Contents
Table of Contents
封锁救援记录
把服务器搞崩的凌晨 🌙
凌晨的时候,想部署一个 RSSHub。
原因只是 AO3 的自带 rss 订阅实在是太奇怪了…想让 AO3 的订阅更方便一些,加点标签过滤什么的,省得每天还要手动剔除奇怪的 tag,听说 rsshub 可以自建订阅源,想都没想就开始了。
毕竟折腾不止嘛…
没想太多,照着官方的 docker-compose 配置直接跑了,容器一个个拉下来,Chrome 浏览器环境、Redis 全都部署起来,那一刻我还挺满意的,觉得很快就能接入自己的订阅源了…
上一秒还在感叹 rsshub 真大,这么多服务要下这么久,这台机子网络还不太行,居然拉个源还能弹出一个 Error…

下一秒,那台服务器断连了。
一开始以为只是偶发性掉线,但 ping 不通、SSH 一直连接不上,部署在上面的所有活动也全部失效,打开部署过服务的域名,图床、监控,各种小服务全部挂掉。🫠开始意识到问题不小。
问了可能的原因:
RSSHub 容器拉起来后疯狂爬取内容,导致 Oracle 免费实例的带宽/网络资源被用爆。Oracle 免费机器对带宽出站流量非常敏感……
原来不是偶发断连,不是我网络不好,而是是它本身“出站带宽被封了”…
尝试处理,失败 ⚠️
那台机器不是我自己注册的,是我爸之前玩服务器,拿 Oracle 免费 vps 分给我的。我没有绝对控制权,只有账号端口与密码,不能连 ssh 一切都免谈…只能大半夜发消息问他能不能帮我重启。

老爸说是甲骨文的原生系统里装了监控软件,估计是因为镜像拉取,带宽消耗太大,被判断为异常,直接切断了出口。他的服务器监控系统也显示那台服务器已经失联…SSH 连不上,所有容器也都停在原地。 我这边没什么办法,只能靠老爸在 oracle 后台控制台手动重启了一下机器(与此同时还被狠狠质问一顿😭),幸好在焦急的等待过后,服务器终于恢复了。但问题还没有结束。清了一遍 docker ,重启服务,结果试图登录网站监控,依然进不去…
反代服务失效 🧩
我的域名绑定在新加坡的 VPS 上,走的是 Nginx Proxy Manager 的反代,反代目标是这台 Oracle 服务器的公网 IP。理论上来说,重启后恢复网络出口,服务已经恢复了,域名也应该能访问了。
但我发现:
域名依然打不开,服务依然报错。
慌张地 ping,根本 ping 不通那些域名…
绝望之际去 vps 习惯性地 curl 了一下 ip.sb (这个网站确实好记…),发现返回 ip 怎么成了 ipv6 …
然后突然意识到,问题出在网络出口。
warp 造成的影响 🌐
一问才知道,是老爸在 Oracle 的机器上开过 warp 全局代理,重启自动全部启动了… 所有出站流量都走 warp,反代解析的时候出现问题。这可能是他习惯性的操作…为了挂梯子解锁流媒体吧,但这带来了大麻烦。
我的 npm 反代全都是直接通过公网 IP 反代的,warp 一转发,原本通过公网 IP 的反代方式通通失效…在启用了 warp 后,服务器所有流量都经过 warp 代理,外网访问压根够不到原 IP。
WARP 转发之后: VPS 对外只发起连接,但不会正确响应外界主动连接。 反向代理就是主动去连 Oracle 的公网 IP → Oracle VPS 实际上已经绕过公网走 WARP,所以响应包没回来。
这也解释了为什么我之前搭好的服务都本地正常运行,但外界访问不了。
转向 tailscale ✅
既然连不上公网,那我只有内网一个路子了。
一瞬间想起了 tailscale ,直接加入内网 tailnet,因为远程桌面天天用,也超级好用…
最终的解决方式是:
保留 warp,但重新用 tailscale 接入,将反代目标改成 tailscale 的内网 IP。
这一次,服务恢复得很快,也很稳定,甚至比之前快了不少。
目前那台服务器部署的网站基本是另一台服务器反代的(主要还是 Ngnix Proxy Manager 真的很好用),将直接公网去转发改为内网之间的转发,网站延迟似乎能低不少…🤔
小插曲 🛜
恢复自己的网站监控后,发现自己的网站解析全部故障,并且报错原因都是同一个。

找了半天本机 DNS 的原因,发现本机 DNS 完全正常,摸不着头脑的时候突然想起来我的服务全是docker 部署…
进 docker 容器查看一下这个服务的 reslov.conf ,果不其然只剩下了 127.0.0.11,DNS 全部不见了。

重新去docker-compose.yml 添加了 DNS,然后down 后 up,果然恢复正常。 warp 转发也能影响我的 docker 容器内 DNS 吗?真神奇。😑
后记 📝
第一次把服务器搞崩,是在凌晨两点部署一个我以为不会出问题的小服务,结果是整台机器失联,网站服务中断,连不上控制台,只能靠远程帮我重启…
还好它不是我最核心的那台服务器。
如果是部署博客的,就是目前这个网站的服务器,服务器崩掉的那一刻我可能会先崩溃。😵💫
这也算是一次提醒。
- 免费的可能是最贵的,配置锁定,服务器确实不太稳定,也容易触发一些不可控的判定,别因为“永久免费”就把东西全部堆上去…要是服务器彻底收回,里面的数据怎么都要不回来了。
- 下次部署之前,还是应该提前考虑网络出口的影响,构建自己的 vps 内网网络。
- 在凌晨部署的时候,千万别太自信,要折腾尽量在白天折腾,至少那个时候神志清醒。🫠