接入DDoS防护后最典型的性能问题不是防护设备本身不行，而是流量路径变长、连接处理逻辑变化、以及默认策略过于保守。很多网站在上线高防IP或云清洗服务后，首次字节时间从几十毫秒飙升到几百毫秒，甚至出现间歇性超时。核心原因通常集中在三个层面：回源链路绕行、防护节点对长连接和WebSocket支持不完整、以及源站安全策略误伤回源IP。解决思路不是盲目提高服务器配置，而是从链路、协议、缓存、源站信任机制四个方向做精细调整。

先优化回源链路，减少绕行损耗

DDoS防护服务通常会把流量先牵引到清洗中心，再通过回源线路送回源站。如果清洗节点与源站物理距离远，或者回程走的是公共互联网而非专线，延迟会明显增加。首先要确认回源IP是否走BGP优化线路，很多服务商默认给的是普通公网回源，升级到静态BGP或专线回源能把延迟压下来。其次，如果源站有多个可用区或机房，把源站入口切到离清洗节点最近的机房，比升级服务器更有效。对于自建清洗设备的场景，检查回源路由是否绕行核心交换机或防火墙，尽量让清洗设备与源站前端负载均衡直连。

另一个容易被忽略的点是DNS解析。接入高防后，网站对外IP变成高防IP，但部分用户本地DNS缓存了旧解析记录，导致流量直接绕过防护回源，既暴露源站又无法享受清洗能力。正确做法是把DNS的TTL在切换前降到60秒，切换后持续观察至少48小时，同时把源站IP的80和443端口对公网做严格白名单，只允许高防回源IP段访问。

调整防护节点的连接与超时策略

高防设备默认的连接超时和并发限制往往偏保守，尤其是针对HTTP/2和WebSocket。很多防护平台默认关闭HTTP/2，导致浏览器只能回退到HTTP/1.1，多路复用失效，页面加载资源时并发连接数受限，感知上就是变慢。如果源站已支持HTTP/2，必须要求防护侧开启HTTP/2透传或终结，并确认ALPN协商正常。

对于WebSocket和长轮询应用，防护节点的空闲连接超时通常设得很短，比如30秒或60秒，这会导致在线聊天、实时行情、协同编辑等场景频繁断连重连。需要把空闲超时调整到300秒以上，同时开启TCP keepalive探测。如果防护平台不支持自定义WebSocket超时，可以考虑把长连接业务拆到独立子域名，通过白名单方式绕过清洗节点，但前提是该子域名有独立的源站保护和限流机制。

还有一个细节是SYN Cookie和连接建立速率。高防设备在检测到攻击时会自动提高SYN Cookie触发阈值，但正常突发流量也可能被误判。如果网站有秒杀、抢票、整点活动等流量尖峰，要提前与防护服务商沟通，把该业务的源IP、URL特征加入白名单，或者把触发阈值调高，避免正常用户握手被丢弃。

源站信任与安全策略必须重新梳理

接入DDoS防护后，源站看到的请求全部来自回源IP，而不是真实用户IP。如果源站的Web服务器、WAF、或应用层限流模块仍然按IP做频率限制或黑名单，很容易把回源IP当成攻击源封掉，导致全站不可用。必须把回源IP段加入源站防火墙、Nginx、Apache、以及应用限流组件的白名单，并且关闭针对回源IP的连接数限制。

真实用户IP的获取要依赖防护平台传递的X-Forwarded-For或自定义头。但要注意，这个头可以被伪造，所以源站日志分析和风控系统必须只信任来自回源IP的该字段。Nginx层面可以用real_ip模块把真实IP还原出来，但前提是set_real_ip_from只包含回源IP段，否则外部攻击者可以伪造X-Forwarded-For绕过IP限制。

# Nginx real_ip 配置示例
set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

如果源站还部署了本地WAF或ModSecurity，要检查规则是否会对回源IP的高频请求产生误报。很多规则默认对单个IP的请求速率有阈值，回源IP在正常业务下每秒可能承载数百甚至上千请求，极易触发封禁。正确做法是对回源IP段关闭速率限制规则，把限流能力前移到防护节点。

缓存策略前置，减轻源站压力

高防节点本身具备缓存能力，但默认缓存命中率往往不高，因为很多站点没有正确设置Cache-Control和Expires头。对于静态资源，应该在源站明确设置长缓存时间，并让防护节点开启静态缓存。对于半静态内容，比如首页、分类页、详情页首屏数据，可以利用防护平台的页面缓存功能，设置较短的缓存TTL，比如30秒到5分钟。这样在遭受CC攻击或流量突增时，大部分请求在清洗节点就被响应，源站压力骤降，响应速度反而提升。

动态接口不适合整页缓存，但可以对部分读接口做边缘缓存。例如商品库存查询、文章内容、配置项等，只要数据一致性要求不高，都可以在防护节点缓存几百毫秒到几秒。实现方式通常是在响应头里加Cache-Control: public, max-age=3，或者通过防护平台的自定义规则对特定路径设置缓存。注意写操作和用户个性化接口绝不能缓存，否则会造成数据泄露或逻辑错误。

TLS握手与证书部署的优化

DDoS防护节点会终结TLS连接，这意味着用户到防护节点是一段TLS，防护节点到源站是另一段TLS或明文HTTP。如果源站也开启了HTTPS，那么防护节点回源时还要再做一次TLS握手，增加延迟。如果回源线路是专线或内网，可以考虑回源走HTTP，省掉一次握手。但如果回源走公网，则必须保持HTTPS，防止中间人窃取数据。

证书部署方面，防护节点需要托管你的SSL证书。很多平台支持证书自动同步，但如果证书链不完整或中间证书缺失，部分移动端或旧系统会握手失败或耗时增加。建议用SSL Labs测试防护IP的证书链完整性，确保fullchain上传。同时开启OCSP Stapling，减少客户端在线查询证书状态的时间。TLS版本建议只保留TLS 1.2和1.3，关闭1.0和1.1，既提升安全性也减少协商开销。

监控与持续调优的闭环

接入防护后的性能优化不是一次性工作。必须建立从用户侧到源站的全链路监控。用户侧用真实浏览器监测首屏时间、DOMContentLoaded、资源加载耗时；防护侧看清洗节点的连接数、回源延迟、缓存命中率、丢弃率；源站看CPU、内存、网络吞吐、以及应用响应时间。三者对比才能定位瓶颈到底在哪个环节。

常见的性能劣化模式有三种：一是用户到防护节点延迟正常，但防护到源站延迟高，说明回源链路有问题；二是防护节点连接数激增但源站请求量很低，说明缓存没生效或攻击被拦截在边缘，此时要检查缓存策略和攻击类型；三是源站响应慢导致防护节点大量排队，这时要优化源站应用和数据库，而不是继续调防护参数。

建议每周拉取一次防护平台的性能报表，重点关注回源RTT、缓存命中率、以及异常丢弃的请求比例。如果缓存命中率长期低于30%，说明静态资源缓存策略有较大优化空间。如果回源RTT波动超过20%，要检查回源线路是否被切换或拥塞。对于自建清洗方案，还可以通过流量镜像分析正常请求与攻击请求的比例变化，动态调整清洗阈值。

最后强调一点：DDoS防护的默认配置是为“扛住攻击”设计的，而不是为“极致性能”设计的。接入后必须根据业务特点做针对性调优，把防护节点当成CDN边缘节点来管理，而不是简单的安全网关。链路、连接、缓存、信任、TLS这五个维度都调整到位后，接入防护带来的性能损耗可以控制在5%以内，甚至在攻击期间因为缓存前置和连接复用，用户体验反而比裸奔时更稳定。