宝塔面板日志被CDN节点IP填满：log_format与real_ip联动调整

发布时间：2026-09-27 12:30 更新时间：2026-09-27 12:30 阅读量：0

站点接入 CDN 之后，很多站长打开宝塔面板的网站访问日志，会发现满屏都是几个固定 IP 的请求，UA 也长得差不多，明显是 CDN 节点的回源记录。原本想用日志看真实访客来源、排查异常请求，结果日志变成了节点心跳统计。更麻烦的是，有些站点同时打开了 real_ip 相关配置，日志里 IP 看似换成了真实访客，但字段错位、格式混乱，用 goaccess 之类的工具解析直接报错。这篇文章把这类问题的成因和调整方法讲清楚，配置改完能立刻验证。

先弄清：real_ip 改的是变量，不是日志本身

Nginx 的 ngx_http_realip_module 作用是把 $remote_addr 等变量的取值替换成请求头里携带的真实客户端 IP，它并不直接修改日志文件。也就是说，日志里显示什么，取决于你的 log_format 指令里引用了哪些变量。如果日志格式里写的是 $remote_addr，并且 real_ip 配置正确生效，那么写进日志的就是被还原后的访客 IP；如果 real_ip 没配或没生效，写进去的就是 CDN 节点 IP。

宝塔面板默认的 Nginx 日志格式通常引用 $remote_addr 和 $http_x_forwarded_for 等变量。接入 CDN 后，请求由节点发起，$remote_addr 自然变成节点地址。要拿到访客 IP，需要告诉 Nginx：从哪个请求头取真实 IP、信任哪些来源。常见写法如下，把 CDN 回源段替换成你实际使用的服务商网段，具体网段以服务商官方文档为准。

set_real_ip_from 203.0.113.0/24;
set_real_ip_from 198.51.100.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

这几行一般放在 http 块或单个 server 块里。宝塔面板可以在「软件商店 - Nginx - 配置修改」里加到 http 段，也可以在站点配置文件的 server 段内添加，改完重载 Nginx 生效。注意 real_ip_recursive on 会从 X-Forwarded-For 右侧往前找第一个不在信任列表里的地址，链路上有多层代理时更准确；如果 CDN 只透传单层 XFF，也可以不开这个选项，按实际链路决定。

日志格式与 real_ip 的联动调整

real_ip 配好后，日志里 $remote_addr 已经是访客 IP，但很多站长想同时保留回源节点 IP 用于排查回源问题，这时候就要在 log_format 里把两类地址都记下来。宝塔面板的日志格式定义在 Nginx 主配置的 http 段，修改前建议先备份原配置。下面是一个兼顾真实 IP 与回源 IP 的格式示例：

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" '
                'node=$realip_remote_addr req_time=$request_time';

这里 $remote_addr 是还原后的访客 IP，$realip_remote_addr 是 real_ip 模块处理前的原始连接地址，也就是 CDN 节点 IP，两者一起记录，既能分析访客来源，也能在回源异常时确认是哪个节点来的。需要提醒的是，$realip_remote_addr 是 real_ip 模块提供的变量，使用前要确认模块已编译进 Nginx，宝塔面板自带的 Nginx 一般已包含，具体可以用 nginx -V 查看编译参数确认。

如果站点原本的日志格式是自定义的，改完 log_format 后要确认站点 access_log 指令引用的是新格式名，否则格式改了也不生效。宝塔站点配置里通常写作 access_log /www/wwwlogs/xxx.log;，不带格式名时使用默认格式。建议显式指定：

access_log /www/wwwlogs/example.com.log main;

改完执行 nginx -t 检查语法，再 nginx -s reload 或通过宝塔面板重载。重载后刷新几次页面，用 tail -f 观察新写入的日志行，确认 IP 字段与节点字段是否符合预期。

验证、切割与常见坑

验证 real_ip 是否生效，最简单的办法是用手机流量访问站点，然后看日志里出现的 IP 是不是你当前网络的出口 IP。也可以在服务器上直接带自定义头请求本地站点：

curl -H "X-Forwarded-For: 198.51.100.77" -I http://127.0.0.1/
tail -n 5 /www/wwwlogs/example.com.log

如果日志里 $remote_addr 位置显示 198.51.100.77，说明 real_ip 链路通了；仍显示 127.0.0.1，则说明信任来源没覆盖到本机，或者 real_ip 配置没放在请求经过的 server 块里。注意这只是本地模拟，真实 CDN 环境下还要确认服务商回源时是否携带 X-Forwarded-For，有些服务商默认用 X-Real-IP 或 CF-Connecting-IP，这时 real_ip_header 要跟着换，具体头名称以服务商文档为准。

日志格式变长之后，单行体积会变大，磁盘占用增长更快。宝塔面板的日志切割默认按天执行，如果站点流量大，建议确认切割任务正常，必要时在面板「计划任务」里加一条日志切割任务，或配合 logrotate 按大小切割。另外要注意，部分日志分析工具对字段顺序敏感，改了 log_format 之后旧的解析规则可能失效，需要同步更新工具配置。

最后给一个调整顺序建议：先确认 CDN 回源请求头，再配 set_real_ip_from 与 real_ip_header，然后改 log_format 增加节点字段，最后重载并用真实访问验证。整个过程不涉及复杂操作，核心是记住 real_ip 改的是变量、log_format 决定写什么。配置前备份 Nginx 主配置和站点配置，出错可以快速回滚。不同 CDN 服务商的回源头名称与网段差异较大，落地时以官方文档和实际抓包结果为准。

继续阅读