背景
在使用 FRP（Fast Reverse Proxy）进行内网穿透时，FRPS（服务器端）的通信端口配置直接影响系统的稳定性、安全性以及后续的运维复杂度。
随着 FRP 新版本引入基于 QUIC 的传输方式，配置项中新增了 QUIC 相关监听参数，这使得服务器端可能同时存在多种控制通道实现方式，有必要对其协议属性与实际影响进行明确分析。
QUIC 监听端口的协议属性
结论明确：
FRPS 中用于 QUIC 的监听端口基于 UDP 协议
原因在于：
- QUIC 是一种构建在 UDP 之上的可靠传输协议
- 其连接管理、重传与加密机制由协议自身实现
- 不依赖 TCP 的连接语义
协议层级关系如下：
QUIC
└── UDP
└── IP
因此：
- QUIC 监听端口并不使用 TCP
- 防火墙或安全组必须允许对应的 UDP 流量
- 未放行 UDP 将导致客户端无法建立连接
传统控制端口与 QUIC 控制端口的差异
FRPS 提供两种功能等价的控制通道实现方式：
| 项目 | 传统控制通道 | QUIC 控制通道 |
|---|---|---|
| 底层协议 | TCP | UDP |
| 连接可靠性 | 由 TCP 提供 | 由 QUIC 协议实现 |
| 网络兼容性 | 高 | 依赖 UDP 质量 |
| 运维复杂度 | 较低 | 相对较高 |
两种方式在功能层面并无差异，仅在传输机制与稳定性表现上不同。
同时启用两种控制通道的隐患
某些配置中可能同时启用了传统控制通道与 QUIC 控制通道，且使用了相同的端口编号。
虽然该配置在技术上通常可以正常启动，但存在以下问题：
实际暴露监听面扩大
- 同一端口编号下：
- 同时存在 TCP 监听
- 同时存在 UDP 监听
- 从安全角度看，相当于暴露了两个独立入口
防护与排错复杂度上升
- 防火墙规则需同时覆盖 TCP 与 UDP
- 日志分析时需要区分协议来源
- 安全审计难度增加
行为预期不清晰
- 客户端是否使用 QUIC 取决于额外配置
- 两种控制通道并存会增加排查成本
QUIC 在 FRP 场景下的现实适用性
从工程实践角度观察：
- UDP 更容易受到网络设备与运营商 QoS 影响
- 在跨网络环境中，UDP 的稳定性往往低于 TCP
- FRP 的 QUIC 实现成熟度有限，主要面向特定场景
因此，在追求长期稳定运行、行为可预测以及故障可复现的部署环境中，QUIC 并不适合作为默认方案。
管理接口暴露风险分析
若 FRPS 的管理接口监听在全地址范围，则意味着该接口可被公网直接访问。
即使启用了加密与认证，仍然存在以下风险：
- 被端口扫描工具发现
- 被持续探测登录接口
- 产生不必要的攻击日志与负载
推荐原则
- 管理接口应仅监听本地地址
- 通过受控方式进行访问（如本地转发或受限反代）
- 避免任何形式的直接公网暴露
端口白名单配置的使用原则
端口白名单机制用于限制 FRPS 可被使用的远端服务端口范围。
合理的使用方式是：
- 仅列出确实需要对外提供的端口
- 不包含系统可能使用、但未实际映射的端口
- 白名单越精简，系统的安全边界越清晰
推荐的稳定配置策略
综合稳定性与可维护性考虑：
- 控制通道优先使用 TCP
- 禁用 QUIC 相关监听配置
- 明确区分业务端口与管理接口
- 严格限制监听范围与端口数量
总结
- FRPS 中的 QUIC 控制通道基于 UDP
- 同时启用 TCP 与 QUIC 控制通道并无明显收益，反而增加风险
- 在强调稳定性与可控性的环境中，应优先选择 TCP
- 管理接口与监听端口应始终遵循最小暴露原则