嗨，我来帮你拆解分析这个问题～

先理清楚你的核心场景和矛盾点：

• 你本地有Windows主机、带WireGuard+Nginx的RPI（本地IP 192.168.0.96，VPN网段10.6.0.0/24）、NAS
• 在外网连VPN时，能正常SSH本地192.168段设备，说明VPN的基础路由配置是没问题的
• 回到本地网络后，Windows连VPN只能通过RPI的VPN IP（10.6.0.1）SSH，用本地IP访问却失败；但WSL和手机连VPN时，却能同时用两种IP正常访问

问题根源 #

核心原因出在Windows WireGuard客户端的路由优先级和默认路由覆盖逻辑上：

看你的Windows WireGuard配置里写了AllowedIPs = 0.0.0.0/0, ::/0，这意味着所有流量都会被强制导向VPN隧道。当你在本地网络时，Windows要访问192.168.0.96，会把请求塞进VPN隧道发往RPI；而RPI收到后，会从VPN接口回包，但Windows此时的路由表已经把所有流量都导向VPN，导致回包路径异常，相当于形成了一个小的路由环路，自然无法正常连通。

而WSL和手机能正常工作的原因是：

• WSL本质是Windows上的轻量虚拟机，它的网络栈相对独立，不会完全被Windows的WireGuard路由规则覆盖，依然能优先匹配本地局域网的路由
• 手机的WireGuard客户端通常会自动识别本地网段并做路由例外（很多移动端VPN客户端默认会跳过本地流量），或者路由表优先级逻辑和Windows不同

两种可行的修复方案 #

方案1：修改Windows WireGuard配置，排除本地网段

把Windows配置里的AllowedIPs改成排除本地192.168.0.0/24网段，这样访问本地设备时走本地网络，其他流量走VPN：

[Interface]
PrivateKey = ...
Address = 10.6.0.5/24
DNS = 10.6.0.1

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 0.0.0.0/0, ::/0, !192.168.0.0/24
Endpoint = ...

注：!符号表示排除该网段，WireGuard会自动处理对应的路由优先级

方案2：在RPI上添加反向路由（适合不想修改Windows配置的情况）

在RPI上添加一条路由规则，让发往本地192.168.0.0/24网段的流量走本地eth0接口，而非VPN隧道：

ip route add 192.168.0.0/24 dev eth0 src 192.168.0.96 metric 100

如果要让这条路由永久生效，可以把命令加到RPI的WireGuard配置里（在wg0.conf的[Interface]段添加）：

[Interface]
PrivateKey = ...
Address = 10.6.0.1/24
ListenPort = ...
PostUp = ip route add 192.168.0.0/24 dev eth0 src 192.168.0.96 metric 100

验证方法 #

修改配置后重启Windows的WireGuard连接，然后：

1. 用route print命令查看Windows路由表，确认192.168.0.0/24网段的下一跳是本地网关，而非VPN接口
2. 尝试SSH 192.168.0.96，应该就能正常连通了

备注：内容来源于stack exchange，提问作者Strinnityk