接入高防前，先花一两个小时把域名和端口整理成一份业务基线清单，比急着挑高防厂商更管用。很多团队第一次接高防，第一反应是问哪家便宜、哪个节点多，结果真到配置那天，域名解析乱成一团，端口映射对不上，回源全部超时，这篇文章按实际接入流程，把域名和端口梳理的方法拆开讲。
接入高防前梳理什么？
这里说的梳理不是让你打开Excel随便填两列,而是要把线上真实流量、源站IP、业务协议全部对一遍，你知道你业务现在开放了多少个端口吗？大多数团队答不上来，安全组上放着一堆历史规则，谁也说不清哪些还在用。
梳理的目标,是产出一份可执行清单，清单上每一行，对应一个真实业务。
先画业务拓扑，再谈技术细节
不管你用的是简米云、酷番云，还是自建机房，第一步永远是把业务拓扑图扒出来，从入口到源站，每一层转发关系都要清楚：
- 客户端域名 → DNS解析 → 高防IP（CNAME或A记录）
- 高防IP → 转发规则 → 回源IP:回源端口
- 源站安全组 → 是否放行高防回源IP段
很多团队直接在云控制台看安全组列表,发现20条规则，然后拿这些规则当端口清单用，这不够，安全组里放行的端口，未必真的有服务在监听。
正确做法：登录源站服务器，用命令扫一遍真实监听端口。
netstat -tunlp # 查看所有监听端口及对应进程
这一步能让你发现：哪个端口被占用但业务已下线，哪个服务在跑但从来没配过安全组规则，哪个数据库端口直接暴露在公网。
用DNS记录还原域名全貌
域名梳理比端口更容易漏,一个业务线七八个域名很正常，有的做跳转，有的存静态资源，有的只是API网关的子域，你不把DNS解析记录全量导出来，根本不知道公网暴露面有多大。
操作路径：
- 登录域名解析服务商后台,导出所有域名解析记录
- 按记录类型分组：A记录、CNAME、MX、TXT、NS
- 标记哪些域名最终指向源站IP,哪些指向CDN或云WAF
- 将有真实业务流量、且需要高防保护的域名单独拉一组
注意,不只有Web域名需要高防，你APP的API接口、游戏登录服、IM消息推送长连接，这些终端域名如果直连源站IP，同样暴露在DDoS攻击下。
域名解析切高防IP，DNS与证书的坑怎么避免
域名清单出来后,第二步是切换DNS解析，这步操作风险高，因为不是改一条记录那么简单。
CNAME切换前，先检查TTL
你当前域名的TTL如果是600秒甚至更低,那切换后生效很快，但如果某个域名TTL设置成了86400，意味着全球DNS缓存最长需要一天才能失效，切换高防前，提前24到48小时把TTL调低到300秒或600秒，让旧记录快速过期，这个前置操作，是整个切流过程中最容易被忽略的一环。
TXT验证记录别顺手删了
域名从普通DNS切到高防CNAME时,很多团队习惯把域名解析记录整体清掉再重建，这一清，把SSL证书的TXT验证记录也清了，导致证书续签失败，正确做法是：只改A记录和CNAME，保留TXT、MX等非业务解析记录，除非你确定它们不再需要。
证书别只盯443端口
域名接上高防后,证书会卸载在高防节点上，源站可以放HTTP，这没问题，但如果业务里有非标准端口的HTTPS，比如8443、9443，你需要确认高防是否支持这些端口的证书卸载，相当一部分高防套餐默认只支持80和443的证书配置，其他端口要么走TCP转发，要么需要单独提工单开通，不提前确认，到了上线当天才发现在线支付接口全挂了。
业务域名是HTTP还是HTTPS,证书是通配符还是单域名，证书绑定了几层CDN，这都要写进域名梳理表里。
别让CDN和高防叠加成回源死循环
有些业务原本用了CDN,现在要在前面再加高防，架构变成：客户端 → 高防 → CDN → 源站，听起来没问题，但如果你把高防的CNAME指向CDN域名，而CDN源站又指向原域名，就会形成解析环路，行业共识认为，同一条链路里，高防和CDN的串联顺序需要提前和厂商确认，是支持这样的链路，还是需要改成高防回源时直接解析到源站IP。先改哪条记录，哪条记录保持不动，切流顺序直接决定业务中断时长。
回源端口与业务端口的对应关系，如何逐项核对
端口梳理是接高防的核心,前面域名理清了，下一步就落到具体端口策略。
端口不只有TCP和UDP两种
高防的端口转发规则通常要区分四层和七层：
- 四层转发（TCP/UDP）：端口透明转发，适合游戏、IM、视频流等自定义协议，高防不解析内容，只做流量清洗
- 七层转发（HTTP/HTTPS）：高防解析HTTP头部，可以配合CC防护策略，适合Web业务
你是什么业务,决定你选哪种转发模式，很多团队以为高防就是回源到80/443，结果把TCP长连接的业务配到七层转发下，连接状态全乱，玩家疯狂掉线。
一张表说清业务端口和回源端口的关系
| 业务场景 | 客户端访问端口 | 高防转发端口 | 回源端口 | 协议 |
|---|---|---|---|---|
| Web官网 | 443 | 443 | 8443（源站Nginx） | HTTPS |
| API接口 | 443 | 443 | 8080（后端服务） | HTTPS |
| 游戏登录服 | 8000 | 8000 | 8000（直连源站） | TCP |
| 文件上传 | 80 | 80 | 8080（限流节点） | HTTP |
| 视频点播 | 1935 | 1935 | 1935（RTMP流） | TCP |
这张表就是你的端口映射基线,每一行都代表一个独立业务，接入高防时按行配置规则，就不会漏，也不会错配。
源站安全组只放行高防回源IP
配置完端口转发后,还有一步容易被漏掉：源站服务器安全组必须设置访问白名单。
- 把高防厂商提供的回源IP段全部加进安全组
- 删除原本放行0.0.0.0/0的规则
- 运维人员办公网IP单独加白,保留直连排查通道
这一步做完,源站就隐藏在公网视野之外了，攻击者即使拿到源站IP，也无法直接访问业务端口，只能打到高防上被清洗。
端口清单确认后，还要补上这些边角
域名和端口的大头理清了,但有几个场景特别容易被漏掉，接高防后才发现“怎么这个功能用不了”。
源站出口IP与回源IP要区分开
源站需要主动访问外部的场景,比如调用第三方支付回调、拉取远程配置，这时候源站访问外部服务用的是源站自己的公网出口IP，不是高防回源IP，有些高防厂商支持“回源IP透传”，有些则要求源站出口IP也加入白名单才能访问外部服务，这属于配置细节，但会直接影响业务对外调用的功能。
长连接和WebSocket的Keep-Alive超时时间
高防节点介于用户和源站之间,如果业务里有WebSocket长连接或者高频轮询接口，需要确认高防的空闲连接超时时间是否匹配，有的高防默认120秒没有数据传输就断开连接，而你的业务心跳包可能60秒发一次，看起来配好了，实际运行一段才发现连接全断。
高防的TCP连接空闲超时、HTTP头超时、请求体大小限制，这些参数直接影响业务稳定性，不确认清楚就上线，后期排查成本极高。
解析记录切到高防后，原域名要保留回源域名
高防回源
时,很多配置场景需要用到回源域名，而不是直接填IP，所以原来的业务域名最好不要直接删掉，而是改为一条独立的解析记录，指向源站IP，只允许高防节点解析使用，这样当高防需要回源时，解析到的是源站IP；而公网用户解析该域名时，由于DNS已经切换到高防CNAME，解析到的是高防节点，不会直接暴露源站。
源站上的业务配置里,如果有强制跳转域名的逻辑，要特别小心，比如源站Nginx里配置了return 301，将HTTP请求跳转到HTTPS域名，而这个域名现在指向高防IP，可能导致回源请求在源站和高防之间互相跳转，形成死循环，配置回源时，建议用独立的回源域名或者直接关闭强制跳转。
高防IP哪家价格低？先别急着比价
梳理完域名和端口后,你才有资格去比价，不同高防的接入差异很大，价格高低的背后，往往对应着不同的能力边界。
有些套餐绑定固定的转发端口数上限,比如默认只支持5个端口，端口清单太长就得加钱，有些高防对于非标准端口的支持需要单独配置，比如Redis的6379、MySQL的3306，并不是所有厂商都默认放行，端口清单里如果有这些业务，你要在接入前就问清楚是否纳入防护范围。
要明确的一点是,高防IP的实际成本不仅包含防护套餐费，还包含正常业务流量的带宽费用。按比例预留带宽比盲目选最大清洗能力更省钱。先把业务峰值流量算清楚，再针对峰值来选择套餐，这才是合理的选型顺序。
Q&A：高防接入前的域名与端口常见问题
高防IP接入前的端口清单需要包含所有端口吗？
只包含有真实对外业务的端口,内网端口、数据库端口、运维端口这些不需要经过高防，它们应该通过安全组白名单限定来源IP，只允许办公网或跳板机访问，把所有端口都填进高防规则，既浪费端口配额，又扩大了攻击面。
域名解析切到高防后，源站还需要保留公网IP吗？
需要保留,但公网IP只能让高防回源IP和办公网白名单访问，源站公网IP不能完全移除，因为高防回源需要找到源站的真实地址，但该IP的访问权限必须收紧到最小范围，否则攻击者绕过高防直接打源站IP，高防就失效了。
接入高防前需要备份哪些配置？
备份当前全部DNS解析记录、域名证书、源站安全组规则、Nginx或负载均衡的server配置，特别是nginx配置文件里关于域名跳转、回源地址、websocket代理超时时间等参数，一旦切换过程需要回滚，这些配置能帮助你快速恢复原状。