wangyaominde

human:


你这个架构光猫能看到的就只有一个 ikuai 来的 pppoe ，像是 ikuai 的问题，有几个方向，一个是代理节点抖、掉线，疯狂重连，还有一个可能是 v2 那台机器开了 mux ，但是服务端不支持，最后一个可能是你自己操作 v2 那台机器当代理出口，用 ikuai 打到 v2 机器，然后递归了，自己建立的连接又发回自己，流量回环了属于是，如果设置过透明代理，大概率是第三种问题


自己觉得可读性太差 ai 整理了下：


这个架构下，如果光猫是桥接，光猫侧基本只看到 iKuai 发起的 PPPoE 会话，不太像是光猫单独被 v2rayA 的 1w 连接打挂，更像是 iKuai 或 10.160.3.100 这台机器把连接数/NAT 表/CPU 打满了。

可以重点看几个方向：

1. 代理节点或中间链路抖动、掉线，v2rayA 没有做好连接上限或重试退避，导致疯狂重连；
2. v2rayA 开了 mux ，但服务端不支持或兼容性不好，导致连接异常、反复重试；
3. 10.160.3.100 被当成透明代理/DNS/代理出口后，路由规则写错，自己发起的代理连接又被 iKuai 或本机规则打回 10.160.3.100 ，形成流量回环。

如果你之前设置过透明代理、旁路由、DNS 分流、端口转发之类的规则，我觉得第三种概率最大。建议先关掉透明代理、mux 、局域网共享，只保留手动 SOCKS/HTTP 代理测试；同时看 iKuai 上 10.160.3.100 的实时连接数和 NAT 会话数。如果关掉 v2rayA 全网立刻恢复，基本就能定位到这台机器或它的代理规则了。