防CC攻击这件事，单靠一个HTML页面是防不住的。这话说出来有点扫兴，但得先把这点讲清楚。HTML是跑在浏览器里的东西，攻击者的请求直接打到服务器上，根本不会经过你页面的同意。你在HTML里写再多的防护逻辑，攻击者用脚本发请求的时候压根不执行你的页面。所以真正的CC防护，主战场在服务端和边缘节点，HTML能做的只是配合。
不过HTML层面也不是完全没事可做。有些手段能提高攻击成本，或者帮正常用户通过验证，把机器人挡在外面。
最常见的一招是JS挑战。页面加载的时候不直接显示内容，先跑一段JavaScript，算一个简单的工作量证明，算完了把结果提交给服务端，服务端验证通过才返回真正的内容。攻击者用curl或者Python脚本发请求，不会执行JS，拿到的只是一个空壳页面。正常用户的浏览器会跑JS，一两秒内自动完成验证，无感通过。Cloudflare的“Under Attack”模式就是这个思路。你自己实现的话，页面里放一段计算脚本，把结果写进cookie或者隐藏字段，服务端检查这个值对不对。缺点是懂技术的攻击者可以用无头浏览器绕过，但能挡住大部分低成本的脚本小子。
另一个思路是延迟加载和元刷新。页面先返回一个过渡页，里面用meta refresh或者JS的setTimeout，等三五秒再跳转到真正的内容页。攻击者的脚本通常不会等，请求一到就断开，等于白打。正常用户等几秒虽然有点烦，但至少能进去。这个办法比较糙，适合临时应急，长期用用户体验不好。
验证码是更直接的手段。页面里嵌一个reCAPTCHA或者hCaptcha，用户提交之前先过验证。攻击者要批量打请求，就得批量过验证码，成本一下就上去了。但验证码影响转化率，电商站或者内容站慎用，搞不好正常用户也跑了。折中的做法是只在检测到异常流量的时候才弹验证码，平时不弹。
静态化是另一条路。如果你的页面内容不经常变，直接生成纯HTML文件，前面挂Nginx或者CDN，请求进来直接返回静态文件，不经过PHP或者数据库。CC攻击打的是动态请求消耗CPU和数据库连接，你全静态了，它打过来就是Nginx返回一个几KB的HTML文件，跟正常访问没区别。攻击者打得再猛，Nginx扛静态请求的能力比PHP强几个数量级。WordPress可以用WP Super Cache或者W3 Total Cache生成静态页，其他程序也有类似的插件。
Nginx层面可以做限速和限连接。limit_req_zone限制单个IP每秒的请求数，limit_conn_zone限制单个IP的同时连接数。配置大概是这样：在http块里定义zone，比如limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s，然后在location里应用limit_req zone=one burst=20 nodelay。意思是每个IP每秒最多10个请求，突发允许20个，超了就返回503。正常用户不会一秒发10个请求，攻击脚本会。这个配置对CC有不错的缓解效果，但要注意别把API接口或者正常的高频操作给限了。
CDN和WAF是更省心的方案。Cloudflare免费版就带基础CC防护，开启“I'm Under Attack”模式后，所有访客先过五秒盾，验证通过才放行。国内的话，阿里云DDoS高防、腾讯云大禹、百度云加速都有CC防护功能，按QPS或者按流量计费。这些服务在边缘节点就把攻击流量清洗掉了，根本到不了你的源站。缺点是花钱，免费的Cloudflare在国内访问速度一般，付费的高防又比较贵。
服务端代码里也能做一些事。比如检查User-Agent，空的或者明显是脚本的UA直接拒绝。检查Referer，关键操作要求请求来源必须是自己的域名。给每个会话发一个token，提交的时候验证token，token不对就拒绝。这些手段单独用效果有限，但叠加起来能提高攻击门槛。
还有一点容易被忽略：日志和监控。你得知道攻击什么时候来、量有多大、打的是哪个页面。Nginx的access log里看IP分布，如果某个IP或者某个IP段请求量异常大，直接在防火墙或者Nginx里deny掉。用fail2ban自动封禁频繁请求的IP，配置好规则之后它帮你盯着日志，触发阈值就自动加iptables规则。这个适合中小规模的CC，攻击源不多的时候管用。
说到底，HTML页面本身防不了CC，它能做的是配合服务端的验证机制，让正常用户顺畅通过，让脚本卡在门外。真正的防护体系是分层的：CDN挡第一波，Nginx限速挡第二波，应用层验证挡第三波，最后还有日志监控兜底。只靠其中任何一层都不够，叠在一起才能把大部分CC攻击消化掉。攻击者真要下血本打你，那得靠专业的高防服务，不是改几行HTML能解决的。