腾讯云服务器内网 DNS 与私有域名解析：解析不对到底该查哪一层
客户凌晨发来消息：内网两台云服务器 CVM（行业里常叫 ECS）互相调不通，域名 ping 出来的是一台早就下线的旧机器地址，可解析记录明明改过了。很多人第一反应是去改 hosts，但腾讯云服务器私有DNS 的毛病，十有八九不在 hosts 里，而在你没注意到的那一层被悄悄覆盖了。作为长期帮客户做选型和排障的代理商，我处理这类工单最快的办法不是猜，而是把解析链路从应用一路剥到 VPC，逐层验证。
先搞清：一次内网解析到底走了哪几层
一台腾讯云服务器要解析某个域名，请求会依次经过这几个环节：应用调用的解析库（glibc 的 getaddrinfo 与 NSS 机制）、本机的解析配置（通常是 /etc/resolv.conf，启用 systemd-resolved 时会指向本机 stub）、VPC 内置的私有 DNS 解析服务，最后才可能落到公网权威 DNS。腾讯云的 VPC 会为子网下发默认的解析服务地址，实例开机时经 DHCP 拿到，自动写入解析配置。这一步你平时感觉不到，但它决定了默认解析路径往哪走。
这里要先建立一个认知：解析服务是 VPC 级别的公共设施，不是某一台实例私有的。也就是说，同一张 VPC 里所有机器默认走的是同一套解析入口，配置也由平台统一维护，你没法单独给某台机器换一个入口而不落到本机配置层。再往下才是本机这一层，它决定"遇到查询该问谁、按什么顺序问"。如果域名不在私有域里，VPC 的解析服务会把它转交给公网递归解析；只有在私有域里配置过的记录，才会返回你自定义的内网地址。所以"解析不对"先分两种：一种是本该走内网私有域却走了公网，另一种是两条路径都在、但优先级顺序和你预期相反。方向不同，查的地方完全不一样。
还有一点容易被忽略：解析顺序不只由服务器的 IP 决定，还由本机的名称服务开关决定。Linux 上真正决定"先查本地 hosts 还是先问 DNS、要不要走 mDNS"的，是 nsswitch.conf 里的 hosts 行。排查前顺手看一眼这一行，能避免在一个方向上死磕很久却始终找不到答案。
resolv.conf 与 systemd-resolved：谁在说话
这是最常见的坑。很多人手动编辑 /etc/resolv.conf，加了一行 nameserver，当时生效，重启或重启网络服务后又变回去了。原因很简单：这份文件在启用 DHCP 的网卡上是由网络管理进程动态生成的，你改的只是产物，不是源。在腾讯云服务器上直接手改 resolv.conf，很容易被 DHCP 下发覆盖，这就是"改了又不生效"的根源。
如果系统启用了 systemd-resolved，情况更绕一层：resolv.conf 往往指向 127.0.0.53 这个本机 stub 地址，真正的上游服务器写在 resolved 自己的配置目录里。这时候你 dig 看到的是 stub 在回答，上游怎么配的要去对应的配置文件看。排查时先确认三件事：resolv.conf 是文件还是软链、指向谁；系统是否跑了 systemd-resolved；网卡是不是 DHCP 获取。判断清楚了，才知道该改哪一层，而不是反复和数据打架。
想长期改，正确姿势是回到网络配置层：如果是 DHCP，就在网卡配置里声明要用的解析地址或覆盖项；如果是 systemd-resolved，就在它的全局或按链路配置里改上游。改完记得重启对应服务再验证，光保存文件不重载进程，很多时候不会立刻生效。
DNS 缓存与 TTL：记录改对了为什么还不生效
解析记录改对，客户端却还返回旧地址，通常是多层缓存没到期。链路上至少有几级缓存：应用或语言运行时自己的解析缓存、本机解析器的缓存、VPC 私有解析服务的缓存。TTL 决定的是每级缓存愿意把结果留多久，TTL 设长了解析切换就慢，设短了递归查询压力就大。做迁移时，稳妥做法是提前把 TTL 调小，等旧 TTL 全部过期后再切记录，避免一部分客户端还拿着老地址回不去。
还有一种"假缓存"：进程根本没重启，把解析结果缓存在自己的连接池里。数据库连接、长连接客户端尤其明显。遇到这种情况，先确认命中的是解析缓存的哪一级，再决定是清缓存、等 TTL，还是重启进程。
值得单独提的是负缓存。查询一个当时不存在的域名，解析器通常也会把这个"查不到"的结论按一定时间记住，这段时间内你再查还是查不到，哪怕记录已经加好了。所以记录刚创建就说"没生效"，很可能只是负缓存还没过期。判断方法很朴素：换一台从没查过的实例再去解析一次，如果新实例能通、老实例不通，就是缓存那一层的问题。
私有域、内网域名与解析记录到底怎么配
腾讯云的私有 DNS 能力，是按"私有域 + 解析记录 + 关联 VPC"三层来组织的。私有域相当于一个只有你指定 VPC 才能看到的域名空间，往里加 A、CNAME、TXT 等记录，再把私有域关联到你自己的 VPC，VPC 内的实例解析该域名时就会命中私有记录，而不是去公网问。用法上适合内网服务发现、数据库内网别名、灰度切流这类场景。
配置时有几个容易忽略的细节：私有域的域名和后缀要规划好，别和自己拥有的公网域名撞车；关联 VPC 后要确认实例所在子网确实在那张 VPC 里；记录加完后到生效之间有缓存窗口，别立刻下结论说没配成功。私有记录本身也可以设 TTL，改内网别名时同样要考虑这个值。私有域的最大价值，是把内网地址从"到处写 IP"变成"统一写域名"，将来换机器、换网段只改一处记录。这对运维交接特别友好，新人接手不用满文档翻散落的 IP。
要区分两层概念：VPC 解析服务里那个"递归"的角色，负责帮你把公网域名问到答案；而"私有域"是权威性质的，只负责回答你自己登记的那几条记录。理解了这一点，就能明白为什么私有域里的名字，公网那边根本查不到，也不用去公网那边配。
跨 VPC 关联与那个总被忽略的 search 域冲突
当你有多个 VPC，私有域要依次关联到每一个需要解析它的 VPC 上，没关联的 VPC 里的实例是看不到这条私有记录的。跨 VPC 场景下"同一个域名在两个 VPC 解析结果不同"，绝大多数就是关联关系没对齐，而不是记录写错了。
多账号体系下更要留意：私有域是跟账号和 VPC 绑定的，子账号里的 VPC 不会自动继承主账号的私有域关联。团队做多 VPC 治理时，建议把"哪些私有域需要关联到哪些 VPC"列成一张清单，扩容或新建 VPC 时照着清单补关联，别等业务报障才回头找。
另一个隐蔽的坑是 search 域。当系统解析配置里带了 search 或 ndots 参数，你输入一个短名字时，解析器会按 search 列表拼出多个候选域名去试，只有全部失败才用原始名字。如果内网里同时存在相似后缀的域名，就会出现"明明配了却没命中""解析慢半拍"的现象。排查这类问题时，把完整域名带上一个结尾的点（绝对域名写法）再 dig 一次，能立刻区分是 search 拼接捣乱还是记录本身有问题。日常规范就是：配置文件里尽量写完整域名，别图省事用短名。
排查顺序：dig、nslookup、host 该先跑哪个
工具选择上我有一套固定顺序。先 dig 指定服务器，直接问目标解析地址，看它回什么；再 dig 不加服务器走系统默认，对比两者差异；nslookup 用来快速看默认服务器是谁；host 适合做反向解析和简单确认。先区分"是 VPC 解析服务答错了"还是"本机配置把它带偏了"，再往下查，能省掉一大半功夫。命令都写在行内，方便你直接复制：dig @<解析服务地址> example.internal A 看指定服务器返回；dig example.internal 看默认路径；dig +trace example.com 看公网传播链；cat /etc/resolv.conf 确认上游；resolvectl status 在 systemd-resolved 系统上看真实上游。
除了工具，还要注意方向：VPC 内部解析和公网解析服务是两套边界。私有域只对关联的 VPC 生效，公网权威 DNS 不知道也不该知道你的内网记录；反过来，公网域名能不能在 VPC 里解析，取决于出网和递归是否通。不要把内网私有域当成公网域名的替代品，两者适用范围不重叠。把常见现象和该查的层对应起来，排查会快很多：
现象 最可能出问题的层 先跑的验证命令 处理方向
改了 resolv.conf 重启后失效 动态生成的解析配置被 DHCP 覆盖 查看 resolv.conf 是否软链及指向 改网络配置源而非产物文件
内网域名解析到公网地址 私有域未关联当前 VPC 对完整域名做指定服务器解析 把私有域关联到目标 VPC
记录改对仍返回旧地址 多级 DNS 缓存未过期 逐级对比默认与指定解析结果 等 TTL 或提前调小 TTL 切换
DNS 查询偶发超时变慢 IPv6 优先或上游回落顺序 对比 A 与 AAAA 记录的响应 调整优先策略与解析顺序
短名字命中错误域名 search 域与 ndots 拼接 用带点的绝对域名再解析一次 规范使用完整域名或改搜索域
两个 VPC 解析结果不同 跨 VPC 关联关系不对齐 分别在两个 VPC 内验证 补齐私有域与 VPC 的关联
IPv6 优先为什么会让解析"变慢"
很多系统默认优先尝试 IPv6，解析器会同时查 A 和 AAAA，如果 AAAA 查询被上游丢弃或超时，要先等一轮超时才会回落到 A 记录，表现出来就是"解析能用但慢半拍"。腾讯云服务器私有DNS 场景下，如果内网只有 IPv4 地址，而客户端还在死等 AAAA，慢的根子就在这。处理方向是让解析顺序符合你的实际网络：内网纯 IPv4 就明确优先 A，别让每一次解析都白等一个超时窗口。这类问题往往在并发一上来才暴露，单机试的时候很难复现。
和它相关的是 DNS 的查询超时与重试策略。默认超时窗口往往偏保守，在网络抖动时会把某一次请求拖得很久，应用侧看到的却是"服务偶尔卡一下"。做稳定性优化时，把这些超时参数和重试次数一起调，比单纯换解析服务器更对症。排查这类"偶发慢"，可以临时抓包看解析请求和响应之间的时间差，一眼就能看出是超时等待还是上游真的慢。
FAQ
Q：内网域名解析不通，第一件事该查什么？
A：先确认实例所在 VPC 是否关联了对应私有域，再看本机 resolv.conf 指向的上游对不对。这两步能覆盖大多数"解析不对"的工单，比一开始就改 hosts 有效得多。
Q：手动改 /etc/resolv.conf 为什么总会失效？
A：在 DHCP 场景下这份文件由网络管理进程生成，你改的是结果不是来源，重启或重新获取地址就会被覆盖。要持久生效得改网络配置层，启用 systemd-resolved 时还要改它的上游配置。
Q：私有域和公网域名解析服务是同一个东西吗？
A：不是。私有域只在关联的 VPC 内可见，用来放内网记录；公网域名解析面向整个互联网。两者边界清晰，内网记录不要指望公网能看到。
Q：改完解析记录，客户端多久能生效？
A：取决于链路上最短那一段的缓存，通常是旧 TTL 到期之后逐步生效。做迁移时提前调小 TTL、错峰切换，是最稳的做法。
结语
遇到腾讯云服务器私有DNS 解析异常，别从 hosts 开始乱试，按"应用解析库 → 本机配置 → VPC 解析服务 → 公网递归"的顺序逐层验证，用 dig 指定服务器和默认路径做对比，基本一次就能定位。手头这套流程我在客户那边跑过很多次，也顺手帮不少用轻量应用服务器做内网服务发现的小团队理清过配置。如果你正准备搭多 VPC 架构、又不确定私有域该怎么规划关联关系，可以先私信把拓扑发我，让腾讯云代理这边的技术同学帮你把解析层级先设计对，再动手买机器，能省掉后面反复返工的麻烦。
如果需要更深入咨询了解可以联系全球代理上TG:jinniuge