门户网站的DDoS防护之所以难做，不是因为带宽不够，而是因为大流量攻击往往混杂着海量“看似正常”的请求。攻击者不再单纯打满带宽，而是模拟真实用户行为，针对搜索接口、登录页、评论区、API动态页进行高频请求。这类攻击单看每一条请求都合法，但聚合起来就能把源站数据库连接池、缓存节点和CPU全部拖垮。所以门户网站做DDoS优化，核心不是堆硬件，而是把“正常流量”和“攻击流量”在靠近用户的位置就分开，并且让源站具备快速丢弃和降级的能力。
先梳理清楚门户网站最容易被打穿的几个点
第一个是首页和频道页。这些页面通常做了大量动态渲染，比如实时新闻排序、用户推荐位、广告轮播。每次请求都可能触发后端多个接口聚合，一旦攻击者用不同参数反复请求，缓存命中率会急剧下降，源站压力成倍放大。第二个是搜索接口。搜索框看似简单，但模糊查询、热词联想、分词排序都是高消耗操作，攻击者用随机字符串批量请求搜索，能直接打满数据库。第三个是登录和注册接口。门户网站往往有大量老用户体系，登录接口涉及密码校验、验证码、风控、token下发，单次请求耗时远高于普通页面。第四个是评论和投票类接口，这类接口写入频繁，容易成为CC攻击目标。第五个是静态资源，虽然图片和JS可以走CDN，但门户网站经常有突发新闻，静态资源更新频繁，缓存策略一旦设置不当，回源量会暴增。
防护架构上必须先做分层，而不是指望一台设备解决所有问题
门户网站应该把防护拆成四层：边缘节点层、清洗层、业务网关层、源站层。边缘节点层负责把静态内容分发出去，同时做第一道IP信誉过滤和频率限制。清洗层专门处理大流量DDoS，包括SYN Flood、UDP Flood、DNS反射放大等，这一层通常由运营商或专业抗D服务商提供，把攻击流量在进入机房前就丢掉。业务网关层做应用层CC防护，识别请求是否来自真实浏览器、是否携带正确cookie、是否满足人机校验。源站层只接收经过前面几层过滤后的干净流量，同时做好资源隔离和降级开关。
很多门户网站的问题在于，把清洗层和业务网关层混在一起。大流量攻击一来，清洗设备虽然能挡住网络层攻击，但应用层CC攻击会绕过清洗规则直接打到网关。网关如果没有独立的CC防护策略，就会把压力继续传导给源站。所以必须让每一层只干自己擅长的事，层与层之间通过健康检查和实时流量数据联动。
边缘节点要针对门户业务做定制化缓存策略
门户网站的内容更新频率差异很大。首页可能几分钟更新一次，文章页可能几小时更新一次，而静态图片和CSS可能几天不变。如果统一设置缓存时间，要么首页缓存太久导致新闻延迟，要么静态资源缓存太短导致回源频繁。正确做法是按URL路径和文件类型分级缓存。例如，/news/开头的文章页缓存300秒，/static/开头的静态资源缓存7天，/api/开头的接口默认不缓存，但对可公开的排行榜、热门列表接口做短缓存，比如30秒。这样即使攻击者打这些接口，边缘节点也能直接返回缓存内容，不会每次都回源。
还有一个容易忽略的点是缓存键的归一化。攻击者会在URL后面加随机参数，比如?from=attack123，如果缓存键包含这些参数，缓存就会失效。应该在边缘节点对参数做白名单处理，只保留对内容有影响的参数，比如分页参数page、分类参数cat，其余参数全部丢弃。对于User-Agent、Referer这类头信息，也不要默认加入缓存键，除非业务确实需要区分。
CC防护不能只靠频率限制，要结合行为特征和业务逻辑
单纯按IP做频率限制很容易误伤。门户网站经常有大量用户来自同一出口IP，比如学校、公司、运营商NAT。一个IP一分钟请求几十次搜索可能只是正常用户，但如果是几百个IP同时请求同一个不存在的关键词，那就是攻击。所以CC防护要结合多个维度：单IP请求频率、单IP对同一URL的请求频率、全局对某一URL的请求频率、请求是否携带合法cookie、是否执行了JavaScript、是否通过了验证码。
实际操作中，可以先在网关层做一个“软挑战”机制。当某个IP或某个URL的请求量超过阈值时，不直接拒绝，而是返回一个302跳转，要求客户端带上网关下发的临时cookie重新请求。真实浏览器会自动跟随跳转并携带cookie，而大部分脚本攻击不会处理cookie。如果客户端能正确响应，就放行；如果不能，就继续挑战或直接丢弃。这种方式对用户体验影响很小，因为只发生在请求量异常时。
对于搜索接口，还可以做业务层面的防护。比如限制搜索词长度，超过50个字符直接返回空结果；对搜索词做复杂度检测，如果包含大量特殊字符或随机字母数字组合，直接拒绝；对同一IP的搜索频率做阶梯式限制，超过阈值后要求输入验证码。这些规则比单纯的网络层限制有效得多，因为攻击者必须模拟更真实的搜索行为才能绕过。
源站要做资源隔离和降级预案
即使前面几层都做好了，源站也必须假设自己会遭受一定量的攻击。门户网站的源站通常由多台服务器组成，前面有负载均衡。但负载均衡只能分发流量，不能隔离故障。如果攻击者专门打某一个高消耗接口，比如搜索，所有源站服务器都会因为处理这个接口而耗尽资源，导致其他正常页面也无法访问。
解决办法是把高消耗接口单独部署。搜索服务、评论服务、登录服务分别放在不同的服务器集群上，通过网关路由到不同后端。这样即使搜索服务被打挂，首页和文章页仍然可以正常访问。对于数据库，读写分离是基础，搜索相关的查询走从库，主库只负责写入。攻击者打搜索接口时，最多拖垮从库，主库不受影响。
降级预案要提前准备好。门户网站可以设置几个降级等级：一级降级是关闭评论和投票功能，减少写入压力；二级降级是关闭搜索接口，返回“搜索服务暂时不可用”的提示页；三级降级是首页和频道页改为静态快照，不再实时渲染。这些降级操作要能一键触发，不能等到源站已经打挂了才手动操作。
大流量DDoS的清洗策略要跟运营商紧密配合
门户网站遭遇几百G甚至上T的流量攻击时，单靠自建清洗设备根本扛不住。必须提前和运营商或抗D服务商做好联动。通常的做法是，门户网站把自己的公网IP段通过BGP宣告给清洗服务商，正常流量和攻击流量都先经过清洗服务商的网络。清洗服务商在自己的骨干网上做流量牵引和清洗，把攻击流量丢弃后，再把干净流量回注到门户网站的机房。
这里有几个关键点。第一，清洗服务商的路由宣告要精准，不能把整个AS都宣告过去，否则正常流量也会绕路，增加延迟。第二，回注流量要经过隧道或专线，避免在回注过程中被再次攻击。第三，清洗服务商要能实时上报清洗前后的流量数据，门户网站根据这些数据判断攻击类型和规模，及时调整源站策略。第四，要提前做好清洗服务商的备用方案，一旦主清洗服务商本身被打穿，可以快速切换到备用服务商。
日志和监控是优化的基础，没有数据就没法判断攻击是否被有效拦截
门户网站应该对每一层都做详细的流量日志。边缘节点记录请求URL、状态码、命中缓存情况、回源情况。清洗层记录丢弃的攻击流量类型、来源IP、攻击峰值。网关层记录CC防护触发次数、挑战通过率、拦截的请求特征。源站记录每个接口的响应时间、错误率、数据库连接数、CPU负载。
这些日志要汇总到一个统一的监控平台，按分钟级别出报表。当攻击发生时，能快速看到攻击流量在哪一层被拦住了，还有多少漏到了源站。如果源站压力仍然很大，说明前面几层的策略有漏洞，需要调整。比如边缘节点缓存命中率突然下降，可能是攻击者用了新的随机参数绕过缓存；网关层挑战通过率异常升高，可能是攻击者升级了脚本，能自动处理cookie。
监控还要设置合理的告警阈值。不要等流量打到带宽上限才告警，而是当源站某个接口的响应时间超过正常值两倍时，就触发告警。这样运维人员可以在攻击造成实际影响前介入处理。
实际优化中容易踩的坑
第一个坑是过度依赖CDN。很多门户网站以为把静态资源放到CDN上就万事大吉，但CDN节点本身也可能成为攻击目标。如果攻击者直接打CDN节点的IP，CDN服务商可能会因为成本问题把该客户“踢下线”。所以选择CDN服务商时，要确认其抗D能力和对突发流量的处理政策。
第二个坑是防火墙规则太宽泛。有些运维人员为了省事，直接封掉整个海外IP段或者某个运营商IP段。门户网站通常有海外用户，这样做会误伤正常访问。正确的做法是基于威胁情报做精准封禁，只封那些被确认参与攻击的IP。
第三个坑是忽略IPv6的防护。现在很多门户网站已经支持IPv6，但防护设备对IPv6的支持可能不完善。攻击者可以利用IPv6地址空间巨大、难以封禁的特点发起攻击。所以防护策略要同时覆盖IPv4和IPv6。
第四个坑是降级预案没有演练。很多门户网站写了降级预案，但从来没有实际演练过。真到攻击发生时，运维人员手忙脚乱，不知道先执行哪一步。应该定期做攻击演练，模拟不同类型的DDoS攻击，验证每一层防护是否生效，降级操作是否能在几分钟内完成。
总结门户网站DDoS防护优化的核心思路
门户网站做DDoS防护优化，不是买一台更贵的设备，而是把整个访问链路拆开，每一层都做针对性的优化。边缘节点管好缓存，清洗层挡住大流量，网关层识别CC攻击，源站做好隔离和降级。同时，日志监控要贯穿始终，数据驱动策略调整。攻击者会不断变化手法，门户网站的防护策略也要持续迭代。只有把防护做成一个动态调整的体系，而不是一次性配置，才能在真正的大流量攻击面前扛得住。
