DNS 的 TTL 设置多少才不会影响切换速度

TTL 这个参数看起来很小，实际切换业务时经常卡在这里。域名解析已经改了，权威 DNS 也返回新 IP 了，但用户还是访问老 IP；监控看新节点正常，客服那边还在收到部分地区打不开的反馈。这个现象大多数时候不是 DNS 没生效，而是递归 DNS、客户端、浏览器、运营商缓存还没过期。

TTL 不是“解析多久生效”的开关，它的意思是：递归 DNS 拿到这条记录后，可以缓存多久。比如 A 记录 TTL 设置为 600 秒，某个用户使用的 Local DNS 在 10:00:00 查询过一次，它理论上可以把结果缓存到 10:10:00。你在 10:03:00 把 IP 从 A 机房切到 B 机房，这个用户那边大概率还会继续拿到老 IP，直到缓存过期。

TTL 对切换速度的影响到底有多大

实际使用中发现，切换速度不能只看 DNS 控制台显示的 TTL。真正影响用户访问切换的链路大概是：

权威 DNS 修改记录 → 递归 DNS 缓存过期 → 客户端重新查询 → 应用重新建立连接 → 用户访问新 IP。

这里面 TTL 只控制“递归 DNS 什么时候愿意重新问权威 DNS”。它控制不了用户手机里的 DNS 缓存，也控制不了浏览器连接池，更控制不了 App 自己写死的 DNS 缓存时间。

比如 TTL 设置 300 秒，看起来最多 5 分钟切完。但实际场景里，经常会出现 5 到 15 分钟的尾巴流量。原因不复杂：有些递归 DNS 不严格遵守低 TTL，有些客户端还在复用旧连接，有些企业网络出口 DNS 会做二次缓存。

常见 TTL 数值怎么选

TTL 30 秒

30 秒适合故障切换、灰度调度、DDoS 攻击期间切高防 IP、游戏区服临时调线这类场景。它的优点是切换快，递归 DNS 重新查询频率高。缺点也明显：权威 DNS 查询量会上来，解析服务本身要足够稳，不能用质量很差的 DNS 服务。

这里补充一点，有些 DNS 服务商控制台允许填 30 秒，但部分公共 DNS 或运营商 DNS 可能会把低 TTL 调整到 60 秒甚至 300 秒。所以设置 30 秒不等于所有用户 30 秒内切走，只能说把大多数正常遵守 TTL 的解析链路压到很短。

TTL 60 秒

60 秒是比较常见的动态切换值。线上业务需要在故障时快速切 IP，又不想让 DNS 查询量太夸张，60 秒通常比较稳。高防切换、源站热备、海外节点切换都可以用这个值。

如果业务前面接的是高防 IP，后面有源站或者多个机房，TTL 60 秒会比较舒服。攻击来了，把解析从普通 IP 切到高防 IP，或者从一个高防节点切到另一个清洗节点，大多数用户会在 1 到 5 分钟内逐步切过去。

TTL 300 秒

300 秒，也就是 5 分钟，是生产环境最常见的折中值。它适合稳定业务、日常小调整、非强实时切换的服务。比如企业官网、后台管理系统、API 域名，只要不是秒级容灾，300 秒够用。

很多云厂商默认 TTL 也是 300 秒或 600 秒。原因很现实：查询量不会太高，解析链路稳定，出问题时切换也不会慢到不可接受。

TTL 600 秒到 3600 秒

600 秒、1800 秒、3600 秒适合很稳定、几乎不切换的记录。比如验证记录、固定入口、低频访问的业务域名。好处是 DNS 查询压力小，缓存命中率高。坏处是切换慢，改错了也要等。

如果是线上主业务，不建议长期设置 3600 秒以上。特别是游戏、支付、登录、API 网关这类入口，一旦 IP 出问题，半小时到一小时的缓存尾巴会让排障非常被动。

不同场景下的 TTL 取值

生产里可以按场景直接定，不用纠结得太细。

普通企业网站：TTL 300 秒到 600 秒。网站不是强实时业务，几分钟切换可以接受，没必要一直压到 30 秒。

API 接口、登录服务、业务网关：TTL 60 秒到 300 秒。接口类业务对可用性敏感，TTL 太长会拖慢故障切换。

游戏入口、区服调度：TTL 30 秒到 60 秒。玩家侧对延迟和连接失败很敏感，切节点、切线路、切高防时 TTL 要短。

DDoS 防护切换：TTL 30 秒到 60 秒。攻击流量上来后，经常要把业务从普通线路切到高防 IP，TTL 长了会导致老 IP 继续承压。

海外访问优化：TTL 60 秒到 300 秒。比如香港、新加坡、泰国、日本、美国节点之间做调度，TTL 太长会影响线路调整效果。

邮件 MX 记录：TTL 600 秒到 3600 秒。邮件不是典型实时访问入口，缓存长一点问题不大。

TXT 验证记录：TTL 600 秒到 3600 秒。验证通过后一般不频繁变更，低 TTL 意义不大。

切换前临时降低 TTL，比事后改 TTL 更关键

很多人容易在迁移当天才想起改 TTL，这时候已经晚了。

假设当前 TTL 是 3600 秒，你在 10:00 把 TTL 改成 60 秒。这个动作不会让已经缓存了 3600 秒的递归 DNS 立即失效。那些在 9:59 查过记录的递归 DNS，可能要到 10:59 才重新查询。也就是说，TTL 的降低也要等旧 TTL 过期后才真正覆盖出去。

比较稳的操作方式是：计划迁移前一天，把业务 A 记录或 CNAME 的 TTL 从 3600 秒降到 60 秒或 300 秒。等一个旧 TTL 周期过去，再做真正的 IP 切换。这样迁移当天，大多数递归 DNS 已经拿到短 TTL，切换速度才会接近预期。

如果是重要业务，建议提前 24 小时降 TTL。不是因为 DNS 一定需要 24 小时，而是为了覆盖各种不规范缓存、企业出口 DNS、运营商缓存和用户侧异常情况。

A 记录、CNAME、CDN 场景里的 TTL 不一样

A 记录直接切 IP

A 记录最直观，域名直接指向 IP。TTL 设置为 60 秒，理论上递归 DNS 缓存 60 秒后会重新查。如果业务是单机、单高防 IP、单负载均衡入口，这种方式最容易理解。

比如源站从普通公网 IP 切到高防 IP，A 记录 TTL 60 秒，改完后大多数用户会逐步访问新高防 IP。这里的关键是老 IP 不要马上关，至少保留一段时间接尾流量。

CNAME 链路要看整条链的缓存

CNAME 场景容易被忽略。用户访问 www.example.com，它 CNAME 到 lb.example.net，lb.example.net 再返回 A 记录。这里不只 www.example.com 有 TTL，CNAME 目标和最终 A 记录也有 TTL。

如果 www.example.com 的 TTL 是 60 秒，但 lb.example.net 的 A 记录 TTL 是 600 秒，切换最终 IP 时仍然可能被 600 秒拖住。排查时要用 dig 或 nslookup 把整条解析链都看完，不要只看第一层。

CDN 和高防 CNAME 通常由服务商控制后段调度

CDN、高防、Anycast、GSLB 常用 CNAME 接入。业务域名 CNAME 到服务商提供的域名，后面的 IP 调度由服务商负责。这个时候业务侧 TTL 主要影响“是否能快速切到另一个 CNAME 或另一个接入域名”，而服务商内部的节点调度不完全依赖你的 DNS TTL。

多说一句，如果业务经常遇到 DDoS，单纯靠 DNS TTL 切 IP 不够。DNS 切换有缓存尾巴，攻击者也可能直接打源站 IP。更稳的做法是源站隐藏、入口走高防 IP 或高防 CNAME，源站安全组只放行高防回源段。

TTL 设置太低会不会有副作用

会有，但多数中小业务感知不明显。

TTL 越低，递归 DNS 重新查询越频繁，权威 DNS 的请求量会增加。如果域名访问量很大，比如日活百万级、全球用户、客户端频繁重连，TTL 从 300 秒降到 30 秒，DNS 查询量可能明显上升。权威 DNS 如果性能差、线路差，反而会影响解析稳定性。

另一个问题是低 TTL 不代表真正的秒级容灾。DNS 不是连接调度器，它只负责告诉客户端一个地址。用户已经和旧 IP 建立 TCP 连接，DNS 改了也不会自动断开重连。长连接业务、WebSocket、游戏 TCP 长连接尤其明显。

所以 TTL 低只能让“新解析”更快拿到新 IP，不能让“旧连接”立刻迁移。

实战里比较常用的配置节奏

日常稳定运行时，主业务域名 TTL 设置 300 秒。这个值对多数网站、API、管理后台都比较合适。

计划迁移、换机房、换高防、换负载均衡前，提前一天降到 60 秒。等旧缓存自然过期后，再改 A 记录或 CNAME。

故障演练、攻击期间、游戏开服、临时调度时，可以降到 30 秒或 60 秒。等业务稳定后，再恢复到 300 秒，避免长期过低带来不必要的解析压力。

如果是海外业务，比如香港、泰国、新加坡这类节点之间做线路切换，TTL 建议 60 秒到 300 秒。跨境网络波动不是 DNS 能完全解决的，TTL 只能解决入口切换速度，线路质量还得看实际网络。

高防切换场景下 TTL 怎么设

DDoS 场景最怕 TTL 过长。攻击已经打过来了，DNS 还要等半小时才让大部分用户切到高防 IP，这段时间源站可能已经被打挂，用户也访问失败。

比较常见的做法是：平时业务入口就接高防 IP，TTL 设置 300 秒。这样攻击来了不用临时切，直接由高防清洗。只有在高防节点异常、需要换高防 IP 时，才依赖 DNS 切换。

如果预算或架构原因，平时走普通 IP，攻击时才切高防，那么主域名 TTL 建议长期保持 60 秒或 300 秒，不要设置 3600 秒。真正遇到攻击时，再把 A 记录切到高防 IP。

选择高防服务器时可以关注单机防御、带宽峰值、线路质量和是否限制流量。比如需要香港方向入口，同时又要抗攻击，可以看看 129云 的香港高防-B型，4C、4G DDR4 ECC、60G SSD、150Mbps 峰值带宽、1 个 IPv4、200Gbps 单机防御，适合网站、游戏入口、海外业务高防接入这类场景。需要咨询配置或切换方案，可以直接打客服热线 400-9177118。

TTL 和 BGP、CN2、GIA 不是一回事

TTL 解决的是 DNS 缓存多久的问题，BGP、CN2、GIA 解决的是网络路径和线路质量问题。两者经常一起讨论，但不是同一个层面。

比如香港 GIA 线路延迟低，回国质量好；BGP 线路多运营商接入，容错更强；高防线路能清洗攻击流量。TTL 只是决定用户多久能拿到新的入口 IP。你把 TTL 设置成 30 秒，也不会把普通线路变成 CN2 GIA。

这里有个很典型的误区：解析切到新 IP 后，用户反馈还是慢，于是继续调 TTL。其实 TTL 已经完成了它的工作，慢可能是线路绕路、跨境拥塞、服务器负载、回源带宽不足。这个时候应该看 traceroute、mtr、TCP 建连耗时、丢包率，而不是继续改 DNS。

老 IP 要保留多久

DNS 切换后，老 IP 不建议马上下线。哪怕 TTL 设置 60 秒，也建议至少保留 30 分钟到 2 小时。访问量大的业务可以保留更久，比如 6 小时或 24 小时。

保留老 IP 的目的不是因为 DNS 一定会缓存这么久，而是为了接住尾流量。实际生产里，总会有一部分用户来自不规范缓存、企业内网 DNS、App 内置缓存，甚至有人直接访问旧 IP。

如果是高防切换，老 IP 更不能随便暴露。攻击场景下，老源站 IP 一旦被打穿，即使 DNS 已经切到高防，攻击者仍然可以继续打源站。所以源站安全组、iptables、防火墙策略要提前配置，只允许高防回源 IP 访问业务端口。

怎么验证 TTL 是否真的生效

不要只看 DNS 控制台。控制台显示的是权威记录配置，不代表全国用户都已经拿到新值。

可以用 dig 指定不同公共 DNS 查询：

dig @8.8.8.8 www.example.com

dig @1.1.1.1 www.example.com

dig @223.5.5.5 www.example.com

dig @114.114.114.114 www.example.com

返回结果里会看到 TTL 数字，这个数字通常是递减的。如果刚查是 58，过几秒再查变成 51，说明这个递归 DNS 正在使用缓存。等它减到 0 后，再查应该会重新向权威 DNS 获取新记录。

还可以从不同地区的服务器上查，比如华东、华南、华北、香港、新加坡、美国。跨境业务尤其要这样看，因为海外公共 DNS 和国内运营商 DNS 的缓存表现不一样。

负 TTL 和改错记录也要注意

除了正常 A 记录 TTL，还有一个容易踩坑的是 negative caching，也就是负缓存。比如某个子域名本来不存在，用户查询后得到 NXDOMAIN，这个“不存在”的结果也可能被缓存一段时间。

如果刚创建一个新子域名，发现部分地区一直解析不到，可能不是记录没加上，而是之前查过不存在结果，被递归 DNS 缓存了。负缓存时间通常和 SOA 记录里的参数有关，不同 DNS 服务商处理方式也不完全一样。

所以新业务上线前，域名记录最好提前创建，不要等发布瞬间才加。哪怕先指向一个临时 IP，也比上线时才从不存在变成存在更稳。

不同业务可以直接按这个范围设

企业官网、展示站：300 秒或 600 秒。

业务 API、登录、支付回调：60 秒或 300 秒。

游戏入口、语音、实时交互：30 秒或 60 秒。

DDoS 高防切换：30 秒或 60 秒。

CDN CNAME 接入：60 秒到 300 秒，重点看 CDN 服务商后端调度能力。

固定办公系统、低频后台：600 秒到 1800 秒。

MX、TXT、域名验证：600 秒到 3600 秒。

云服务器选型时别只盯 TTL

DNS 切换只是入口层动作，后面的服务器和线路也要扛得住。比如切换到新 IP 后，带宽只有 5Mbps，业务照样慢；高防 IP 防御够了，但回源线路差，用户也会觉得卡。

如果是国内电信用户为主，同时需要抗攻击，可以考虑电信优质线路和单机防御能力。129云 的泉州电信-B型是 4C、8G DDR4 ECC、60G SSD、20Mbps 峰值带宽、1 个 IPv4、100Gbps 单机防御，适合电信向业务入口、高防落点、网站防护这类场景。

如果是东南亚业务，泰国曼谷节点更适合当地访问和周边覆盖。泰国｜曼谷配置从 1 核到 4 核、1G 到 8G 内存、30G 到 120G 硬盘、30Mbps 带宽、200G 到 4TB 流量，只计费上行流量，适合轻量网站、海外业务测试、区域节点部署。

TTL 改完后还要看连接层

HTTP 短连接业务对 DNS 切换更敏感，用户重新请求时就可能拿到新 IP。HTTP keep-alive、WebSocket、TCP 长连接、游戏连接就不一样了，连接不断，DNS 再快也不会重新解析。

这类业务做切换时，通常还要配合连接驱逐、服务端优雅下线、负载均衡摘除节点、客户端重连策略。DNS TTL 只能解决入口发现，不能替代应用层容灾。

比如游戏服迁移，TTL 设 30 秒只是让新登录玩家更快进入新入口。已经在线的玩家，要么等自然断线，要么服务端发重连指令，要么网关层做连接迁移。只改 DNS，不处理长连接，切换窗口还是会有明显感知。

比较稳的线上操作顺序

计划变更前一天，把相关 A 记录或 CNAME 的 TTL 降到 60 秒。

确认新服务器、新高防 IP、新负载均衡都已经部署完成，证书、端口、回源、防火墙、健康检查都正常。

变更时先改小流量域名或灰度域名，看访问日志、错误率、延迟、带宽、CPU、连接数。

主域名切换后，不要立即关老节点。观察新旧 IP 的访问日志，老 IP 流量下降到很低后再考虑下线。

业务稳定后，把 TTL 从 60 秒恢复到 300 秒。高频切换业务可以继续保持 60 秒，但要确认 DNS 服务商的解析性能和可用性。

TTL 设置建议值

追求快速切换：30 秒到 60 秒。

生产常规运行：300 秒。

稳定低频业务：600 秒到 1800 秒。

不建议主业务入口长期使用 3600 秒以上，除非这个入口几乎不需要快速切换。

DNS 切换前，提前降低 TTL；DNS 切换后，保留老 IP 接尾流量；涉及高防时，源站不要暴露，安全组只放行高防回源。TTL 设得再短，也不要把它当成故障切换的唯一手段。