代理套代理为什么会全网断开？怎样识别代理循环
系统代理、TUN、上游 SOCKS 和 dialer-proxy 若把客户端自己的出站重新送回本地入口，会形成循环。先还原单层路径，再逐层增加。
先看重点先关闭浏览器扩展、第二款 VPN、上游代理和 dialer-proxy，只保留一个客户端与一个确定可用节点。若恢复，按“应用 → 本地端口 → 节点 → 目标”逐层加回。日志里同一本地端口或进程反复建立连接、流量上涨却没有外部请求完成，是循环信号。
代理链本身可以是合法设计。Mihomo 的 dialer-proxy 就允许一个节点通过另一个节点建立连接。但如果“上游”最终又指回当前客户端自己的本地入口，数据会在本机反复绕圈，始终到不了真正节点。
循环也可能来自两款客户端：A 的系统代理指向 B，B 的上游又指向 A；或者 TUN 把 Mihomo 自己连接节点的出站再次抓回 TUN。
常见的循环结构
- 应用设置 SOCKS
127.0.0.1:7891，而该 SOCKS 出站又配置回同一端口； - Clash A 的上游代理是 Clash B，B 的系统代理又指向 A；
- 浏览器扩展代理到本地端口，同时扩展规则让客户端控制页或上游重复进入；
- TUN 没有正确识别物理出口，把内核连接节点的流量重新导入虚拟网卡；
dialer-proxy的策略组经过若干引用后又选回原节点。
合法的两跳链必须最终走向不同的外部服务器，而且依赖关系不能闭环。
代理循环通常怎样表现
- 开第二层代理后立刻全网超时，关掉就恢复；
- 客户端 CPU、连接数或流量快速上涨；
- 日志反复出现相同本地地址、端口或进程；
- 节点延迟测试全部超时，但直连网络正常；
- 控制面还能打开，外部目标没有任何响应；
- 错误在 timeout、too many open files、connection reset 之间变化。
这些只是信号。端口冲突、节点全挂或 TUN 路由错误也可能相似，所以要靠逐层还原确认。
先回到一条最短路径
- 关闭第二款 VPN/代理客户端；
- 关闭浏览器代理扩展和应用内上游代理；
- 移除自定义
dialer-proxy，保留原始订阅节点； - 关闭 TUN，只用当前客户端系统代理；
- 选一个已知可用节点访问同一目标。
恢复后一次只加回一层，每一步记录“上游地址最终指向哪里”。当某一步再次断网，根因就在新加的依赖附近。
TUN 要给内核自己的出站留出口
Mihomo 的 auto-detect-interface 用于自动选择流量出口，多网卡环境也可明确指定 interface-name。这不是让节点绕过规则，而是确保内核建立到节点服务器的底层连接能从物理网卡发出，而不是再次进入自己。
不要随便把所有私网或全部进程排除 TUN。先确认当前物理网卡和节点服务器流量，再做最小范围调整。
dialer-proxy 的链路要画出来
官方示例中，ss1 通过 ss2 拨号，最终访问目标；这是有方向的两跳。逐项写成：
应用 → Mihomo 入站 → ss1 → ss2 → 互联网如果任何箭头回到同一个 Mihomo 入站或先前节点，就存在环。策略组名称很多时，不要只看当前 UI 选中项，应检查最终配置里的引用。
修复后的验收
保留确实需要的最少层数，连续访问多个目标，确认连接数不会无界增长，日志中每个入站只有一条可解释的出站链。若单层已经满足需求，就不必为了“更隐蔽”增加第二层；多一跳也会增加延迟、故障点和运营方可见范围。
资料来源
以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……