路由规则：VPN连接后路由表查看方法

凌晨三点十七分，我的Telegram群里炸了锅。一个叫“老K”的哥们儿发了一张截图，上面是他刚通过某海外交易所提现的USDT到账记录，但紧接着他又发了一条语音，声音里带着明显的焦躁：“操，我的节点是不是被劫持了？明明连上了VPN，但查路由表发现流量根本没走隧道，全他妈裸奔出去了！”

群里瞬间刷过几十条“+1”和“我也是”。我盯着屏幕，手里的冰美式已经没了气，但脑子却异常清醒——这已经不是第一次了。在虚拟币圈子里，尤其是玩链上交互、撸空投、做跨链桥套利的老手，VPN是标配，但百分之九十的人，根本不知道连上VPN之后，自己的路由表到底长什么样。他们以为点一下“连接”就万事大吉，实际上，你的数据包可能正大摇大摆地走ISP的默认网关，把钱包地址、私钥签名请求、甚至交易所的登录凭证，暴露在任何一个能抓包的中间节点面前。

这不是危言耸听。就在上周，有个做铭文打新的朋友，因为VPN分流规则写错，导致一笔价值2.8个ETH的转账交易在未加密的通道里被篡改了目标地址——虽然最后链上回滚了，但手续费亏了200多刀，更惨的是他那个钱包地址被标记了风险，后续所有白名单项目都把他拒了。

所以，今天这篇东西，我不打算跟你讲什么“VPN原理”或者“加密协议”的教科书内容。我就用老K这个真实事件作为引子，手把手带你在Windows、macOS、Linux甚至路由器上，把VPN连接后的路由表扒个底朝天，让你看清楚：你的数据到底是从哪条路走的，哪条路是安全的，哪条路是裸奔的。顺便，我会穿插几个虚拟币圈常见的坑，比如“连上VPN但交易所还是显示异地登录”、“撸空投时IP被识别为数据中心导致女巫”这些，全都能从路由表里找到答案。

---

二、事件复盘：老K的“假VPN”与真实路由表

先回到老K的截图。他用的是一款市面上口碑不错的商业VPN，协议是WireGuard，节点选的是日本东京。但他在群里喊“流量没走隧道”之后，我让他立刻打开命令行，执行了一条命令。他照做了，然后发出来的输出让我差点笑出声——不是因为问题搞笑，而是因为太典型了。

他执行的是 route print（Windows系统），输出里有一条关键信息：

活动路由: 网络目标 网络掩码 网关 接口 跃点数 0.0.0.0 0.0.0.0 10.8.0.1 10.8.0.2 50 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.105 25

看到没？两条默认路由，跃点数分别是50和25。Windows会优先选择跃点数小的那条，也就是25的，而那条的网关是192.168.1.1——这是他的家用路由器，也就是物理网卡的默认网关。而VPN分配的虚拟网卡10.8.0.2虽然也有一条默认路由，但跃点数50太高，根本不会被选中。

这意味着什么？意味着老K的VPN连接是“半吊子”——握手成功了，加密隧道建立了，但操作系统压根没打算把流量塞进隧道里。他的所有访问，包括打开交易所、广播交易、查询链上状态，全部是直接通过家用宽带发出的。那些数据包没经过WireGuard的加密封装，就赤裸裸地发到了ISP的机房。

为什么会出现这种情况？很简单：VPN客户端在配置路由表时，默认只添加了一条“按需路由”或“高跃点默认路由”，但Windows的“自动跃点”机制认为物理网卡的带宽更高（比如千兆光纤），所以给物理网卡分配了更低的跃点数。除非你手动修改，否则这种“假连接”会一直存在。

我让老K执行了另一条命令：route change 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 10。强制把VPN隧道的默认路由跃点数改成10。然后让他重新访问一个IP检测网站，果然，出口IP变成了东京的节点。但老K又问了第二个问题：“那我怎么确认，链上交易的数据包是不是也走了这个隧道？”

这个问题问得好。因为虚拟币交易不仅仅是HTTP请求，还有WebSocket长连接、RPC调用、甚至P2P节点同步。你要确认的是所有协议、所有端口的流量都走隧道，而不是只改了浏览器代理。

---

三、实战：Windows/ macOS / Linux 下查看路由表的正确姿势

3.1 Windows系统：别只盯着 route print，要看 Get-NetRoute

很多教程让你用 route print，但那个输出太冗长，而且不会告诉你哪个接口是VPN，哪个是物理网卡。我建议你用PowerShell，执行：

powershell Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Format-Table InterfaceAlias, NextHop, RouteMetric

这会列出所有默认路由，按跃点数排序。你会看到类似：

InterfaceAlias NextHop RouteMetric -------------------- ----------- ----------- WireGuard Tunnel 10.8.0.1 10 Ethernet 192.168.1.1 25

如果WireGuard Tunnel的RouteMetric不是最小的那个，那么恭喜你，你正在裸奔。这时候你需要用管理员权限执行：

powershell Set-NetRoute -DestinationPrefix "0.0.0.0/0" -InterfaceAlias "WireGuard Tunnel" -NextHop "10.8.0.1" -RouteMetric 5

改完之后，再用上面的命令查一遍，确保WireGuard的跃点数最小。

但这里有个虚拟币圈特有的坑：如果你同时运行了多个VPN，比如一个用来连交易所，一个用来连链上节点，那么路由表里会有多条默认路由，而且可能互相冲突。最典型的是，你用了A VPN连Coinbase，又用B VPN连Uniswap的RPC，结果A VPN的隧道覆盖了B的，导致你的Uniswap交易请求走了Coinbase的出口IP——如果Coinbase的风控系统检测到你的IP同时登录了另一个交易所的账户，可能会触发关联封禁。所以，一定要用 Get-NetRoute 看清楚每条路由的接口和跃点数，必要时用 Remove-NetRoute 删掉不用的默认路由。

3.2 macOS系统：netstat -rn 是基础，route -n get default 才是关键

macOS上，很多人习惯用 netstat -rn 查看路由表，但那个输出里，Flags 一栏的 U 和 UG 让你分不清哪条是VPN的。我教你一个更直接的方法：

bash route -n get default

输出会告诉你当前默认路由的接口名和网关。如果接口名是 utun4 或 ipsec0，那说明流量走的是VPN隧道；如果接口名是 en0（Wi-Fi）或 en1（以太网），那说明你白连了。

macOS的隧道跃点数调整比较麻烦，因为系统不直接暴露“跃点数”设置。但你可以用 ifconfig 查看接口的 mtu 和 flags，然后通过修改路由表优先级：

bash sudo route change default -ifscope utun4

这条命令会把默认路由强制绑定到utun4接口上。但注意，macOS重启后这个修改会失效，建议写个开机脚本。

虚拟币场景提示：如果你用macOS做链上开发，经常要连接本地节点（比如 http://127.0.0.1:8545）。这时候你千万别让VPN把127.0.0.1这个回环地址也劫持了。检查路由表时，确保有一条 127.0.0.0/8 指向 lo0 接口的规则，而且优先级高于VPN的默认路由。否则你的RPC请求会先被VPN加密，然后发到VPN服务器，再绕回本地，延迟暴增且可能被中间人篡改。

3.3 Linux系统：ip route show 和 ip rule show 双管齐下

Linux是虚拟币矿工和跑节点的人最常用的系统。但正因为Linux太灵活，很多人用 iptables 或 ip route 做策略路由，导致问题更隐蔽。

先执行 ip route show，看默认路由：

default via 10.8.0.1 dev tun0 proto static metric 50 default via 192.168.1.1 dev eth0 proto dhcp metric 100

这里 tun0 是VPN接口，eth0 是物理网卡。如果 metric 50 小于 100，那默认走VPN。但Linux还有个 策略路由 的概念，用 ip rule show 查看：

0: from all lookup local 32766: from all lookup main 32767: from all lookup default

如果你有额外的规则，比如 from 192.168.1.105 lookup vpn_table，那意味着只有源IP是192.168.1.105的流量才走VPN，其他流量还是走主路由表。这时候你光改默认路由没用，得修改 vpn_table 里的规则。

虚拟币圈经典错误：很多人跑节点时，为了“安全”，把SSH端口也强制走VPN，结果VPN一断，服务器彻底失联。正确做法是，用 ip rule 把SSH流量（目的端口22）单独分流到物理网卡，而把RPC端口（比如8545）分流到VPN。命令参考：

bash ip rule add dport 22 table main priority 100 ip rule add dport 8545 table vpn_table priority 200

这样即使VPN挂了，你还能SSH进去修复。但要注意，千万别把钱包的广播端口（比如UDP 30303）也强制走VPN，因为P2P节点需要公网IP直连，如果走了VPN，你的节点会变成“隐藏节点”，影响出块奖励。

---

四、进阶：用 traceroute 和 tcpdump 验证你的交易数据包是否真的走了隧道

光看路由表还不够，因为有些VPN客户端（比如Clash、Surge）是基于代理模式的，它们不修改系统路由表，而是通过TUN虚拟网卡劫持流量。这时候路由表显示的是 utun 接口，但你不知道具体某个端口的流量是否被代理规则捕获。

方法一：traceroute 到交易所的API服务器

假设你用的交易所API域名是 api.coinbase.com，先 nslookup 得到IP，然后：

bash traceroute -p 443 <交易所IP>

如果你看到第一跳就是VPN的网关（比如 10.8.0.1），那说明流量进了隧道。如果第一跳是你家路由器（192.168.1.1），那说明走了物理网卡。

但这个方法有个问题：很多交易所的API服务器用了CDN，IP会变。而且 traceroute 只显示路径，不显示加密状态。所以更精确的是用 tcpdump。

方法二：tcpdump抓包，看是否有WireGuard的UDP包

WireGuard协议默认是UDP 51820端口。你在VPN服务器端（或者本地）执行：

bash tcpdump -i eth0 udp port 51820

然后你在另一台机器上发起一笔测试交易（比如转账0.0001 ETH），如果抓包显示有UDP包发往VPN服务器的IP，那说明你的交易数据确实被封装进了隧道。如果抓不到，只有TCP 443的包（HTTPS），那说明你的交易请求是直接发的明文HTTPS，没走VPN。

虚拟币场景：链上交易最怕的不是“被看到IP”，而是“被篡改交易内容”。如果你用HTTPS访问RPC节点，那数据是加密的，但IP暴露了，交易所或节点可以关联你的钱包地址和家庭IP。如果你用VPN，但路由表没生效，那你的IP还是暴露的。所以抓包验证是必须的，特别是当你用某个不常见的RPC端口（比如8545）时，很多VPN的代理规则默认不劫持非标准端口，导致你的JSON-RPC请求直接裸奔。

我见过一个真实案例：有个朋友用Infura的RPC节点做套利机器人，他连了VPN，但Infura的API走的是443端口，他的VPN客户端（某机场）只劫持了TCP 443，但没劫持UDP，而他的套利脚本用的是WebSocket（ws://），走的是TCP 80端口——结果所有订单数据都暴露了，被一个恶意MEV机器人抢跑，损失了3万多U。

---

五、路由器层面：OpenWrt 上查看和修改路由表，让全屋设备都走VPN

如果你是重度玩家，家里有矿机、多个钱包、多个节点，那最好在路由器上做全局VPN。OpenWrt是首选，因为它的路由表完全可控。

SSH进路由器，执行：

bash ip route show table all

你会看到多个路由表，比如 main、default、vpn。OpenWrt的VPN插件（比如mwan3或wireguard）会创建独立的策略路由表。

查看当前默认路由：

bash ip route show default

如果默认路由指向的是 pppoe-wan（宽带拨号），而不是 wg0（WireGuard接口），那你需要修改：

bash ip route replace default via 10.0.0.1 dev wg0

但这里有个更高级的玩法：按目的IP分流。比如，你想让所有访问以太坊节点（IP段为 1.2.3.0/24）的流量走VPN，而其他流量走宽带。可以用：

bash ip rule add to 1.2.3.0/24 lookup vpn_table priority 500 ip route add table vpn_table default via 10.0.0.1 dev wg0

这样，你的钱包广播交易时，目标节点IP命中规则，自动走VPN；而你刷YouTube时，流量走宽带，不浪费VPN流量。

虚拟币圈特别提醒：如果你在路由器上跑了 adblock 或 dnsmasq，记得检查DNS解析是否也走VPN。因为很多恶意攻击是DNS劫持——你的钱包连的节点域名被解析到一个假IP，即使路由表正确，流量也会被送到攻击者服务器。在OpenWrt上执行：

bash nslookup api.etherscan.io

如果返回的IP不是你预期中的（比如被污染成某个海外IP），那你需要在 dnsmasq 配置里指定上游DNS为VPN提供的DNS（比如 10.8.0.1），并强制所有DNS查询走VPN隧道。

---

六、事件结局与自查清单

老K最后在我的指导下，用PowerShell修改了跃点数，然后用 tcpdump 抓包确认了WireGuard的UDP包确实在传输。他又检查了交易所的登录日志，发现之前的“异地登录”警告消失了。但他还是心有余悸，因为那笔2.8ETH的差点被篡改的交易，让他意识到路由表不仅仅是网络技术，而是资产安全的第一道防线。

现在，我给你一份自查清单，你可以照着做一遍：

1. Windows：打开PowerShell（管理员），执行 Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric，确认VPN接口的跃点数最小。
2. macOS：执行 route -n get default，确认接口名是 utun 或 ipsec，而不是 en0。
3. Linux：执行 ip rule show 和 ip route show table all，确认没有遗漏的策略路由，且默认路由的metric正确。
4. 所有系统：执行 traceroute -p 443 <你的交易所API域名>，看第一跳是否是VPN网关IP。
5. 抓包验证：用 tcpdump 或 Wireshark 过滤 udp port 51820，发起一笔小额测试交易，确认有加密UDP包发出。
6. DNS检查：nslookup 你的RPC节点域名，确保解析结果不是被污染的IP。

如果以上任何一步没通过，那你的VPN就是“假VPN”，你的币可能正在裸奔。记住，在虚拟币的世界里，你的IP就是你的身份，你的路由表就是你的保险箱。别让保险箱的钥匙，插在别人家的锁孔里。