故障排查

LetsVPN日志自助排查：7字段定位连接失败

作者：LetsVPN官方团队
#日志#连接诊断#字段解析#自助排障#本地分析
LetsVPN日志字段, 连接失败排查, 自助排障步骤, LetsVPN本地日志, 如何解读LetsVPN日志, VPN日志字段速查, LetsVPN 连接失败原因, 7个关键日志字段, LetsVPN 故障定位, 日志排查教程

问题定义：连接失败时官方客服也“看不见”什么

LetsVPN 采用「零日志策略通过瑞士 Proton 审计」，服务器侧不保留任何可关联到用户的连接记录。好处是合规与隐私，副作用是——一旦握手失败，官方工单系统里几乎没有现场数据。工程师只能让用户「再试一次」并本地抓包，沟通成本高。2025-06 版客户端因此把「本地诊断日志」默认开启，但只保留最近 12 小时，且字段多达 60+，多数为 LetS-Relay 协议内部计数器，对普通用户没有意义。

经验性观察：>80% 的连接失败可归为 7 类——时间戳错位、节点离线、协议被 DPI 重置、握手超时、证书校验失败、上下行零流量、认证额度耗尽。对应到日志里，恰好有 7 个字段能秒级定位。掌握这套「7 字段速查表」后，你可在提交工单前完成一轮自助排障，平均节省 2～3 个往返邮件。

功能边界：本地日志能做什么、不能做什么

能做什么

  • 记录最后一次连接尝试的客户端侧事件（time_stamp 精度到毫秒）。
  • 显示节点层 ID 与所选协议（node_id、proto），用于判断是否命中「闪电节点」。
  • 给出握手阶段错误码（handshake、error_code），对照官方公开表即可定位失败原因。
  • 记录上下行字节（rx_bytes、tx_bytes），零流量场景一眼识别。

上述四项覆盖了「客户端是否发出请求—服务器是否给出回应—数据是否真正流动」的完整闭环，足够让大多数家庭宽带用户在 30 秒内完成「症状—病因」映射。

不能做什么

  • 不会保留你访问的目标域名或 IP——零日志策略决定了连本地都不写。
  • 无法揭示服务器侧负载或端口占满情况，只能看到「节点无响应」这类客户端推断。
  • 12 小时后自动清零，重启客户端也会提前刷盘；需要离线分析务必先导出。

简言之，本地日志是「客户端侧后视镜」，对服务端黑盒内部既无感知也无记忆；一旦错过 12 小时窗口，现场即消失。

警告：导出日志按钮会把全部 60+ 字段明文写入文件，若通过第三方 IM 发送，记得手动删除带有 device_id 的行，避免泄露硬件指纹。

最短可达路径：三端入口与导出命令

Android（v10.12 及以上）

  1. 打开 LetsVPN → 右上角「⋯」→「诊断」→「本地日志」。
  2. 点击「导出日志」→ 选择保存到「下载」文件夹，文件名格式 letsvpn_log_YYYYmmdd_HHMMSS.txt。
  3. 用任意文本编辑器打开，搜索关键词 latest_attempt，即可定位到最近一次连接块。

iOS（v10.12 及以上）

  1. LetsVPN →「设置」→「帮助」→「导出诊断日志」。
  2. 系统弹出「分享到…」面板，建议先存到「文件」App，再用内置「查看」打开。
  3. iOS 版日志额外包含 os_version 字段，用于排查 Apple 私有 VPN API 变更导致的兼容问题。

桌面端（Windows & macOS v10.11f）

  1. 任务栏/菜单栏图标右键 →「诊断工具」→「保存日志到桌面」。
  2. 若客户端完全无法启动，可用 CLI 兜底：LetsVPN-cli.exe --dump-log，输出到标准错误，可重定向至文件。
提示：macOS 版日志默认写入 ~/Library/Logs/com.letsvpn.mac/，即使不手动导出，也可用 tail -f 实时观察。

7 字段速查表：含义、阈值、判定口诀

字段 典型正常值 异常阈值 一眼判定口诀
time_stamp 与系统时间差 ≤3s >30s 偏差 「时间跳变」触发证书有效期校验失败
node_id 数字+字母 8 位 为空或「unknown」 节点配置文件未拉取成功，先清 App 缓存
proto UDP|TCP|LetS 显示「–」 协议协商被 DPI 重置，尝试 Obfs4
handshake ok timeout/reset >92% 成功率基准，若连续 3 次 reset 建议换节点
error_code 0 401/402/521 401=凭证过期；402=多设备超限；521=节点离线
rx_bytes >0 0 零下行 = 握手后无数据，可能 UDP 被丢包
tx_bytes >0 0 零上行 = 本地 App 没发数据，检查分应用代理 SplitApp 是否把 LetsVPN 自身排除

速记口诀：「时间对得上，节点有编号；协议别为空，握手要 ok；错误看代码，流量别是零。」

实战示例：30 秒定位「401 凭证过期」

场景：2025-11-12 08:10 用户 A 反馈「突然连不上，昨天还好」。导出日志后，搜索 latest_attempt 得到片段：

time_stamp=2025-11-12 08:10:33.442
node_id=7f3a9bc1
proto=LetS
handshake=timeout
error_code=401
rx_bytes=0
tx_bytes=246

解读：error_code=401 → 凭证过期；tx_bytes=246 说明客户端已发出第一个握手包，但 rx_bytes=0 说明服务器直接拒收，符合「凭证失效」特征。用户前往「账号」→「恢复购买」，重新拉取订阅后 10 秒内恢复。整个排障流程 3 步，无需抓包，也未暴露任何浏览历史。

例外与副作用：什么时候 7 字段也救不了

1. 中间人证书篡改

若企业网关强制替换 TLS 证书，handshake 字段会显示 certificate_verify_failed，但 error_code 仍写 0，因为 LetS-Relay 协议在应用层才校验。此时 7 字段只能告诉你「证书不过」，要进一步确认需对比「系统根证书」是否被导入新的 CA。可复现验证：在 macOS「钥匙串」搜索「LetsVPN」证书，若出现「Blue Coat」类中间人标志，即属此类。

2. 本地防火墙拦截 Outbound UDP

Windows 11 22H2 的「核心隔离」功能会默认屏蔽未签名驱动 UDP 流量。日志里 proto=UDP、rx_bytes=0、tx_bytes>0，但 error_code 依旧 0。7 字段提示「零下行」，却说不清是谁拦截。需要用户自行把 LetsVPN.exe 加入 Defender 允许列表，这一步无法通过日志自动化。

3. 节点侧负载 100% 但健康探针仍返回「ok」

经验性观察：偶尔出现 handshake=ok 但 rx_bytes=0，且多次切换节点后才恢复。原因是 Anycast 探针对 443 端口做 TCP 三次握手即判「alive」，但节点内部转发队列已满。7 字段无法区分「节点 alive」与「节点可转发」，只能建议多跳 2 次后仍失败就人工报障。

验证与回退：确保你的改动没把网络搞得更糟

  1. 每改一次节点或协议，在日志里新建书签文件，命名 attempt_x.txt，防止后续循环覆盖。
  2. 观察指标：若 handshake 从 timeout→ok 且 rx_bytes>0，即算恢复；若只是 error_code 变化但 rx_bytes 仍 0，则属于「假性成功」，继续排查。
  3. 回退方案：在「设置」→「高级」→「协议优先级」关闭「AI 智能选路」，手动锁 TCP-443，即可回到最保守模式，通常能绕过 UDP Qos。

适用/不适用场景清单

场景 是否推荐 7 字段排查 理由
家宽千兆，突然连不上 ✅ 推荐 字段清晰，5 步内可定位
企业 WPA2 强制代理 ⚠️ 部分适用 能发现 521/401，但证书篡改需额外查根证书
iOS 越狱后装多个 VPN 插件 ❌ 不推荐 插件注入会篡改 socket，日志字段不可信
路由器 OpenWrt 插件模式 ✅ 推荐 日志同样落盘 /tmp/letsvpn.log，7 字段照样可用

与第三方机器人协同：仅做离线转发

市面上存在「第三方归档机器人」声称能「自动诊断日志」。实测做法只是调用正则提取 7 字段后回显文字，不具备官方 API 权限。使用此类机器人时，务必在本地完成脱敏（删除 device_id、subscriber_hash）再转发，并遵循最小化原则：只发 latest_attempt 区块，而非整份日志。

版本差异与迁移建议

2025-07 以前旧版（v9.x）日志采用 JSON 嵌套，字段名大小写不统一，例如 RxBytes 与 rx_bytes 并存，脚本容易误判。若你仍在用 v9.x，建议先升级至 v10.x 再使用本文速查表；如暂时无法升级，可把日志丢到 jq 做统一小写转换后再匹配。

最佳实践清单（检查表）

  • 连接失败 → 先导出日志 → 搜索 latest_attempt
  • 按「时间-节点-协议-握手-错误-流量」六连问，逐项写答案
  • error_code 非 0 时，先到官网状态页核对「订阅到期」「多设备超限」
  • rx+tx 同时 0 且 proto=UDP → 手动切 TCP-443 或开 Obfs4
  • 若 3 次节点漂移后 rx_bytes 仍 0 → 备份日志 → 脱敏 → 提交工单

案例研究

1. 小型工作室（10 人）——「401 轮换」批量掉线

背景：2025-10 某游戏美术工作室使用同一 LetsVPN 年付账号，凌晨 3 点集体掉线。

做法：IT 人员让所有人导出日志，统一搜索 error_code=401；发现 8 台设备同时在线，触发多设备上限。随即在管理后台踢掉 3 台闲置机，再让主力机「恢复购买」刷新令牌。

结果：3 分钟内全部恢复，零抓包、零抓瞎。

复盘：401 字段秒级定位，避免「挨个换节点」的盲目操作；工作室后续把「设备上限」写进入职手册，提前规避。

2. 跨国会议（500 人）——UDP 被运营商 QoS

背景：2025-11 全球线上发布会，北京与旧金山两地演示，直播前 30 分钟北京侧 80% 节点握手 timeout。

做法：现场工程师批量收集日志，发现 proto=UDP、rx_bytes=0、error_code=0，判定为 UDP 黑洞；立刻在「协议优先级」里关闭 UDP，强制走 TCP-443，并开启 Obfs4。

结果：2 分钟后握手成功率回到 96%，发布会准时开始。

复盘：零下行流量是 QoS 典型特征，7 字段把「网络层丢包」与「应用层错误」快速区分；后续公司把「TCP-443 保底」写进 Runbook。

监控与回滚 Runbook

异常信号

  • 连续 3 次 handshake=timeout
  • rx_bytes=0 且 tx_bytes>0 持续 30s
  • error_code=521 出现在 50% 以上节点

定位步骤

  1. 导出日志 → 搜索 latest_attempt → 填写 7 字段值到共享文档。
  2. 若 error_code=401/402，先检查订阅状态；若 521，切到「节点列表」手动选延迟最低的非灰节点。
  3. 若 rx=0 且 proto=UDP，立即切 TCP-443 并开启 Obfs4；观察 rx_bytes 是否 >0。

回退指令

Windows：设置 → 高级 → 协议优先级 → 取消“AI 智能选路” → 手动置顶 TCP-443
macOS：defaults write com.letsvpn.mac fallbackProtocol -string "TCP-443"
Android/iOS：设置 → 协议优先级 → 拖动 TCP-443 到首位

演练清单（月度）

  • 随机挑 1 个节点，手动屏蔽 UDP 出口，验证能否 30s 内切到 TCP-443。
  • 模拟 error_code=401，在测试账号里超额登录，检查「恢复购买」链路是否通畅。
  • 导出日志后，用脚本自动删除 device_id，确认脱敏脚本无遗漏。

FAQ

Q1：日志里出现 error_code=0 但仍旧连不上，怎么办？ 结论：优先看 rx_bytes 是否为零。
背景：零下行多由中间人 RST 或本地防火墙拦截导致，error_code 未被触发。 Q2：device_id 被误发到微信群，有无补救？ 结论：device_id 仅用于本地计数，无法直接关联身份，但建议后续删除消息并换机重装。
证据：官方文档声明 device_id 为随机 UUID，不含账号哈希。 Q3：iOS 日志为何比 Android 多 4 个字段？ 结论：Apple 要求提供 NetworkExtension 帧率与内存峰值，用于崩溃溯源。
背景：字段名均以 ios_ 前缀开头，与 7 字段无冲突。 Q4：重启客户端后日志消失，能否延长保留？ 结论：暂不支持，12 小时硬限制由沙盒 size quota 决定。
变通：设置定时任务每小时导出一次并异地备份。 Q5：error_code=521 持续一整天，是否节点永久下线？ 结论：经验性观察，>24h 可视为永久下线，应切其他节点并提交工单。
官方状态页未给出 SLA，只能人工报障。 Q6：为何切换节点后 handshake 仍是 reset？ 结论：可能本地出口 IP 被全局拉黑，与具体节点无关。
验证：用手机共享 4G 再做同步骤对比。 Q7：日志出现 negative rx_bytes 正常吗？ 结论：属于溢出回卷，不代表真实流量为负。
背景：字段用 uint32，>4GB 会回绕，关注是否为零即可。 Q8：台式机与笔记本同时导出，文件名冲突？ 结论：文件名含时间戳到秒级，正常使用不会冲突；批量收集建议加 hostname 前缀。 Q9：可以写脚本自动轮询日志并告警吗？ 结论：技术上可行，但官方无 API，需自行 tail 文本，版本升级时字段位置可能漂移。
建议锁定大版本后再写死偏移量。 Q10：7 字段速查表会随版本更新吗？ 结论：2025-06 之后字段语义已冻结，官方 changelog 未提及改动计划；若新增字段，会在附录公告而非替换现有字段。

术语表

  • 零日志策略：服务器不存储可关联用户的连接记录，首次出现于 2024 白皮书。
  • LetS-Relay：LetsVPN 自研传输层协议，基于 UDP 并内嵌前向纠错。
  • latest_attempt：日志分块标识，记录最近一次完整连接事件。
  • error_code：4xx-5xx 风格整数，0 表示无错误，401 凭证过期见表格。
  • handshake：握手阶段结果，枚举值 ok/timeout/reset/certificate_verify_failed。
  • node_id：8 位 alphanumeric，对应 Anycast 边缘节点。
  • proto：协商协议，UDP/TCP/LetS/Obfs4。
  • rx_bytes/tx_bytes：连接块内累积上下行字节，溢出后回绕。
  • DPI：Deep Packet Inspection，运营商深度包检测。
  • Obfs4：流量混淆插件，把握手伪装成普通 TLS。
  • SplitApp：分应用代理开关，误把自身排除会导致零上行。
  • Anycast：同 IP 多节点广播，最近路由自动接入。
  • AI 智能选路：客户端动态评分算法，优先选延迟最低节点。
  • subscriber_hash：订阅标识哈希，日志内可能出现，需脱敏。
  • device_id：本地随机 UUID，用于计数器去重，非硬件序列号。

风险与边界

  • 不可用情形：iOS 越狱、Android ROOT 后注入 Xposed 模块，日志字段可能被篡改，7 字段表失效。
  • 副作用：导出日志明文包含 device_id 与粗略时间轴，若在外部渠道传播，可被关联到同一设备的多条记录。
  • 替代方案：若对脱敏要求极高，可改用本地抓包（Wireshark）+ 过滤器仅保留握手包，但需一定技术门槛。

未来趋势：官方会开放「字段过滤 API」吗？

经验性观察，LetsVPN 在 2025-Q4 测试版已出现「一键复制诊断链接」按钮，背后是把 7 字段打包成加密二维码，客服扫码即可解析，省去用户手动脱敏步骤。但该功能仍灰度，仅对部分年付订阅可见。若正式推出，自助排查流程将再缩短至 15 秒。

收尾结论

LetsVPN 的零日志策略把「排障现场」完全推到用户侧，7 字段速查表提供了一条最短可达的自助路径：导出 → 定位 → 对照 → 决策。它无法替代深度抓包，却能在 30 秒内筛掉 80% 常见订阅/节点/协议问题，显著降低工单往返。下次再遇到「突然连不上」，不妨先让日志说话，或许比反复切换节点更有效。

返回博客列表