[{"data":1,"prerenderedAt":178},["ShallowReactive",2],{"blog:dns-leak-check-guide":3},{"zh-CN":4,"en":97},{"blocks":5,"faq":81},[6,9,11,15,17,19,21,24,26,28,30,33,35,38,56,58,61,63,65,67,70,72,74,77,79],{"type":7,"html":8},"p","DNS 泄漏说的是：网页的实际内容走了加密隧道，但访问这个网页之前「这个域名对应哪个地址」的查询请求，走了隧道外的另一条路。结果是内容本身别人截获不到，但沿途能看到的人依然知道你查过哪些域名，等于隐私保护出现了一个具体的缺口，而不是整体失效。",{"type":7,"html":10},"这篇先给一个三十秒能做的自查方法，再按从最普遍到最少见的顺序讲清楚几种常见原因，最后说清楚查到以后具体该怎么处理，不需要一遇到就把系统重装一遍。原则不变：怀疑泄漏时先自查确认，再决定要不要动系统或路由器设置，不要没查清楚就把好几个地方一起改，改完也说不清到底是哪一处起了作用。",{"type":12,"id":13,"html":14},"h2","bp-what","DNS 泄漏具体指什么",{"type":7,"html":16},"平时上网，设备要先把域名（比如某个网站的名字）转换成一串数字地址，这一步就是域名解析，日常说的「DNS」指的就是这一层。没有 VPN 的时候，这个查询请求直接发给运营商指定的解析服务器；连上 VPN 以后，正常情况下这个查询也应该经过隧道，发给隧道那一端的解析服务器。",{"type":7,"html":18},"「泄漏」指的就是这个查询请求没有跟着隧道走，而是继续发往本地或者运营商的解析服务器。网页、视频这些实际内容可能确实加密传输了，但域名查询这一条单独溜了出去，能看到这条请求的一方，还是能拼出一份你访问过哪些网站的记录，只是看不到网页里具体的内容。这也是为什么「连了 VPN」和「所有流量都在隧道里」不是同一件事，中间这一层解析很容易被忽略——它不像网页打不开那样明显，泄漏了通常什么异常都感觉不到，日常使用完全正常，只有专门去查才会发现。",{"type":7,"html":20},"这也是为什么这一层容易被忽视：出问题不会有任何提示，不会卡顿，不会报错，唯一的办法就是主动查一次。",{"type":12,"id":22,"html":23},"bp-quick-check","三十秒自查",{"type":7,"html":25},"最简单的方法是搜索「DNS leak test」，打开任意一个这类检测页面，连接 VPN 之后跑一次检测。页面通常会列出它查到的解析服务器所在地区和运营商，拿这个结果和你实际的宽带或者手机运营商对比：如果显示的是隧道所在地区的解析服务器，说明没有泄漏；如果显示的还是本地运营商的名字，说明查询请求确实溜出去了。",{"type":7,"html":27},"测的时候有两个小细节容易被忽略：一是要在真正连上 VPN、状态稳定几秒之后再测，刚连上那一瞬间测到的可能还是切换前的结果；二是如果电脑和手机都在用，两边分开各测一次，不要测了一边就假设另一边情况相同，尤其是两边如果连的不是同一个网络。",{"type":7,"html":29},"如果更习惯用命令行确认，也可以直接查当前使用的解析服务器地址：",{"type":31,"code":32},"code","# macOS \u002F Linux\nscutil --dns | grep nameserver\n\n# Windows\nipconfig \u002Fall | findstr \u002FR \"DNS\"",{"type":7,"html":34},"输出里出现的地址如果是本地运营商常见的地址段，而不是隧道对应地区的地址，同样说明存在泄漏。两种方法选一种即可，不需要都做。",{"type":12,"id":36,"html":37},"bp-causes","常见原因，从最普遍到最少见",{"type":39,"items":40},"steps",[41,46,51],{"title":42,"body":43},"系统里配置了自定义 DNS",[44,45],"不少人为了解决其他问题（比如加速某个网站），在系统或者路由器里手动填过一个固定的 DNS 地址。这个设置一旦存在，优先级通常比客户端想要接管的设置更高，于是查询请求就按手动填的地址走，绕开了隧道。","怎么确认：回想一下有没有在网络设置里手动填过 DNS 地址，或者路由器管理页面里有没有类似的自定义项。怎么处理：把这类手动设置改回自动获取，让客户端自己接管这一层，改完重新测一次。",{"title":47,"body":48},"客户端没有把 DNS 也收进隧道",[49,50],"有些工具只处理网页和应用的数据内容，没有把域名查询这一步也一起收进隧道，两者被当成了两件独立的事情来处理。这种情况下，数据内容看起来完全正常，但查询请求全程都在隧道外面，用户很难从表面现象上察觉到。","怎么确认：如果自定义 DNS 那一项排除了，自查结果依然显示泄漏，基本可以确认是这一层没有被正确接管。怎么处理：这属于客户端本身的处理方式问题，用户侧能做的有限，换一个会把 DNS 也纳入隧道的客户端是更直接的解法。",{"title":52,"body":53},"浏览器自己的加密 DNS 绕开了系统",[54,55],"部分浏览器自带加密 DNS 功能，会绕开系统设置，直接把查询发给浏览器自己指定的服务器。这个功能本意是保护隐私，但如果浏览器指定的服务器和 VPN 的隧道没有关系，实际效果反而是又开出了一条新的泄漏路径。","怎么确认：在浏览器设置里找和「安全 DNS」「加密 DNS」相关的选项，看看是不是开着，指向的又是哪个服务商。怎么处理：不需要整体关掉这个功能，把它指向的服务器换成经隧道可达的地址，或者暂时关闭交给系统统一处理，测试后再决定。",{"type":57},"downloads",{"type":12,"id":59,"html":60},"bp-ipv6","IPv6 是另一个容易漏的口子",{"type":7,"html":62},"前面三种原因排除以后，还有一种情况值得单独留意：设备同时具备 IPv4 和 IPv6 两套网络能力，如果只有 IPv4 那一套被隧道接管，走 IPv6 的域名查询和实际连接都可能绕开隧道，表现和前面说的一样，是查询请求走了另一条路，只是这次连接本身也一起漏了出去。",{"type":7,"html":64},"这和\u003Ca href=\"\u002Fblog\u002Fip-still-shows-china-after-vpn\u002F\">连上 VPN 后 IP 还显示国内\u003C\u002Fa>里提到的其实是同一个原因在两篇文章里的两种表现：那篇里看到的是查 IP 时结果没变，这篇里看到的是 DNS 检测显示泄漏，根源都是 IPv6 那一条路没被一起处理。移动网络和不少家用宽带这几年默认开启 IPv6 的比例都在上升，这类「部分泄漏」也比几年前更容易遇到，不算什么罕见的边缘情况。",{"type":7,"html":66},"如果自查结果显示泄漏，且怀疑和 IPv6 有关，可以在系统网络设置里暂时关闭 IPv6，重新测一次作为对照：关闭以后泄漏消失，基本能确认就是这个原因；关闭以后泄漏依然存在，说明问题在前面三种原因里，和 IPv6 没关系，不需要一直关着它。",{"type":12,"id":68,"html":69},"bp-fix-summary","查到泄漏以后怎么办",{"type":7,"html":71},"按上面三个原因的顺序排查一遍，多数泄漏都能定位到具体哪一层：先看是不是系统或路由器里有手动填的 DNS，再看客户端本身有没有把 DNS 收进隧道，最后看浏览器有没有自己开了加密 DNS。改完对应的设置，重新跑一次自查确认，而不是改完就假设一定好了。",{"type":7,"html":73},"如果几种原因都排除了，自查结果依然显示泄漏，把检测页面的截图、使用的设备型号和系统版本一起发给客服，比自己继续猜测更快找到原因，也方便对方判断是不是某个版本特有的问题。",{"type":12,"id":75,"html":76},"bp-final","总结",{"type":7,"html":78},"DNS 泄漏意味着域名查询走了隧道之外的另一条路，泄漏的是「访问过哪些网站」这类记录，不是网页具体内容。三十秒自查加上按常见程度排查三个原因，大多数情况能自己定位和解决，IPv6 是排查完常见原因之后还值得留意的一个角落。",{"type":7,"html":80},"不想每次换设备、换网络都重新自查一遍，方向就是让客户端自己把这一层管好。\u003Ca href=\"\u002Ffeatures\u002F\">快橙\u003C\u002Fa>的思路是把 DNS 也收进隧道自动处理，不需要手动配置系统或路由器。如果按上面的步骤查完还是无法确认，\u003Ca href=\"\u002Fcontact\u002F\">联系客服\u003C\u002Fa>时带上检测结果，能更快判断问题出在哪一层。更多关于\u003Ca href=\"\u002Fsecurity\u002F\">VPN 安全\u003C\u002Fa>这块的内容，也可以一并了解。",[82,85,88,91,94],{"q":83,"a":84},"DNS 泄漏是不是就等于 VPN 完全没用？","不是。即使存在 DNS 泄漏，实际的数据内容依然走了加密隧道，别人截获不到具体在看什么内容，但域名查询记录能看出访问过哪些网站，这部分隐私保护确实打了折扣，不代表整层保护都失效了。",{"q":86,"a":87},"用手机自带浏览器和用 App 内置浏览器查，结果会不一样吗？","有可能不一样。不同浏览器的 DNS 设置不一定完全跟随系统，尤其是开启了浏览器自己的加密 DNS 功能之后，两边测出来的结果可以完全不同，测的时候最好把常用的几个都测一遍。",{"q":89,"a":90},"路由器上设置的 DNS 会不会影响手机？","会。如果手机的网络设置里没有单独指定 DNS，就会跟随路由器分配的设置。这也是为什么换一个网络环境，泄漏情况有时候会忽然出现或者消失。",{"q":92,"a":93},"多久应该自查一次？","不需要天天查。换新设备、换新网络，或者系统升级之后测一次就够，这几种情况最容易让之前设好的东西被悄悄改回默认值。",{"q":95,"a":96},"快橙怎么处理 DNS 这一层？","快橙的思路是让客户端自己接管 DNS 这一层，不需要手动去改系统或路由器的 DNS 设置，减少这类泄漏发生的机会。",{"blocks":98,"faq":162},[99,101,103,105,107,109,111,113,115,117,119,120,122,124,141,142,144,146,148,150,152,154,156,158,160],{"type":7,"html":100},"A DNS leak means the actual content of a page goes through the encrypted tunnel, but the lookup that happens right before it — "what address does this domain point to" — takes another path outside the tunnel. The content itself stays out of reach for anyone watching, but whoever can see that lookup still knows which domains you looked up. That is a specific gap in privacy protection, not the whole thing failing.",{"type":7,"html":102},"This article gives a thirty-second self-check first, then works through the common causes in order, most likely first, and finishes with what to actually do once you find one. The rule stays the same: confirm it with a self-check before deciding whether to touch system or router settings, and do not change several things at once before you know which one matters: change everything together and you will not know which change actually fixed it.",{"type":12,"id":13,"html":104},"What a DNS leak actually is",{"type":7,"html":106},"Every time you browse normally, your device first has to turn a domain name into a numeric address, and that step is DNS resolution; "DNS" in everyday use refers to this layer. Without a VPN, that lookup goes straight to the resolver your carrier assigns. With a VPN connected, that same lookup should normally travel through the tunnel too, reaching a resolver on the far end.",{"type":7,"html":108},"A "leak" is when that lookup does not follow the tunnel and keeps going to a local or carrier resolver instead. The actual content — a page, a video — may genuinely be encrypted in transit, but the domain lookup slips out on its own, and whoever can see that request can still piece together a record of which sites you visited, just not what was on them. This is exactly why "connected to a VPN" and "all traffic is in the tunnel" are not the same statement, and this particular layer is the one most likely to get overlooked — it is nothing like a page failing to load. A leak usually produces no symptom at all: everything feels completely normal day to day, and the only way to notice is to go and check deliberately.",{"type":7,"html":110},"That is exactly why this layer is easy to ignore: nothing stutters, nothing throws an error, there is no warning of any kind — checking for it yourself is the only way to know.",{"type":12,"id":22,"html":112},"A thirty-second self-check",{"type":7,"html":114},"The simplest method is to search for "DNS leak test," open any page that runs this kind of check, and run it once while connected. The page usually lists the region and provider of the resolver it found: compare that against your actual broadband or mobile carrier. If it shows a resolver in the tunnel's region, there is no leak; if it still shows your local carrier's name, the lookup really did slip out.",{"type":7,"html":116},"Two small details are easy to miss while testing: run the check only after the connection has been stable for a few seconds, since testing the instant it connects can still catch the state from before the switch — and if you use both a computer and a phone, test each separately rather than assuming one result applies to both, especially if they are not on the same network.",{"type":7,"html":118},"If you would rather confirm it from the command line, you can check the resolver address currently in use directly:",{"type":31,"code":32},{"type":7,"html":121},"If the address in the output falls in a range your local carrier commonly uses, rather than one belonging to the tunnel's region, that also indicates a leak. Either method is enough on its own; there is no need to run both.",{"type":12,"id":36,"html":123},"Common causes, most likely first",{"type":39,"items":125},[126,131,136],{"title":127,"body":128},"A custom DNS address configured somewhere in the system",[129,130],"Plenty of people have, at some point, manually entered a fixed DNS address in the system or the router to solve a different problem, like speeding up a specific site. Once that setting exists, it usually takes priority over whatever the client is trying to take over, so lookups follow the manually entered address and bypass the tunnel.","How to confirm it: think back on whether a DNS address was ever entered manually in network settings, or check the router's admin page for a similar custom entry. How to fix it: switch that setting back to automatic and let the client take over this layer itself, then test again.",{"title":132,"body":133},"The client never routed DNS through the tunnel in the first place",[134,135],"Some tools only handle the data content of pages and apps, treating the domain lookup as a separate matter it never brings into the tunnel at all. In this case the data itself looks completely normal while the lookup travels outside the tunnel the whole time, and there is very little on the surface that would tip you off.","How to confirm it: if a custom DNS setting has been ruled out and the self-check still shows a leak, this layer simply never being taken over is the likely explanation. How to fix it: this is really a question of how the client itself is built, and there is not much to adjust on your end; switching to a client that routes DNS through the tunnel too is the more direct fix.",{"title":137,"body":138},"The browser's own encrypted DNS bypassing the system",[139,140],"Some browsers ship their own encrypted DNS feature that bypasses system settings entirely and sends lookups straight to a server the browser itself specifies. The feature is meant to protect privacy, but if the server it points to has nothing to do with the VPN's tunnel, the practical effect is opening up a brand-new leak path instead.","How to confirm it: look in the browser's settings for anything related to "secure DNS" or "encrypted DNS," check whether it is switched on, and see which provider it points to. How to fix it: there is no need to turn the feature off entirely: point it at a server reachable through the tunnel, or disable it temporarily and let the system handle it, then decide after testing.",{"type":57},{"type":12,"id":59,"html":143},"IPv6 is another gap that is easy to miss",{"type":7,"html":145},"With the three causes above ruled out, there is one more case worth watching for on its own: a device with both IPv4 and IPv6 connectivity, where only the IPv4 side got taken over by the tunnel. DNS lookups and actual connections over IPv6 can both bypass the tunnel entirely — the same underlying pattern as above, a lookup taking another path, except this time the connection itself leaks along with it.",{"type":7,"html":147},"This is the same root cause behind \u003Ca href=\"\u002Fen\u002Fblog\u002Fip-still-shows-china-after-vpn\u002F\">IP still shows China after VPN\u003C\u002Fa>, just showing up two different ways across the two articles: there it is an IP check that never changes, here it is a DNS test reporting a leak, and both trace back to the IPv6 path never being handled. IPv6 has become the default on a growing share of mobile networks and home broadband over the last few years, so this kind of partial leak is not some rare edge case anymore — it is easier to run into than it used to be.",{"type":7,"html":149},"If the self-check shows a leak and IPv6 looks like the likely cause, try turning IPv6 off temporarily in the system's network settings and testing again as a comparison: if the leak disappears, that confirms it; if it is still there, the cause is one of the three above and has nothing to do with IPv6, so there is no need to leave it switched off.",{"type":12,"id":68,"html":151},"What to do once you find a leak",{"type":7,"html":153},"Working through the three causes above in order pins down most leaks to a specific layer: check first for a manually entered DNS address in the system or router, then whether the client itself ever routes DNS through the tunnel, then whether the browser turned on its own encrypted DNS. After changing the relevant setting, rerun the self-check to confirm rather than assuming it is fixed just because you changed something.",{"type":7,"html":155},"If all of these are ruled out and the self-check still shows a leak, send support a screenshot of the test result along with your device model and OS version — that gets you an answer faster than continuing to guess, and makes it easier for them to tell whether it is specific to a particular version.",{"type":12,"id":75,"html":157},"In summary",{"type":7,"html":159},"A DNS leak means domain lookups are taking a path outside the tunnel. What leaks is a record of which sites you visited, not the content of the pages themselves. A thirty-second self-check combined with working through the three causes by likelihood resolves most cases on your own, and IPv6 is the one corner still worth checking once the common causes are cleared.",{"type":7,"html":161},"If you would rather not re-run this check every time you get a new device or join a new network, the real fix is having the client manage this layer itself. \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">FastOrange\u003C\u002Fa> is built to route DNS through the tunnel automatically, with nothing to configure on the system or the router by hand. If you have worked through the steps above and still cannot confirm it, \u003Ca href=\"\u002Fen\u002Fcontact\u002F\">contact support\u003C\u002Fa> with the test result attached, which makes it much faster to pin down which layer the problem is actually in. More on this area is covered under \u003Ca href=\"\u002Fen\u002Fsecurity\u002F\">security\u003C\u002Fa> as well.",[163,166,169,172,175],{"q":164,"a":165},"Does a DNS leak mean the VPN is completely useless?","No. Even with a DNS leak, the actual data still travels through the encrypted tunnel, so no one intercepting it can see the content itself. What leaks is the record of which domains you looked up: a real privacy gap, but not the whole layer failing.",{"q":167,"a":168},"Would checking from a phone's built-in browser and an app's built-in browser give different results?","Possibly. Different browsers do not always follow the system's DNS setting, especially once a browser's own encrypted DNS feature is turned on. It is worth testing whichever ones you actually use rather than just one.",{"q":170,"a":171},"Can DNS settings on my router affect my phone?","Yes. If the phone's network settings do not specify its own DNS, it inherits whatever the router hands out. That is also why a leak can suddenly appear or disappear just from switching networks.",{"q":173,"a":174},"How often should I check for this?","Not every day. Testing once after getting a new device, joining a new network, or updating the OS is enough; those are the situations most likely to quietly reset something you had already configured back to default.",{"q":176,"a":177},"How does FastOrange handle this layer?","FastOrange's approach is to have the client take over DNS itself, so there is no need to manually change DNS settings on the system or the router, which cuts down on how often this kind of leak happens in the first place.",1793276292175]