在 WSL2 (Manjaro) 环境下进行全栈开发时，我遇到了一个网络冲突问题。我的项目连接云端数据库（PostgreSQL），同时依赖 Github Copilot / Antigravity 等海外开发服务。
为了让 Github Copilot / Antigravity 的 AI 正常稳定运行，我开启了本地网络调试工具的 TUN (虚拟网卡) 模式。但开启后发现：Prisma 连接数据库会报错超时；关闭 TUN 模式数据库恢复，但我的 AI 又无法连接了。
这篇文章记录了该问题的排查过程，涉及 Fake-IP 机制 与 DNS 劫持 的冲突解决。
问题现象
环境信息：
- OS: Windows 11 + WSL2
- 网络环境: 开启了本地代理工具的 TUN 模式
- 数据库: 云端 PostgreSQL (AWS)
- ORM: Prisma
具体表现：
当开启 TUN 模式接管系统流量时，运行 npx prisma db pull，抛出以下错误：
Error: P1001
Can't reach database server at `xxx.pooler.supabase.com:5432`
Please make sure your database server is running...
与此同时，部分 OAuth 回调可能也会出现连接超时。关闭 TUN 模式后，数据库连接恢复正常。
排查过程
1. 检查 DNS 解析（发现端倪）
为了搞清楚网络层发生了什么，我在 WSL2 终端里 ping 了一下数据库域名：
ping aws-1-ap-northeast-2.pooler.supabase.com
返回的结果显示解析到了一个特殊的 IP 段：
PING xxx.supabase.com (198.18.0.18) 56(84) bytes of data.
64 bytes from 198.18.0.18: icmp_seq=1 ttl=64 time=0.297 ms
关键点： 解析结果是 198.18.0.18。
198.18.0.0/15 是网络基准测试保留网段，常被各类网络调试工具用于 Fake-IP (虚假IP) 模式。这说明 DNS 解析已经被工具劫持，返回了虚拟 IP 以便接管流量。
原因分析：
对于 HTTP 协议，Fake-IP 模式通常工作良好。但对于数据库连接（TCP 端口 5432），在这个虚拟 IP 的映射和流量转发过程中，可能出现了规则匹配失败或链路丢失，导致 ORM 无法通过这个“假 IP”建立真实的 TCP 连接。
解决方案
要解决这个问题，必须配置网络工具，让特定数据库域名绕过 Fake-IP 机制，直接解析出真实的公网 IP。
第一步：开启 DNS 覆写/接管
在你的网络工具设置中（通常在 DNS 设置板块），确保 DNS 覆写 (DNS Override) 或类似功能已开启。这一步是为了确保我们接下来的过滤规则能生效。
第二步：配置 Fake-IP 过滤 (关键)
我们需要将数据库域名添加到 Fake-IP 过滤列表 (Fake-IP Filter) 中。这个列表的作用是告诉工具：“遇到这些域名时，不要返回 198.18.x.x，请去查询并返回真实的公网 IP”。
在配置文件的 dns -> fake-ip-filter 字段，或者软件界面的“Fake IP 过滤”输入框中，追加以下内容：
, *.supabase.com, *.supabase.co, *.supabase.in
第三步：验证
保存配置并重启网络工具后，再次回到 WSL2 终端测试：
ping aws-1-ap-northeast-2.pooler.supabase.com
此时返回的应该是真实的公网 IP 地址（例如 52.x.x.x），而不再是 198.18.x.x。
再次运行 npx prisma db pull，数据库连接成功。
总结
在 WSL2 开发环境中，如果开启了网络工具的全局/TUN 模式，遇到非 HTTP 协议（如数据库连接、自定义 TCP 服务）连接超时，可以优先排查 DNS 解析结果。
如果发现解析 IP 为 198.18.x.x，说明走了 Fake-IP 模式。此时无需关闭 TUN 模式，只需在工具的 Fake-IP Filter 中排除相关域名，获取真实 IP 即可解决冲突。
