打开一个网页，域名要先被翻译成地址，这一步就是域名解析。解析走的传输方式有两种，短查询通常用 UDP，数据量大或者有特殊要求时改用 TCP。平时两种都能用，感觉不出区别，放在代理IP链路上看，选择不同带来的影响就开始分化。
两种传输方式各有什么脾气
UDP 查询的好处是快，一问一答，不用先建立连接，开销小。代价是丢包之后要等超时再重试，丢一次就要多等一截。TCP 查询要先握手，多了一个来回，但结果有保证，返回内容长的时候也不会被截断。查询结果超过一段长度、或者带上了安全校验字段，就必须走 TCP，这是一条硬性规则。
短问题走 UDP，长答案必须走 TCP。
| 对比项 | UDP 查询 | TCP 查询 | 备注 |
|---|---|---|---|
| 连接开销 | 无握手，开销小 | 需先握手 | 短查询差异明显 |
| 结果保证 | 丢包靠超时重试 | 传输有确认 | 链路越差差距越大 |
| 长度限制 | 超出需截断重来 | 可完整返回 | 大结果必须用 TCP |
| 转发兼容 | 部分转发不完整 | 兼容性更好 | 看中间层的支持度 |
代理环境下容易出问题的环节
代理IP链路上多了几层转发，解析的路径也跟着变长。常见的一种情况是解析请求被转发层拦下、由转发方代为解析，返回的地址是转发方那边看到的版本。这种结果对本地来说未必最优，访问速度可能反而变慢。解析在哪儿完成，决定了你拿到的是哪个视角的答案。排查时可以先确认解析是本地做的还是转发方代做的。
- 先确认解析由谁执行
- 再看查询走的哪种传输
- 丢包频繁的改用 TCP 查询试试
- 把解析耗时单独记录下来对比
另一种情况是丢包被放大。UDP 查询本身不带重传保证，链路上丢一次就要等超时；代理线路的转发层如果对 UDP 的支持不完整，解析失败率会明显高于直连。表现是页面时快时慢、偶尔打不开，重启一下又好了。遇到这种不规律的现象，先测解析环节往往比从浏览器端找更快。
解析只占整个访问过程的一小段，出问题时却影响很大。把这一步单独拿出来测，很多说不清的时快时慢就有了答案。