cdn环境下真实用户ip需从x-forwarded-for提取并用set_real_ip_from白名单校验，referer为空亦是线索，tcp连接表（ss命令）可获取底层真实ip，恶意location劫持会隐藏攻击源。
CDN环境下，$remote_addr 不是真实用户IP，而是CDN节点IP
这是溯源失败最常见的起点。只要网站启用了CDN（哪怕只是宝塔自带的“反向代理”或用了腾讯云、阿里云、Cloudflare等），Nginx日志里默认的$remote_addr字段就已失效——它记录的是最后一跳CDN服务器的IP，不是攻击者本人的出口IP。
真正可信的线索藏在HTTP请求头里：X-Forwarded-For（XFF）是CDN转发时带上的原始客户端IP链，格式如 1.2.3.4, 10.0.0.1, 203.208.60.1，最左边那个才是目标IP。但注意：X-Forwarded-For 可被客户端伪造，所以必须配合 set_real_ip_from 白名单校验，只信任来自已知CDN网段的XFF值。
- 宝塔中需手动编辑站点Nginx配置，在
server或http块内加入：set_real_ip_from 1.2.3.0/24;（替换成你CDN厂商公布的IP段，比如Cloudflare官方段见https://www.cloudflare.com/ips/） - 紧接其后加：
real_ip_header X-Forwarded-For;和real_ip_recursive on; - 否则即使日志里写了
$http_x_forwarded_for，也可能是攻击者自己构造的假IP
攻击者伪造Referer或清空它，不代表没留下痕迹
很多人查Referer字段全是-就放弃溯源，其实这本身就是线索。HTTPS页面跳转到HTTP站点、浏览器隐私模式、APP内嵌WebView、或攻击脚本显式设置referrerPolicy: 'no-referrer'，都会导致Referer丢失——但这些场景往往伴随固定User-Agent、异常URI路径、高频低延时请求等特征。
- 在宝塔「网站监控报表」→「URI统计」中筛选出请求量TOP 50的路径，重点看是否含随机参数（如
/api/test?id=abc123、/wp-json/v2/posts?_=<timestamp></timestamp>）、无规律哈希名（如/static/7f3a9b2e.js）、或明显非人类行为的深度分页（/list?page=9999） - 同步去「错误日志」里搜索状态码
403或499，再用grep -E "User-Agent|Referer"提取上下文，常能发现同一IP反复用不同UA试探，或Referer被设为百度但IP根本不在百度段内 - 注意：宝塔默认不记录POST请求的Referer，所以暴力破解类攻击（如/wp-login.php POST）在Referer字段里必然为空，得靠IP+时间戳+响应体大小交叉比对
用netstat和ss直接抓取TCP层真实连接IP
当Web日志被污染、CDN头部被绕过、或攻击者用肉鸡代理时，底层网络连接仍是不可篡改的事实。Linux内核维护的TCP连接表（/proc/net/tcp）记录了每个ESTABLISHED连接的真实远端IP和端口，不受任何上层协议干扰。
- 在宝塔「终端」执行：
ss -tn state established '( dport = :80 or dport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20，可快速列出当前活跃连接最多的20个源IP - 若发现某IP持续维持上百个ESTABLISHED连接，或大量
SYN_RECV（ss -tn state syn-recv | wc -l> 50），基本可判定为CC攻击或慢速攻击，此时该IP就是第一手攻击源（哪怕它只是傀儡机） - 注意：
netstat在高并发下有性能损耗，ss更准更快；且需确认未启用iptables的SNAT或DNAT规则，否则看到的仍是中间节点IP
恶意修改的location块会劫持流量并隐藏攻击入口
近期高频出现的黑链注入手法，是在/www/server/panel/vhost/nginx/下的站点配置文件中，偷偷插入带proxy_pass的location规则（例如匹配/.*intron.*跳转到cdnv2.zdink.com）。这类配置不仅导流，更关键的是：所有经此跳转的请求，其X-Forwarded-For会被上游CDN覆盖，原始攻击IP彻底消失。
- 务必定期检查该目录下所有
.conf文件，搜索关键词：proxy_pass、proxy_set_header、set_real_ip_from、real_ip_header，尤其警惕非宝塔自动生成的location ~*块 - 一旦发现异常
proxy_pass，立即备份原文件，删除恶意块，并用nginx -t验证语法，再systemctl reload nginx重载 - 修复后，用
curl -H "X-Forwarded-For: 1.1.1.1" https://yoursite.com/test测试是否还能被伪造——如果日志里真出现了1.1.1.1，说明set_real_ip_from未生效或白名单范围过大
$remote_addr。
