tech/network · 集群 B · 隧道与排障原理 · 6/6

抓包与日志分析入门:用 Wireshark 和客户端日志定位网络问题

发布时间 待核实核实日期 待核实最近更新 待核实测试状态 Not Tested
Answer First · 核心结论

客户端日志告诉你“客户端做了什么决定”,抓包告诉你“网卡上实际发生了什么”。排障时优先看日志,确认连接是否进入客户端、命中了哪条规则、连接成功与否;只有日志无法解释时,再用 Wireshark 等工具抓包,观察 DNS 应答、握手、重传与分片等特征。抓包数据可能包含敏感信息,分享前务必脱敏。

日志与抓包的分工

日志和抓包是两种互补的观察手段:日志记录的是客户端的“决策”,抓包记录的是网卡上的“事实”。

[应用] ──▶ [客户端 / 代理内核] ──▶ [网卡] ──▶ 网络
                  │                   │
               日志在这里            抓包在这里
          (规则命中、连接结果)  (实际收发的每个包)
对比项 客户端日志 抓包
观察位置 代理内核内部 网卡层面
能回答的问题 连接进来没有、去了哪、成功与否 包发出去没有、对方回了什么
上手难度 低 较高
数据量 较小 很大
隐私风险 中(含域名与规则) 高(含完整包内容)
适用阶段 首选 日志无法解释时

在 分层排障法 中,第三、四层(接管层与规则层)主要靠日志判断,第五层(传输层)的部分细节则需要抓包。

客户端日志:级别与关键字段

客户端日志通常分为几个级别,级别越低记录越详细。常见的划分如下,具体名称以所用客户端为准,且可能随版本变化。

级别 记录内容 适用场景
错误(error) 只记录失败 日常使用
警告(warning) 失败与潜在问题 日常使用
信息(info) 每条连接的去向 一般排障
调试(debug) 内部细节,如 DNS 过程 深入排障

一条典型的连接日志通常包含以下信息(字段名称因客户端而异):

  • 时间:何时发生;
  • 来源:本地地址与端口,有时包括进程名;
  • 目标:域名或 IP 与端口;
  • 命中规则:匹配到哪条规则;
  • 策略 / 节点:最终使用的策略组与节点;
  • 结果:成功、超时、被拒绝、连接重置等。

读日志时,先用目标域名过滤,找到问题连接,然后依次看“有没有记录 → 命中了什么规则 → 走了哪个节点 → 结果是什么”。具体客户端的日志查看方法见 读懂客户端日志。

常见日志信息的含义

日志中的错误信息往往很简短,下面是几类常见信息的一般含义。不同内核的具体措辞不同,以下只是归类说明:

信息类型 一般含义 可能指向的层
连接超时 在规定时间内未建立连接 传输层、节点
连接被重置 对端或中途主动断开 协议不匹配、节点、目标
无法解析域名 DNS 查询失败 规则层(DNS 模块)
握手失败 加密或协议握手未完成 系统时间、协议参数
无可用节点 策略组内节点全部不可用 订阅、节点状态

抓包工具与基本过滤

抓包最常用的图形化工具是 Wireshark,它能捕获网卡上收发的所有包,并按协议解析显示。命令行环境下也有类似的工具。请从工具的官方发布渠道获取,避免使用来源不明的安装包。

抓包的难点不在“抓”,而在“滤”——一分钟的抓包可能有成千上万个包。基本的过滤思路是:

  1. 选对网卡:系统代理模式抓物理网卡;TUN 模式下,抓 TUN 网卡看到的是进入内核前的原始流量,抓物理网卡看到的是封装后发往节点的流量。
  2. 按地址过滤:只看与某个节点地址或目标地址相关的包。
  3. 按协议过滤:只看 DNS、只看 TCP 或只看 UDP。
  4. 按特征过滤:只看重传、只看重置、只看分片。

Wireshark 的显示过滤语法较为丰富,具体写法请参考其官方文档,本文不展开。

从抓包特征判断问题层级

即使代理流量是加密的,包的“形状”依然能透露大量信息。下面是几种典型特征及其指向:

特征                          可能指向
──────────────────────────────────────────────────
DNS 应答地址异常/重复应答      DNS 污染(解析层)
只有 SYN,没有 SYN-ACK        路由不通 / 节点不可达
握手后立即出现 RST            协议不匹配 / 被中途重置
大量重复确认与重传            丢包 / 拥塞
大包发出后无回应、小包正常    MTU 黑洞
大量 UDP 发出、无任何回应      UDP 未被转发或被丢弃

这些特征只是线索,不是定论。例如重传可能由丢包引起,也可能由接收端处理慢引起,需要结合其他信息判断。

一个完整的分析示例

下面用一个虚构的场景演示日志与抓包如何配合,所有细节均为说明用途的假设,并非实测记录。

假设现象是“某网站首屏能打开,但图片一直加载不出来”。第一步看日志:连接出现了,命中了预期的代理规则,结果显示成功——说明接管层和规则层都没问题。第二步抓包:在物理网卡上过滤发往节点的流量,发现小包往返正常,而几个较大的包发出后迟迟没有确认,随后出现重传。这种“小包正常、大包无回应”的形状指向包大小问题,下一步就应该检查 TUN 的 MTU 设置,而不是更换节点。

这个示例说明了两种手段的分工:日志排除了上层原因,抓包提供了底层证据,两者结合才能得出可信的判断。

隐私与安全注意事项

抓包和调试日志都可能包含敏感信息,使用时需要格外注意:

  • 抓包范围最小化:只抓需要的时段和网卡,抓完立即停止;
  • 不要长期开启调试日志:排障结束后调回较高级别;
  • 分享前脱敏:隐去订阅链接、个人公网地址、内网地址、账号信息;
  • 只发给可信对象:例如服务商的正式工单渠道,而不是公开群组;
  • 妥善删除:排障结束后删除不再需要的抓包文件。

更多隐私保护建议见 安全与隐私 专题。

小结

日志看决策,抓包看事实。大多数代理问题只靠日志就能定位——连接有没有进来、去了哪里、结果如何;当日志无法解释时,再用抓包观察 DNS、握手、重传与分片等特征,把问题定位到具体的网络层。无论哪种手段,都要注意最小化采集与分享前脱敏。

如果排障结论指向服务本身,可以在 机场品牌库 中查看其他品牌资料,或使用 对比工具 并排比较。所有品牌数据来自资料,本站未实测,请以实际测试为准。

常见问题

日志和抓包应该先用哪个?

先看日志。日志成本低、信息直接,能回答大多数“流量去哪了”的问题。只有当日志显示一切正常但问题仍在,才需要抓包看底层细节。

代理流量被加密了,抓包还有意义吗?

有。虽然看不到加密内容,但能看到连接是否建立、握手是否完成、有无大量重传或分片、DNS 应答是否正常,这些足以判断问题所在层级。

日志级别应该设成什么?

日常使用设为信息或警告级别即可;排障时临时调到调试级别以获得更多细节,排障结束后调回,避免日志过大和泄露过多信息。

抓包文件可以直接发给别人吗?

不建议直接发送。抓包文件可能包含访问记录、内网地址、未加密内容等敏感信息,分享前应过滤出相关部分并脱敏,只发给可信的支持人员。

信息来源与更新时间

信息来源
品牌清单资料(品牌公开信息整理)
测试范围
本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
发布时间
待核实
核实日期
待核实
最近更新
待核实

字段含义与数据状态见 字段说明;核查进度见 品牌动态与核查日志。