DNS 的 SRV 记录能证明节点更快吗？先分清服务端口与选择权重

查到 SRV 记录，里面既有主机名，又有端口、优先级与权重，很容易把它当成“节点性能表”。实际上，这些字段首先描述服务发现与目标选择，不提供某条线路的测速成绩。

本文适用于正式服务文档明确使用 SRV、或自己管理的 DNS。普通机场订阅已经给出服务器和端口时，先沿用其正式配置，不擅自猜一条 SRV 查询来替换连接参数。

SRV服务发现中的目标与端口、选择规则和应用连接分开核对的示意

示意图：SRV 字段描述服务发现，优先级与权重不是节点测速数据。

SRV 要查的是服务名称

RFC 2782定义的查询名称包括服务、协议与域名，例如 _service._proto.name 这样的结构。它不是对任意首页域名查询一次，就一定能得到所有应用端口。

先向正式说明核对完整查询名、服务类型与客户端是否使用这种发现方式。没有说明就记录“SRV 用途未确认”，不扫描端口，也不假定所有代理协议都支持它。

Microsoft 的 Resolve-DnsName支持 SRV 查询类型。以下只演示写法，服务名和域名都是占位项，要替换为你获准查询且由正式文档给出的名称：

Resolve-DnsName -Name '_service._tcp.example.com' -Type SRV -DnsOnly

保留时间、查询名和返回结果。示例并不保证存在对应记录；没有取得记录也不能据此认定机场已经停止服务，它可能根本不采用这套发现方式。

RFC 对同优先级下的选择概率给出权重机制。因此，更大的 Weight 不能解释为“更快”，Priority 较小也不能解释为“硬件更好”。目标的地址解析与实际连接仍需各自完成。

先确认客户端是否按该服务说明读取 SRV。若它只使用订阅里的固定主机和端口，那么这次 DNS 观察不能自动改写客户端配置，也不能证明本次连接实际选中了哪一条记录。

需要核对连接时，仅对自己的服务目标按正常客户端流程验收，检查预期功能是否完成；不要为了试出结果自行换端口、关闭证书验证或把某个主机名当成新的 TLS 名称。

查询成功、目标地址存在、端口可达和应用操作成功是不同阶段。记录中保留每一阶段的实际结果，没有做到就写待查，不从前一阶段推导后一阶段成功。

用于机场推荐的测试表，可以保存正式服务发现规则、客户端支持依据、当时选中的目标和真实任务结果。SRV 中的数字作为路由元数据保留，速度比较另做同条件测量。

这样复查者能看清你观察的是 DNS 配置，还是已经完成了一项连接任务；也能避免把服务端口误填到本地代理端口里。

官方资料核验日期：2026-10-13。本文提供操作与判断方法，不代表本站对某家机场的实测结论。