疑难解答

遇到问题先拆成两个提问：流量到底有没有进入 Chute（接管问题），以及Chute 能不能把它转发出去（转发问题）？实时流量视图能直接回答——打开仪表盘（iOS）或主窗口的流量标签页（Mac），随便浏览一个网站：什么都不出现，说明流量没有进入 Chute；出现了连接但失败，说明 Chute 无法转发。这两类问题的修法完全不同。

什么都不出现：接管问题

Chute iOS

• 开关拨不开、配置栏在抖动——没有选中配置。点配置栏，点按一份配置使其出现对勾，再点完成（「请先选择配置」）。
• VPN 授权弹窗被拒绝了——再拨一次开关并允许。如果 VPN 描述文件卡住（开关立刻弹回），在应用设置里用重置 VPN 配置，下次启动会重新创建并重新请求授权。
• 另一个 VPN 应用正在连接——iOS 同一时间只运行一条 VPN 隧道。断开另一个应用（并留意它的按需连接规则，可能会悄悄把隧道抢回去）。

Chute Mac

• 系统代理已开但某个应用不走代理——不少工具（尤其是终端程序）不遵循系统代理。让它们显式指向 Chute 的监听端口（菜单里的 Copy Shell Export Command 为 shell 准备好了命令），或改用增强模式在网络层接管。
• 增强模式无法启动——网络扩展或 Helper 需要批准；确切的系统设置路径、「系统扩展已被阻止」的处理和 VPN 配置卡住的重置方法见增强模式的故障排除。
• 发往局域网地址的流量本来就会绕过 Chute——先检查杂项选项中的 skip-proxy 与 tun-excluded-routes，再判断是不是接管坏了。

出现连接但失败：转发问题

• 先隔离路径。 把策略组切到 DIRECT：直连能打开而走代理失败，问题就在代理服务器——主机/端口/凭据/加密方法写错，或服务器不可用。对策略组跑一次延迟测试；别的策略都能通过而某一个始终超时，元凶就是它。
• 命中了预期之外的规则。 在实时流量视图里查看失败连接实际命中的规则，再对照规则匹配顺序：规则分两轮评估，对主机名请求来说，靠后的非 IP 规则可能先于靠前的 IP 规则命中。no-resolve 和 FINAL 的位置是最常见的原因。
• DNS 结果不对。 检查 DNS 配置：使用加密 DNS 时，确认 DoH/DoT 服务器本身不经代理也可达；换过服务器后清一次 DNS 缓存（iOS 控制面板里的开关、脚本里的 flushDNS，或 HTTP 控制 API 的 DELETE /api/dns/cache）。
• 依赖 UDP 的应用异常——确认所选策略支持 UDP 中继（见代理策略的能力矩阵），并记得 Tailscale 不转发 ICMP，经出口节点 ping 不会有回应。

HTTPS 解密解不出来

• CA 证书必须已安装且已信任——在 iOS 上这是两个独立步骤，第二步（设置 → 通用 → 关于本机 → 证书信任设置）最容易被漏掉。见安装并信任 CA 证书。
• 主机必须命中 [MITM] 的 hostname 列表——只有声明过的主机才会被解密，且默认只有 443 端口，除非用 :port/:0 后缀放开。
• 有些应用固定（pin）了自己的证书，被解密就会失败——用 - 前缀把它们的主机排除掉，不必硬碰。
• QUIC/HTTP-3 无法被解密——用 block-quic 把兼容的客户端逼回 TCP。

查看日志

上面几节都没解决时，日志通常能给出答案：

• 临时调高日志级别：loglevel = verbose（用完记得改回来——verbose 很拖性能）。
• Chute Mac：主窗口的日志标签页。Chute iOS：仪表盘，或 HTTP 控制 API 的 GET /api/logs。
• 重点看警告行：未知策略、被拒绝的选项、无法解析的规则，都会在配置加载时以警告形式写进日志。