QuickQ 连接后 IP 地址没变

QuickQ 连接后外网 IP 没变，通常是配置或分流问题：它可能只做应用级代理/本地代理而非全局 VPN、连接没有生效（回落到直连）、存在 IPv6/DNS 或 WebRTC 泄露，或运营商/局域网使用透明代理。逐项检查 QuickQ 的连接日志、分流/白名单设置、系统或浏览器代理、IPv6 与 DNS 设置，以及用 curl/traceroute/nslookup 验证外部路由与解析，基本上能定位并修复。

先用一句话把事情说清楚（费曼式的第一步）

当你打开 QuickQ 后，期望公共 IP 变为远端出口节点的 IP，但如果没变，说明你的流量并没有走到那个出口。要弄清楚“为什么没变”，先搞清三件事：QuickQ 实际有没有建立隧道／代理；哪些流量被转发；系统或网络有没有其它路径把请求送出。

为什么会出现“连接后 IP 没变”的常见原因

• 仅应用级代理而非全局隧道：有些工具只代理特定应用（浏览器、客户端）或提供 SOCKS/HTTP 代理，需要在浏览器或程序里单独配置，系统其他流量仍直接走本地网络。
• 分流（split tunneling）或白名单设置：QuickQ 或系统可能启用了分流，部分目的地/应用被排除在隧道之外，导致这些请求显示本地 IP。
• 连接失败或回落直连：看起来已连接，但实际隧道未建立或断开，软件自动回落到直连模式。
• IPv6 泄露：很多 VPN/代理只处理 IPv4，若系统同时使用 IPv6，外网服务可能通过 IPv6 看到你的本地地址。
• DNS 泄露：即便 HTTP/HTTPS 流量通过隧道，DNS 查询走了本地解析服务器，某些检测会据此判定为“没变”。
• 浏览器层面的 WebRTC 泄露：浏览器的 WebRTC 可直接暴露本机公网/局域网地址。
• 操作系统或路由表问题：路由表、默认网关设置不对或防火墙规则阻止了隧道流量。
• 运营商/局域网透明代理：有些网络（尤其企业、校园或运营商）会对外层使用透明代理或 NAT，使得即便你连接了远端，检测到的 IP 仍是本地网关或运营商出口。
• 缓存与测试方法误差：你用来检测 IP 的服务可能有缓存，或只是访问了本地化的镜像。

按步骤排查：从最简单到最复杂

下面是一个按逻辑排查的清单，按顺序做能最快定位问题。费曼方法要求把每一步都能说清楚：做了什么、为什么做、期望结果如何。

1）确认是否真的“连上”QuickQ

• 看软件界面：状态是否显示“已连接”？是否有隧道时长/流量计数？
• 检查系统的 VPN 指示（手机状态栏或系统网络偏好）是否出现。
• 查看 QuickQ 的日志：有没有错误、认证失败或建立隧道失败的记录。

2）在外部验证你的公网 IP（不要只看客户端内置提示）

在命令行或浏览器访问一个“看我公网 IP”的服务，优先使用多种方式交叉验证：

• 命令行（推荐）：
  • Linux/macOS: curl -4 ifconfig.me（IPv4）和 curl -6 ifconfig.me（IPv6）
  • Windows PowerShell: (Invoke-WebRequest ifconfig.me).Content
• 使用不同的网站或工具交叉比对（避免缓存误判）。

3）判断是全局问题还是仅浏览器/某应用问题

• 用 curl 或命令行工具发起请求，比较结果与浏览器显示是否一致。
• 若命令行显示 IP 改变，但浏览器不变：可能是浏览器代理或 WebRTC 问题。
• 若所有工具都显示未变：问题在系统/路由或 QuickQ 没生效。

4）检查分流/白名单/应用权限设置

打开 QuickQ 的设置，查找“分流”、“绕过 VPN”、“仅代理应用”等选项：

• 若启用分流，临时关闭分流使所有流量走隧道，再测一次。
• 检查是否对特定应用授权使用 VPN（特别是移动端的“按应用分配 VPN”设置）。

5）排查 IPv6 与 DNS 泄露

• IPv6：临时禁用系统的 IPv6（或在 QuickQ 中启用 IPv6 支持），再测 IPv6 地址。很多服务优先使用 IPv6，导致“看起来没变”。
• DNS：运行 nslookup baidu.com 或 dig（如果有）检查 DNS 响应来自哪个服务器；使用第三方的 DNS 泄露测试网站或工具。

6）浏览器专有问题：WebRTC 与代理设置

• WebRTC：在 Chrome/Edge 里，WebRTC 默认会尝试直接建立点对点连接，可能泄露本机地址。可通过浏览器设置或扩展屏蔽 WebRTC。
• 代理设置：确认浏览器是否使用系统代理或单独配置了 HTTP/SOCKS 代理。

7）查看路由表与网络接口

在遇到复杂路由问题时，查看路由表能告诉你“哪个网关被当作默认路由”。

• Windows: route print 或 netstat -rn
• macOS: netstat -rn 或 route get default
• Linux: ip route 或 route -n

预期：连接 VPN 后，默认路由应指向虚拟网卡（tun/tap）的网关；若仍指向本地物理网卡，流量不会通过隧道。

8）Traceroute（路由追踪）帮你看“流量走到哪儿”

• 用 traceroute（或 Windows 的 tracert）追踪到一个外部 IP，看第一跳是否到达 VPN 节点或仍然走本地 ISP。
• 注意：有些网络会对 ICMP/UDP 做限制，这会影响 traceroute 的可读性，但通常能看出第一、第二跳的差别。

具体修复建议（按场景）

如果是“只代理某个应用”

• 确认 QuickQ 的工作模式：全局 VPN（tun/tap）或代理（HTTP/SOCKS）。
• 若是代理，手动在需使用的应用里设置代理（浏览器/下载器），或用浏览器插件将流量导向代理。
• 如果你需要全局效果，切换到全局 VPN 模式或使用系统级 VPN 客户端。

如果是“分流导致部分流量走直连”

• 临时关闭分流/白名单，确认是否因此 IP 发生变化。
• 调整分流规则，确保目标服务域名或 IP 列表正确。

如果是“IPv6/DNS/WebRTC 泄露”

• 禁用 IPv6（临时测试），或在 QuickQ 中启用 IPv6 支持。
• 设置为使用远端 DNS（在 QuickQ 设置中或手动配置系统 DNS），并启用 DNS 通过隧道转发。
• 在浏览器中禁用 WebRTC 或安装阻止 WebRTC 泄露的扩展。

如果“QuickQ 显示已连接但路由未生效”

• 重启 QuickQ 客户端并重新连接；重启网络适配器或整机。
• 查看防火墙/安全软件是否阻止了虚拟网卡或隧道进程。
• 升级 QuickQ 到最新版本，或尝试桥接/不同协议（如 WireGuard、OpenVPN、Shadowsocks）看是否有区别。

一些常用诊断命令与示例说明

这些命令能帮助你在不同操作系统上快速定位问题（以 Linux/macOS/Windows 常用命令为例）：

目的	命令（示例）	期望/说明
查看公网 IPv4	curl -4 ifconfig.me	输出应为 QuickQ 节点的公网 IP（如果全局代理生效）。
查看公网 IPv6	curl -6 ifconfig.me	若显示本地 ISP 的 IPv6，说明 IPv6 未走隧道。
路由表	ip route（Linux） / route print（Windows）	检查默认路由指向哪个网卡（tun/tap vs eth/wlan）。
Traceroute	traceroute 8.8.8.8 / tracert 8.8.8.8	第一跳若为本地网关且未经过 VPN 节点，说明路由未生效。
DNS 查询来源	nslookup baidu.com / dig +short @resolver1.opendns.com myip.opendns.com	检查返回的 DNS 服务器是否为远端隧道侧的解析器。

当你已经尝试了上述步骤但仍旧没解决

• 收集日志：QuickQ 的连接日志、系统的路由表截图、traceroute 输出、curl 的原始输出。
• 联系 QuickQ 官方支持，提供以上日志与你所在网络环境（家用、公司、校园）说明。
• 在不同网络环境下复现：尝试用手机热点（移动数据）或另一 Wi‑Fi，看问题是否只在某个网络出现；若只在特定网络出现，很可能是运营商/局域网策略导致。

小结性建议（实际可操作的清单）

• 先确认 QuickQ 的工作模式（全局 VPN vs 应用代理）。
• 用 curl / 命令行确认 IPv4 与 IPv6 的公网地址。
• 临时禁用分流与 IPv6，禁用浏览器的 WebRTC，再测一次。
• 查看路由表，确认默认路由是否被隧道占用。
• 如果问题只在某一网络出现，优先怀疑运营商或局域网的透明代理。

说点更生活化的经验话

我遇到过好几次「看起来连上了但 IP 没变」的情况，最后发现很多是浏览器扩展或系统代理冲突导致的；也有一次是在公司网络，网络管理员在出口做了透明代理，连了 VPN 也还是走公司的出口。排查时别慌，按顺序一步步来：确认连接、确认路由、确认 DNS/IPv6，日志比直觉更可靠。

如果你愿意，可以把你做的具体几个检测结果贴出来（例如 curl 的输出、route/traceroute 的前几行、QuickQ 日志的报错片段），我可以帮你进一步读日志并指明最可能的修复方向。总之，这类问题基本上是“流量没走到你以为它走的地方”，把那条路找出来就好——有时候只是一个分流开关或一条路由没切换。