[{"data":1,"prerenderedAt":200},["ShallowReactive",2],{"blog:how-does-a-vpn-work":3},{"zh-CN":4,"en":108},{"blocks":5,"faq":92},[6,9,11,15,17,19,22,41,44,46,48,50,53,55,76,78,81,83,85,88,90],{"type":7,"html":8},"p","VPN 工作的核心说白了就一句话：设备不再直接和目标网站对话，而是先跟一个中间节点建立连接，再由节点替你转发。这篇按数据实际走的顺序讲清楚这一路发生了什么，包括很多人搞混的 DNS 和 IP 变化这两件事。",{"type":7,"html":10},"想先弄清楚 VPN 整体解决的是什么问题、日常在哪些场景里用得上，\u003Ca href=\"\u002Fblog\u002Fwhat-is-a-vpn\u002F\">VPN 是什么\u003C\u002Fa>那篇从更基础的地方讲起，这篇假设你已经知道「要连 VPN」，专讲连上之后数据具体怎么走——从设备出发，到最后内容传回来，一步都不跳过。",{"type":12,"id":13,"html":14},"h2","bp-baseline","先看没有 VPN 时，数据怎么走",{"type":7,"html":16},"没有 VPN 的时候，设备发出的请求先到本地网络（家里的路由器或者手机信号塔），再经过运营商的网络，才到目标网站。这一路上，运营商能看到你连的是哪个网站，也能看到连接的大致时间和时长；如果目标网站本身没有用加密连接，运营商理论上还能看到传输的内容。",{"type":7,"html":18},"这条路径是默认状态，多数人平时不会意识到它的存在——直到需要多加一层的时候，才需要弄清楚这条默认路径原来是什么样子，也才能看清楚 VPN 到底改变了哪一段。运营商能看到&quot;连了哪个网站&quot;这件事本身不算新闻，路由能工作的前提就是沿途每一站都得知道包裹该往哪转，VPN 要做的不是让这件事消失，而是换一个地方发生。",{"type":12,"id":20,"html":21},"bp-path","连上 VPN 之后，这条路多了一段",{"type":23,"items":24},"steps",[25,29,33,37],{"title":26,"body":27},"第一步：设备先连上 VPN 节点",[28],"打开 VPN、点连接，设备做的第一件事是跟服务商选定的节点建立一条加密连接，这条连接建立之后，之后所有的网络请求，都会先经过这里，而不是直接发往目标网站。这一步通常几秒钟就能完成，连接状态从「未连接」变成「已连接」，就是这一步做完了的信号，之后不用再手动做什么，剩下的转发都是自动完成的。",{"title":30,"body":31},"第二步：节点转发你的请求",[32],"请求到达节点之后，节点把加密的外层拆开，看到你实际要去的目标地址，再用自己的身份（自己的 IP）把请求转发出去。目标网站收到的请求，看起来是节点发出的，不是你设备本身发出的——这也是为什么网站判断&quot;你在哪&quot;会跟着变成节点所在的地方，后面会展开讲这一点。",{"title":34,"body":35},"第三步：目标网站把内容传回节点",[36],"目标网站处理完请求，把内容传回给发出请求的那一方——也就是节点。这一步和普通上网没什么不同，目标网站并不知道节点后面还连着谁，处理方式跟对待任何一个普通访客没有区别——对目标网站来说，这次访问看起来就是节点自己发起的一次普通访问。",{"title":38,"body":39},"第四步：节点把内容原路加密传回设备",[40],"节点拿到目标网站传回的内容，重新加密，沿着最开始建立的那条连接传回设备，设备解密后，你才看到最终的网页或者 App 内容。整个过程通常只需要零点几秒，感觉不到中间多转了一次，日常刷网页、看视频的体验跟直接连接几乎没有分别，除非线路本身质量不好，才会感觉出多了一段路要走。",{"type":12,"id":42,"html":43},"bp-dns","DNS 在这中间扮演了什么角色",{"type":7,"html":45},"打开一个网站，设备首先要做的是把你输入或者点击的域名换算成一串数字地址，这一步叫 DNS 查询，日常可以理解成查一本电话本——你知道对方的名字，但拨号前得先查到对应的号码，浏览器和 App 也是先查到地址，才知道该往哪发请求，这一步发生在真正的数据传输之前，是整条链路里很容易被忽略的一个环节。",{"type":7,"html":47},"DNS 这一步如果没跟着 VPN 这条隧道走，而是继续用你本地网络的查询通道，会出现一种「裂开」的情况：主要的流量走了 VPN 加密隧道，但 DNS 查询这一小段还在本地网络那边完成，本地网络这时候依然能看到你查询过哪些域名，等于间接知道了你访问了哪些网站，哪怕主流量本身是加密的。这种情况有个专门的名字，DNS 泄漏是什么，怎么自查那篇讲了具体怎么检查、怎么确认自己有没有踩到这个坑。一个设计合理的 VPN 客户端会把 DNS 查询也一起塞进同一条隧道，这样本地网络连&quot;查询过哪些域名&quot;都看不到，不用用户自己额外操心这一步。",{"type":49},"downloads",{"type":12,"id":51,"html":52},"bp-ip","为什么你看到的 IP 地址变了",{"type":7,"html":54},"网站和 App 判断「你在哪里」，很大程度上依据的是连接过来的那个 IP 地址。没连 VPN 的时候，这个地址是你自己网络的出口地址；连上 VPN 之后，节点用自己的身份转发请求，网站看到的地址变成了节点的，不是你设备原本的。这也是为什么选节点的时候，节点所在的地区会影响网站给你展示的内容——语言、货币单位，甚至能不能打开某些页面，都可能跟着这个地址一起变。",{"type":56,"align":57,"head":59,"rows":63},"table",[58,58,58],null,[60,61,62],"状态项","未连接 VPN","连接 VPN 之后",[64,68,72],[65,66,67],"目标网站看到的出口 IP","你自己网络的出口地址","节点的地址",[69,70,71],"本地网络能否看到访问的具体网站","能","通常不能，只看到连了 VPN",[73,74,75],"网站据此判断的大致地区","你自己网络所在的地区","节点所在的地区",{"type":7,"html":77},"这张表里的变化，都是「地址层面」的变化，不是「消失」——网站依然收到了一个地址，只是这个地址换成了节点的，网站自己的判断逻辑还是照常运作，只是输入的信号变了。把这张表和前面&quot;没有 VPN 时数据怎么走&quot;那一节放在一起看，会更清楚：多出来的不是一个全新的机制，只是在原来那条路径中间，插入了节点这一站。",{"type":12,"id":79,"html":80},"bp-practical","换节点之后，为什么有些网站又要重新验证一次",{"type":7,"html":82},"不少网站和 App 会把「连接过来的地址」当成判断「是不是同一个人在用同一个会话」的信号之一。换了节点，这个信号跟着变了，有些服务会因此多问一次身份验证，或者要求重新登录——这不是 VPN 出了故障，是对方的判断逻辑把地址变化当成了一个值得多确认一次的信号，属于正常反应。",{"type":7,"html":84},"VPN 登录失败、验证码收不到怎么办那篇讲了具体遇到这类情况该怎么处理，多数时候换回原来那个节点，或者干脆固定用一个节点，就能减少这种反复验证的情况——道理很简单，信号越少变化，对方越少理由多问一次。如果连上之后查到的 IP 显示还是国内，没有变成节点的地址，连上 VPN 后 IP 还显示国内那篇专门排查过这种情况，跟这篇讲的原理是同一套，多半也是某个环节没跟着这条隧道一起走。",{"type":12,"id":86,"html":87},"bp-final","总结",{"type":7,"html":89},"VPN 工作的整个过程，说白了就是设备先连节点，节点替你转发，目标网站把内容传回节点，节点再传回设备，来回都走同一条加密隧道。这条路径里，DNS 查询要不要跟着走同一条隧道、网站看到的 IP 地址会不会变，是两个最容易被忽略、也最值得弄清楚的细节，前者决定了本地网络还能不能看到你访问了哪，后者决定了网站怎么判断你的位置。",{"type":7,"html":91},"想先弄清楚 VPN 整体解决的是什么问题、日常在哪些场景里用得上，本篇开头提到的那篇文章从更基础的地方讲起，两篇合起来看，「是什么」和「怎么工作」这两件事就都讲全了。\u003Ca href=\"\u002Ffeatures\u002F\">快橙\u003C\u002Fa>处理的正是上面这整条路径——一键连接、自动选节点，\u003Ca href=\"\u002Forder\u002F\">注册\u003C\u002Fa>后每天有免费试用时长，先连上测一次比读完这篇更直观。",[93,96,99,102,105],{"q":94,"a":95},"DNS 出问题和 VPN 连接失败是不是一回事？","不是一回事。VPN 连接失败是节点那条隧道没建立起来，网页完全打不开；DNS 出问题是隧道建立了，但域名查询这一步走错了通道，表现通常是「部分网站访问不稳定」或者「查到的信息和实际不一致」，两者的排查方向不一样。",{"q":97,"a":98},"换了 VPN 节点，网站显示的地区多久会更新？","因服务而异，不属于 VPN 能控制的部分。多数情况下刷新页面或者重新打开 App 就会更新，也有一些服务会缓存判断结果一段时间，需要多等一会儿。",{"q":100,"a":101},"我自己能看到自己访问了什么网站吗，还是只有服务商看到？","你自己的设备当然能看到，浏览器历史记录、App 使用记录都在本机留着。这篇讲的是「网络路径上的其他人」看不看到，别把自己的视角和别人的视角搞混。",{"q":103,"a":104},"为什么有时候感觉网页判断的地区不准？","网站判断地区的方法不只看 IP 地址，可能还结合了账号设置、浏览器语言之类的信号，综合判断的结果和单看 IP 地址不完全一致，这不属于 VPN 能控制的范围。",{"q":106,"a":107},"是不是每个网站都能看出我用了 VPN？","不一定，能不能判断出来取决于网站自己有没有做这类检测，以及用什么方式检测，不同网站的机制不一样，VPN 这一层不控制对方怎么判断。",{"blocks":109,"faq":184},[110,112,114,116,118,120,122,140,142,144,146,147,149,151,170,172,174,176,178,180,182],{"type":7,"html":111},"How a VPN works comes down to one line: the device stops talking to the destination site directly, and instead connects to a middle node first, which forwards everything on its behalf. This walks through what happens along that path in the order it actually happens, including DNS and the IP change — the two things people mix up most.",{"type":7,"html":113},"To get the bigger picture of what a VPN solves and where it shows up day to day, \u003Ca href=\"\u002Fen\u002Fblog\u002Fwhat-is-a-vpn\u002F\">what a VPN is\u003C\u002Fa> covers that from the ground up. This one assumes you already know why you'd connect one, and focuses entirely on where the data actually goes once it's up.",{"type":12,"id":13,"html":115},"First, how data travels without a VPN",{"type":7,"html":117},"Without a VPN, a request leaves the device for the local network (a home router, or a phone tower), then passes through the carrier's network before reaching the destination site. Along that path, the carrier can see which site you're connecting to, and roughly when and for how long; if the destination site itself isn't using an encrypted connection, the carrier could in theory see the content too.",{"type":7,"html":119},"This path is the default, and most people never notice it exists — not until there's a reason to add another layer, at which point it's worth knowing what the default actually looked like. Seeing a connection at all isn't news to the carrier — routing only works because every hop along the way knows where to forward things next. What a VPN changes isn't whether that happens, but where it happens.",{"type":12,"id":20,"html":121},"Once a VPN connects, the path gains one more leg",{"type":23,"items":123},[124,128,132,136],{"title":125,"body":126},"Step one: the device connects to the VPN node first",[127],"Open the VPN and tap connect, and the first thing the device does is establish an encrypted connection to whichever node the provider assigned. Once that's up, every network request from that point on goes through it first, instead of heading straight for the destination site. This step usually takes a few seconds, and the status flipping from &quot;not connected&quot; to &quot;connected&quot; is the signal that it's done — nothing else needs doing by hand after that; the forwarding that follows happens automatically.",{"title":129,"body":130},"Step two: the node forwards the request",[131],"Once the request reaches the node, the node strips the encrypted outer layer, reads the actual destination address inside, and forwards the request onward under its own identity — its own IP. What the destination site receives looks like it came from the node, not from the device itself. This is also exactly why a site's guess at &quot;where you are&quot; ends up following the node instead — more on that below.",{"title":133,"body":134},"Step three: the destination site sends content back to the node",[135],"The destination site processes the request and sends the content back to whoever asked for it — the node. Nothing about this step differs from ordinary browsing; the destination site has no way of knowing who's connected on the other side of the node. As far as it's concerned, this looks like an ordinary visit initiated by the node itself.",{"title":137,"body":138},"Step four: the node encrypts the content and sends it back to the device",[139],"The node takes what the destination site sent back, encrypts it again, and returns it along the same connection that was established at the start; the device decrypts it, and only then does the page or app actually show anything. The whole round trip usually takes a fraction of a second — nothing about the extra hop is noticeable day to day, browsing or streaming feels about the same as connecting directly, unless the route itself is having a bad day, in which case the extra leg becomes noticeable.",{"type":12,"id":42,"html":141},"What DNS is actually doing in the middle of this",{"type":7,"html":143},"Opening a site starts with the device converting the domain name you typed or tapped into a numeric address — that step is called a DNS lookup, and day to day it's basically looking up a number in a phone book: you know the name, but dialing requires the number first. A browser or app does the same lookup before it knows where to even send the request, and this happens before any actual data transfer — an easy step to overlook in the whole chain.",{"type":7,"html":145},"If that DNS step doesn't travel through the VPN tunnel and instead keeps using the local network's own lookup path, a &quot;split&quot; shows up: the bulk of the traffic goes through the encrypted tunnel, but that one small DNS step still completes on the local network, which means the local network can still see which domains were being looked up — indirectly learning which sites were visited, even though the main traffic itself was encrypted. This has its own name, and what a DNS leak is and how to check for one covers exactly how to test for it and confirm whether it's happening. A properly built VPN client routes DNS lookups through the same tunnel as everything else, so the local network can't see even that much — nothing for the user to manage by hand.",{"type":49},{"type":12,"id":51,"html":148},"Why the IP address you show up as changes",{"type":7,"html":150},"Sites and apps judging &quot;where you are&quot; rely heavily on the IP address the connection arrives from. Without a VPN, that's your own network's outbound address; once connected, the node forwards the request under its own identity, and the address the site sees becomes the node's instead of the device's own. It's also why the region a node sits in affects what a site shows — language, currency, sometimes even whether certain pages open at all can shift along with that address.",{"type":56,"align":152,"head":153,"rows":157},[58,58,58],[154,155,156],"What changes","Without a VPN","Once connected",[158,162,166],[159,160,161],"Outbound IP the destination site sees","Your own network's address","The node's address",[163,164,165],"Whether the local network sees which site you visited","Yes","Usually not — just that a VPN is connected",[167,168,169],"The rough region a site infers","Wherever your own network is","Wherever the node is",{"type":7,"html":171},"Everything in that table is a change at the address level, not a disappearance — the site still receives an address, it's simply the node's instead. The site's own logic for judging things keeps running exactly as before; only the signal feeding into it changed. Placed next to the &quot;how data travels without a VPN&quot; section above, the picture gets clearer: nothing new was invented here, one more stop — the node — was inserted partway through the same path that was already there.",{"type":12,"id":79,"html":173},"Why switching nodes sometimes triggers a fresh verification",{"type":7,"html":175},"Plenty of sites and apps treat &quot;the address a connection arrives from&quot; as one signal for judging whether the same person is using the same session. Switch nodes, and that signal changes along with it — some services respond by asking for identity verification again, or requiring a fresh login. That's not a VPN malfunctioning; it's the other side's own logic treating an address change as something worth double-checking, which is a normal reaction on its part.",{"type":7,"html":177},"VPN login failures and missing verification codes covers exactly what to do when this comes up — switching back to the previous node, or simply staying on one node, usually cuts down on how often this happens. The logic is simple: fewer signals changing gives the other side fewer reasons to ask again. If the IP still shows up as a mainland address after connecting, instead of the node's, IP still shows China after connecting to a VPN covers exactly that case, and it runs on the same underlying logic as this page.",{"type":12,"id":86,"html":179},"In summary",{"type":7,"html":181},"How a VPN works, stripped down: the device connects to a node, the node forwards on its behalf, the destination site sends content back to the node, and the node sends it back to the device — the whole round trip riding the same encrypted tunnel both ways. Two details in that path are the easiest to overlook and the most worth understanding: whether DNS lookups travel through the same tunnel, and whether the IP a site sees changes — the first decides whether the local network can still see where you went, the second decides how a site judges where you are.",{"type":7,"html":183},"To get the bigger picture of what a VPN solves in the first place, the article mentioned at the start covers that from the ground up — read together, &quot;what it is&quot; and &quot;how it works&quot; cover the whole thing. \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">FastOrange\u003C\u002Fa> handles exactly this path — one tap to connect, nodes chosen automatically — and every registered account gets free trial time each day. \u003Ca href=\"\u002Fen\u002Forder\u002F\">Signing up\u003C\u002Fa> and connecting once says more than finishing this page does.",[185,188,191,194,197],{"q":186,"a":187},"Is a DNS problem the same thing as a VPN connection failing?","No. A failed VPN connection means the tunnel to the node never came up, and pages don't load at all. A DNS problem means the tunnel is up, but domain lookups are taking the wrong path — it usually shows up as certain sites acting unstable or location checks not matching reality. The two point in different troubleshooting directions.",{"q":189,"a":190},"After switching nodes, how long until a site updates the region it shows me?","It varies by service and isn't something a VPN controls. Refreshing the page or reopening the app usually updates it right away, though some services cache that judgment for a while, so it can take longer.",{"q":192,"a":193},"Can I see what sites I've visited myself, or only the provider can?","Your own device obviously can — browser history and app activity both stay on it. This page is about whether other parties along the network path can see it, which is a different question from your own view of your own device.",{"q":195,"a":196},"Why does a site's guess at my region sometimes seem off?","A site's region check usually isn't based on the IP alone — account settings or browser language can factor in too, and the combined result doesn't always match what the IP alone would suggest. That's outside anything a VPN controls.",{"q":198,"a":199},"Can every site tell that I'm using a VPN?","Not necessarily — whether a site can tell depends on whether it runs that kind of detection at all, and how. Different sites use different methods, and a VPN doesn't control how the other side chooses to judge that.",1790199275381]