[{"data":1,"prerenderedAt":196},["ShallowReactive",2],{"blog:what-is-dns":3},{"zh-CN":4,"en":106},{"blocks":5,"faq":90},[6,9,11,13,17,19,21,23,26,28,36,38,40,43,45,47,49,51,54,56,58,60,62,65,67,69,71,74,76,83,86,88],{"type":7,"html":8},"p","DNS 的工作是把域名翻译成 IP 地址——浏览器地址栏里的名字本身连不上任何服务器，必须先查到对应的地址，这一步就是域名解析，日常说的「DNS」指的就是这一层。",{"type":7,"html":10},"打不开网页的时候，先怀疑 DNS 是有道理的：这是请求出发前必须先完成的一步，一旦这一步出错，后面无论网络本身多通畅，都到不了正确的地方。这篇讲清楚 DNS 具体怎么工作，以及打不开网页时它到底该不该是第一个怀疑对象。",{"type":7,"html":12},"先说清楚它和 IP 地址的关系：\u003Ca href=\"\u002Fblog\u002Fwhat-is-an-ip-address\u002F\">IP 地址是什么\u003C\u002Fa>那篇讲的是地址本身，这篇讲的是「怎么查到这个地址」的那道手续，两者是同一件事的前后两步，不是竞争关系。",{"type":14,"id":15,"html":16},"h2","bp-what","DNS 到底是什么",{"type":7,"html":18},"每个网站都有一个人类好记的域名，但设备之间实际用来找路的，是数字组成的 IP 地址。DNS 就是把域名翻译成对应地址的这套系统——没有这一步，输入域名以后设备根本不知道该往哪发请求。",{"type":7,"html":20},"打个比方，域名像是写在名片上的人名，IP 地址像是这个人的实际门牌号——认识的人靠名字就能想起来是谁，但快递员送东西还是得靠门牌号，DNS 做的就是从名字查到门牌号这件事。",{"type":7,"html":22},"这套翻译工作日常感觉不到，因为整个过程通常在几十毫秒内完成，而且结果会被缓存一段时间。同一个域名短时间内重复访问，很多时候用的是缓存好的答案，不需要每次都重新查一遍。",{"type":14,"id":24,"html":25},"bp-how","DNS 是怎么工作的",{"type":7,"html":27},"查一个域名，大致按这个顺序找答案，前一步没找到才会问下一步：",{"type":29,"items":30,"ordered":35},"list",[31,32,33,34],"先看浏览器自己的缓存——如果最近查过这个域名，直接用记住的答案。","再看系统的缓存——浏览器没记住，系统层面可能还记得。","两边都没有，才真正发请求给本地或者运营商指定的解析服务器。","如果这个解析服务器自己也没有答案，会再去问更上层的服务器，一路问到能给出准确答案的那一台，再把结果逐层带回来。",true,{"type":7,"html":37},"这几层缓存的存在，是为了少走最后两步——它们最耗时，也最容易受路上环节的影响。这也是为什么「刚改了设置却好像没生效」经常只是缓存还没过期，不是设置本身没生效，等缓存自然过期或者手动清一下，通常就能看到新结果。",{"type":7,"html":39},"对使用者来说，这几层缓存大多数时候是好事——同一个网站反复打开速度会更快，因为很多时候答案早就在手边，不用每次都跑一趟最耗时的那两步，只有在答案本身是错的时候，缓存才会变成拖慢排查速度的麻烦。",{"type":14,"id":41,"html":42},"bp-why-first","打不开网页时，为什么先想到 DNS",{"type":7,"html":44},"网页打不开，原因可能出在很多层，DNS 只是其中一层，但排在前面查是有道理的，因为它是最早发生的一步——域名解析没成功，后面的连接根本没有机会开始。",{"type":7,"html":46},"一个比较好认的信号：网页一直转到超时才报错，而不是立刻报「无法连接」。这种「卡住不动」的表现，比「秒失败」更像是解析这一层没拿到答案，设备不知道该往哪发，只能干等。",{"type":7,"html":48},"另一个信号是直接用 IP 地址访问同一个服务：如果 IP 能通、域名不能通，基本可以确定问题出在域名解析这一步，不是网络本身断了，也不是目标服务器出了问题。",{"type":7,"html":50},"第三个信号是同一个域名，换一个网络环境（比如从家庭宽带切到手机数据）就能打开——说明域名解析这一步严重依赖连的是哪张网络，不同网络指定的解析服务器不一样，查到的结果也可能跟着不一样。",{"type":14,"id":52,"html":53},"bp-privacy","DNS 查询会不会暴露我访问过的网站",{"type":7,"html":55},"DNS 查询本身通常不加密，沿途能看到这条请求的一方——比如所在网络的运营商——能看到你查过哪个域名，即使查询之后实际打开的内容是加密的，域名这一条记录依然可能被看到。",{"type":7,"html":57},"这也是为什么「网页内容加密了」和「访问记录不会被看到」不是同一件事——内容加密解决的是「看不懂传输的具体内容」，域名查询这一步如果单独走在外面，还是可能留下「查过哪个域名」的痕迹，两者是链路上的不同环节，VPN 加密入门对这条边界讲得更细。",{"type":7,"html":59},"这也是为什么翻墙工具通常会强调「DNS 也走隧道」——只加密网页内容，不管 DNS 查询这一步，这段记录依然会暴露在隧道之外，防护并不完整。",{"type":61},"downloads",{"type":14,"id":63,"html":64},"bp-practice","在实际使用中你会在哪见到这件事",{"type":7,"html":66},"最常被提到的场景是「DNS 污染」或者「DNS 劫持」——查询过程被干扰，拿回来的地址是错的，于是设备兴高采烈地连到一个连不上或者不该连的地方。这类问题的表现和普通网络故障很像，区别在于换个网络环境，同一个域名有时候就能查对，因为不同网络指定的解析服务器不一样。更完整的自查方法在DNS 泄漏是什么，怎么自查里。",{"type":7,"html":68},"另一个常见说法是「换了公共 DNS 就能解决翻墙问题」——只换 DNS 服务器，解析结果确实可能变得更准确，但如果问题出在分流规则或者节点本身，换 DNS 帮不上忙。DNS 只是链路里的一层，不是万能钥匙，VPN 显示已连接，却打不开网页按 DNS、分流规则、系统代理、节点这四层顺序讲了完整的排查思路，DNS 只是第一层。",{"type":7,"html":70},"路由器上设置的 DNS 也会影响连在这个路由器下的所有设备——如果手机或者电脑没有单独指定，会跟着路由器分配的设置走。换一个网络环境，同一台设备的解析结果有时候就会不一样，这不是设备本身的问题，是继承了不同网络的设置。",{"type":14,"id":72,"html":73},"bp-limits","DNS 不能做什么",{"type":7,"html":75},"DNS 只负责翻译域名，不负责别的事，下面这几条经常被误会成它的责任。",{"type":29,"items":77},[78,79,80,81,82],"不负责传输内容本身——查到地址之后，实际的网页内容走的是另一条路，DNS 的工作在查到地址那一刻就结束了。","不负责加密——查询和返回的过程本身，多数情况下不加密，这也是上一节提到的痕迹问题的根源，不是这一层刻意留下的漏洞，是这套系统设计之初就没有把加密算在职责范围内。","不能让本来到不了的地方变得能到——如果目标服务器本身不可达，或者网络层面被更彻底地拦截，查对了地址也连不上，DNS 解决的只是「查对地址」这一步，剩下的路要靠别的机制打通。","不是唯一会让网页打不开的原因——分流规则、系统残留的旧代理设置、节点本身的问题，都可能表现成同样的「打不开」，DNS 只是排查顺序里排在前面的一层，不是唯一嫌疑对象。","不会主动提醒你查询出错了——解析错了、被污染了，设备通常不会弹出任何提示，只会安静地连到错的地方，这也是为什么这一层的问题总要靠使用者自己留意「卡住不动」这类间接信号才能发现。",{"type":14,"id":84,"html":85},"bp-final","总结",{"type":7,"html":87},"DNS 把域名翻译成 IP 地址，是打开网页前必须先完成的一步，也是打不开网页时值得优先怀疑的一层，因为它发生得最早。它不负责传输内容、不负责加密，也不是网页打不开的唯一原因，遇到问题时把它当成排查顺序里的第一层，而不是唯一答案。",{"type":7,"html":89},"快橙的客户端连接时自己接管 DNS 查询，让它走隧道内的解析服务器，不需要手动去改系统或者路由器设置，也更不容易被沿途的解析服务器污染。\u003Ca href=\"\u002Ffeatures\u002F\">功能介绍\u003C\u002Fa>有更完整的说明，注册后每天有免费试用时长，先连上感受一下。",[91,94,97,100,103],{"q":92,"a":93},"DNS 和 IP 地址是同一件事吗？","不是。IP 地址是设备的地址，DNS 是把域名翻译成这个地址的那道翻译手续，\u003Ca href=\"\u002Fblog\u002Fwhat-is-an-ip-address\u002F\">IP 地址是什么\u003C\u002Fa>专门讲了地址本身，这篇讲的是翻译这一步。",{"q":95,"a":96},"换个公共 DNS 服务器，能解决打不开网页的问题吗？","看情况。如果问题出在域名解析这一层，换一个响应更快或者不被污染的服务器确实可能有帮助；如果问题出在分流规则或者节点本身，换 DNS 帮不上忙。",{"q":98,"a":99},"为什么有的网站用 IP 地址能打开，换成域名就不行？","说明能连通目标服务器本身，卡住的是域名到地址这一步的翻译。这种情况先怀疑 DNS 这一层，而不是网络本身断了。",{"q":101,"a":102},"DNS 污染和 DNS 劫持是一回事吗？","日常经常混用。严格说前者是查询结果被篡改成错误地址，后者范围更广，包括查询请求被引导到别的解析服务器。对使用者来说表现都是「打开的不是该打开的地方」，处理思路是相通的。",{"q":104,"a":105},"手机和电脑的 DNS 行为一样吗？","不完全一样。电脑上常有残留的系统代理和浏览器插件会各自改解析，手机基本只看系统这一层，所以同一条网络下两台设备结果不同是常见的。",{"blocks":107,"faq":180},[108,110,112,114,116,118,120,122,124,126,132,134,136,138,140,142,144,146,148,150,152,154,155,157,159,161,163,165,167,174,176,178],{"type":7,"html":109},"DNS translates a domain name into an IP address. The name typed into a browser's address bar cannot reach any server on its own; it has to be looked up first, and that lookup is what "DNS" refers to day to day.",{"type":7,"html":111},"Suspecting DNS first when a page won't load makes sense: it is the step that has to happen before the request even sets off, and if it goes wrong, no amount of network health downstream will get you to the right place. This article covers how DNS actually works, and whether it deserves to be the first suspect when something won't load.",{"type":7,"html":113},"Worth separating out first: \u003Ca href=\"\u002Fen\u002Fblog\u002Fwhat-is-an-ip-address\u002F\">what an IP address actually is\u003C\u002Fa> covers the address itself. This article covers the lookup that finds it. The two are consecutive steps in the same process, not competing explanations.",{"type":14,"id":15,"html":115},"What DNS actually is",{"type":7,"html":117},"Every site has a domain name that is easy for a person to remember, but what devices actually use to find each other is a numeric IP address. DNS is the system that translates a domain name into the matching address; without that step, a device has no idea where to send a request once a domain name is typed in.",{"type":7,"html":119},"Here's an analogy: a domain name is like the name printed on a business card, and an IP address is that person's actual street number. Someone who knows the name can recall who it is; a courier delivering a parcel still needs the street number. DNS is what gets you from the name to the number.",{"type":7,"html":121},"This translation is invisible day to day, because the whole process usually finishes in tens of milliseconds, and the result gets cached for a while. Visiting the same domain again shortly after often reuses that cached answer instead of looking it up fresh every time.",{"type":14,"id":24,"html":123},"How DNS actually does its job",{"type":7,"html":125},"Looking up a domain roughly follows this order, moving to the next step only if the one before comes up empty:",{"type":29,"items":127,"ordered":35},[128,129,130,131],"Check the browser's own cache first — if this domain was looked up recently, use the remembered answer.","Check the system's cache next — the browser may not remember, but the system layer might.","Only once both come up empty does a request actually go out to the resolver the local network or carrier has specified.","If that resolver does not have the answer either, it asks a server further up the chain, all the way up to whichever one can give a definitive answer, then carries the result back down.",{"type":7,"html":133},"Those layers of caching exist to skip the last two steps as often as possible — they take the longest, and they are the most exposed to whatever happens along the way. That is also why "I just changed a setting and it looks like nothing happened" is often just a cache that has not expired yet, not a setting that failed to take.",{"type":7,"html":135},"For the person using it, that caching is mostly a good thing: the same site loads faster on repeat visits because the answer is often already at hand, skipping the two slowest steps entirely. It only turns into a problem once the cached answer itself is the wrong one, at which point the same caching that usually helps ends up slowing down the diagnosis.",{"type":14,"id":41,"html":137},"Why suspect DNS first when a page won't load",{"type":7,"html":139},"A page failing to load can trace back to any of several layers, and DNS is only one of them. Still, checking it first makes sense, because it is the earliest step in the chain — if domain resolution never succeeds, the connection that follows never gets a chance to start.",{"type":7,"html":141},"One fairly recognisable signal: the page spins until it times out, rather than failing immediately with something like "unable to connect." That "stuck, not failing" pattern looks more like the resolution step never got an answer, leaving the device with nowhere to send the request and nothing to do but wait.",{"type":7,"html":143},"Another signal is reaching the same service directly by its IP address. If the IP address works and the domain name does not, that is fairly strong evidence the problem sits in domain resolution specifically, not in the network being down or the destination server having an issue.",{"type":7,"html":145},"A third signal is the same domain loading fine the moment you switch networks, say from home broadband to mobile data. That points at how much domain resolution depends on which network you are on: different networks specify different resolvers, and the same lookup can come back with different results depending on which one answers.",{"type":14,"id":52,"html":147},"Does a DNS lookup reveal which sites I visit",{"type":7,"html":149},"A DNS query itself is usually unencrypted, so whoever can see that request along the way, a network's operator, for instance, can see which domain got looked up, even when the content opened afterward is itself encrypted. The domain name is a separate record, and it can still be visible on its own.",{"type":7,"html":151},"That is exactly why "the page content is encrypted" and "my browsing record cannot be seen" are not the same claim. Content encryption solves "the transmitted content cannot be read." A DNS lookup travelling on its own, outside that protection, can still leave a trace of "this domain got looked up." The two sit at different points in the chain. VPN encryption, the basics draws that boundary more precisely.",{"type":7,"html":153},"That is also why circumvention tools tend to advertise "DNS goes through the tunnel too" as a separate claim. Encrypting page content while leaving the DNS lookup outside the tunnel still exposes that record; the protection is incomplete without covering both.",{"type":61},{"type":14,"id":63,"html":156},"Where you actually run into this",{"type":7,"html":158},"The scenario that comes up most is "DNS pollution" or "DNS hijacking": the lookup gets interfered with, the address that comes back is wrong, and the device happily connects to somewhere unreachable or somewhere it should not. It looks a lot like an ordinary network fault, except switching networks can make the same domain resolve correctly, because different networks specify different resolvers. DNS leaks, and how to check for one yourself covers the fuller self-check.",{"type":7,"html":160},"Another common claim is that switching to a public DNS server fixes circumvention problems on its own. Changing the resolver really can make lookups more accurate, but if the actual problem is a routing rule or the node itself, changing DNS will not touch it. DNS is one layer in the chain, not a master key. VPN connected but no internet: fix it in order works through DNS, routing rules, the system proxy, and the node in that order, with DNS as only the first of the four.",{"type":7,"html":162},"The DNS setting on a router affects every device connected to it, too. A phone or laptop that has not specified its own resolver inherits whatever the router hands out. Switch networks and the same device can get different resolution results, not because anything is wrong with the device, but because it inherited a different network's settings.",{"type":14,"id":72,"html":164},"What DNS cannot do",{"type":7,"html":166},"DNS's job is translating domain names, nothing more. The following get mistaken for its responsibility fairly often.",{"type":29,"items":168},[169,170,171,172,173],"It does not carry the content itself. Once an address is resolved, the actual page content travels down a separate path; DNS's job ends the moment the address comes back.","It does not encrypt anything. The lookup and its response usually travel unencrypted, which is exactly the source of the tracing issue covered above — not a deliberately left gap, but a job DNS was never designed to cover.","It cannot make an unreachable destination reachable. If the destination server itself cannot be reached, or the network is blocked at a deeper level, resolving the correct address still will not connect you. DNS only handles "resolve the right address."","It is not the only reason a page fails to load. Routing rules, a leftover system proxy from another tool, or the node itself can all produce the exact same "won't load" symptom. DNS is simply the layer worth checking first, not the only suspect.","It never actively warns you when something goes wrong. A wrong or polluted resolution usually raises no prompt at all; the device just quietly connects to the wrong place, which is exactly why this layer tends to surface only through an indirect signal like a page stuck spinning.",{"type":14,"id":84,"html":175},"In summary",{"type":7,"html":177},"DNS translates a domain name into an IP address, the step that has to succeed before a page can load, and the layer worth suspecting first when one does not, simply because it happens earliest. It does not carry content, does not encrypt anything, and is not the only reason a page can fail to load — treat it as the first layer in the diagnosis, not the only possible answer.",{"type":7,"html":179},"FastOrange's client takes over DNS lookups the moment it connects, routing them through a resolver inside the tunnel, with no need to change system or router settings by hand, and far less exposed to a resolver being polluted along the way. \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">See what it does\u003C\u002Fa> for the fuller picture. Every registered account gets free trial time daily, so connect once and see for yourself.",[181,184,187,190,193],{"q":182,"a":183},"Are DNS and an IP address the same thing?","No. An IP address is the device's address; DNS is the lookup that translates a domain name into that address. \u003Ca href=\"\u002Fen\u002Fblog\u002Fwhat-is-an-ip-address\u002F\">What an IP address actually is\u003C\u002Fa> covers the address itself; this one covers the lookup.",{"q":185,"a":186},"Will switching to a public DNS server fix a page that won't load?","Depends. If the problem sits in domain resolution, a faster or unpolluted resolver can genuinely help. If the problem is a routing rule or the node itself, changing DNS will not touch it.",{"q":188,"a":189},"Why does a site load by IP address but not by domain name?","That means the destination server itself is reachable, and the step stuck is translating the domain into an address. Suspect DNS first in that case, not the network as a whole.",{"q":191,"a":192},"Are DNS pollution and DNS hijacking the same thing?","They get used interchangeably in everyday talk. Strictly, pollution means the lookup result itself gets tampered with into a wrong address, while hijacking is broader and includes the query being redirected to a different resolver. To the person using it, both look like 'this opened somewhere it shouldn't have,' and the way to handle them is the same either way.",{"q":194,"a":195},"Do a phone and a computer resolve names the same way?","Not quite. Computers often carry leftover system proxies and browser extensions that each redirect lookups, while a phone mostly has only the system layer. Two devices on one network disagreeing is common.",1790199275569]