很多人以为买了云防护，网站网站就进了保险箱。访问防护服务去年我帮一个做跨境电商的节点朋友排查故障，他的源站网站套了某主流云WAF，结果连续三天间歇性502。网站查到最后发现，访问防护服务攻击者根本没打他的节点域名，而是源站通过扫描全网IP找到了他源站服务器的真实地址，直接绕过云节点打了过去。网站云防护节点和源站服务器之间的访问防护服务关系，比大多数人想的节点要脆弱得多。

云防护节点本质上是源站一层反向代理。用户请求先到节点，网站节点清洗流量后再转发给源站。访问防护服务这个架构有个致命前提：源站IP必须藏好。节点一旦暴露，攻击者可以完全跳过云节点，直接对源站发起DDoS或CC攻击。我见过太多案例，运维在配置邮件服务器、FTP服务、甚至SSL证书申请时，不小心把源站IP泄露出去。更隐蔽的是DNS历史记录——有人换过DNS服务商，旧记录被缓存或存档，攻击者翻出来照样能用。

那源站服务器该怎么配置才安全？最基础的一条：防火墙只允许云节点回源IP段访问。各大云厂商都会公布自己的回源IP列表，把这些IP段加入白名单，其他所有入站请求全部丢弃。听起来简单，但实际操作中有人图省事，直接开放80和443给0.0.0.0/0，那云防护就成了摆设。我自己的做法更极端一些，源站只监听内网端口，通过专线或VPN与云节点通信。成本高一点，但安心。

另一个容易被忽略的点是回源协议。很多云防护默认用HTTP回源，哪怕用户访问的是HTTPS。这意味着云节点到源站那段路是明文传输。如果源站和节点不在同一内网，数据在路上就可能被嗅探。改成HTTPS回源，或者在源站配置自签名证书让节点校验，能堵住这个口子。不过要注意，开启HTTPS回源后，源站服务器的时间必须准确，否则证书校验会失败。我遇到过一台源站因为NTP没同步，时间差了十几分钟，导致回源全部超时，网站直接挂了。

源站服务器的性能配置也得跟着调整。云节点回源时，源站看到的客户端IP全是节点IP。如果你的源站有基于IP的限流或封禁逻辑，会误伤所有正常用户。正确做法是让云节点在回源请求头里带上真实客户端IP，源站从X-Forwarded-For或X-Real-IP里取。但这里有个坑：不同云厂商用的头字段不一样，有些用X-Forwarded-For，有些用X-Real-IP，还有些两个都带但顺序不同。迁移云厂商时，源站的解析逻辑不改，真实IP就取错了。

缓存策略是另一个战场。云节点缓存了静态资源，源站压力确实小。但动态请求回源时，如果源站响应头里的Cache-Control设置不当，云节点可能缓存了不该缓存的内容。我见过一个论坛，用户登录后的个人页面被云节点缓存，结果A用户看到了B用户的头像和昵称。这种事故比被攻击还尴尬。源站必须对动态接口显式设置Cache-Control: no-store，别偷懒。

最后说个真实观察：很多中小团队把云防护当成万能药，源站却跑着三年前的未打补丁的Nginx，数据库密码还是root/123456。云节点能挡流量攻击，挡不住源站自身的漏洞。攻击者绕过云节点后，一个SQL注入就能拖库。云防护节点和源站服务器，一个负责挡外面的明枪，一个负责防内部的暗箭。两边都硬，网站才真的稳。