记录一次软路由 Passwall + V2Ray 代理排查全过程，踩了不少坑，整理出来希望能帮到有同样问题的人。

起因

我的网络结构是这样的：软路由（Kwrt/OpenWrt）运行 Passwall，Passwall 的节点指向本地一台电脑（10.0.0.112）上运行的 V2RayN 的 socks5 共享端口（10808）。这样软路由的流量就走本地 V2Ray 出去，同时 V2Ray 的日志我也能看到，方便排查是代理还是直连。

frpc 连接的 frps 服务器是一台美国 VPS（107.1.178.2），移动运营商经常屏蔽这类 IP 和可疑流量，所以我希望 frpc 连接 frps 的流量也能走代理出去。

问题一：frpc 配置了代理，但 V2Ray 看不到 107 这个 IP 的流量

frpc 配置了 transport.proxyURL = "socks5://10.0.0.112:10808"，理论上应该走 V2Ray，但 V2Ray 日志里完全没有 107.1.178.2 的记录。

后来发现 frpc 日志里有这条：

dial tcp 10.0.0.112:10808: connect: connection refused

说明 frpc 配置的代理地址是对的，但当时 V2Ray 的 socks5 端口没有正常监听，连接被拒绝了，frpc 就直连出去了。端口问题解决后，V2Ray 日志里终于能看到：

from tcp:10.0.0.112:12990 accepted tcp:107.1.178.2:7000 [socks >> proxy]

frpc 连 frps 的流量走代理这个问题算是解决了。然后通过解决下面的关于直连的问题，frpc这个代理配置就可以注释掉了。

问题二：浏览器直接访问 107.1.178.2:1011 还是直连，软路由日志没有记录

frpc 走代理没问题了，但我直接在浏览器访问 https://107.1.178.2:1011 时，软路由日志里完全没有这条流量记录，说明软路由把它直连放走了。

我明明在 Passwall 的访问控制里手动把这个 IP 加到了代理列表，但就是不走代理。

先用 SSH 进软路由排查：

nft list ruleset | grep -B 5 -A 2 "107.1.178.2"

发现这个 IP 出现在了两个 set 里，一个是代理 set，另一个是一个小列表，里面还有 10.0.0.112、1.1.1.1 这些。

继续查这个小列表的名字：

nft list ruleset | grep -B 20 "10.0.0.112" | grep "set "

结果是 passwall_vps。

根本原因找到了：passwall_vps 直连优先级最高

passwall_vps 这个 set 是 Passwall 自动生成的，它会把所有节点的服务器 IP 加进去，强制直连，目的是防止代理流量形成回环（代理节点的流量再次被代理，死循环）。

而 107.1.178.2 既是我的 frps 服务器，同时也是我配置在 Passwall 里的节点 IP，所以它被自动加进了 passwall_vps 直连列表。无论我怎么在代理列表里加这个 IP，passwall_vps 的直连优先级永远更高，直接覆盖了代理规则。

用这个命令确认了：

grep -r "107.1.178.2" /etc/config/passwall*

这个 IP 出现了 9 次（passwall 和 passwall2 各一堆），全都是节点配置里的 option address，说明这个 IP 被配置成节点太多次了，passwall_vps 永远会包含它。

解决方案：换域名访问

既然 IP 永远在 passwall_vps 直连列表里，那就不用 IP 访问，改用域名。

把 107.1.178.2 解析到一个子域名，在 Passwall 访问控制里加这个域名走代理。域名不会被加进 passwall_vps，所以代理规则能正常生效。换成域名访问之后，立刻能在 V2Ray 日志里看到流量走了代理。

核心规律：用这台服务器 IP 配置的节点，直接访问 IP 永远直连，换域名就行。

问题三：Cloudflare Tunnel 连接失败，TLS handshake EOF

同一台 VPS 上还跑着 cloudflared（Cloudflare Tunnel），日志一直报：

TLS handshake with edge error: EOF

连接 Cloudflare 边缘节点（198.41.x.x）时 TLS 握手被切断，移动运营商在干扰。

让 cloudflared 走软路由代理出去后，V2Ray 日志能看到流量走了代理：

from tcp:10.0.0.1:44420 accepted tcp:198.41.192.27:7844 [socks -> proxy-88]

但还是 EOF，说明代理节点本身连 Cloudflare 的 7844 端口也有问题。

试了一下在 Passwall 转发配置里把 7844 端口加到「TCP 不转发端口」，让 7844 直连出去，结果反而好了。

原因：cloudflared 使用的是私有 TLS 协议连接 Cloudflare edge，这类流量经过 V2Ray 的 socks5 代理时，V2Ray 的 sniffing（流量探测）会尝试解析 TLS 内容，导致握手数据被破坏，产生 EOF。7844 直连绕过了 V2Ray 的 sniffing，所以正常了。

解决：在 Passwall 基本设置 → 转发配置 → TCP 不转发端口里填入 7844，保存应用。

额外发现：为什么软路由透明代理不会回环

排查过程中一直有个疑问：软路由连着本机 V2Ray（10.0.0.112:10808），V2Ray 处理完流量发出去，发出去的流量不是又会被软路由拦截，再扔给 V2Ray，形成死循环吗？

实际上不会，原因是 Passwall 的 nftables 规则里有这条：

ip daddr 10.0.0.112 tcp dport 10808 return

目标是 10.0.0.112:10808 的流量直接放行不拦截。更关键的是，V2Ray 连接节点服务器时，节点 IP 在 passwall_vps 里，passwall_vps 里的 IP 全部直连放行，所以 V2Ray 发出的加密流量直接走网卡出去，不会再被 tproxy 拦截。

另一个发现：10.0.0.112 这台电脑即使 V2Ray 没有开系统代理，软路由照样会透明代理它的流量。因为 tproxy 只看数据包的源 IP，不区分是哪台设备，10.0.0.112 发出的浏览器流量照样会被拦截转给 V2Ray 处理。这台电脑自己就是 socks5 节点所在的设备，所以能正常用，不会回环。

关于 Passwall 域名分流看不到域名日志的问题

Passwall 透明代理模式下，V2Ray 日志里看到的全是 IP 地址，看不到域名。原因是透明代理拦截到的流量只有目标 IP，域名信息在 DNS 解析阶段已经消耗掉了。

Passwall 用的是 chinadns-ng 做 DNS 分流，不是 dnsmasq。通过 SSH 确认：

uci show passwall | grep dns
# 结果：passwall.@global[0].dns_shunt='chinadns-ng'

勾选「覆盖连接目标地址」后，Passwall 会从 TLS SNI 或 HTTP Host 头里探测域名，再传给 V2Ray。但前提是 V2Ray 的日志级别要开到 info，这样才能看到：

app/dispatcher: sniffed domain: example.com
app/dispatcher: taking detour [proxy-xx] for [tcp:example.com:443]

不过这个功能开了之后，有时候域名分流规则和 IP 分流规则会产生冲突，导致某些域名走了直连（比如我遇到的 claude.ai 在 chinadns-ng 运行时的 proxy_host 列表里没有，被当成默认直连处理）。如果不需要看域名日志，不开这个功能也完全没问题，分流是正常工作的。

总结

整个排查过程的核心发现：

1. passwall_vps 是 Passwall 防回环的核心机制，节点 IP 永远直连，想代理访问同一个 IP 必须用域名。

2. Cloudflare Tunnel 的 7844 端口走 V2Ray socks5 代理会因为 sniffing 导致 TLS 握手失败，把 7844 加到不转发端口直连即可。

3. 透明代理下看到的都是 IP，不是 V2Ray 的问题，是透明代理的工作原理决定的，想看域名要开日志 info 级别并启用覆盖连接目标地址。

4. 运行 V2Ray 的设备本身也会被软路由透明代理，不需要开系统代理也能科学上网，不会回环。

---