网站接入加速器后的源站边界与日志验证

发布于2小时前2小时

网站接入 CDN 或反向代理加速后，常见问题不只是缓存是否命中：如果源站仍对公网开放，用户可能绕过加速器直连源站；如果源站信任任意客户端提交的转发头，访问日志中的客户端地址也可能被伪造。下面以授权测试环境中的 Nginx 源站为例，说明如何检查访问路径、日志和修复效果。

背景与范围

假设网站域名为 site.example，前置加速器将请求转发到 Nginx 源站。测试前确认已获得网站与源站管理方授权，并明确源站地址、允许测试的入口和时间窗口。示例中的 192.0.2.0/24、198.51.100.10 等均为文档示例地址，实际部署时应替换为加速服务商公布并持续维护的出口网段及源站地址。

问题定位

从正常用户入口访问，确认解析结果、HTTPS 证书、响应状态码及缓存响应头，记录加速器请求 ID（如有）。
在授权的管理主机上检查源站的公网暴露情况；不要通过扫描无关地址验证。若源站端口对所有公网地址开放，即使域名已接入加速器，也仍存在绕过代理访问的入口。
核对 Nginx 日志中的客户端地址和 TCP 对端地址。客户端地址应来自可信代理链，而不能直接采信任意请求携带的 X-Forwarded-For。

技术分析与操作步骤

第一步，盘点加速器到源站的实际回源地址段，并在云防火墙、安全组或主机防火墙上限制源站 80/443 仅接受这些来源。若有办公网、运维跳板机或健康检查节点需要直连，应单独登记网段和用途，不要用“允许全部”作为临时例外。

第二步，在 Nginx 中仅信任已确认的代理网段。下面示例同时记录 Nginx 还原后的客户端地址和原始 TCP 对端地址，便于发现代理链配置错误。

http {
    # 仅填写加速器真实回源网段；应按服务商变更公告维护
    set_real_ip_from 192.0.2.0/24;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    log_format origin '$time_iso8601 client=$remote_addr peer=$realip_remote_addr '
                      'host=$host request="$request" status=$status '
                      'xff="$http_x_forwarded_for" request_time=$request_time';

    server {
        listen 443 ssl;
        server_name site.example;
        access_log /var/log/nginx/site_access.log origin;

        location / {
            proxy_pass 
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

配置前先确认当前 Nginx 版本支持 realip 模块。修改后执行 nginx -t，通过后再平滑加载；不要在配置检查失败时直接重启服务。

nginx -t
nginx -s reload

# 经正常加速入口检查响应头与状态码
curl -sS -D - -o /dev/null 

# 仅在已授权的测试主机上，将域名解析到已知源站地址进行直连验证；
# 若防火墙策略正确，非加速器来源应连接失败或被拒绝
curl -k -sS --connect-timeout 5 --resolve site.example:443:198.51.100.10 \
  -D - -o /dev/null 

# 查看最近的源站访问记录，重点比对 client 与 peer
 tail -n 50 /var/log/nginx/site_access.log

如果测试主机属于加速器允许的回源网段，直连成功并不说明策略失效；应从不在允许列表中的授权测试出口复测，并结合安全组规则及源站日志判断。不要只凭 curl 返回码下结论：连接超时可能是路由或网络策略导致，需同时检查防火墙计数、Nginx 错误日志和云平台流量日志。

日志判读与漏洞验证

正常经代理访问时，peer 通常应落在已登记的加速器网段，client 应为还原后的用户地址。若 peer 是公网用户地址，说明源站可能被直连，或前置链路并非预期代理。
若日志中的 client 与请求头 XFF 不一致，先核对代理是否覆盖或追加该头，以及 real_ip 信任范围是否配置正确。不要把 XFF 原文当作身份认证或访问控制依据。
将直连测试的时间、源地址、目标地址、返回结果与安全组/防火墙日志关联；保留配置变更前后的日志片段和规则导出，便于复核。
对源站管理端、调试端口和应用后端端口执行同样的边界盘点。它们不应因网站加速接入而暴露给公网，运维访问应走 VPN、跳板机或专用管理网。

风险与修复建议

源站只允许加速器回源网段访问 80/443；其他必要来源使用最小范围的单独规则，并设置责任人与复核日期。
定期同步加速器出口网段，更新规则后从允许和不允许的测试出口分别验证，避免网段变更导致业务中断或重新暴露。
只信任代理连接来源上的转发头。若有多层代理，逐层确认头部追加规则和信任边界，避免客户端伪造的地址被误认为真实来源。
日志中保留真实客户端地址、代理对端、请求时间、状态码和请求 ID；控制日志访问权限与留存周期，并对异常直连和管理路径访问设置告警。
修复后再次验证正常入口仍可用、非授权来源无法直连，并检查应用是否在反向代理之后仍正确处理 HTTPS、Host 和客户端地址。

总结

网站加速配置不能只看域名是否指向 CDN。有效的边界验证需要同时检查回源访问控制、Nginx 对代理头的信任范围，以及能够区分客户端和代理对端的日志。把验证结果与防火墙规则、访问日志和变更记录对应起来，才能确认源站没有留下绕过加速入口的路径。

登录