[{"data":1,"prerenderedAt":226},["ShallowReactive",2],{"blog:ip-still-shows-china-after-vpn":3},{"zh-CN":4,"en":124},{"blocks":5,"faq":108},[6,9,11,13,17,19,27,29,31,45,48,59,62,64,66,68,71,79,82,90,92,95,97,99,101,104,106],{"type":7,"html":8},"p","连上以后打开一个查 IP 的网站，结果显示的还是国内地址——第一反应大多是「没生效」，但多数情况下，这只是验证方式不对，连接本身是正常的。真的没生效当然存在，只是排在原因列表比较靠后的位置。",{"type":7,"html":10},"比较典型的场景是：刚点了连接，提示「已连接」的瞬间就切到浏览器查 IP，结果和断开时一模一样，于是断定没用，反手就去重装应用、换账号、到处找教程。等真正查清楚，往往发现只是查得太早，或者用错了查询入口，连接从头到尾都没出问题。",{"type":7,"html":12},"这篇先给一套正确的验证步骤，再按从常见到少见的顺序讲清楚查到「还是国内」可能对应哪几种情况。原则不变：每次只改一个变量，别在没验证清楚之前就同时换节点、重装应用、重启设备，那样问题解决了也不知道是哪一步起的作用。",{"type":14,"id":15,"html":16},"h2","bp-triage","先按顺序验证一次",{"type":7,"html":18},"大多数误判都是验证步骤本身出了问题，先按这个顺序走一遍，能排除掉一半的「假警报」，剩下没解释清楚的才值得继续往下细查。",{"type":20,"items":21,"ordered":26},"list",[22,23,24,25],"断开 VPN，先查一次原始 IP，记住地区和城市，作为对照基准","连接 VPN，等待五到十秒让连接完全稳定，不要连上立刻就查","用同一个查询网站再测一次，中途不要换成另一个网站","如果结果还是没变，换一个只支持 IPv4 或者只支持 IPv6 的查询方式各测一次",true,{"type":7,"html":28},"这四步花不了一分钟，但能直接定位问题出在哪一层——如果第三步就已经显示新地址，那说明一开始查得太早或者用错了对照，连接本身没有问题；如果到第四步才有变化，说明走的是 IPv6 那条路没被接管，方向完全不同，往下看对应的原因。",{"type":7,"html":30},"第三步之前还有一个更快的对照：应用自己通常就会显示当前的出口地址。拿它和查询网站的结果比一下，两边对不上，说明问题出在查询方式上，不在隧道本身。",{"type":32,"src":33,"alt":34,"caption":35,"width":36,"height":37,"sources":38},"figure","\u002Fimg\u002Fapp-mac-connected-zh.png","快橙 macOS 界面上显示当前连接的节点和出口地址","应用里显示的这个地址，就是拿去和查询网站对照的那一个",577,1200,[39,42],{"type":40,"srcset":41},"image\u002Favif","\u002Fimg\u002Fapp-mac-connected-zh.avif",{"type":43,"srcset":44},"image\u002Fwebp","\u002Fimg\u002Fapp-mac-connected-zh.webp",{"type":14,"id":46,"html":47},"bp-cache","最常见的原因：查得太快",{"type":49,"items":50},"steps",[51,55],{"title":52,"body":53},"怎么确认",[54],"连接成功的提示出现以后马上打开查询网站，很多客户端在提示「已连接」的那一刻，底层的路由和 DNS 还在切换过程中，这时候查到的结果可能还是切换前的状态，等一两秒切换彻底完成，结果就会正常。这个时间差通常很短，但足够让心急的第一次查询显示错误的结果。",{"title":56,"body":57},"怎么处理",[58],"等五到十秒再查，或者刷新一次查询页面而不是立刻相信第一次的结果。如果查询网站本身有缓存机制，同一个页面刷新可能还是拿旧结果，换成重新打开一个新的查询页面更可靠。",{"type":14,"id":60,"html":61},"bp-wrong-checker","第二种原因：查询网站本身没查到隧道流量",{"type":7,"html":63},"不是所有「查 IP」的入口都在查同一件事。有些手机应用内置的网络状态显示、部分超级 App 里的小程序查询功能，走的是自己的内部接口，不一定经过系统级别的网络路由，查到的结果和浏览器里直接打开一个独立查询网站可能不是同一条路径。",{"type":7,"html":65},"举个具体例子：某些内置在社交、支付类超级 App 里的「查网络环境」小工具，读取的是这些 App 自己服务器记录的登录地区，而不是当前这一次连接实际的出口地址，两者更新的时机完全不同步，App 内显示滞后一两天都不算罕见。这类工具本来就不是为了检测 VPN 而设计的，拿来当验证标准会一直得到误导性的结果。",{"type":7,"html":67},"这种情况下，换成在系统自带浏览器里直接访问一个独立的查询网站重新测，比继续相信应用内置的显示更准确。两边结果不一致时，优先相信浏览器里测出来的，而不是纠结哪个 App 说的才对。",{"type":14,"id":69,"html":70},"bp-routing","第三种原因：分流规则把查询网站直连了",{"type":49,"items":72},[73,76],{"title":52,"body":74},[75],"多数客户端会把明显是「国内」的网站直接放行，不走隧道，这样能减少不必要的绕行，提升访问国内站点的速度。问题是部分查询网站的服务器实际部署在国内机房，或者用了国内的 CDN 加速，规则表可能把它也归类成「直连」，于是查到的正好是真实的本地地址，而不是隧道那一端的地址——规则本身没有出错，只是恰好把验证工具当成了不该走隧道的目标。",{"title":56,"body":77},[78],"把分流模式切换成全局模式，再重新查一次。如果这时候地址变了，说明确实是分流规则把这个查询网站排除在隧道之外，换一个查询网站测试就能绕开，不需要一直用全局模式。这和「已连接却打不开网页」背后是同一层机制，\u003Ca href=\"\u002Fblog\u002Fvpn-connected-but-no-internet\u002F\">VPN 显示已连接，却打不开网页\u003C\u002Fa>里有更完整的分流排查顺序。",{"type":14,"id":80,"html":81},"bp-silent-fail","第四种原因：其实没有真的连上",{"type":49,"items":83},[84,87],{"title":52,"body":85},[86],"前三种原因排除以后，如果多次验证都确认地址完全没变，就该往回退一步，怀疑连接本身。有些情况下客户端界面显示「已连接」，但隧道握手其实没有完全成功，界面状态没有及时反映真实情况。",{"title":56,"body":88},[89],"断开重连一次，重连成功以后按前面的四步顺序重新验证。如果依然查不到变化，检查系统里是否残留了别的代理设置——之前装过别的工具留下的旧配置，有时候会让新客户端连上了却没有真正接管流量，界面显示「已连接」只代表客户端自己这一层握手成功，不代表系统的流量转发规则真的切了过去。这一层的排查见\u003Ca href=\"\u002Fblog\u002Fvpn-connected-but-no-internet\u002F\">VPN 显示已连接，却打不开网页\u003C\u002Fa>，里面按 DNS、分流规则、系统代理、节点这四层讲得更细。",{"type":91},"downloads",{"type":14,"id":93,"html":94},"bp-ipv6","容易被忽略的 IPv6 泄漏",{"type":7,"html":96},"前面四种原因都排除了，还有一种情况容易被漏掉：设备同时具备 IPv4 和 IPv6 两套网络能力，VPN 只接管了其中一套，通常是 IPv4。如果查询网站优先走 IPv6，看到的可能就是没经过隧道的真实地址，而换一个只支持 IPv4 的查询方式测，结果却完全正常，两次查询看起来像是矛盾的，其实是查了两条不同的路。",{"type":7,"html":98},"这种情况的关键特征是：同一台设备，换不同的查询网站会得到不一样的结论，有的显示已经变了，有的显示没变，而且这个现象相对稳定，不是偶尔一次的巧合，每次用同一个网站测都是同样的结果。移动网络环境下 IPv6 覆盖率这几年提升得很快，家用宽带很多也默认开着，这也是这类「部分泄漏」比几年前更容易遇到的原因之一。",{"type":7,"html":100},"这本质上和\u003Ca href=\"\u002Fblog\u002Fdns-leak-check-guide\u002F\">DNS 泄漏是什么，怎么自查\u003C\u002Fa>里说的是同一类问题：一部分流量走了隧道之外的另一条路，只是这里泄漏的是 IP 地址本身，那篇里泄漏的是域名解析请求，机制相通。判断和处理方式那篇讲得更完整，这里不重复展开，怀疑是这个原因的话直接去那篇按步骤自查即可。",{"type":14,"id":102,"html":103},"bp-final","总结",{"type":7,"html":105},"查到 IP 还显示国内，先怀疑验证方式本身：查得太快、用错了查询入口、分流规则把查询网站直连了，这三种加起来占了大多数情况，而且都不代表连接本身有问题。真的没连上和 IPv6 泄漏反而是比较少见的两种，排在后面查更合理，别一上来就往这两个方向想。",{"type":7,"html":107},"如果每次连接后都要靠自己一步步验证才放心，说明客户端在这件事上做得还不够透明。\u003Ca href=\"\u002Ffeatures\u002F\">快橙\u003C\u002Fa>连接状态和实际路由是一致的，显示已连接就代表流量确实在走隧道，不需要每次都自己反复验证。如果按上面的步骤查完依然不确定，把两次查询的截图、用的查询网站名称一起发给\u003Ca href=\"\u002Fcontact\u002F\">客服\u003C\u002Fa>，比自己继续猜更快有结果，也更容易判断到底是哪一层出的问题。",[109,112,115,118,121],{"q":110,"a":111},"换了个查询网站，结果又不一样了，到底该信哪个？","不同查询网站用的定位数据库不完全一样，小范围不一致很常见。真正该关注的是地区大方向对不对，而不是具体城市或者运营商名字是否一致。",{"q":113,"a":114},"IP 没变是不是说明 VPN 没生效？","不一定。多数情况是查得太快，或者查询网站本身有缓存，真的没生效反而是比较少见的原因。先按验证步骤重新测一次，再下结论。",{"q":116,"a":117},"查到的地区和我选的节点地区不完全一致，正常吗？","正常。定位数据库更新速度不一样，同一个 IP 段在不同查询站点上可能显示相邻的地区或城市，这类误差不代表没生效。",{"q":119,"a":120},"IPv6 会不会让 VPN 白连了？","有可能。如果设备同时有 IPv6 直连能力，一部分支持 IPv6 的网站会看到真实地址，这属于\u003Ca href=\"\u002Fblog\u002Fdns-leak-check-guide\u002F\">DNS 泄漏是什么，怎么自查\u003C\u002Fa>里提到的同一类问题。",{"q":122,"a":123},"快橙一般多久能查到 IP 变化？","连接稳定以后立刻就能查到新地址，不需要特意等待。如果查了好几次都没变化，按下面的步骤重新验证一次，比继续刷新更有效。",{"blocks":125,"faq":210},[126,128,130,132,134,136,142,144,146,155,157,167,169,171,173,175,177,185,187,195,196,198,200,202,204,206,208],{"type":7,"html":127},"Connect, open an IP checker, and it still shows a domestic address — the first instinct is almost always "it did not work," but most of the time this is simply the wrong way to verify, and the connection itself is fine. A genuine failure does happen, it just sits fairly far down the list of causes.",{"type":7,"html":129},"A typical version of this: the instant "connected" appears, you switch straight to the browser and check, get exactly the same result as before disconnecting, decide it is broken, and go reinstall the app, switch accounts, or search for a fix. By the time it is actually sorted out, the usual discovery is that the check happened too early or through the wrong checker, and the connection was never the problem.",{"type":7,"html":131},"This article gives a proper verification sequence first, then walks through what "still shows China" can mean, most likely cause first. The rule stays the same: change one variable at a time. Do not switch the node, reinstall the app and restart the device all at once before you have even verified anything: fix something that way and you will not know which step did it.",{"type":14,"id":15,"html":133},"Verify it properly, in order",{"type":7,"html":135},"Most false alarms come from a flawed verification method. Work through this sequence first, and it clears up half of them before you even get to a real cause.",{"type":20,"items":137,"ordered":26},[138,139,140,141],"Disconnect the VPN and check your original IP once, noting the region and city as a baseline","Connect the VPN and wait five to ten seconds for the connection to fully settle; do not check the instant it connects","Test again on the exact same checker site; do not switch to a different one mid-way","If it still shows no change, try an IPv4-only checker and an IPv6-only checker separately",{"type":7,"html":143},"These four steps take under a minute, and they immediately point at which layer the problem is in. If step three already shows the new address, the check was simply too early or compared against the wrong baseline, and the connection itself is fine. If nothing changes until step four, that points at IPv6 traffic that never got taken over, a different direction entirely covered further down.",{"type":7,"html":145},"There is a shortcut worth taking before step three: the client itself usually names the address it is using. Compare that with what the checker site reports, and a mismatch says the problem is in the checking rather than in the tunnel.",{"type":32,"src":147,"alt":148,"caption":149,"width":36,"height":37,"sources":150},"\u002Fimg\u002Fapp-mac-connected.png","The Fast Orange VPN macOS window showing the connected node and the address it is using","The address the app reports is the one to compare against the checker site",[151,153],{"type":40,"srcset":152},"\u002Fimg\u002Fapp-mac-connected.avif",{"type":43,"srcset":154},"\u002Fimg\u002Fapp-mac-connected.webp",{"type":14,"id":46,"html":156},"The most common cause: checking too fast",{"type":49,"items":158},[159,163],{"title":160,"body":161},"How to confirm it",[162],"Opening a checker site the instant "connected" appears catches many clients mid-transition — routing and DNS are still switching over right as that message shows, so what you see can still reflect the state from before the switch. Give it a second or two to fully settle and the result comes back correct. The window is short, but long enough for an impatient first check to show the wrong thing.",{"title":164,"body":165},"How to fix it",[166],"Wait five to ten seconds before checking, or reload the checker page instead of trusting the very first result. If the checker site itself caches results, reloading the same page may still return the old answer; opening a fresh page is more reliable.",{"type":14,"id":60,"html":168},"The second cause: the checker is not seeing tunnel traffic at all",{"type":7,"html":170},"Not every "check my IP" entry point is checking the same thing. Some phone apps' built-in network-status displays, and mini-programs inside certain super-apps, run on their own internal APIs rather than going through system-level network routing, so what they show can be a completely different path from opening an independent checker site in a browser.",{"type":7,"html":172},"A concrete example: a "check your network" tool built into a social or payments super-app often reads the login region its own servers recorded, not the actual exit address of this specific connection. The two update on entirely different schedules, and the in-app display lagging by a day or two would not be unusual. Tools like this were never designed to detect a VPN in the first place, and using them as your verification standard just keeps producing misleading results.",{"type":7,"html":174},"When this happens, switch to opening an independent checker site directly in the system's own browser and retest: that is more accurate than continuing to trust an in-app display. When the two disagree, trust the browser result, not whichever app you are arguing with yourself about.",{"type":14,"id":69,"html":176},"The third cause: a routing rule sent the checker site direct",{"type":49,"items":178},[179,182],{"title":160,"body":180},[181],"Most clients let anything that is obviously a "domestic" site go direct instead of through the tunnel, which cuts out unnecessary detours and speeds up domestic sites. The catch is that some checker sites' servers are actually hosted domestically, or run behind a domestic CDN, and the rule list may classify one as "direct" too — so what you see really is your genuine local address rather than the tunnel's. The rule is not wrong; it just happened to treat your verification tool as something that should not go through the tunnel.",{"title":164,"body":183},[184],"Switch routing to global mode and check again. If the address changes, a routing rule really was excluding this checker site from the tunnel — testing with a different checker site sidesteps it, so you do not need to stay in global mode permanently. This is the same underlying mechanism as "connected but nothing loads," and \u003Ca href=\"\u002Fen\u002Fblog\u002Fvpn-connected-but-no-internet\u002F\">VPN connected but no internet\u003C\u002Fa> has the fuller routing-rule sequence.",{"type":14,"id":80,"html":186},"The fourth cause: it never actually connected",{"type":49,"items":188},[189,192],{"title":160,"body":190},[191],"Once the first three causes are ruled out, if repeated checks keep confirming the address genuinely has not changed, step back and suspect the connection itself. In some cases the client's interface says "connected" while the tunnel handshake never fully completed, and the displayed state simply has not caught up with reality.",{"title":164,"body":193},[194],"Disconnect and reconnect once, then redo the four verification steps above after it reconnects. If it still shows no change, check for a leftover proxy setting in the system — an old configuration left behind by a different tool can let a new client connect on its own layer without actually taking over traffic. "Connected" in the interface only means the client's own handshake succeeded, not that the system's traffic routing actually switched over. \u003Ca href=\"\u002Fen\u002Fblog\u002Fvpn-connected-but-no-internet\u002F\">VPN connected but no internet\u003C\u002Fa> covers this layer in more detail, working through DNS, routing rules, the system proxy and the node.",{"type":91},{"type":14,"id":93,"html":197},"The IPv6 leak that is easy to miss",{"type":7,"html":199},"With the first four causes ruled out, there is one more case that slips through easily: the device has both IPv4 and IPv6 connectivity, and the VPN only took over one of them, usually IPv4. If a checker site prefers IPv6, what it sees can be the real address that never went through the tunnel, while switching to an IPv4-only checker comes back completely normal — the two results look contradictory, but they simply checked two different paths.",{"type":7,"html":201},"The telltale sign is that the same device gives different answers on different checker sites, some showing the change and some not, and the pattern is stable rather than a one-off coincidence, the same site giving the same answer every time you test it. IPv6 coverage on mobile networks has grown quickly over the last few years, and plenty of home broadband has it on by default too, which is part of why this kind of partial leak is easier to run into now than a few years ago.",{"type":7,"html":203},"This is fundamentally the same category of problem as \u003Ca href=\"\u002Fen\u002Fblog\u002Fdns-leak-check-guide\u002F\">What a DNS leak is and how to check for one\u003C\u002Fa>: part of the traffic is taking a path outside the tunnel. Here what leaks is the IP address itself; there it is the DNS lookup, though the underlying mechanism is the same. That article covers how to confirm and fix it in more depth, so this one will not repeat it — if this looks like your cause, go work through the steps there directly.",{"type":14,"id":102,"html":205},"In summary",{"type":7,"html":207},"When an IP check still shows China, suspect the verification method first: checking too fast, the wrong checker, or a routing rule sending the checker itself direct — together these cover most cases, and none of them mean the connection has a real problem. A genuine failure to connect and an IPv6 leak are the two rarer causes, worth checking later rather than jumping to first.",{"type":7,"html":209},"If you need to manually re-verify after every single connection to feel sure, that is a sign the client is not being transparent enough about its own state. With \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">FastOrange\u003C\u002Fa>, the connection status matches the actual routing — "connected" means traffic is genuinely going through the tunnel, with no need to keep re-checking it yourself. If you have worked through the steps above and are still unsure, sending \u003Ca href=\"\u002Fen\u002Fcontact\u002F\">support\u003C\u002Fa> screenshots of both checks along with which checker site you used gets you an answer faster than continuing to guess, and makes it easier to pin down which layer the problem is actually in.",[211,214,217,220,223],{"q":212,"a":213},"Two different IP checker sites give me two different answers. Which one do I trust?","Different checkers use different geolocation databases, and small disagreements between them are normal. What matters is whether the general region is right, not whether the exact city or carrier name matches.",{"q":215,"a":216},"Does an unchanged IP mean the VPN did not work?","Not necessarily. Checking too fast, or the checker site caching an old result, is far more common than the VPN genuinely not working. Retest with the verification steps below before drawing a conclusion.",{"q":218,"a":219},"The region I see does not exactly match the node region I picked. Is that normal?","Yes. Geolocation databases update at different speeds, so the same IP range can show up as a neighbouring region or city on different checker sites. That kind of small mismatch does not mean anything failed.",{"q":221,"a":222},"Could IPv6 make the VPN pointless?","Possibly. If the device also has direct IPv6 connectivity, some IPv6-aware sites will see your real address. This is the same category of problem covered in \u003Ca href=\"\u002Fen\u002Fblog\u002Fdns-leak-check-guide\u002F\">What a DNS leak is and how to check for one\u003C\u002Fa>.",{"q":224,"a":225},"How long does it usually take FastOrange to show the new IP?","As soon as the connection is stable, the new address shows up immediately, with no need to wait deliberately. If several checks in a row show no change, redoing the verification steps below is more useful than refreshing again and again.",1793276291384]