腾讯云国际版私有域解析 Private DNS 实战：0.015 美元/域名/天、0.15 美元/IP/小时与三份互相矛盾的地域清单全解析（2026）

站内写腾讯云 DNS 的文章不少，但讲的都是公网权威解析——DNSPod、域名注册、CNAME 接入、SSL 证书生命周期。真正跑在 VPC 里面、给内网服务做名字解析的那一层，一直没人写。这个缺口有点尴尬：容器镜像仓库的内网访问要它、混合云里 IDC 访问云上资源要它、微服务之间不走公网域名要它，但它的计费结构（按域名条数按天收、按查询量按万次收、按端点 IP 按小时收）在官方文档里分散在三个页面，任何人第一次看账单都会愣一下。

本文用 2026 年 10 月的官方计费页与产品文档做底，把私有域解析 Private DNS 的六个计费项拆成可复算的公式，给出六个规模档的真实月账单，再把文档里三处互相打架的地域清单摆在一起对照。核心结论先放在这里：域名费是"按条包天"，0.015 美元/域名/天意味着只要一个私有域的日解析量低于 3.75 万次，成本就由域名条数而不是查询量决定；而一个转发端点 IP 的月费 109.50 美元，等价于 2.74 亿次解析——端点比解析量贵两个数量级，开之前必须想清楚。

Meta Description: 腾讯云国际版 Private DNS 实测：0.015 美元/域名/天、0.004 美元/万次查询、0.15 美元/端点 IP/小时，六档场景月账单、TTL 造成 1,440 倍价差、三份矛盾的地域清单对照，附配额与上线决策清单。

关键词： 腾讯云国际版, Private DNS, 私有域解析, VPC 内网 DNS, 混合云 DNS 转发, 入站出站终端节点, 云解析计费

一、先说清楚它不是什么

名字容易误导。腾讯云国际站的 Private DNS 不是"私密一点的公网 DNS"，也不是 DNSPod 的一个功能开关，它是一个独立的、依附于 VPC 的内网权威 DNS 服务。官方在常见问题里给了最直白的一句对比：DNSPod 是互联网（WAN）上的 DNS，Private DNS 是 VPC（LAN）里的 DNS。

这句话展开成三条具体差异，决定了它的使用方式：

第三条差异里藏着本文要反复强调的第一个坑：Private DNS 的规则只对发往 183.60.83.19 和 183.60.82.98 这两个 DNS 地址的请求生效。这是腾讯云 VPC 内网默认的 DNS 服务器地址。很多团队为了接自建 AD 域控或 dnsmasq，会把这俩地址从 CVM 的 resolv.conf 里换掉——一旦换掉，Private DNS 的所有规则对这台机器直接失效，而且是静默失效，不报错、不告警，只是解析不到。这一点官方只在产品概述页的一个注里写了一句，翻不到的人会在故障排查里耗掉一整天。

二、六个计费项，三张表

私有域解析的计费项有六个，官方分散写成"域名列表 / 转发规则 / 服务地址"三组。全部按量付费（pay-as-you-go），按天结算，没有包月套餐、没有预留实例、没有阶梯降价。这是它和 CVM、数据库那类产品在成本模型上最大的区别：单位价格是死的，能优化的只有用量结构。

2.1 域名与查询量

2.2 出站终端节点（VPC 内 → 外部 DNS）

2.3 入站终端节点（外部 → VPC 内）

三张表连起来看，真正的结构非常清楚：只有两类单价——按天计的"存在成本"（域名 0.015、端点 IP 3.60/天）和按量计的"流量成本"（0.004 美元/万次）。所有成本优化都只能在这两类之间做腾挪。

把日单价折成月单价（按 730 小时、30.4167 天口径）：

官方账单示例可以直接用来验算这套折算：账号 A 有 3 个私有域（qq.com、dnspod.cn、yun.help），一天收到 10 万次查询，日费用 = 0.015 × 3 + 0.004 × 10 = 0.085 美元。按上表折算，这个规模一个月是 2.585 美元——一年 31 美元。这个数字小到不像"云上服务"，但它是真实的：私有域解析在小规模下几乎免费，成本压力全部来自两个地方：域名条数堆到几百条，或者开了端点。

2.4 一个容易被忽略的等价换算

把两类单价放在一起比，会得到一个特别好用的判断工具：

最后一行值得单独说：单个实例在 VPC 内的解析请求上限是 5,000 次/秒，一天最多 4.32 亿次，一个月 131.4 亿次，对应解析费 5,256 美元。也就是说即使把性能上限打满，纯解析费也就五千多美元一个月——这个量级远低于同规模的 CDN 或 NAT 网关账单。私有域解析从来不是"用量贵"，它是"结构贵"：贵在端点，贵在没人管的僵尸域名。

三、六个规模档的月账单

把上面的公式套到真实规模上，比看单价表有用得多。下面六档按典型团队结构设计，全部按 30.4167 天折算，均为纯按量、无任何免费额度抵扣。

几个从表里直接读出来的结论：

第一，A 档的成本几乎可以忽略，但 E 档不是。 A 档 3 个域、1000 万次查询，一个月 5.37 美元；同样是 1000 万次查询，一旦加了双端双 IP 的混合云互联（F 档），月账单变成 446.56 美元，涨了 83 倍，而解析量一个字节都没多。这是本文最想让人记住的一张表：端点不是"顺手开的功能"，它是账单里唯一能上三位数的项。

第二，域名条数打到配额上限（500 条）也只花 228.13 美元。 也就是说 C 档和 D 档之间，域名从 100 条涨到 500 条只多 182.5 美元，而解析量从 20 亿涨到 50 亿多花 1,200 美元。规模化的成本驱动是解析量，不是域名数——只有当你的域名数上了三位、解析量还在千万级时，域名费才会成为主要项（第 2.4 节的 3.75 万次/天分界线就是这个意思）。

第三，E 档暴露了一个常见的架构误判。 很多团队把"混合云 DNS 转发"当成一个小功能顺手打开，结果发现它一个月 109.50 美元，比整站的解析费贵五倍。如果转发只是为了访问三五个 IDC 里的老系统，用 /etc/hosts 或者一条 CNAME 指到固定 IP 往往更划算——这个判断在第六节展开。

四、TTL 才是最大的成本变量，不是查询量

官方计费页有一句非常关键、但极容易被跳过的说明：Private DNS 统计的是实际回源（origin-pull）次数，不是客户端查询次数。 也就是说，客户端每秒查一次，不代表每秒计一次费——TTL 内的重复查询都命中本地缓存，不产生计费。

这句话把成本模型彻底改写。建一个模型：1,000 台 CVM，每台每 60 秒查一次某个私有域名（典型的连接池健康检查节奏），那么客户端查询总量是恒定的 1,000 × 1,440 = 144 万次/天。但计费的回源次数 = 每台机器每天 86,400 ÷ TTL 次。

客户端查询量全程不变，账单从 17.52 美元到 0.01 美元，差 1,440 倍——刚好等于 TTL 上限 86,400 与下限 60 的比值。这是全文唯一一个"一个配置项就能改两个数量级"的地方。

但 TTL 不是随便调的，它有明确的代价：TTL 就是故障切换的等待时间。TTL 设 86,400 秒，意味着你改一条 A 记录之后，已经缓存过的客户端要等最多 24 小时才生效。所以工业界标准做法是分层：

三个文档里点到、但没算过的额外因素：

一是 NSCD 缓存。 官方明确建议在客户端配置本地 nscd 缓存来减少回源。这件事的意义在 TTL 上叠加：即便 TTL 是 60 秒，nscd 也能把同一台机器上多个进程的查询合并成一次回源。1,000 台机器跑 Java 应用、每台 50 个线程各自解析，不开 nscd 时回源次数按进程算，开了就按机器算——差 50 倍，而且是免费的。

二是递归子域的隐性计费。 只要开了"子域递归解析"，即使某个子域下一条记录都没配，查询也会被转发到公网解析并照常计费。官方给的建议很直白：要么给子域配上记录，要么关掉递归。很多团队为了"让内网也能查公网域名"打开这个开关，然后发现查询量翻了好几倍——因为所有公网域名的解析都从这条通道走了。

三是失败的查询也计费。 官方原话是"无论解析是否成功，任何域名的 DNS 解析查询都会计费"。这对故障场景有直接影响：一旦某个域名配错，客户端的重试风暴会产生全额费用，而且不因为是 NXDOMAIN 就打折。所以改记录前先在测试域验证，别在线上域直接改。

五、端点的两层用法：出站转发与入站服务地址

端点这个概念在文档里被拆成两个方向，很多人第一次看会混。用一句话概括：出站（Forwarding）解决"云内要访问云外"，入站（Service Address）解决"云外要访问云内"。

5.1 出站终端节点：把云内查询甩给 IDC 的 DNS

场景是这样的：VPC 里的应用要访问 IDC 里的一台老系统 erp.corp.local。这个域名只存在于 IDC 的 BIND 上，公网查不到。做法是在 Private DNS 里建一条转发规则，把 corp.local 这个后缀的所有查询，通过出站终端节点（建在 VPC 里的一个网卡）转发到 IDC 的 DNS 服务器 10.1.0.100，由它返回 192.168.10.20。

前置条件有三条，缺一条就走不通：私有域已创建、出站端点所在的 VPC 已创建、VPC 与 IDC 之间已经打通（专线或 VPN）。这也解释了为什么专门讲专线和 VPN 的文章是它的前置阅读——端点本身不建隧道，它只是把 DNS 包扔进已有的隧道。

出站端点可用的地域，官方给的是"北京、广州、上海、新加坡、东京、法兰克福等"，并注明以控制台创建端点页面的实际展示为准。这个"等"字很重要，下面第七节会讲它带来的麻烦。

5.2 入站服务地址：让 IDC 反过来查云内

反方向的需求：IDC 里的应用要访问 VPC 里的数据库，希望用 db.prod.internal 这样的名字而不是记 IP。做法是在 VPC 里规划一个私有 IP，建成入站终端节点，然后把这个 IP 配成 IDC 那侧 DNS 的转发目标（或者直接配成 IDC 机器的 DNS 服务器地址）。

入站端点有一个硬约束，必须在上线前确认：官方明确写目前只有雅加达和新加坡两个地域支持服务地址。也就是说，如果你的 VPC 在香港、硅谷、法兰克福，入站这条路目前走不通，只能反向在 IDC 侧维护 hosts 或自建 DNS 做条件转发。这个限制没有写在产品简介页，只在"服务地址"这篇操作文档的注里出现一次。

计费上两个方向完全对称：0.15 美元/IP/小时 + 0.004 美元/万次。所以高可用设计直接翻倍——每个方向两个 IP 做冗余，就是 4 × 109.50 = 438 美元/月，正是第三节 F 档的数字。这个价格结构值得在设计评审时明确摆出来，因为"再加一个 IP 做高可用"在多数云产品里是零成本的（比如 CLB 的多可用区），在这里不是。

5.3 一个容易踩的端点计费细节

端点按小时计费、按天结算，不足 1 小时不计费。听起来很友好，但按天结算意味着一个自然日内每个 IP 最多计 24 小时。如果 CI 流水线里写脚本每天创建销毁端点做集成测试，一天跑 24 次、每次 1 小时，账单是 24 × 0.15 = 3.60 美元/IP/天——和挂一整天完全一样。测试环境想省钱，正确做法是建一次、用完不删、按需启停依赖它的规则，而不是反复重建。

六、三份地域清单，三个不同的答案

这是本文最有实操价值的一节，也是我在核对资料时花了最多时间的地方：同一个产品，官方三个页面给出的地域支持范围完全不同。

四行数据结构非常整齐：入站 ⊆ 出站转发 ⊆ 基础解析，三个同心圆。真正能用的地域取决于你要哪个能力，而不是产品页上那句"支持全球多地域"。

第二行那个 6 个地域的说法是明确的过期信息。常见问题页的最后更新停在 2024 年 12 月，而使用限制页已经列到 28 个地域、包含 2023 年后才开服的曼谷、雅加达、首尔、多伦多。如果你按常见问题页判断"香港不支持"，就会做出错误的架构决策——香港其实在支持列表里，而且是亚太业务最常用的落点。

这件事的方法论意义大于事实意义：云厂商文档的失效方式通常不是"写错"，而是"某一页停止更新"。同一产品的不同页面由不同团队维护，更新节奏不一致，越靠近产品概述和 FAQ 的页面越容易陈旧，越靠近操作步骤和计费表的页面越新。判断一个能力是否支持的可靠顺序是：先看计费页 → 再看操作文档的前置条件 → 最后才看 FAQ 和产品简介。

反过来说，第三行那个"等"字是另一个方向的坑：出站转发只列了六个地域加一个"等"，并注明"以控制台创建端点页面的实际展示为准"。这意味着唯一权威的确认方式是在目标地域打开控制台点一次创建端点——点不出来就是不支持，文档说什么都没用。这条建议对有合规要求、必须在指定地域落地的项目尤其重要。

七、配额与性能边界

配额是按 UIN（主账号）计的，子账号和协作者共享同一份额度，这一点在多人协作的团队里经常引发"明明没人创建，怎么满了"的疑问。

四个需要额外解释的边界：

通配符必须配递归。 想用 *.prod.internal 指向一组实例，必须先开"子域递归解析"，而开了递归就带来第四节的隐性计费。这是一个功能与成本强耦合的设计，官方文档没有把两者关联说明，但因果链很清楚。

没有 SRV 记录。 这直接决定了它不能替代 Consul 或 CoreDNS 做服务发现。SRV 是服务发现协议（gRPC、Kubernetes headless service、Consul DNS 接口）的基石，A 记录只能给 IP 不能给端口和权重。所以正确的定位是"给服务提供稳定的内网名字"，服务发现仍然交给专门组件。这一点在第 5,000 QPS 的限制上也有印证：这个量级对应的是一个中型业务的内网解析总量，不是服务网格东西向流量的量级。

UDP 512 字节上限意味着大响应会被截断。 一条 A 记录带 30 个 IP 的轮询、或者较长的 TXT（SPF 记录常见超过 255 字节），在传统 UDP 下会触发截断并回退 TCP，而文档只说支持 UDP。实践中把 TXT 拆成多段、把轮询记录控制在 10 条以内，就不会碰到这个问题。

SLA 只对"付费版私有域解析"承诺 99.99%。 使用限制页的原文是：如果 VPC 内单实例 DNS 查询峰值超过 5,000 次/秒，会有被限速的风险，且私有域解析付费版的 99.99% 可用性 SLA 无法保证。这句话隐含两件事：一是 SLA 挂在 5,000 QPS 这个前提上，超了就不算违约；二是外部递归解析这条通道从一开始就不承诺 SLA。所以不要把内网递归解析当生产依赖——它没有合同保障。

八、六个上线前必须定的设计决策

私有域解析的配置项不多，但每一个都不可逆或者迁移成本很高。下面六条按"改起来最贵"排序。

决策一：命名空间怎么切。 建议用一个不带任何公网含义的私有后缀，比如 prod.internal、svc.corp，而不是复用公司已有的公网域名 company.com。原因是同名域会在两套 DNS 里同时存在，一旦有人把 VPC 的 DNS 指向改了，解析结果会在内网 IP 和公网 IP 之间跳变，排查极其痛苦。如果一定要复用公网域名做"双 DNS"（内网查内网 IP、公网查公网 IP），官方支持的路径是建同名私有域并开启子域递归，但这属于高级玩法，先确保团队能维护。

决策二：一个域关联几个 VPC。 一个私有域可以关联多个 VPC，官方明确同一 VPC 内不能存在两个同名域。所以多环境（dev/staging/prod）必须用不同域名，不能靠"同名域 + 不同 VPC"来隔离——这条限制在规划多账号、多 VPC 时是硬约束。

决策三：跨地域怎么处理。 这里文档口径不一致，必须自己验证：使用限制页把"可用地域"定义为"可关联私有域的 VPC 所在的地域"，暗示一个私有域可以关联不同地域的 VPC；而常见问题页写的是"可以关联一个或多个同地域的 VPC"。两句话直接冲突。稳妥做法是按地域分别建同名域（不同地域的 VPC 不冲突），代价是 500 条配额被地域数乘一遍。这也是配额最容易被打满的原因。

决策四：要不要开轮询（round-robin）。 除 PTR 外的记录类型都支持轮询，同一主机记录可以配多条 A 记录做简单负载均衡。但轮询没有健康检查——一条记录对应的机器挂了，客户端仍会拿到它的 IP。所以轮询只能用于"实例等价且都能自愈"的场景（比如无状态 API 集群配合客户端重试），不能用于主备切换。主备要靠改记录 + 短 TTL。

决策五：反向解析要不要做。 需要建一个以 1 至 3 位 IP 段 + in-addr.arpa 结尾的私有域，再加 PTR 记录。实际价值集中在日志可读性和安全审计（把 IP 反查成人可读的名字），对性能没有帮助。如果日志系统已经在应用层记录了服务名，这项可以跳过。

决策六：非标准 TLD 要不要买。 默认只能创建符合 IANA 规范的标准 TLD，想用 .internal、.corp、.local 这类后缀（注意：.local 保留给 mDNS，用它做内网 DNS 会和 Bonjour/Avahi 冲突，强烈不建议）必须先购买非标准 TLD 服务。三条限制必须知道：后缀长度不超过 30 字符；非标 TLD 不会提升 500 条域名上限；到期不续费会被禁止对该后缀域名做任何增删改操作（连删除都不行，只能续费后才能清理）。价格只在购买页展示，文档不列单价，所以这里不给数字——需要的话去控制台购买页看实时报价。

九、从 /etc/hosts 与自建 BIND 迁移过来

私有域解析最现实的定位不是"从零开始建 DNS"，而是替掉那堆已经失控的 /etc/hosts 和那台没人敢重启的 BIND。这两条路径的迁移方式完全不同。

9.1 从 /etc/hosts 迁移

/etc/hosts 的问题是它随机器数量线性膨胀：10 台机器还行，200 台就是 200 份需要同步的配置，而且任何一次 IP 变更都要改 200 个地方。迁移步骤：

1. 收敛现状。 把所有机器的 /etc/hosts 收集起来去重，得到真实的域名-IP 映射表。这一步通常会发现大量已经下线但没人删的条目。
2. 建域、建记录。 按业务域建私有域（比如 prod.internal、db.internal），把映射表灌进去。记录数上限 10 万条，一般够用。
3. 关联 VPC，但先只关联测试 VPC。 官方建议先建域和记录、再关联 VPC，顺序反了会出现"域关联了但没有记录"的空窗期。
4. 灰度一台机器。 在一台 CVM 上把 /etc/hosts 里的条目注释掉，只留 127.0.0.1 localhost 那几行，然后用 getent hosts 验证解析是否走 DNS。
5. 确认后批量清理。 注意不要动 resolv.conf 里的 nameserver ——那两行必须保持 183.60.83.19 / 183.60.82.98，动了就是第一节说的静默失效。

验证命令只有一条，比 ping 可靠，因为它走的是系统实际的 NSS 解析路径（会读 /etc/hosts，也会读 resolv.conf 指定的 DNS）：

getent hosts db.prod.internal
getent hosts erp.corp.local

如果第一条返回了 VPC 内的 IP、第二条无输出（说明转发规则没生效或 VPC 未打通），就说明链路状态清楚了。再用 dig 直接打 DNS 服务器，把"DNS 层面通不通"和"客户端配置对不对"两件事分开验证：

dig @183.60.83.19 db.prod.internal +short
dig @183.60.83.19 erp.corp.local +short

第一条有结果、getent 没结果，说明是客户端解析顺序问题（比如 /etc/nsswitch.conf 被改成了只认 files）；两条 dig 都没结果，问题在服务端配置。这个二分法能省掉大量瞎猜。

9.2 从自建 BIND 迁移

自建 BIND 通常承载着三类东西：内网正解区、反解区、以及转发到公网的上游配置。迁移要分开处理：

最后一行是真正的功能缺口：Private DNS 没有 ACL 和 TSIG，也就是没有"只允许某些源 IP 做动态更新"这种能力。如果你的 BIND 在用 nsupdate 做动态注册（老式 AD 集成、DHCP 联动），迁移会断掉这条链路，得换成 API 调用（Private DNS 已接入腾讯云 API 3.0，可用 CAM 做子账号授权）。

迁移期的双写策略建议是"BIND 保留为上游、Private DNS 做前置"：先在 Private DNS 建好域和记录，把查询引过来，同时用出站转发把还没迁的域甩回 BIND。这样任何一条记录迁漏了都还能解析，代价是转发端点的月费——这也是唯一值得为迁移期付 109.50 美元/月的场景。

十、成本优化清单

按"省钱效率 ÷ 改动成本"排序，前三条基本免费，后两条需要架构决策。

第四条值得展开：私有域是按存在计费的，业务下线后域不会自动消失，还会每月默默贡献 0.45625 美元。听起来很少，但一个跑了两年的平台攒下 200 个历史域很常见，那就是 91 美元/月、1,095 美元/年的纯浪费，而且没人会注意到——因为单条金额太小，不会触发任何预算告警。定期跑一遍"查询量为零的私有域"清单，是这类按条计费产品唯一有效的治理手段。

第五条是本文最实际的省钱建议：转发规则按后缀匹配，不按单个域名匹配。如果你的 IDC 里有 20 个系统分布在 corp.local 下，一条 corp.local 的转发规则就够了，不需要建 20 条。规则本身不收费（收的是端点 IP 和转发量），但把规则收拢能让你用更少的端点，而端点才是钱。

十一、和几个替代方案的边界

选型时最容易纠结的是"到底该用 Private DNS 还是继续用自建/开源方案"。给一张对照表，按能力而不是按产品名比：

三条判断规则：

如果解析需求 100% 在 Kubernetes 集群内部，CoreDNS 就是答案，不要引入 Private DNS，多一层反而多一个故障点。Private DNS 的价值在集群外面——跨 VPC、跨账号、混合云、以及那些不在 K8s 里的老系统。

如果有动态注册需求（DHCP 联动、AD 集成、自动扩缩容实例自注册），自建 BIND 或 CoreDNS 仍然是唯一选择，因为 Private DNS 没有 TSIG 和动态更新。

如果只是想让几台机器互相用名字访问、总量不超过几十条记录，/etc/hosts 加一套配置管理就够了。 为这个规模引入 Private DNS 虽然便宜（0.45625 美元/域/月），但会引入一个"DNS 是外部依赖"的运维事实，出事时排查链路反而更长。

总结

这篇文章的三个结论，都可以直接拿去做决策：

成本结构：私有域解析只有两类单价——按天计的"存在成本"（域名 0.015、端点 IP 3.60/天）和按量计的"流量成本"（0.4 美元/百万次）。一个私有域一天的租金等于 3.75 万次解析，所以日解析量低于 3.75 万的域，钱花在"它有名字"而不是"有人查它"；一个端点 IP 一天的租金等于 900 万次解析，所以端点一旦开启就是账单主角。500 个域名打满（228.13 美元/月）还不如两个端点 IP 贵。

优化杠杆：TTL 是唯一能改两个数量级的旋钮，客户端查询量不变的情况下账单能差 1,440 倍；nscd 是第二杠杆，按进程合并查询，常见再降一个数量级；关闭无用的子域递归是第三杠杆，直接消掉整块隐性计费。三条都不花钱，只需要有人认真配一遍。

文档可信度：同一个产品的四份地域文档给出四个不同范围（入站只用雅加达和新加坡、出站六个地域加"等"、配额页 28 个地域、FAQ 六个且停在 2024 年）。判断能力是否可用的顺序应该是计费页 → 操作文档前置条件 → 最后才看 FAQ；而最终权威永远是控制台点一次。"文档说支持"和"你的地域真的支持"是两件事，这篇文章里所有地域结论都建议你再验证一遍。

如果还缺一块拼图，按需求往下读：VPC 对等连接与云联网 决定私有域能覆盖多大的网络范围，专线接入 和 VPN 连接 是出站/入站端点的前置网络，DNS 解析基础篇 讲公网侧的记录类型与 TTL 语义，组织架构 TCO 讲多账号下配额与成本怎么归属。

价格说明：本文所有单价取自腾讯云国际站私有域解析计费页与计费概述文档（2026-06-16 更新版本）2026-10-30 的抓取结果：私有域 0.015 美元/个/天、解析查询 0.004 美元/万次、进出站端点 IP 0.15 美元/IP/小时，非标准 TLD 与增值包价格只在购买页展示，故未列数字。所有派生数字（月单价、六档场景月账单、TTL 回源模型、等价查询次数）均由脚本按上述单价与 730 小时/30.4167 天口径复算，非估算；TTL 回源模型基于"每台客户端按 TTL 到期回源一次"的假设，实际值受 nscd 与客户端实现影响。价格可能变动，请以腾讯云官网为准。

本文由 4.chengzicloud.cloud 提供，点击访问首页了解更多