高防IP和高防CDN的分界线不在“防护能力”，而在流量以什么形态进入防护层。CDN改的是域名解析，流量按域名牵引到边缘节点；高防IP改的是客户端连接地址，业务直连高防IP的某个端口，清洗后再转发回源站。这个差异决定了端口转发是高防IP最核心的配置动作，也是最容易在细节上翻车的地方。
游戏登录服、直播推流UDP通道、数据库对外端口、物联网设备上报，这些业务没有域名可解析，客户端配置里写死的是IP加端口。坚果盾高防IP全系独立IP、独立清洗能力，不限流量、不限并发连接总数，仅限制带宽速率，DDoS保底从100G起步，至尊版1T，超防版2T，无忧版按需弹性。端口转发支持单端口、批量导入、端口段三种粒度，协议覆盖TCP、UDP及WebSocket。
端口转发的三步链路：监听、清洗、转发
一条转发规则生效后，流量在链路上经历三个动作。
监听。高防节点在指定端口上等待客户端连接。客户端只知道高防IP和对外端口，源站IP不出现在任何客户端配置中。监听端口可以和源站端口不同，比如对外用10086，回源到源站的8080，进一步降低被扫描的概率。
清洗。入站流量先经过DDoS和CC过滤。SYN Flood、UDP反射、畸形分片在这里被丢弃，正常流量进入转发队列。清洗发生在高防节点侧，源站不需要承担任何过滤开销。
转发。清洗后的干净流量按规则转发到源站IP和源站端口。源站只接受来自高防回源IP段的连接，公网直连全部拒绝。
TCP与UDP转发：配置要点完全不同
协议类型必须与业务实际监听一致。TCP和UDP选错，规则显示生效但客户端连接超时，这是接入阶段最常见的故障之一。
TCP转发面向连接，有握手过程。清洗侧可以利用SYN Cookie验证握手真实性，相对成熟。配置时需要注意会话保持：游戏长连接、数据库连接池、WebSocket会话都依赖同一条TCP连接持续转发到同一个源站，转发策略应当选择源IP哈希或会话粘滞，避免连接在多个源站之间漂移导致状态丢失。
UDP转发无连接，每个包独立处理。清洗难度更高，因为无法用握手验证来源真实性。游戏战斗服、直播推流、语音通信是典型UDP场景。配置时需要确认高防节点能识别业务UDP协议的特征，否则可能把正常游戏包误判为攻击流量丢弃。部分自定义UDP协议需要提前确认兼容性。
一个业务端口如果同时跑TCP和UDP（比如某些游戏登录服同时监听两种协议），需要建两条独立规则，不能合并。
三种配置粒度：按端口拓扑复杂度选
单端口转发适合端口数量少、拓扑简单的业务。一个API入口、一个数据库代理、一个游戏登录服，逐条配置即可。排查路径最短，出问题时一眼能定位到哪条规则。
批量端口导入解决的是“端口离散但数量多”的问题。游戏业务是典型：登录、匹配、战斗、聊天、支付各占独立端口，加上测试环境和灰度环境，实际规则数往往是主服务数的两到三倍。坚果盾支持CSV或TXT格式一次性导入，规则保存后即时生效，不需要重启服务。导入时注意端口冲突检查：同一高防IP上监听端口不能重复，但TCP和UDP可以使用相同端口号。
端口段转发面向连续端口区间。物联网平台、P2P应用、需要开放10000到20000这类连续区间的服务，用一条端口段规则覆盖整段映射，避免为每个端口单独建规则。三种方式可以混合使用：核心接口用单端口精确控制，辅助服务用端口段收敛规则数量。
套餐的端口配额决定了能配多少条规则。基础版10个转发端口，标准版20个，商务版30个，依次递增到无忧版100个。按峰值并发端口数估算，而不是按“业务线数量”估算，可以避免后期频繁升配。
源站白名单：先放行，再拒绝，顺序反了业务瞬间不可用
端口转发配置完成后，源站防火墙必须做对应调整。逻辑是默认拒绝，仅放行高防回源IP段。
操作顺序：从高防IP控制台的回源配置页导出回源IP列表，在源站防火墙先添加ACCEPT规则放行这些IP到业务端口，再添加DROP规则拒绝其余所有来源。规则顺序必须是先放行后拒绝。如果顺序反了，回源流量还没到达放行规则就被DROP，业务会瞬间全部超时。
白名单配置完成后需要反向验证：从非白名单IP尝试直连源站业务端口，应当全部超时或被拒绝。如果仍然能连通，检查是否存在0.0.0.0/0的放行规则，或者管理端口（SSH、数据库管理端口）是否单独暴露在公网。
回源IP段会随节点扩容变化，需要纳入定期比对。白名单过期不会立即报错，而是在新增节点开始回源时表现为部分区域用户间歇性失败，排查成本高于定期检查。
配置错误排查：连接超时先查白名单，间歇断连先查协议
连接超时，业务完全不通。最常见原因是源站白名单未放行回源IP。其次检查协议类型是否与源站监听一致（TCP选成了UDP，或反过来），以及源站端口是否处于监听状态。
间歇性断连，部分用户正常部分失败。检查带宽或并发是否触顶。高防IP不限并发连接总数，但带宽是限速的。游戏战斗服的长连接如果心跳间隔小于转发规则的空闲超时时间，连接会被高防节点提前断开，表现为客户端周期性重连。将转发规则的空闲超时调到大于业务心跳间隔即可解决。
UDP业务丢包严重。确认协议特征识别是否匹配。自定义UDP协议如果高防节点无法识别，可能把正常包当作异常流量丢弃。需要联系技术支持确认协议兼容性。
延迟明显升高。检查接入节点与源站是否同区域。坚果盾节点覆盖华东、华南、华北、华中、西南及海外，选择与源站最近的节点接入，同区域延迟增加通常控制在3—8ms。
常见问题
一个高防IP能配多少条转发规则？
取决于套餐的转发端口配额。基础版10个，标准版20个，商务版30个，企业版40个，增强版50个，旗舰版60个，至尊版70个，超防版80个，无忧版100个。TCP和UDP规则都计入端口配额。端口数量按峰值并发端口数估算，不要按“现在够用”选，游戏多区多服场景下实际需求往往比预期多一倍。
转发规则修改后需要重启业务吗？
不需要。控制台保存后规则即时生效，客户端连接地址不变，源站服务不需要重启。切换期间建议保留源站旧入口作为回滚路径，业务稳定运行24—48小时后再收紧源站公网访问。
源站换了IP，端口转发规则需要重新配吗？
需要修改规则中的源站IP字段。但客户端连接的高防IP和监听端口不变，所以客户端侧不需要做任何改动。这也是高防IP接入的一个实际优势：源站迁移对客户端透明。修改规则后记得同步更新源站防火墙的白名单，确认新源站只放行高防回源IP段。
TCP和UDP可以用同一个端口号吗？
可以。同一高防IP上，TCP的8080和UDP的8080是两条独立的转发规则，互不冲突。但如果业务在同一个端口号上同时跑TCP和UDP（比如某些游戏登录服），需要分别建两条规则，只建一条会导致其中一种协议不通。
