[{"data":1,"prerenderedAt":409},["ShallowReactive",2],{"post-2025-11-11-dns-cold-start-dilemma-zh":3,"surround-2025-11-11-dns-cold-start-dilemma-zh":396,"randomIndex/2025/11/11/dns-cold-start-dilemma/":127,"language-switch-/2025/11/11/dns-cold-start-dilemma/-en":408},{"title":4,"date":5,"path":6,"tags":7,"body":10,"description":16},"DNS 冷启动：小型站点的“西西弗斯之石”","2025-11-11","/2025/11/11/dns-cold-start-dilemma",[8,9],"DNS","Network",{"type":11,"value":12,"toc":385},"minimark",[13,17,22,25,65,232,243,247,250,253,256,259,262,277,280,283,287,290,293,307,312,316,319,324,327,330,333,337,340,343,350,354,357,360,363,381],[14,15,16],"p",{},"当我们谈论网站性能时，我们通常关注前端渲染、资源懒加载、服务器响应时间（TTFB）等。然而，在用户浏览器真正开始请求内容之前，有一个至关重要却鲜少在性能优化方面被提及的部分—— DNS 解析。对于默默无闻的小型站点而言，“DNS Cache Miss”（缓存未命中）或我称之为“DNS 冷启动”，会成为绕不过去的性能瓶颈，也就是本文标题所提到的“西西弗斯之石”。",[18,19,21],"h2",{"id":20},"神话的隐喻dns-解析的漫长旅程","神话的隐喻：DNS 解析的漫长旅程",[14,23,24],{},"要理解这块“石头”的重量，我们必须重温 DNS 解析的完整路径。这并非一次简单的查找，而是一场跨越全球的接力赛：",[26,27,28,36,42,53,59],"ol",{},[29,30,31,35],"li",{},[32,33,34],"strong",{},"起点：公共 DNS 服务器"," — 用户发出请求，公共 DNS 服务器尝试在缓存中寻找答案。",[29,37,38,41],{},[32,39,40],{},"首次“推石”：根服务器"," — 缓存缺失（Cache Miss），公共 DNS 服务器被引向全球 13 组根服务器。",[29,43,44,47,48,52],{},[32,45,46],{},"第二程：TLD 服务器"," — 根服务器指向特定后缀（如 ",[49,50,51],"code",{},".com","）的顶级域名服务器。",[29,54,55,58],{},[32,56,57],{},"第三程：权威服务器"," — TLD 服务器指向网站域名最终的“管家”——权威 DNS 服务器。",[29,60,61,64],{},[32,62,63],{},"终点："," 权威服务器返回最终的 IP 地址，再由公共 DNS 服务器返回给用户。",[66,67,72],"pre",{"className":68,"code":69,"language":70,"meta":71,"style":71},"language-mermaid shiki shiki-themes one-light one-dark-pro","sequenceDiagram\n    participant User as 用户/浏览器\n    participant Local as 本地DNS\u003Cbr>递归解析器\n    participant Root as 根域名服务器\n    participant TLD as 顶级域服务器\u003Cbr>(.com, .org等)\n    participant Auth as 权威DNS服务器\n\n    Note over User,Auth: DNS递归查询完整流程\n\n    User->>Local: 1. 查询域名\u003Cbr>www.example.com\n    Note over Local: 检查缓存\u003Cbr>未找到记录\n\n    Local->>Root: 2. 查询 .com 的TLD服务器\n    Root-->>Local: 3. 返回 .com TLD服务器地址\n\n    Local->>TLD: 4. 查询 example.com 的权威服务器\n    TLD-->>Local: 5. 返回 example.com 的权威服务器地址\n\n    Local->>Auth: 6. 查询 www.example.com 的A记录\n    Auth-->>Local: 7. 返回 IP地址 (e.g., 1.1.1.1)\n\n    Note over Local: 缓存结果\u003Cbr>(根据TTL设置)\n\n    Local-->>User: 8. 返回最终IP地址\n\n    Note over User,Auth: 后续流程\n    User->>Auth: 9. 使用IP地址建立TCP连接\u003Cbr>开始HTTP请求\n","mermaid","",[49,73,74,82,88,94,100,106,112,119,125,130,136,142,147,153,159,164,170,176,181,187,193,198,204,209,215,220,226],{"__ignoreMap":71},[75,76,79],"span",{"class":77,"line":78},"line",1,[75,80,81],{},"sequenceDiagram\n",[75,83,85],{"class":77,"line":84},2,[75,86,87],{},"    participant User as 用户/浏览器\n",[75,89,91],{"class":77,"line":90},3,[75,92,93],{},"    participant Local as 本地DNS\u003Cbr>递归解析器\n",[75,95,97],{"class":77,"line":96},4,[75,98,99],{},"    participant Root as 根域名服务器\n",[75,101,103],{"class":77,"line":102},5,[75,104,105],{},"    participant TLD as 顶级域服务器\u003Cbr>(.com, .org等)\n",[75,107,109],{"class":77,"line":108},6,[75,110,111],{},"    participant Auth as 权威DNS服务器\n",[75,113,115],{"class":77,"line":114},7,[75,116,118],{"emptyLinePlaceholder":117},true,"\n",[75,120,122],{"class":77,"line":121},8,[75,123,124],{},"    Note over User,Auth: DNS递归查询完整流程\n",[75,126,128],{"class":77,"line":127},9,[75,129,118],{"emptyLinePlaceholder":117},[75,131,133],{"class":77,"line":132},10,[75,134,135],{},"    User->>Local: 1. 查询域名\u003Cbr>www.example.com\n",[75,137,139],{"class":77,"line":138},11,[75,140,141],{},"    Note over Local: 检查缓存\u003Cbr>未找到记录\n",[75,143,145],{"class":77,"line":144},12,[75,146,118],{"emptyLinePlaceholder":117},[75,148,150],{"class":77,"line":149},13,[75,151,152],{},"    Local->>Root: 2. 查询 .com 的TLD服务器\n",[75,154,156],{"class":77,"line":155},14,[75,157,158],{},"    Root-->>Local: 3. 返回 .com TLD服务器地址\n",[75,160,162],{"class":77,"line":161},15,[75,163,118],{"emptyLinePlaceholder":117},[75,165,167],{"class":77,"line":166},16,[75,168,169],{},"    Local->>TLD: 4. 查询 example.com 的权威服务器\n",[75,171,173],{"class":77,"line":172},17,[75,174,175],{},"    TLD-->>Local: 5. 返回 example.com 的权威服务器地址\n",[75,177,179],{"class":77,"line":178},18,[75,180,118],{"emptyLinePlaceholder":117},[75,182,184],{"class":77,"line":183},19,[75,185,186],{},"    Local->>Auth: 6. 查询 www.example.com 的A记录\n",[75,188,190],{"class":77,"line":189},20,[75,191,192],{},"    Auth-->>Local: 7. 返回 IP地址 (e.g., 1.1.1.1)\n",[75,194,196],{"class":77,"line":195},21,[75,197,118],{"emptyLinePlaceholder":117},[75,199,201],{"class":77,"line":200},22,[75,202,203],{},"    Note over Local: 缓存结果\u003Cbr>(根据TTL设置)\n",[75,205,207],{"class":77,"line":206},23,[75,208,118],{"emptyLinePlaceholder":117},[75,210,212],{"class":77,"line":211},24,[75,213,214],{},"    Local-->>User: 8. 返回最终IP地址\n",[75,216,218],{"class":77,"line":217},25,[75,219,118],{"emptyLinePlaceholder":117},[75,221,223],{"class":77,"line":222},26,[75,224,225],{},"    Note over User,Auth: 后续流程\n",[75,227,229],{"class":77,"line":228},27,[75,230,231],{},"    User->>Auth: 9. 使用IP地址建立TCP连接\u003Cbr>开始HTTP请求\n",[14,233,234,235,238,239,242],{},"对于",[32,236,237],{},"首次","或",[32,240,241],{},"长时间未访问","的请求，这个过程意味着至少 4 次网络往返（RTT），而在涉及到 CNAME 等情况时则会更多。对于那些拥有完美缓存的大型网站来说，这块石头可能已被别人推到了山顶；但对小型站点，它总是在山脚等待它的西西弗斯。",[18,244,246],{"id":245},"多重世界anycast-的镜像迷宫","多重世界：Anycast 的镜像迷宫",[14,248,249],{},"“既然 DNS 冷启动的代价如此之高，那我能否使用脚本定时访问自己的网站，提前让公共 DNS 缓存预热起来呢？”——这是我曾经设想的解题思路。",[14,251,252],{},"然而，这一思路在现代互联网的 Anycast（泛播）架构下，往往徒劳无功。",[14,254,255],{},"Anycast 的核心理念是：同一个 IP 地址在全球多个节点同时存在，用户请求会被路由到“距离最近”或“网络路径最优”的节点。",[14,257,258],{},"这意味着，Google DNS (8.8.8.8) 、Cloudflare DNS (1.1.1.1)、阿里 DNS (223.5.5.5)、腾讯 DNS (119.29.29.29) 等公共 DNS 服务器背后并不是一台中心化的服务器，而是一组分布在世界各地、动态路由的节点集群。",[14,260,261],{},"于是问题出现了：",[263,264,265,268,271],"ul",{},[29,266,267],{},"我在上海运行的预热脚本，也许命中了 223.5.5.5 的上海节点；",[29,269,270],{},"但来自北京的访问者，却会被路由到 223.5.5.5 的北京节点；",[29,272,273,274],{},"这两个节点的缓存，",[32,275,276],{},"彼此独立、互不共享。",[14,278,279],{},"从站长的视角来看，DNS 缓存不再是一个可预测的实体，而是分裂成一片片地理隔离、随时可变的“镜像迷宫”。",[14,281,282],{},"每个访客都在不同的山脚下推着自己的那块石头，仿佛世界上有成千上万个西西弗斯，孤独地在各自的路径上前行。",[18,284,286],{"id":285},"不可控的缓存与冷启动的常态化","不可控的缓存与「冷启动的常态化」",[14,288,289],{},"这也解释了为什么即便一个小型网站有规律地被脚本访问，仍可能在真实访客那里出现明显的 DNS 延迟。因为「预热」只是局部生效 —— 它温暖的是某一个任播节点的缓存，而不是整个网络的全貌。而当 TTL 到期或缓存被公共 DNS 服务器采用 LRU 等算法清理时，这份温度也会悄然散去。",[14,291,292],{},"从宏观上看，这让“小流量站点”陷入了某种宿命循环：",[26,294,295,298,301,304],{},[29,296,297],{},"因访问量低，缓存不易命中；",[29,299,300],{},"因缓存不命中，解析耗时高；",[29,302,303],{},"因解析耗时高，首屏性能差，用户更少访问；",[29,305,306],{},"因用户更少访问，缓存更难命中。",[14,308,309],{},[32,310,311],{},"冷启动不再是偶发的“意外”，而是一种被动的“常态”。",[18,313,315],{"id":314},"我们能否让石头变轻-减缓冷启动影响的策略","我们能否让石头变轻？—— 减缓冷启动影响的策略",[14,317,318],{},"西西弗斯的困境看似无解，但我们并非完全无能为力。虽然无法彻底消除 DNS 冷启动，但通过一系列策略，我们可以显著减轻这块石头的重量，缩短它每次滚落后被推上山顶的时间。",[320,321,323],"h3",{"id":322},"权衡的艺术调整-dns-ttl-time-to-live","权衡的艺术：调整 DNS TTL (Time-To-Live)",[14,325,326],{},"TTL（生存时间）是 DNS 记录中的一个关键值，它告知递归解析器（如公共 DNS、本地缓存）可以将一条解析记录缓存多久，尽管他们可能会被 LRU 算法淘汰。",[14,328,329],{},"拉长 TTL 可以有效提高缓存的命中率，减少 DNS 冷启动的情况，尽可能让西西弗斯之石保留在山顶上。",[14,331,332],{},"但拉长 TTL 是以牺牲灵活性作为代价的：如果你因为某些原因需要更换域名做对应的 IP 地址，过长的 TTL 可能会导致访客在很长一段时间内取得的都是已经失效的 IP 地址。",[320,334,336],{"id":335},"选择更快的信使使用合适的权威-dns-服务器","选择更快的“信使”：使用合适的权威 DNS 服务器",[14,338,339],{},"DNS 解析的最后一公里——从公共 DNS 服务器到你的权威 DNS 服务器——的耗时同样至关重要。如果你的域名所采用的 Nameserver 服务响应缓慢、全球节点稀少、又或者距离访客所请求的公共 DNS 服务器距离太远，那么即使用户的公共 DNS 节点就在身边，整个解析链条依然会被这最后一环拖慢。",[14,341,342],{},"如果我正在写的是一篇英文博客，那么我只需要说把 Nameserver 换成 Cloudflare、Google 等一线大厂就完事了。这些大厂提供免费的权威 DNS 托管业务，且在全球各地拥有大量节点，在这方面是非常专业且值得信赖的。",[14,344,345,346,349],{},"但我现在正在使用简体中文，根据我的博客统计数据，我的读者大多来自中国大陆，他们的站点访客大多也来自中国大陆，他们请求的公共 DNS 服务器大概率也都部署在中国大陆，而 Cloudflare/Google Cloud DNS 完全没有权威 DNS 服务器的中国大陆节点，这会拖慢速度。所以",[32,347,348],{},"如果你的访客主要来自中国大陆境内，或许可以试试阿里云或者 Dnspod","，他们主要的权威 DNS 服务器节点都在中国大陆境内，这在理论上可以减少公共 DNS 服务器与 权威 DNS 服务器之间的通信时长。",[18,351,353],{"id":352},"结语推石头的人","结语：推石头的人",[14,355,356],{},"DNS 冷启动的问题，从未有完美的解决方案。它像是互联网架构中注定存在的一段“延迟的诗意”——每个访问者都从自己的网络拓扑出发，沿着看不见的路径，一步步推着那块属于自己的石头，直到抵达你的服务器山顶，换得屏幕上第一个像素的亮起。",[14,358,359],{},"对小型站点而言，这或许是命运的重量；但理解它、优化它、监测它，便是我们在这条漫长上坡路上，为石头磨出更光滑的棱角。",[18,361,362],{"id":362},"参见",[263,364,365,374],{},[29,366,367],{},[368,369,373],"a",{"href":370,"rel":371},"https://developers.google.com/speed/public-dns/docs/performance",[372],"nofollow","Performance Benefits  |  Public DNS  |  Google for Developers",[29,375,376],{},[368,377,380],{"href":378,"rel":379},"https://falconcloud.ae/about/blog/how-do-dns-queries-affect-website-latency/",[372],"How do DNS queries affect website latency? - falconcloud.ae",[382,383,384],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":71,"searchDepth":84,"depth":84,"links":386},[387,388,389,390,394,395],{"id":20,"depth":84,"text":21},{"id":245,"depth":84,"text":246},{"id":285,"depth":84,"text":286},{"id":314,"depth":84,"text":315,"children":391},[392,393],{"id":322,"depth":90,"text":323},{"id":335,"depth":90,"text":336},{"id":352,"depth":84,"text":353},{"id":362,"depth":84,"text":362},[397,403],{"title":398,"path":399,"stem":400,"date":401,"lang":402,"children":-1},"你的域名后缀拖慢你的网站速度了嘛？——再谈 DNS 冷启动","/2025/11/25/did-your-tld-slowing-down-your-site","posts/zh/did-your-tld-slowing-down-your-site","2025-11-25","zh-CN",{"title":404,"path":405,"stem":406,"date":407,"lang":402,"children":-1},"HTTP/2 Server Push 已事实性“死亡”，我很怀念它","/2025/11/05/http-2-server-push-is-practically-obsolete","posts/zh/http-2-server-push-is-practically-obsolete","2025-11-05","/en/2025/11/11/dns-cold-start-dilemma/",1777565043838]