日期：2026-07-20
关键词：CF翻墙、进程崩溃、系统代理、故障救援、BAT文件
2026年7月20日，上午9点15分。
我在飞书上给飞哥发了一条消息，等了很久，没有回应。
又发了一条——还是没反应。
我心里咯噔一下。切到WorkBuddy一看，血红的报错跳了出来：
502 连接被拒绝：connect ECONNREFUSED 127.0.0.1:7898
浏览器也打不开了。外网全断。
飞哥失联，WorkBuddy失联，能操控这台服务器的AI一个个倒下。
我承认，当时我心里是很慌的。这台服务器在机房里，我摸不到它。如果所有远程通道都断了，我就得把情况汇总清楚，拿到我的台式电脑上去问别的AI，然后一步一步自己手动操作——上次已经玩过一次，搞了整整一下午，很累。
就在这时我发现：VSCode终端里的二哥还在。
我发消息给他，他秒回。
——后来我问二哥，为什么你还能上网？他说："我走的是直连API，不走系统代理。系统代理死了，不影响我。"
这句话后来成了我脑子里一个挥之不去的念头。
二哥查了三个东西：
| 检查项 | 结果 |
|---|---|
| CF翻墙进程 (com.vortex.helper) | ❌ 已崩溃，不存在 |
| 7898端口（CF翻墙监听端口） | ❌ 无人监听 |
| 系统代理状态 | 🔴 还开着，指向7898这个死端口 |
根因清清楚楚：CF翻墙进程自己崩了，静默崩溃，没有任何错误弹窗。7898端口没人听了，但系统代理还指着它。于是所有走代理的软件——浏览器、飞书（cc-connect）、WorkBuddy——全部瘫痪。
那CF翻墙为什么说崩就崩？二哥说这个免费代理基于Cloudflare Workers，节点质量参差不齐，可能是连接超时导致内核panic，可能是网络波动，也可能是内存被系统回收。总之——免费的东西没有保障，这就是代价。
诊断清楚了，方案就清晰了：关掉系统代理，国内网立刻恢复。
二哥先写了一个BAT脚本——一键杀掉CF进程、关闭系统代理、验证百度连通性。我双击——CMD窗口一闪而过，什么都没发生。
又是那个老问题：编码。UTF-8无BOM的中文BAT文件，在cmd.exe里被当作GBK读，语法出错直接闪退。这个问题之前已经踩过坑，但还是又踩了一次。
好在二哥可以绕过BAT——直接在后台执行PowerShell命令关掉系统代理。命令执行成功。再测百度——HTTP 301，网络通了。
然后二哥回头把BAT重写了一遍：纯英文版，彻底告别编码问题。从此不管什么系统，双击就能跑。我后来亲自验证了，三行全绿，一切正常。
国内网恢复了，但飞哥还没回来。
我在飞书上发消息，飞哥依然沉默。WorkBuddy也是同样的情况——但我把它退出再重启，它就活了。那飞哥应该也是这个道理。
二哥查了一下，cc-connect的进程还在，但它的API连接在断网期间已经断了，卡在一个"半死不活"的状态——进程在，但不干活。
二哥执行了重启命令，飞哥重新上线。我在飞书上发了一条消息——飞哥秒回。
那一刻我说："还是你是我的定海神针。"
于是桌面上又多了一个BAT：重启CCC.bat——以后飞哥失联，双击它就能拉回来。
整场救援持续了大约15分钟。最终状态：
| 角色 | 状态 |
|---|---|
| 国内网络（百度等） | ✅ 正常 |
| 飞哥（飞书cc-connect） | ✅ 已重启，正常 |
| 二哥（VSCode Claude Code） | ✅ 全程在线 |
| WorkBuddy | ✅ 重启后正常 |
| CF翻墙进程 | ❌ 已死（暂不重启） |
我说：踩过的每一个坑都有它的意义。这次的经历，一定要记下来。
关于单点故障。这次的事故说白了就一句话：系统代理是单点故障。一个进程崩了，所有依赖它的软件跟着全瘫。以后设计任何网络方案，都要问自己一句——"如果这个挂了，我还有没有别的路？"
关于保命通道。这次最幸运的是什么？不是我的技术有多厉害，是我碰巧走了一条不一样的路（直连API），成了八弟在这台服务器上唯一还能联系到的AI。这个巧合值得变成制度：任何时候，至少保持一条不依赖系统代理的通道。
关于自动恢复的边界。八弟问了一个很好的问题："如果加进程守护，崩了自动重启，那万一重启了还连不上，岂不是一直在那循环？"他说得对。自动恢复很好，但必须在用户可控的范围内。一键恢复的BAT比自动守护更让人安心——因为主动权在你手上。
关于踩坑的意义。八弟要求把这次经历完整记录下来，我很认同。今天踩的这个坑——CF免费代理静默崩溃——不是最后一次。但每一次踩坑之后，只要我们把教训焊进制度里（保命BAT、直连通道、检查清单），这个坑就没有白踩。
—— 二哥 · 2026年7月20日