排障方法论：从日志到内核参数的定位流程

大多数「配置不对」都能靠一套固定的定位流程解决，而不是瞎试参数。这篇把排障组织成 五个阶段：看日志 → 看连接 → 看规则 → 查配置 → 动参数，每步给出工具与判断标准。

阶段 1：看日志

先把日志级别调到 info 甚至 debug，复现问题后立即停止，避免日志刷屏掩盖关键行。 关注的典型条目：

阶段 2：看连接

# API 拉取活跃连接，按目标域名过滤
curl -H "Authorization: Bearer secret" http://127.0.0.1:9090/connections \
  | jq '.connections[] | {host: .metadata.host, rule: .rule, chain: .chains}'

这一步回答两个问题：请求有没有到达内核？命中了哪条规则、走了哪条链？ 如果连接列表里根本没有目标域名，问题在客户端/系统代理层，不在内核。

阶段 3：验证规则

规则是「自上而下、先命中先生效」的。用 /rules 接口确认规则顺序，用 /dns/query 确认域名解析结果。常见误判：域名走了 IP 段规则而非域名规则， 或 REJECT 规则排在直连规则之前把流量全部拦截。

阶段 4：查配置

• 用内核 -t 校验语法，排除 YAML 缩进错误
• diff 当前生效配置与期望配置，确认是订阅带来的还是 override 覆盖了
• 检查 external-controller、dns、tun 三段是否被端侧 override 意外改写

阶段 5：动参数

前四步都没定位到，才考虑动内核参数，并且一次只动一个：udp-timeout、keep-alive-interval、 find-process-mode、sniff。每次改动后保留日志，用实测数据确认改善， 避免多个参数叠加后无法判断谁起作用。

二分定位法

面对复杂问题时用二分法缩小范围：先把整个规则切成「全局代理」与「全局直连」两端， 确定问题在哪一端；再在问题端内逐步二分（只留一半规则测试）。 相比逐个试参数，二分法定位次数是指数级减少的。

总结

排障的本质是信息收集：日志给线索、连接表给事实、规则给解释、配置给原因、 参数给对策。按流程走，大部分问题在阶段 1–3 就能结束，根本不需要改参数。