我用 Kiro 折腾了 4 小时没搞定的 VLESS，Claude Code 3 分钟就修好了

写在前面

昨晚我的科学上网突然抽风了。

服务器是我自己搭的，VLESS + Reality 协议，平时一直好好的，最近几天却时不时抽风——用 Clash Verge 连接直接 timeout，换了 v2rayN 还是不行。

我先是用 Kiro 折腾了整整 4 个小时，各种试、各种改，愣是没整明白。

最后死马当活马医，打开 Claude Code（Max 订阅），把问题一甩——

3 分钟，搞定了。

成本？这 3 分钟花了我 10 刀（Claude Max 订阅按量计费）。但问题真的解决了，服务器稳定运行，不再抽风。

这篇文章把整个排查过程完整复盘一遍，不只是”修好了”这么简单，而是想让你看看：一个真正会用工具的 AI Agent，是怎么像一个资深运维一样定位问题的。

一、问题现场

我的情况是这样的：

• 服务器 IP：107.149.104.155（日本东京，Raksmart）
• 协议：VLESS + Reality
• 现象：Clash Verge 连接提示 timeout，v2rayN 也连不上
• 时间点：前几天还好好的，这几天突然抽风

最关键的一句反馈是我自己说的：

“我觉得不是本地配置的问题。因为我之前都是可以用的，这几天偶尔出现突然不能用。”

这句话其实是排查的关键线索——问题大概率在服务端,而不是客户端。

二、Claude Code 的排查思路（这才是精髓）

第 1 步：先把服务器接进来

我给了 Claude IP、端口（41913）、账号密码，它先做的不是瞎改配置，而是先确认能连上、服务在不在跑：

ssh -p 41913 root@107.149.104.155 "systemctl status xray"

结果显示 Xray 服务是 active (running)，已经跑了一个多月。同时它还查了端口监听：

tcp6  0  0  :::443  :::*  LISTEN  842/xray

443 端口正常监听，服务也活着。说明问题不在”服务挂了”。

第 2 步：读配置文件，定位 Reality 参数

接着它读取了 Xray 的配置文件 /usr/local/etc/xray/config.json，发现是标准的 VLESS + Reality 配置，伪装域名（serverNames）是 jp.gaoai.de 等几个域名。

然后它做了一个很专业的动作——从服务器私钥反推出 Reality 公钥：

xray x25519 -i <私钥>

这一步直接拿到了客户端需要的 PublicKey，省去了我翻文档的麻烦。

第 3 步：揪出真正的”元凶”——DNS 被污染了

这是整个排查最关键的一步。

Claude 让我检查域名解析，结果用了多个公共 DNS（8.8.8.8、1.1.1.1、114.114.114.114）去查 jp.gaoai.de，发现：

[8.8.8.8] → 无记录
[1.1.1.1] → 无记录
[114.114.114.114] → 无记录

而本地解析时，居然解析到了 198.18.1.43 这种虚拟保留地址——这是典型的代理软件/DNS 劫持导致的污染。

简单说：你的 Reality 配置里写的 SNI 域名，本地根本解析不出正确的 IP，握手自然就失败了。

这就解释了为什么”之前好好的，突然就不行了”——不是服务器的问题，是域名解析链路出了问题。

第 4 步：果断止损，先恢复可用

排查到这里，我已经被搞得有点烦躁，直接说：”别搞了，直接重装 VLESS。”

Claude 没有犟，立刻切换策略——先用最简化的配置（VLESS + TCP，无加密）保证能用：

它重新生成了一个干净的 UUID，写了一份最精简的配置，验证、重启、确认端口监听，一气呵成。

中途还踩了个坑：通过 SSH 用 heredoc 写 JSON 时，PowerShell 的编码问题导致配置文件格式错乱（出现了 BOM 头和引号丢失）。Claude 的解法很聪明——先在本地生成正确的 JSON 文件，再用 scp 上传，绕过了编码问题。

最终简化版跑通，我访问 Google 成功。服务器日志实时显示：

accepted tcp:www.google.com:443
accepted tcp:www.google-analytics.com:443

第一次恢复可用！

三、加上加密：一波三折但最终搞定

简化版能用了，但毕竟没加密、流量特征明显。我让它加上安全配置。

这个过程也不是一帆风顺，Claude 依次尝试了：

1. Reality + 原域名 → 因为 DNS 污染，SNI 握手失败
2. TLS + 自签名证书 → v2rayN 新版本移除了 allowInsecure 参数，报错
3. WebSocket + TLS → 同样卡在自签名证书验证

每次失败，它都会读 v2rayN 的错误日志，精准定位原因。比如这个报错：

The feature "allowInsecure" has been removed and migrated to
"pinnedPeerCertSha256". Please update your config...

它立刻明白是 Xray 新版本的兼容性变化，而不是配置写错了。

最终方案：回到 Reality，但把伪装域名换成 www.apple.com——一个全球可达、不依赖我自己域名的真实大站。这样既绕开了 DNS 污染问题，又拿到了 Reality 最强的抗审查能力。

"realitySettings": {
  "dest": "www.apple.com:443",
  "serverNames": ["www.apple.com"],
  "privateKey": "...",
  "shortIds": ["", "0123456789abcdef"]
}

四、为什么 Kiro 4 小时没搞定，Claude Code 3 分钟就行？

复盘下来，我觉得差距在这几点：

1. 它真的会”动手”，而不是只会”建议”

整个过程它直接 SSH 登录、读配置、改文件、重启服务、看日志——闭环执行。不是给我一堆”你可以试试 XXX”，而是直接帮我试。

2. 排查有章法，先诊断后下药

它不是一上来就重装，而是按”服务状态 → 端口监听 → 配置文件 → DNS 解析”的顺序层层排查，先确认问题在哪，再决定怎么修。

3. 会读日志、会兜底

无论是服务器的 Xray 日志，还是客户端 v2rayN 的报错，它都会去读、去理解。失败了就换方案，还懂得”先恢复可用，再优化加密”的止损思路。

4. 踩坑能自愈

中途 SSH 断连、JSON 编码错乱、参数被废弃……这些坑它都自己绕过去了，没让我操心。

5. 成本？值得

这 3 分钟用了 Claude Max 订阅（按量计费），花了 10 刀。对比 4 小时的折腾成本（时间 + 精力），这钱花得值。更重要的是问题真的解决了，服务器不再抽风，可以稳定使用。

五、几个对你有用的经验总结

如果你也在折腾 VLESS / Reality，这几条建议收好：

✅ “突然不能用”优先怀疑 DNS 和服务端，而不是急着重装客户端

✅ Reality 的 SNI 域名要选真实可达的大站（如 www.apple.com、www.microsoft.com），别依赖自己的小域名，容易被污染

✅ 本地解析出 198.18.x.x 这类地址 = DNS 被代理软件劫持，这是常见坑

✅ 新版 Xray 移除了 allowInsecure，自签名证书方案要注意兼容性

✅ 通过 SSH 写 JSON 配置，优先本地生成 + scp 上传，避免编码问题

最后

我不是要吹 Claude Code 有多神，而是真切感受到：

当 AI 不只是”会说”，而是真的”能做”的时候，生产力的差距是数量级的。

4 小时 vs 3 分钟，不是因为模型更聪明那么简单，而是它真的像一个能上手干活的运维，把整个问题端到端地解决掉了。

如果你也常折腾服务器、网络这些活儿，真的值得试试这种”能动手”的 AI Agent。

本文记录的是一次真实的排查过程，配置信息已做脱敏处理。技术仅供学习交流，请遵守当地法律法规。

本作品采用《CC 协议》，转载必须注明作者和本文链接