一套业务里同时存在两类流量是常态：官网、H5、小程序接口走HTTP/HTTPS域名，游戏战斗、直播推流、数据库代理走TCP/UDP原生端口。前者适合高防CDN做边缘缓存和域名接入，后者只能用高防IP做端口转发。混合部署要解决的问题不是“两个产品都买”，而是两条链路的接入方式、回源路径和白名单规则互不冲突。
按接入方式分工，不按业务线分工
混合部署的第一条规则：域名业务走CDN，端口业务走IP。判断依据是客户端连接的目标形态，不是业务部门怎么划分产品线。
客户端连接的是一个域名、由DNS解析决定去向的，接高防CDN。典型场景：官网、活动页、H5、小程序后端API、WebSocket长连接（域名形式）。CDN侧改CNAME完成接入，源站不需要改监听端口。
客户端连接的是一个IP加端口、地址写死在配置文件或客户端代码里的，接高防IP。典型场景：游戏登录/匹配/战斗服、直播推流UDP通道、数据库对外端口、物联网设备上报端口、私有协议服务。接入动作是替换客户端连接地址，源站端口监听不变。
同一条业务线可能同时落在两边。一款游戏，官网和充值页面走CDN，登录服和战斗服走高防IP。一个直播平台，Web控制台走CDN，推流和拉流走高防IP的UDP转发。按业务线统一选一种防护，必然有一半流量接不进去。
域名侧：哪些域名接CDN，哪些不接
不是所有域名都适合放到CDN后面。接入前先做一次域名清点，按“是否需要公网用户直接访问”分类。
对公网用户提供内容或接口的域名，接CDN。包括主站、活动子域、API子域、静态资源域。接入后CNAME指向坚果盾分配的调度域名，源站只保留回源域名。
管理后台、内部工具、运维接口的域名，不接CDN，走IP白名单或VPN。这类域名的访问来源固定，放到CDN后面反而扩大了暴露面，且管理后台通常不需要边缘缓存。
已经废弃但仍在解析的旧域名，直接删除解析记录。历史上线过的测试域名如果还指向源站，是高防接入后最常见的旁路入口。子域名枚举一遍，不在用的下线，在用的全部纳入CDN或白名单。
端口侧：TCP与UDP分开配，协议类型选错等于没接
高防IP的转发规则里，协议类型必须与源站实际监听一致。游戏登录服监听TCP，规则选TCP；战斗服走UDP，规则选UDP；同一个端口号如果TCP和UDP都在用，需要建两条规则。
TCP业务重点关注长连接保持。游戏、即时通信、数据库代理的连接存活时间从几分钟到几小时不等，转发规则的空闲超时时间要大于业务自身的心跳间隔，否则连接会被高防节点提前断开，表现为客户端周期性重连。
UDP业务重点关注会话保持和MTU。推流、实时对战对丢包和分片敏感，转发链路需要保持同一客户端会话落到同一源站，避免会话漂移导致的状态不一致。UDP没有连接概念，源站侧要能接受来自高防回源IP的任意源端口。
端口数量按峰值并发端口数估算，不按业务线数量估算。登录、匹配、战斗、聊天、支付各占一个端口，加上测试环境和灰度环境，实际规则数通常是主服务数的两到三倍。坚果盾高防IP基础版提供10个转发端口，标准版20个，商务版30个，按峰值端口数选档位比按“现在够用”选更少返工。
源站白名单要同时放行两套回源IP
混合部署下源站接收两路回源流量：CDN节点的回源IP，高防IP节点的回源IP。防火墙规则必须同时放行这两组地址段，只配一套是混合部署最常见的故障原因——域名访问正常，游戏端口连不上，或者反过来。
操作顺序：先从坚果盾高防CDN控制台导出CDN回源IP段，再从高防IP控制台导出IP回源IP段，两组地址合并后写入源站防火墙的放行规则。放行规则按“源地址段+目的端口”精确匹配：CDN回源IP只放行80/443，高防IP回源IP只放行业务端口，不要做全端口放行。
两套回源IP段都会随节点扩容变化。把“定期导出并比对回源IP列表”放进运维例程，周期与节点变更频率匹配。白名单过期不会立刻报错，而是在新增节点开始回源时表现为部分区域用户间歇性失败，排查成本高于定期比对。
两条链路的DNS与客户端配置互不干扰
CDN侧改的是域名解析，高防IP侧改的是客户端连接地址，两条链路的配置入口不同，变更时不需要同步操作。
域名接入CDN后，DNS记录从A记录指向源站改为CNAME指向调度域名。游戏客户端、APP、桌面程序的连接配置不在DNS体系里，单独维护高防IP地址加端口。这意味着域名侧的CNAME调整不影响已发布客户端的连接，IP侧的转发规则调整也不影响Web访问。
需要留意的是同域名下的混合场景。一个域名如果既提供HTTP页面又承载WebSocket长连接，两者都走CDN，由CDN的协议支持覆盖，不需要拆到高防IP。只有当连接目标本身就是IP加端口、无法用域名表达时，才拆到高防IP侧。拆分依据是客户端连接形态，不是协议名称。
故障隔离：一条链路异常不拖垮另一条
混合部署的一个实际收益是故障域分离。CDN节点调度异常影响的是域名访问，游戏端口连接不受影响；高防IP某个转发节点异常影响的是对应端口，Web页面照常打开。要拿到这个收益，两条链路的监控和告警需要分开建。
域名侧监控：CDN回源成功率、边缘缓存命中率、各区域访问延迟、CNAME解析是否正常。高防IP侧监控：各转发端口的连接数、回源成功率、节点到源站的延迟、UDP会话保持情况。两套指标分开看，避免一条链路的抖动掩盖另一条链路的真实状态。
源站侧要能区分流量来源。访问日志里按回源IP段标记请求来自CDN还是高防IP，出问题时能快速判断是哪条链路的回源异常。源站带宽和连接数监控也按两路拆分，防止一侧的异常流量吃满源站资源、连带影响另一侧。
套餐分开评估，不互相抵扣
高防CDN和高防IP是两条独立计费的产线，套餐参数各自对应各自的流量特征，不能用一个产品的余量补另一个产品的缺口。
CDN侧按带宽速率档位计费，不限流量和并发连接，10Mbps到300Mbps对应不同规模的Web业务。评估依据是正常访问的峰值带宽和缓存收敛后的回源量。
高防IP侧按DDoS保底、业务带宽、转发端口数、域名位四个维度组合，100G到2T+独享防护，带宽50Mbps到500Mbps。评估依据是攻击峰值、端口业务正常吞吐、峰值并发端口数。
混合部署时两侧的带宽需求分别测算。CDN侧的带宽主要消耗在动态请求回源和未命中缓存的内容上，高防IP侧的带宽消耗在端口业务的原始流量上，两者不重叠。把两侧带宽加总后按一个产品选套餐，会高估单侧需求；只按其中一侧选，另一侧会在峰值时受限。
常见问题
同一个源站可以同时接CDN和高防IP吗？
可以。源站同时接受CDN回源和IP回源两组地址段访问，业务端口按来源做放行。前提是两组回源IP都已加入白名单，且放行规则按目的端口精确匹配，不做全端口放行。
域名业务能不能也走高防IP？
技术上可以，用高防IP的80/443端口转发到源站。但这样拿不到边缘缓存和静态资源收敛，源站仍然承受全部正常回源并发。域名业务需要缓存加速时接CDN，只需要端口级防护、不需要缓存时可以用高防IP转发。
混合部署后源站IP还需要换吗？
如果源站IP在接入前已经通过历史DNS、子域名或证书日志泄露，建议更换。白名单控制的是“谁可以连”，更换IP切断的是“攻击者已知的目标地址”，两者处理的是不同层面的暴露。接入前做过完整排查且无泄露记录的，可以不换。
两条链路的回源IP段冲突怎么办？
回源IP段是地址集合，合并放行即可，不存在冲突。需要注意的是放行规则的目的端口：CDN回源IP只放行Web端口，高防IP回源IP只放行端口业务，按来源和目的做二维匹配，避免一组IP获得超出其链路的访问权限。
