[{"data":1,"prerenderedAt":307},["ShallowReactive",2],{"blog:vpn-connected-but-no-internet":3},{"zh-CN":4,"en":163},{"blocks":5,"faq":147},[6,9,11,13,17,19,26,28,31,33,35,47,50,52,60,63,65,73,75,78,80,82,84,87,89,91,93,101,104,106,108,110,118,121,123,125,127,130,132,138,140,143,145],{"type":7,"html":8},"p","「已连接」这三个字只说明一件事：客户端和服务器之间的隧道建起来了。它不保证你的浏览器把请求送进了这条隧道，也不保证隧道对面能把结果拿回来。",{"type":7,"html":10},"所以这种故障几乎总是出在中间某一层，而不是「没连上」。好消息是层数有限，按顺序过一遍，通常五分钟之内就能定位。",{"type":7,"html":12},"排查的原则是：\u003Cstrong>每次只改一个变量\u003C\u002Fstrong>。同时换节点、换协议、重装应用，问题即使消失了，你也不知道是哪一步起的作用，下次还会再遇到。",{"type":14,"id":15,"html":16},"h2","bp-triage","先做一次三十秒的分诊",{"type":7,"html":18},"打开两个东西：一个国内网站，一个海外网站。结果只有四种，对应四个完全不同的方向。",{"type":20,"items":21},"list",[22,23,24,25],"两个都打不开：本机网络断了，和工具无关。先看 Wi-Fi 或数据。","国内能开、海外不能：最典型的情况，继续往下看。","海外能开、国内不能：分流规则出了问题，国内流量被送进了隧道。","都能开，只有某一个站不行：是那个站点自己的问题，或者规则单独放行了它。",{"type":7,"html":27},"这一步不能跳。没有它，后面每一步都是在猜。",{"type":14,"id":29,"html":30},"bp-dns","第一层：DNS 没走对",{"type":7,"html":32},"最常见的原因。域名解析还在用本地的 DNS，拿回来的地址是错的，于是浏览器兴高采烈地连到一个连不上的地方。",{"type":7,"html":34},"表现很好认：网页一直转到超时，而不是立刻报错。直接用 IP 访问反而通。",{"type":36,"items":37},"steps",[38,42],{"title":39,"body":40},"怎么确认",[41],"断开再重连一次。多数客户端在连接时会接管 DNS，重连相当于重新设置一遍。",{"title":43,"body":44},"怎么处理",[45,46],"重连之后先清一下浏览器缓存再试。浏览器自己会缓存解析结果，旧的错误地址会被继续用上几分钟。","如果你想更系统地理解这一层在做什么，\u003Ca href=\"\u002Fblog\u002Fwhat-is-dns\u002F\">DNS 是什么\u003C\u002Fa>那篇讲得更细。",{"type":14,"id":48,"html":49},"bp-routing","第二层：分流规则把流量放回了直连",{"type":7,"html":51},"现在的客户端基本都做分流：国内网站直连，海外网站走隧道。规则表更新不及时，或者你手动加过白名单，就会出现「某些站点永远打不开」的情况。",{"type":36,"items":53},[54,57],{"title":39,"body":55},[56],"看同一类站点是不是集体异常。如果是一整类（比如所有 Google 域名）都不行，多半是规则；如果只有一个站，先怀疑那个站。",{"title":43,"body":58},[59],"把模式切成全局，再打开同一个网站。能开，就说明是规则问题；不能开，说明问题在更下面一层。",{"type":14,"id":61,"html":62},"bp-proxy","第三层：系统里还留着旧的代理设置",{"type":7,"html":64},"这一层专坑电脑用户。之前用过别的工具，或者装过浏览器插件，系统代理里留了一条已经失效的记录。新工具连上了，流量却仍然被送去那条死路。",{"type":36,"items":66},[67,70],{"title":39,"body":68},[69],"换一个浏览器试试。如果换了就好，问题在浏览器插件；如果都不行，问题在系统设置。",{"title":43,"body":71},[72],"关掉所有浏览器里的代理类插件，只留一个正在用的工具。这类冲突很少报错，只会安静地失败，所以值得专门看一眼。",{"type":74},"downloads",{"type":14,"id":76,"html":77},"bp-node","第四层：节点本身不行",{"type":7,"html":79},"前面三层都排除了，就该怀疑节点。节点可能过载，可能被目标站点单独拦了，也可能只是那一段线路当时不通。",{"type":7,"html":81},"换一个地区的节点，不要在同一个地区里换。同一地区的出口经常共享上游，一起坏的概率不低。",{"type":7,"html":83},"如果换完立刻正常，那就是节点的问题，不需要再动任何设置。想知道该常驻哪个地区，\u003Ca href=\"\u002Fblog\u002Fvpn-server-location-explained\u002F\">服务器选哪个地区最合适\u003C\u002Fa>里有按用途的建议。",{"type":14,"id":85,"html":86},"bp-clock","第五层：系统时间不对",{"type":7,"html":88},"这一层很少有人想到，但一旦中招，症状和前面几层几乎一模一样：全部 HTTPS 站点打不开，提示也含糊。",{"type":7,"html":90},"原因是加密连接要校验证书的有效期。设备的时间如果偏了几个小时甚至几天，证书就会被判定成「还没生效」或者「已经过期」，连接在握手阶段就被拒了，看上去就像网络不通。",{"type":7,"html":92},"最常见的触发场景：手机或电脑长时间关机后重新开机、换了时区、主板电池没电、或者手动关掉了自动对时。",{"type":36,"items":94},[95,98],{"title":39,"body":96},[97],"看一眼系统时间和真实时间差多少。差超过几分钟就值得怀疑，差到小时级基本可以确定。",{"title":43,"body":99},[100],"打开自动同步时间，或者手动改成正确的时间和时区，然后重新连接。这一层一旦修好，前面所有症状会同时消失。",{"type":14,"id":102,"html":103},"bp-mtu","五层之外，还有一种更隐蔽的情况",{"type":7,"html":105},"前面五层排查完，如果症状变成了很怪的一种——网页整体打得开，图标、文字都正常，但一到某张大图、某个视频或者某次大文件下载就卡在中间不动了——大概率是数据包大小的问题，业内一般管这个叫 MTU。",{"type":7,"html":107},"打个比方：网络传数据是分成一个个固定大小的包发出去的，隧道会在每个包外面再包一层，包整体就比不走隧道时稍微大一点。大部分网络设备能处理这个大小，但沿途只要有一段设备只肯放行更小的包，超出的部分就会被直接丢掉，不会提示包太大了。",{"type":7,"html":109},"这就是为什么现象这么奇怪：打开网页这种小包能过去，页面正常显示；一旦请求变成大文件、清晰图片或者视频这种需要连续传大包的操作，卡住的概率就明显变高，不是网速不够，是包在半路被丢了，设备还在等一个永远不会完整到达的响应。",{"type":36,"items":111},[112,115],{"title":39,"body":113},[114],"换一个明显更小的文件测试，比如打开一张小图代替一段视频。小文件正常、大文件必卡，基本可以把方向锁定在这里，不用再怀疑前面五层。",{"title":43,"body":116},[117],"大多数客户端会自动处理这一层，不需要手动设置。工具如果支持手动调整包大小，把数值调低一档试试；不支持的话，换一个节点通常也能绕开当前这条路径上的限制。",{"type":14,"id":119,"html":120},"bp-log","把这次的结果记下来",{"type":7,"html":122},"排查完别急着关掉——花三十秒记一句：什么时候、什么网络、哪一层出的问题、怎么解决的。",{"type":7,"html":124},"这件事的价值下次才显出来。同一个人遇到的故障往往重复：公司网络总是卡在端口，家里总是 DNS，出差总是酒店门户。攒够三五条记录，你会发现自己根本不需要每次从头排查，直接跳到那一层就行。",{"type":7,"html":126},"记录还有第二个用处：真要联系客服的时候，带着「几点、哪个地区的节点、哪些域名不通、换节点是否有效」这四条信息，比「我打不开网页」能快上几轮对话。\u003Ca href=\"\u002Fcontact\u002F\">联系我们\u003C\u002Fa>那边最常问的也是这几项。",{"type":14,"id":128,"html":129},"bp-network","什么时候该怀疑网络本身",{"type":7,"html":131},"有几种环境天生容易出这个问题：",{"type":20,"items":133},[134,135,136,137],"公司或校园网做了额外限制，只放行少数端口","酒店 Wi-Fi 需要先在门户页登录，而你还没登","移动数据信号弱，隧道建起来了但吞吐极低","路由器上还开着另一层代理，两层叠在一起互相打架",{"type":7,"html":139},"判断方法：用手机开热点，让电脑连热点再试。换一条完全不同的物理链路，能立刻区分是环境问题还是设备问题。",{"type":14,"id":141,"html":142},"bp-final","总结",{"type":7,"html":144},"已连接但打不开，按 DNS、分流规则、系统代理、节点、系统时间这五层顺序排，配合开头那次三十秒分诊，绝大多数情况都能在五分钟内定位。记住每次只动一个变量。",{"type":7,"html":146},"日常想少遇到这类问题，方向只有一个：让客户端把 DNS、分流和重连都自己处理好，不需要你手动配。\u003Ca href=\"\u002Ffeatures\u002F\">快橙\u003C\u002Fa>就是按这个思路做的——一键连接，断了自动重连，换节点也是一下。注册后每天都有免费试用时长，先拿它把上面那个三十秒分诊跑一遍。",[148,151,154,157,160],{"q":149,"a":150},"为什么重启一下就好了？","重启会重建网络接口和 DNS 缓存，等于把前面几步一次做完。它能解决问题，但不告诉你原因。",{"q":152,"a":153},"只有某一个网站打不开，其他都正常，是什么情况？","多半是分流规则把这个域名放回了直连，或者是该站点自己在拦截。先看规则，再换节点。",{"q":155,"a":156},"手机能上，电脑不能上，问题在哪？","两台设备走的是不同的系统代理设置。电脑上的浏览器插件、旧的代理配置最容易留下残留。",{"q":158,"a":159},"换节点有用还是换协议有用？","先换节点。节点是最常见的变量，换完还不行，再去动其他设置。",{"q":161,"a":162},"快橙遇到这种情况怎么处理？","断开重连并换一个节点，多数情况一次就好。仍不行请联系\u003Ca href=\"\u002Fcontact\u002F\">客服\u003C\u002Fa>，把出现问题的域名一起发过来。",{"blocks":164,"faq":291},[165,167,169,171,173,175,181,183,185,187,189,200,202,204,212,214,216,224,225,227,229,231,233,235,237,239,241,249,251,253,255,257,265,267,269,271,273,275,277,283,285,287,289],{"type":7,"html":166},"The words "connected" only tell you one thing: a tunnel exists between the app and the server. They do not promise that your browser put its request into that tunnel, nor that the far end could bring an answer back.",{"type":7,"html":168},"So this failure almost always sits in one of the layers in between rather than in the connection itself. The good news is that there are only a few layers, and working through them in order usually pins the problem down inside five minutes.",{"type":7,"html":170},"One rule governs the whole process: \u003Cstrong>change one variable at a time\u003C\u002Fstrong>. Switch the node, switch the protocol and reinstall the app together, and even when the problem disappears you have learned nothing, so it will happen again.",{"type":14,"id":15,"html":172},"Start with a thirty-second triage",{"type":7,"html":174},"Open two things: a domestic site and an overseas one. There are only four outcomes, and they point in four completely different directions.",{"type":20,"items":176},[177,178,179,180],"Neither opens: your local network is down and the app is irrelevant. Check Wi-Fi or mobile data.","Domestic opens, overseas does not: the classic case. Keep reading.","Overseas opens, domestic does not: routing rules are wrong and domestic traffic is being pushed through the tunnel.","Everything opens except one site: that site is the problem, or a rule singles it out.",{"type":7,"html":182},"Do not skip this step. Without it, everything that follows is guesswork.",{"type":14,"id":29,"html":184},"Layer one: DNS is not following the tunnel",{"type":7,"html":186},"The most common cause by a wide margin. Name resolution is still using the local resolver, the address that comes back is wrong, and the browser cheerfully connects to somewhere unreachable.",{"type":7,"html":188},"It is easy to recognise: the page spins until it times out instead of failing immediately. Reaching the same service by IP works.",{"type":36,"items":190},[191,195],{"title":192,"body":193},"How to confirm it",[194],"Disconnect and reconnect once. Most clients take over DNS as they connect, so a reconnect effectively sets it up again.",{"title":196,"body":197},"How to fix it",[198,199],"After reconnecting, clear the browser cache before retrying. Browsers cache resolutions themselves, so a stale wrong address keeps getting used for several more minutes.","If you want the underlying mechanism rather than the fix, \u003Ca href=\"\u002Fen\u002Fblog\u002Fwhat-is-dns\u002F\">what DNS is\u003C\u002Fa> covers this layer properly.",{"type":14,"id":48,"html":201},"Layer two: rules sent the traffic back to a direct connection",{"type":7,"html":203},"Every modern client splits traffic: domestic sites go direct, overseas sites go through the tunnel. When the rule list is out of date, or you once added something to a bypass list, you get sites that never open no matter what.",{"type":36,"items":205},[206,209],{"title":192,"body":207},[208],"Check whether a whole class of sites fails together. An entire family failing at once — every Google hostname, say — points at rules. A single site failing points at the site.",{"title":196,"body":210},[211],"Switch to global mode and open the same page. If it works, the rules were the problem. If it still does not, the fault is a layer further down.",{"type":14,"id":61,"html":213},"Layer three: an old proxy setting is still in the system",{"type":7,"html":215},"This one is a computer-only trap. You used another tool once, or installed a browser extension, and a dead entry stayed behind in the system proxy settings. The new app connects fine while traffic keeps being posted down that dead end.",{"type":36,"items":217},[218,221],{"title":192,"body":219},[220],"Try a different browser. If the other browser works, the problem is an extension. If neither works, it is the system settings.",{"title":196,"body":222},[223],"Turn off every proxy-type extension in every browser and leave only the app you actually use. These conflicts rarely raise an error; they just fail quietly, which is exactly why they deserve a deliberate look.",{"type":74},{"type":14,"id":76,"html":226},"Layer four: the node itself",{"type":7,"html":228},"With the first three layers ruled out, suspect the node. It may be overloaded, it may be blocked by the destination specifically, or that stretch of route may simply be down at the moment.",{"type":7,"html":230},"Pick a node in a different region rather than another one nearby. Exits in the same region often share upstream capacity, so they tend to fail together.",{"type":7,"html":232},"If a different region works immediately, the node was the whole story and nothing else needs changing. For which region to sit on day to day, \u003Ca href=\"\u002Fen\u002Fblog\u002Fvpn-server-location-explained\u002F\">choosing a server location\u003C\u002Fa> has recommendations by use case.",{"type":14,"id":85,"html":234},"Layer five: the system clock",{"type":7,"html":236},"Almost nobody thinks of this one, and when it bites, the symptoms are nearly identical to every layer above: no HTTPS site opens, and the message explains nothing.",{"type":7,"html":238},"Encrypted connections check a certificate's validity dates. If the device's clock is off by hours or days, the certificate reads as "not valid yet" or "expired", the connection is refused during the handshake, and the whole thing looks like a dead network.",{"type":7,"html":240},"The usual triggers: a machine switched on after a long time off, a time-zone change, a dead motherboard battery, or automatic time sync turned off by hand.",{"type":36,"items":242},[243,246],{"title":192,"body":244},[245],"Compare the system clock against the real time. A few minutes off is worth suspecting; hours off settles it.",{"title":196,"body":247},[248],"Turn automatic time sync on, or set the correct time and zone by hand, then reconnect. Fix this layer and every symptom above disappears at once.",{"type":14,"id":102,"html":250},"Beyond the five layers, one more subtle case",{"type":7,"html":252},"Work through all five layers and the symptom can turn into something oddly specific: the page loads fine, icons and text render normally, but one particular large image, a video, or a big file download stalls partway through and goes nowhere. The likely cause is packet size, usually called MTU.",{"type":7,"html":254},"Here is the mechanism. Network data travels in fixed-size chunks, and a tunnel wraps each chunk in an extra layer, making the whole thing slightly bigger than it would be without the tunnel. Most equipment along the way handles that fine, but if even one hop only accepts smaller chunks, anything over its limit gets silently dropped, with nothing telling you the packet was too big.",{"type":7,"html":256},"That is exactly why the symptom looks so strange. A small chunk, like the request for a web page, gets through fine and the page renders. Anything that needs a steady stream of large chunks — a big file, a full-resolution image, a video — stalls far more often. It is not a lack of speed; the packet died somewhere along the route, and the device is still waiting for a reply that was never going to arrive complete.",{"type":36,"items":258},[259,262],{"title":192,"body":260},[261],"Test with something obviously smaller, like a small image instead of a video. If the small file is fine and the large one reliably stalls, that points squarely at this layer, with no need to keep suspecting the five above.",{"title":196,"body":263},[264],"Most clients handle this layer automatically, with no manual setting involved. If a client exposes a manual packet-size option, try a smaller value. If it doesn't, switching nodes usually routes around whatever is enforcing the limit on the current path.",{"type":14,"id":119,"html":266},"Write down what worked",{"type":7,"html":268},"Do not close the laptop the moment it works. Spend thirty seconds on one line: when, which network, which layer, what fixed it.",{"type":7,"html":270},"The value shows up next time. Faults repeat per person: the office network always stalls on ports, home is always DNS, hotels are always the portal. Three or four entries in and you stop diagnosing from scratch — you jump straight to the layer that is usually yours.",{"type":7,"html":272},"There is a second use. If you do end up contacting support, arriving with four facts — the time, which region's node, which hostnames failed, and whether another node helped — saves several rounds over "I can't open websites". Those are the four things \u003Ca href=\"\u002Fen\u002Fcontact\u002F\">support\u003C\u002Fa> asks for anyway.",{"type":14,"id":128,"html":274},"When to suspect the network itself",{"type":7,"html":276},"A few environments produce this failure on their own:",{"type":20,"items":278},[279,280,281,282],"Office or campus networks that permit only a short list of ports","Hotel Wi-Fi that wants a portal login you have not completed","Weak mobile signal, where the tunnel builds but throughput is near zero","A router running its own proxy layer, with the two stacked and fighting",{"type":7,"html":284},"The test: tether your computer to your phone's hotspot and retry. Swapping to a completely different physical link separates an environment problem from a device problem in one move.",{"type":14,"id":141,"html":286},"In summary",{"type":7,"html":288},"Connected but nothing loads is worked in five layers — DNS, routing rules, system proxy, node, clock — after the thirty-second triage at the top. That combination locates the overwhelming majority of cases inside five minutes. Change one variable at a time.",{"type":7,"html":290},"To meet this less often, there is really only one direction: let the client handle DNS, routing and reconnection itself instead of asking you to configure them. \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">FastOrange\u003C\u002Fa> is built that way — one tap to connect, automatic reconnection when a link drops, one tap to change node. Every registered account gets free trial time daily, so run that thirty-second triage with it first.",[292,295,298,301,304],{"q":293,"a":294},"Why does a reboot fix it?","A reboot rebuilds the network interface and clears the DNS cache, which quietly performs the first few steps at once. It works, but it never tells you what was wrong.",{"q":296,"a":297},"One site fails and everything else is fine. What is that?","Usually a routing rule sending that hostname back to a direct connection, or the site itself refusing you. Check the rules first, then change nodes.",{"q":299,"a":300},"It works on my phone but not my laptop.","The two devices use different system proxy settings. On a computer, browser extensions and old proxy entries are the usual leftovers.",{"q":302,"a":303},"Should I change the node or the protocol?","The node, first. It is the most common variable by far. Only touch anything else if a different node does not fix it.",{"q":305,"a":306},"What does FastOrange do about this?","Disconnect, reconnect, and pick another node — that clears most cases in one go. If it does not, send \u003Ca href=\"\u002Fen\u002Fcontact\u002F\">support\u003C\u002Fa> the hostname that failed.",1793276292196]