核验防护节点支持的TCP和UDP协议范围如何核验，不能只看控制台里有没有端口输入框。需要分别确认节点能处理哪些协议、当前策略放行哪些端口，以及目标服务是否实际可达。三者对应产品能力、配置状态和测试结果，任何一项都不能代替另外两项。
尤其要注意：同一个端口号不代表协议相同。例如 DNS 常用 UDP 53，也可能通过 TCP 53通信；QUIC 通常使用 UDP 443，而基于 TCP 的 HTTPS 不能据此证明 UDP 443也可用。
先确认“支持”指什么
不同服务商对“支持 TCP/UDP”的描述可能指协议类型、可配置端口，或某种特定转发能力。先查产品说明、策略页面和节点配置，确认适用的地址类型、端口范围、方向限制及是否需要单独启用 UDP。没有明确说明时，应向服务提供方确认，不要把页面上可填写的端口直接当作节点已支持。
- 协议能力：节点是否能识别并转发 TCP 或 UDP 流量。
- 规则范围：策略是否允许指定协议、源地址、目标地址和端口。
- 服务状态：目标端口上是否有对应服务监听，并且返回路径正常。
例如，防火墙规则（ACL）可能允许 TCP 443，却没有 UDP 443规则；这时 TCP 连接正常，并不能证明 QUIC 可用。规则还可能按 IPv4、IPv6 分开生效，应分别检查实际使用的地址族。
按步骤核验，避免把配置和连通性混为一谈
- 列出待测清单。记录目标地址、协议、端口、测试来源及预期结果。按业务需要列出端口，不要用“所有端口都应开放”作为默认目标。
- 核对节点与策略。在产品文档或管理页面确认 TCP、UDP 是否分别支持，再检查对应放行规则、优先级、源地址限制和生效节点。若有多层策略，逐层确认。
- 验证目标服务。确认服务确实监听指定协议和端口，并检查主机防火墙、返回路由等条件。节点允许流量，不等于目标端必然响应。
- 从授权的外部测试点分别探测。使用获准的端口检测工具，例如 Nmap，对同一端口分别选择 TCP 探测和 UDP 探测；控制扫描范围与频率，避免扫描未获授权的地址。
- 结合日志复核。对照节点流量记录、目标服务日志，必要时用 Wireshark 在受控环境观察请求与响应，判断报文是否到达、是否被丢弃或无应用层回复。
- 变更后重复测试。记录时间、节点、地址族、协议、端口和结果。策略调整后重新核对，避免只凭一次旧结果作结论。
TCP 与 UDP 的结果不能用同一标准解读
TCP：重点看连接建立过程
TCP 测试通常通过连接是否建立、连接被拒绝或超时来判断路径状况。连接成功说明该来源到目标的这条 TCP 路径可用，但不代表其他端口、其他来源或 UDP 也可用。连接被拒绝通常表示目标主动回应但没有接受连接；超时则可能由节点策略、主机防火墙、路由或服务无响应等多种因素造成。
UDP：无响应不等于被拦截
UDP 没有 TCP 那样的连接握手。应用可能只在收到符合格式的请求后才回复，因此端口扫描显示“开放或过滤”时，单靠结果往往无法区分端口开放但应用静默，还是报文被过滤。DNS 查询可通过有效请求和应答核验 UDP 53；NTP 服务可在获准条件下检查 UDP 123。测试应尽量使用真实、格式正确的应用请求，并结合日志或抓包判断。
端口扫描（Nmap 等工具）适合初步筛查，不应取代业务验证。若节点显示允许而服务端看不到请求，问题可能在中间路径；若请求到达但没有响应，则需继续检查服务配置与返回流量。
用结果表留痕，形成可复查结论
| 目标 | 协议 | 应记录的信息 | 判断重点 |
|---|---|---|---|
| DNS 服务 | UDP、TCP | 端口、请求类型、响应与日志 | 两种协议分别验证，不能互相代替 |
| NTP 服务 | UDP | 请求是否到达、是否有有效回复 | 仅有超时结果不足以判定节点不支持 |
| QUIC 服务 | UDP | 实际客户端握手或服务端记录 | TCP 443成功不等于 UDP 443可用 |
表格中的端口是常见服务用法，不代表所有部署都采用默认端口。最终应以目标服务的实际监听配置和业务要求为准。采用这套核验防护节点支持的TCP和UDP协议范围如何核验的方法，可以把“节点不支持”“规则未放行”和“服务没有响应”分开定位。
常见问题
只查产品说明够不够？
不够。说明用于确认能力边界，还应核对当前策略，并对目标服务做实际测试。
UDP 扫描显示过滤，该怎么处理？
使用有效的应用层请求，检查节点与服务日志；必要时在授权环境抓包。不要仅凭“无回复”认定 UDP 被拦截。
TCP 测通后，还要测 UDP 吗？
要。两种协议的规则、处理方式和应用监听可能不同，必须按业务需要分别测试。
什么时候需要重新核验？
节点、策略、目标服务、地址族或网络路径发生变更后，应重新检查相关协议和端口，并保存结果供后续比较。