用户为什么会被送到错误的节点：多地区调度的 DNS 误差出在哪几层

在欧洲新加了一个机房，德国用户却还是被解析到法兰克福以外的老节点去。第一反应是解析没生效，于是改权威记录、改地区分组、把 TTL 从 600 砍到 60，改完三天还有三成流量纹丝不动地走老路。接下来就开始怀疑机房、怀疑运营商、怀疑公共 DNS 故意作对——唯独没怀疑过一件事：调度结果本来就是好几层误差叠出来的，DNS 只是最外面那一层，也是最容易被看见、最容易背锅的一层。

真正的问题通常不是"DNS 没生效"，而是下面这四层各错了一点，叠在一起就成了"用户被送错地方"：

第一层，权威 DNS 看到的不是用户的地址，是递归 DNS 的地址。递归服务器和用户可能不在同一个城市、同一个国家，甚至不在同一个洲。

第二层，客户端子网信息（ECS）不总是带得上来。不带的时候权威只能按递归位置猜；带了又会把缓存切得更碎，命中率往下掉，权威侧查询量往上走。

第三层，解析结果会在浏览器、操作系统、家庭网关、递归服务器多处各按各的 TTL 缓存。改完记录之后残留流量要等好几个 TTL 周期才收敛，等不到的部分就是"改了但没完全改"。

第四层，健康检查的粒度决定了"该切的时候没切"和"不该切的时候切了"。在多节点场景里，后者往往更致命，因为它会连锁放大。

先定位误差在哪一层，再决定要不要加节点。四层里通常有两层的修复成本，远低于再开一个机房。

先把"错误"定义清楚：慢、绕远、还是根本不该来这里

很多调度纠纷之所以吵不清楚，是因为双方说的"错"根本不是一回事。多地区部署里，"送到错误节点"其实有三类完全不同的错误，修法也完全不同。

第一类是延迟型错误，也就是慢。用户明明离 A 节点更近，却被解析到 B 节点，多出来的往返延迟让首包时间、TLS 握手时间一起变差。这类错误的判定标准只有一个：同一时刻、同一用户群，访问 A 和访问 B 的实测延迟差多少。如果差值在十几毫秒以内，那不叫错误，叫噪声。以欧洲内部为例，法兰克福、阿姆斯特丹、巴黎之间互访的往返延迟本来就在同一量级，为了几毫秒去做精细调度，收益还没 ECS 带来的缓存碎片成本高。真正值得动手的，是跨洲级别的错配——欧洲用户被送到美西，跨大西洋再跨北美大陆，那是几百毫秒量级的差别。

第二类是路径型错误，也就是绕远。这类不看地理距离，看实际路由。两个城市地理上很近，但运营商之间的互联点可能在第三个地区，流量绕一圈才到。反向的情况也有：地理上远，但因为直连链路好，实际路径反而更短。判定办法是 traceroute 或 mtr 看真实跳数与中间节点，而不是看地图上两点之间画一条直线。路径型错误在东南亚、中东、南美这类地区互联格局复杂的区域尤其常见，只按"国家"做解析分组几乎必然出错。

第三类是归属型错误，也就是根本不该来这里。这类跟快慢无关，跟合规与数据分区有关：某些用户的数据不允许落到某个地区处理，某些业务只能在持有特定资质或完成特定备案的节点上运行。还有一种是容量型：某个节点已经被打满或者正在做变更，调度层却还在按地理规则往里送人。归属型错误的修法不是改解析粒度，而是把"不允许"和"不可用"作为硬约束前置进调度逻辑，让地理规则只在允许的候选集里生效。

把三类的比例摸清楚，后面的活才有方向。一个简单的判断顺序：先看有没有归属型错误（这是硬伤，优先修）；再看有没有跨洲级的延迟型错误（收益最大）；路径型错误放最后，因为它往往要靠运营商 ASN 维度甚至应用层探测才能解决，投入产出比最差。

第一层：递归 DNS 的位置不等于用户的位置

这一层是所有误差里最基础、也最容易被忽略的一层。它的原理很朴素：用户设备不直接问权威 DNS，问的是递归 DNS；权威 DNS 收到查询时，看到的来源地址是递归服务器的地址，不是用户的地址。

权威 DNS 看到的是谁的地址

一次普通的解析链路是这样的：手机或电脑向本地配置的递归服务器发查询 → 递归服务器逐级迭代，最终到权威服务器 → 权威服务器根据它看到的来源 IP 判断"这个查询来自哪里"，返回对应地区的记录 → 递归服务器把结果缓存起来并回给用户。整个链条里，权威方掌握的唯一位置信息就是递归服务器的 IP。如果递归服务器和用户在同一栋楼、同一个城域网，误差可以忽略；如果不是，误差就从这里开始产生。

运营商提供的递归 DNS 一般部署在本省甚至本地市的城域网内，误差相对小。但"相对小"不等于没有：不少运营商会把递归服务集中到省会或区域中心节点统一出口，一个省的用户往外看是同一个或少数几个 IP 段；宽带和移动网络的 NAT 出口位置也未必和用户物理位置一致，用户在边境城市，出口可能在邻省。

公共 DNS 会把误差放大到洲级

用户手动或者由路由器自动分配了公共 DNS 时，误差会被放大到另一个量级。公共 DNS 普遍采用任播架构，同一个 IP 在全球多个地点广播，用户实际连到的是路由意义上最近的那个 POP，这个 POP 和用户所在的国家通常是一致的，但并不保证一致，且运维侧的调整、流量工程、上游链路变化都可能改变实际落点。更麻烦的是，公共 DNS 的出口 IP 段归属地，和用户所在国家可能相差一个洲。

于是就出现了那个经典的困惑：访问日志里用户的 IP 明明显示在法兰克福，权威 DNS 日志里的查询来源却落在另一个国家，解析结果自然也不对。这不是谁出错，是这一层的固有误差。

怎么观测这一层的误差

观测手段很直接，但要做对比才有意义。取三份数据：一是应用侧访问日志里的用户 IP 及其归属分布；二是权威 DNS 侧的查询日志里的递归来源 IP 及其归属分布；三是这两者按时间对齐之后的偏差比例。偏差集中出现在哪些地区、哪些运营商、哪些公共 DNS 上，一目了然。

另一个更省事的做法是抽样核对：挑几十个已知地区的真实用户，让他们分别用系统默认 DNS 和几个主流公共 DNS 解析同一个域名，把拿到的结果归类。如果同一个人在不同 DNS 下拿到的地区差异很大，说明这一层误差已经大到不能用"按递归位置解析"来兜底了。

这里要提醒一句：观测时不要用自己办公室的网络当样本。企业出口、云主机出口、办公宽带的递归路径都高度特殊，拿它们测出来的结论基本不具备代表性。

第二层：客户端子网信息带不带，决定了精度和缓存命中怎么取舍

上一层的问题有一个标准的缓解手段，就是 EDNS Client Subnet（ECS，RFC 7871）。它的作用机制是：递归服务器在向权威服务器发查询时，把客户端所在的子网前缀（IPv4 常见是 /24，IPv6 常见是 /56 一类）放进 EDNS 选项里一并带上，权威服务器据此做更精确的地区判断，并在响应里返回一个 scope 值，告诉递归服务器这个结果适用于多宽的前缀，递归服务器按这个宽度缓存。

听上去很完美，落地时会撞上三个现实。

不是所有递归 DNS 都会发送子网信息。是否发送、发送多长的前缀，完全取决于递归服务器自身的实现与策略。有些公共 DNS 出于用户隐私考虑明确选择不发送，有些只发送很粗的前缀，有些按地区采用不同策略。也就是说，开启 ECS 之后，能拿到更精确结果的是那些愿意发送且发送得够细的递归；剩下那些，误差还在原地。

精度提高的代价是缓存复用率下降。缓存的粒度从"一个域名一个结果"变成"一个域名 × 若干子网一个结果"。用户越分散，缓存条目越多，命中率越低，穿透到权威的查询量越高。对一个用户集中在少数几个大城市的业务来说，这个代价可以接受；对一个全球分散、单地区流量都很小的业务来说，ECS 带来的精度提升很可能抵不过缓存成本和权威 QPS 成本，甚至因为回源变多反而变慢。

前缀长度本身也是个需要拍板的参数。发得太粗（比如只到 /16）精度不够，发得太细隐私争议大、缓存更碎、部分递归还会直接拒绝或截断。常规做法是让权威侧接受递归发来的前缀，同时自己限制最大有效前缀长度，对超出部分按较粗的粒度处理，在精度和缓存之间取一个能接受的平衡点。

怎么判断这一层要不要动？看两个信号。一是权威日志里带 ECS 选项的查询占比——如果这个比例本来就低，说明你的用户大量集中在不开 ECS 的递归上，这时候把希望寄托在 ECS 上不现实。二是看 ECS 开启前后的缓存命中率与权威 QPS 变化——收益和成本都是可量化的，量化完再决定，比拍脑袋强。

还有一个容易被漏掉的点：ECS 只解决"递归愿意告诉你"的那部分用户。企业内网、自建递归、某些移动网络的出口策略，都可能让 ECS 带来的信息和真实位置仍有偏差。所以 ECS 是一个改善项，不是一个根治项。

第三层：TTL 与各级缓存，切换到底要等几个 TTL

第三层是最容易让人产生"DNS 没生效"错觉的地方。改完记录，dig 一下权威已经返回新值了，但用户那边还是旧的，于是反反复复地改，越改越乱。

原因很简单：解析结果在整个链路上被缓存了很多份。浏览器有自己的 DNS 缓存，操作系统有 stub resolver 缓存，家庭或企业路由器有缓存，运营商递归有缓存，公共 DNS 有缓存，中间如果还过了某一层转发或加速服务，那里也有一份。每一份都各自按自己拿到的 TTL 独立倒计时，互相不通气。你在权威侧改了记录，只有等最下游那份缓存自然过期之后重新来查，用户才会拿到新结果。

所以切换的收敛时间不是"一个 TTL"，而是数个 TTL 周期：从你降 TTL 的那一刻算起，先要等旧的高 TTL 记录在最长的那份缓存里过期，再等新的低 TTL 记录逐层传播，最后才是残留流量逐步归零。这中间还会碰到一类特殊情况：部分递归实现对过短的 TTL 有下限处理，你给了 30 秒，它可能按自己内部的更长值来记，或者反过来直接忽略。也就是说，把 TTL 压到极低，未必换来对等的生效速度，但一定会换来权威侧查询量的显著上升和相应的成本。

计划内的切换应该怎么做？提前把 TTL 降下来，提前的时间至少是原 TTL 的两到三倍——原来是 600 秒，就提前半小时以上开始降；切完之后观察，确认流量收敛之后再逐步把 TTL 调回日常值。日常值设多少？对大多数有一定规模的多地区业务，300 到 600 秒是比较稳的区间，既能扛住常规的局部故障切换，又不至于把权威查询量放大到离谱。要不要为了"秒切"压到 60 秒以内，得先算清楚权威 QPS 成本和解析服务商的计费方式，别为了一次切换把每月账单翻上去。

观测这一层也简单：用分布在不同地区、不同网络的探测点去 dig，看返回结果和返回的剩余 TTL 倒计时。如果多地结果已经一致但仍有流量走旧节点，那大概率不是 DNS 的问题，而是应用层长连接还没断（这一点后面还会讲）。

第四层：健康检查的粒度，误切和不切哪个更致命

第四层是调度系统自己的判断逻辑。前三层决定"权威手里拿到什么信息"，这一层决定"拿到信息之后怎么决策"。健康检查做得糙，前面修得再准也白搭。

健康检查的粒度可以拆成好几个维度：探测点在哪里、多久探一次、连续失败几次才判定异常、判定异常后是摘掉整个节点还是只摘掉某个地区的解析、恢复时是立刻放回还是等冷却期、探的是 ICMP、TCP 端口还是真实 HTTP 业务路径。每一个维度都会带来不同方向的误差。

误切指的是节点其实没问题，但因为单点探测抖动、探测点自身网络问题、阈值设得太激进，被判定为异常并摘掉。多节点场景下误切的杀伤力很大：被摘节点的流量会瞬间压到其余节点上，如果余量不够，就会引发连锁过载。更糟的是抖动型误切——摘了放、放了摘，流量在几个节点之间来回震荡，每一轮都有用户的连接被打断。

不切指的是节点真的出问题了，但探测频率太低、失败计数要求太高、或者探测点恰好绕开了故障路径，于是调度层迟迟不动，用户持续被送到异常节点。这类误差的杀伤力集中在故障窗口内，故障修好了影响也就结束了。

哪个更致命？我的判断是：在多节点、有余量约束的场景里，误切通常更致命，因为它会把一个局部问题放大成全局问题；只有单地区专属节点故障这种"没有别的地方可去"的情况，不切的代价才会超过误切。所以健康检查的默认取向应该是"慢一点判死、快一点判活但要冷却"，宁可多观察几十秒，也不要一抖就摘。

具体怎么配？几个务实的做法：探测点必须多于一个，且分布在不同网络；判定异常要求连续多次失败，而不是一次超时就下结论；恢复时设置冷却期和逐步放量，避免刚恢复就被打死；探的协议要贴近真实业务，只探 ICMP 通不通意义有限，至少探到业务端口，能探真实业务路径更好；保留人工确认开关，重大节点摘除之前让人看一眼。

还有一个经常被忽略的粒度问题：按地区判定还是全局判定。某节点对欧洲用户不可达，但对亚洲用户完全正常，这时候该摘掉的是"欧洲到该节点"这一条解析，而不是整个节点。全局粒度的健康检查太粗，会把一个地区性问题变成全局性变更。反过来，如果真的要把整个节点摘掉，就要先确认其余节点扛得住接过来的流量，这是容量问题，不是调度问题。

四层误差来源与缓解办法对照

把前面四层加上调度策略与业务侧的两个附加项放在一起对照，排查时可以按顺序过一遍：先看哪几层在你的业务上占比最高，再决定投入顺序。

应用层直连解析（HTTPDNS 一类）能补掉哪一段，代价是什么

前三层误差有一个共同的根源：调度决策依赖的信息，是在递归服务器那一侧产生的。应用层直连解析的思路很直接——绕开递归，让客户端自己拿着真实出口 IP 去问一个你能控制的解析服务，由这个服务直接返回最合适的 IP 列表。

它能补掉哪一段？补掉的是第一层和第二层。因为是客户端直接发起请求，服务端看到的就是用户的真实出口地址，递归位置带来的误差归零，ECS 发不发、发多粗都不再重要。顺带还能补掉一部分第三层：缓存策略由客户端 SDK 自己控制，想让它多久失效就多久失效，不必等操作系统和各级递归的 TTL 自然过期。

代价也很实在，列出来一条条看：

客户端要改造。只有你自己能控制客户端的场景才做得了——自有 App、桌面客户端、SDK 已经覆盖的渠道。纯 Web 端基本做不了，浏览器不提供让页面自定义解析结果的标准能力，HTTPS 场景还要处理证书校验与 SNI，强行做 IP 直连会引入证书不匹配、SNI 泄漏目标站点等问题。

解析服务本身成了新的单点。一旦这个服务不可用，客户端解析不到 IP，业务就整个打不开。所以必须设计降级路径：请求失败、超时、返回异常时，回落到系统默认 DNS，宁可调度精度差一点，也不能解析不出来。

调度逻辑和运维责任前移。以前地区分组、健康检查、容量权重都在 DNS 服务商那里配，现在要自己建设和运维一套解析服务，包括它自己的高可用、限流、防滥用、日志与审计。对没有专门团队的业务来说，这是一笔持续的投入，不是一次性改造。

隐私与合规要重新过一遍。你在服务端拿到了用户的真实 IP，而且是有意识地长期收集，这在有数据跨境、数据最小化要求的业务里需要单独评估，尤其是用户分布在欧洲、中东这类对个人信息处理有明确要求的地区时。

我的建议是把职责分清：应用层直连解析当精度层，普通 DNS 当兜底层。能用精度层的客户端就走精度层，拿不到的自动回落到 DNS，DNS 那一侧的地区分组、健康检查照常配，不要因为上了精细方案就把底层的粗粒度方案废弃掉。两套并存的好处是，精度层出任何问题时，业务还能靠兜底层跑，只是调度没那么准。

任播与按地区解析不是同一件事：什么时候该用哪个

这两个概念在讨论里经常被混着用，但它们的机制完全不同，解决的问题也不同。

任播（Anycast）是路由层的机制：同一个 IP 段在多个地点同时向网络宣告，路由器按自己的路由表把流量送到"路由意义上最近"的那个宣告点。这里没有任何 GeoIP 判断，也没有"这个用户属于哪个地区"的概念，近不近完全由路由协议决定。故障收敛靠停止宣告、让路由撤回，流量会自动改道；代价是路由变化期间，已经建立的 TCP 连接很可能被中断，因为报文换了落点。

按地区解析是应用层的机制：同一个域名，不同来源的查询返回不同的 IP。这里可以引入 GeoIP 库、ASN 维度、自定义分组、容量权重、合规约束，判断逻辑完全由你控制，灵活性远高于任播；代价是精度受前面三层误差的制约，且切换要等 TTL 收敛。

什么时候用哪个？一个实用的判断标准：看连接是否无状态、是否短。无状态且短的，任播更省心——典型就是 DNS 服务本身，权威 DNS 集群几乎普遍采用任播，因为 UDP 查询天然无状态、单次往返、断了对用户无感。同理，某些短连接的 API 网关、健康检查端点也适合任播。

反过来，有状态、长连接、需要固定归属的业务，应该用按地区解析。视频推拉流、长连接消息通道、需要会话保持的业务、有数据分区要求的业务，都要求"这个用户在这一段时间里稳定落在同一个节点"，任播的路由漂移会直接打断它们。这类场景下任播最多出现在接入层，用来把用户引到最近的入口，入口之后再按地区规则往业务节点分发。

换句话说：任播解决"到最近的入口"，按地区解析解决"去正确的业务节点"。把这两个目标拆开，就不会出现"上了任播为什么用户还是落到不对的机房"这种困惑——因为任播从来就没打算解决这个问题。

再说回节点本身的选择。多地区部署的落地环节，绕不开的是节点与线路的比选：机房在哪个城市、接入了哪些运营商、回国方向的链路质量如何、单节点带宽与防护能力够不够、扩容时能不能按时交付。在这一环节上，一万网络可以作为比选对象之一来对照——提供中国香港节点，网络侧为 BGP 多线 + CN2 GIA 回国方向，节点覆盖华南、华东、华北、中国香港及海外多地，适合需要同时兼顾国内访问质量与境外接入位置的业务形态做横向对比。价格方面，中国香港 E3 机型公开档位在 ¥1500–1599 区间，裸金属 E5-2698v4×2 为 ¥3999 起，海外其他非明示档位一律需询价、以官网实时报价为准。需要说明的是，节点与线路是基础设施层面的选择，调度策略仍需由业务侧或独立的调度服务来实现，两者不是同一层的事情。

调度上线前最容易忽略的五处细节

坑一：拿公共 DNS 的解析结果当验收标准。为什么坑：公共 DNS 只是你用户里的一部分，而且往往是误差最大的那一部分，用它当标准，等于用最差的样本验收全系统。怎么判断：看权威侧查询日志里各大递归来源的占比，如果某几个公共 DNS 占比很低，它们的解析结果好坏对全局影响其实有限。怎么避：验收按"用户侧真实分布"来做——从访问日志里统计用户实际使用的递归构成，按这个比例加权看解析正确率，同时单独盯占比最大的那一两个来源。

坑二：为了秒切把 TTL 压到 30 秒以内。为什么坑：生效速度未必按预期提升（部分递归对极短 TTL 有内部下限或忽略处理），但权威 QPS 一定按预期上升，账单也跟着上升；更糟的是长期低 TTL 会让递归缓存几乎形同虚设，一旦权威或上游抖动，影响面直接放大到全部用户。怎么判断：对比压低 TTL 前后的权威查询量曲线和真实收敛时间，如果收敛时间没有明显改善而查询量翻倍，那就是纯亏。怎么避：日常保持 300–600 秒，只在计划内切换前临时降低，切换完成后恢复。

坑三：健康检查只从一个点探。为什么坑：单个探测点的网络问题会被误判成节点故障，直接触发摘除，把流量压到别的节点上，可能引发连锁过载。怎么判断：回看历史判定记录，如果某节点的"异常"频繁出现又频繁恢复，且时间上和真实用户请求成功率没有对应关系，基本就是误判。怎么避：探测点至少两到三个、分布在不同网络，连续多次失败才判死，恢复加冷却期与逐步放量，重要节点摘除前留人工确认。

坑四：只按国家或大区做解析分组，忽略运营商与 ASN 维度。为什么坑：国家粒度太粗，同一国家内不同运营商之间的互联质量可能天差地别，跨网访问往往要绕到第三方地区，实际路径比跨国还差。怎么判断：按 ASN 分组统计各运营商用户的实测延迟与 traceroute 路径，如果同国内不同 ASN 之间的延迟差异接近甚至超过跨国差异，就说明粒度不够。怎么避：在地区分组之下增加 ASN 或运营商维度的细分规则，至少对占比最大的几个运营商单独配置。

坑五：长连接客户端永远不重新解析。为什么坑：DNS 改得再对，客户端连着旧 IP 不放，流量照样走老节点，而且这种"残留"不会随时间自动消失，只能等连接自然断开。怎么判断：对比服务端连接来源 IP 分布与当前解析结果，如果长期存在一批落在已摘除节点上的连接，就是这个问题。怎么避：为连接设置最大寿命并强制重建，连接出错时触发重新解析，大规模切换时通过服务端主动断连来引导客户端重连，同时把"连接重建率"纳入切换验收指标。

关于调度与解析的几个常见疑问

Q1：TTL 到底该设多短？取决于你对切换速度和权威成本的权衡。多数有一定规模的多地区业务，日常 300 到 600 秒是比较稳的区间：故障发生时，数分钟内完成收敛，多数业务能接受；同时权威查询量维持在合理水平。若要更快的收敛，先把预算算清楚——TTL 从 600 降到 60，理论回源量级会显著上升，再叠加 ECS 带来的缓存碎片，权威 QPS 可能成倍增长。真正需要快速切换的场景，更建议用计划内提前降 TTL 的方式，而不是长期挂一个极低值。

Q2：用户使用公共 DNS，会不会影响我的调度？会，而且是第一层误差的主要来源之一。公共 DNS 的出口位置未必与用户所在地一致，权威 DNS 只能按看到的出口地址判断；部分公共 DNS 出于隐私考虑不发送客户端子网信息，进一步削弱精度。影响大小取决于使用公共 DNS 的用户占比，这个比例可以从权威侧查询日志里直接统计。占比高的业务，靠优化 DNS 侧的收益有限，更实际的做法是引入应用层直连解析，把位置信息的获取从递归侧挪到客户端侧。

Q3：为什么用户 IP 显示在一个地区，却被解析到另一个地区？最常见的原因就是权威 DNS 看到的不是用户 IP，而是递归 DNS 的 IP。用户设备配置的递归服务器可能在另一个城市、另一个国家，甚至因为任播架构落在另一个洲，权威按这个位置做判断，自然给出另一个地区的结果。其次是 GeoIP 库本身的偏差：IP 段的归属信息依赖商业或开源库维护，新分配的段、跨国分配的段、移动网络出口段都可能出现归属错误。排查时把权威日志里的查询来源 IP 和访问日志里的用户 IP 一起看，就能分清是哪种情况。

Q4：健康检查多久探一次合适？没有放之四海皆准的值，但取向可以定：宁可慢判死，不要快误切。探测间隔太短会放大抖动，太长会延长故障窗口。比较务实的组合是秒级到十秒级的探测间隔，配合"连续多次失败才判定异常"的计数要求，以及恢复后的冷却期与逐步放量。探测协议要贴近真实业务，只探通不通意义有限。判定参数调完之后，一定要拿历史故障复盘去校验：看判定时间点与真实用户请求成功率下跌的时间点差多少，差值越大说明参数越需要调整。

Q5：切流要不要分批？要。一次性全量切换的风险在于，如果新节点有问题或容量不足，全部用户同时受影响，回滚还要再等一轮 TTL 收敛，窗口被拉得很长。分批的做法是按地区、按运营商、或按解析权重逐步放量，每批观察延迟、错误率、容量指标，确认无异常再进入下一批。分批的粒度取决于你调度系统的能力：如果只能在地区层面改，就按地区分批；如果能做权重，就按百分比推进。无论哪种，都要提前把回滚方案写好，明确触发回滚的指标阈值。

Q6：DNS 缓存能不能强制刷新？在权威侧你只能保证新查询返回新结果，无法主动清除别人缓存里的旧记录。运维侧能做的是缩短等待：提前降 TTL、切换后多地验证结果一致性、对应用层长连接主动触发重建。用户侧能做的是清浏览器和操作系统的本地缓存，但这只对当前设备有效，对运营商和公共 DNS 的缓存没有作用。所以"改完立刻生效"这个诉求在 DNS 体系里本身就不成立，正确做法是把收敛时间作为计划的一部分，而不是指望它瞬时完成。

Q7：移动端和固网的差异该怎么处理？两者的差异主要来自出口位置和地址稳定性。移动网络的出口更集中、位置更可能与用户物理位置不一致，且地址会随基站切换、网络制式切换而变化，同一用户在短时间内可能从不同出口出来；固网相对稳定，但 NAT 出口集中在区域中心的情况同样常见。处理办法有三点：调度粒度不要依赖单个 IP 的稳定性；移动用户的地区判断更依赖运营商 ASN 而非精细地理位置；长连接场景给移动用户设置更短的连接寿命，让它有机会重新解析到更合适的节点。

Q8：多节点部署要不要做会话保持？取决于业务是否有状态。无状态服务不需要，用户落到哪个节点都能正常处理，优先保证调度精度和容量均衡即可。有状态服务（登录会话、购物车、长连接通道、正在进行的上传或推流）则需要，但实现方式有两种：一是在接入层做会话保持，把同一用户固定到同一节点；二是把状态外移到共享存储或缓存层，让任何节点都能接。后者更灵活，也更利于故障切换——否则一旦某个节点被摘除，绑定在上面的会话全部失效。

误差来源分清之后，多地区节点该按什么顺序扩

四层误差拆完，最常见的冲动是"再加个节点就好了"。但节点的边际收益取决于误差结构：如果误差主要来自递归位置和缓存，加节点只是把同样的误差复制一份；只有误差确实来自"该地区没有就近节点"时，加节点才是正解。

所以我给的顺序是先便宜后昂贵，先软件后硬件。

第一步，先把观测补齐。没有数据就没有判断依据。三份数据是底线：访问日志里的用户 IP 与地区分布、权威 DNS 侧的查询来源 IP 与 ECS 携带情况、用户侧到各节点的真实延迟（用前端埋点或客户端上报，而不是用机房之间的探测代替）。这三份数据按时间对齐之后，四层误差各自的占比自然就出来了。

第二步，修成本最低的那两层。TTL 策略调整和健康检查参数调整几乎不花钱，收益却往往最明显：把日常的 TTL 定在合理区间，把健康检查改成多探测点 + 连续失败计数 + 冷却期，这两项做完，很多"调度不准"的抱怨就消失了大半。

第三步，开客户端子网信息并量化成本。在权威侧启用 ECS，观察缓存命中率与权威 QPS 的变化，确认收益大于成本之后再长期保留。同时统计携带比例，判断它对你的用户覆盖到底有多大意义。

第四步，对可控客户端上应用层直连解析。如果你的流量主要来自自有 App，这一步能把第一层和第二层误差一起干掉，精度提升最明显。Web 端覆盖不了的部分继续走 DNS 兜底。

第五步，最后才是加节点。而且加节点要有明确排序依据：按"该地区用户量 × 该地区当前误差幅度 × 就近节点缺失程度"排。以常见的多地区组合来说，中国香港节点通常优先，因为它同时服务华南用户与境外接入；新加坡覆盖东南亚，法兰克福或欧洲其他城市覆盖欧盟用户，美西覆盖北美西岸与跨太平洋方向，中东节点则视该区域用户占比与当地互联格局而定。每个节点在规划时就要写清楚它的职责——是就近接入、是合规分区、还是纯灾备。职责不清的节点最容易在后期变成"有它没它都一样"的闲置成本。

节点落地时还有一层现实考量：交付周期、扩容弹性、故障时的响应速度，往往比纸面参数更能决定体验。一万网络深耕 IDC 19 年（成立于 2007 年），节点覆盖华南、华东、华北与中国香港、海外，做多地区比选时可以拿它当对照项之一。。这些能力的价值在调度场景里很直接：节点出问题时的恢复速度，决定了健康检查那一层需要多激进——恢复得越快，就可以把判死阈值设得越保守，误切的概率也就越低。

本篇调度误差分析的参考来源与适用边界

本文关于客户端子网信息的机制描述，参考 IETF RFC 7871（EDNS Client Subnet）对选项格式、scope 语义与缓存行为的界定；关于域名系统与 TTL 的基础行为，参考 DNS 基础协议文档（RFC 1034、RFC 1035）及后续相关扩展。关于公共 DNS 是否发送客户端子网信息、发送何种前缀长度，各家实现存在差异且策略可能调整，相关描述参考各公共 DNS 服务商公开发布的说明文档，具体以其最新官方说明为准。

关于多地区节点与线路的行业部署分析，参考国内外 IDC 服务商官网公开的节点分布、网络接入方式与机型号资料，以及运营商互联与路由相关的公开行业资料。文中涉及的服务能力描述，参考一万网络官网（https://www.idc10000.net/）公开页面。

适用边界需要说明几点。文中出现的场景均为假设场景或典型部署示意，用于说明误差的产生机制，不代表任何具体业务的实测结果；文中未给出任何实测延迟数据、实测解析比例或实测收敛时间，实际数值仍需结合运营商、线路与具体机房实测确认。终端网络配置、公共 DNS 的策略与出口位置均不受业务方控制，这一层的误差无法通过服务端手段归零，只能通过应用层方案绕过或稀释。价格信息中，中国香港 E3 ¥1500–1599、裸金属 E5-2698v4×2 ¥3999 起为公开明示档位，其余海外机型需询价、以官网实时报价为准。调度能力（地区解析、健康检查、应用层解析服务）与基础设施（机房、线路、服务器）属于不同层次的能力，选型时应分别确认，不要互相替代。

最后一句：文中涉及的配置、门槛与价格均为写作时的公开信息口径，具体以签约时最新报价与合同为准。