CentOS 7 源码编译 ngx_pagespeed 实战指南

1. 项目概述：为什么在 CentOS 7 上手动编译 ngx_pagespeed 是个“不得不做”的硬功夫

你刚接手一台跑着 WordPress 或静态站点的 CentOS 7 服务器，首页加载时间卡在 3.2 秒，WebPageTest 报告里满屏黄色警告：“未启用图像压缩”、“CSS/JS 未内联关键资源”、“HTML 未最小化”。你查了 Nginx 官方模块列表，发现 pagespeed 压根不在nginx -V的--with-*输出里——它压根不是 Nginx 自带模块。再一搜“CentOS 7 install ngx_pagespeed”，前五条全是“yum install nginx-pagespeed”失败记录，第六条写着“EPEL 源已移除该包”。这时候你就明白了：在 CentOS 7 这个被大量政企和老运维团队锁定的发行版上，想用上 Google 开源的这个“网页加速引擎”，唯一靠谱的路，就是亲手把它编译进 Nginx 二进制文件里。这不是炫技，是生存刚需。ngx_pagespeed 不是插件，它是个深度嵌入 Nginx HTTP 处理生命周期的 C++ 模块，能自动完成图像 WebP 转换、CSS/JS 合并与懒加载、HTML 重写、资源预加载等 30+ 项优化，效果远超单纯加个gzip on。而 CentOS 7 的默认软件仓库（Base + EPEL）早已停止维护 ngx_pagespeed 的 RPM 包，官方也明确声明“仅支持源码编译安装”。我去年帮三个客户迁移旧站时踩过所有坑：有人用dnf install nginx-mod-http-pagespeed试图走捷径，结果装上的是个空壳；有人直接yum update nginx，导致 pagespeed 模块被覆盖失效；还有人图省事用 Docker，却发现容器里 CentOS 7 镜像的 glibc 版本太低，pagespeed 编译直接报GLIBC_2.17 not found。所以这篇不是教程，是我把三年来在生产环境反复验证过的编译路径、参数取舍、故障快照全盘托出。适合正在看这篇的你：手头有一台干净或已部署 Nginx 的 CentOS 7 服务器（Minimal 或 Desktop 版均可），愿意花 45 分钟敲几行命令，换来网站首屏加载速度提升 40% 以上的确定性回报。

2. 整体设计思路与方案选型：为什么必须放弃包管理，坚持源码编译

2.1 为什么不能用 yum/dnf 安装？

CentOS 7 的软件生态有其固有节奏。EPEL（Extra Packages for Enterprise Linux）曾提供nginx-pagespeed包，但早在 2021 年就因维护成本过高和上游更新断档而正式下架。你执行yum search pagespeed或dnf list available | grep pagespeed，返回结果永远为空。更关键的是，即使你找到某个第三方仓库提供的 RPM，它也极大概率存在三个致命缺陷：第一，模块版本严重滞后——当前稳定版 pagespeed 是 1.13.35.2，而能找到的最“新” RPM 往往停留在 1.11.x，缺失对 Brotli 压缩、Critical CSS 自动提取等关键特性支持；第二，ABI 兼容性黑洞——RPM 包是为特定 Nginx 版本（如 1.16.1）编译的，而你线上运行的可能是 1.20.1 或自己编译的 1.18.0，模块加载时会直接报undefined symbol: ngx_http_upstream_init_request这类符号缺失错误；第三，配置隔离陷阱——RPM 安装会把.so文件扔进/usr/lib64/nginx/modules/，但它的pagespeed.conf示例却硬编码了/etc/nginx/conf.d/pagespeed.conf路径，一旦你自定义了 Nginx 配置结构（比如把所有 conf 放在/opt/nginx/conf/下），整个模块就变成摆设。我见过最离谱的案例：某金融客户采购的“安全加固版 CentOS 7”镜像，自带一个阉割版 Nginx RPM，连--with-http_ssl_module都没编译进去，此时强行rpm -ivhpagespeed 包，安装过程看似成功，但nginx -t直接报unknown directive "pagespeed"。所以，放弃包管理不是矫情，是规避不可控风险的必然选择。

2.2 为什么必须重新编译整个 Nginx，而不是动态加载模块？

Nginx 的模块机制分两类：静态模块（static module）和动态模块（dynamic module）。Pagespeed 官方文档明确要求“must be compiled as a static module”，原因在于其架构深度耦合 Nginx 的核心数据结构。Pagespeed 在请求处理链中插入了多达 17 个 hook 点，从NGX_HTTP_POST_READ_PHASE（读取请求头后）到NGX_HTTP_LOG_PHASE（日志记录前），甚至要修改ngx_http_request_t结构体的内存布局以存储优化上下文。动态模块（.so文件）在运行时通过dlopen()加载，其符号解析发生在进程启动后，无法安全地重写 Nginx 核心结构体的字段偏移量。当你尝试用load_module /path/to/ngx_pagespeed.so;方式加载时，Nginx 启动瞬间就会崩溃，core dump日志里全是segmentation fault at address 0x... in module 'nginx'。我实测过 12 种不同 Nginx 版本（1.16–1.22）下的动态加载，全部失败。而静态编译则让 pagespeed 的 C++ 代码与 Nginx C 代码在链接阶段彻底融合，GCC 将二者符号表合并，确保ngx_pagespeed_filter函数能无缝调用ngx_http_send_header()等内部 API。这就像给汽车发动机加装涡轮增压器——你不能把它做成可插拔的 USB 设备，必须焊死在进气歧管上。因此，我们的方案是：下载 Nginx 源码 + Pagespeed 源码 → 解压 → 执行./configure时显式指定--add-module=/path/to/ngx_pagespeed→make && make install。整个过程会生成一个全新的、内置 pagespeed 的nginx二进制文件，完全替代系统原有版本。好处是绝对稳定，坏处是你需要备份原配置并重新安装。

2.3 为什么选择 CentOS 7 Minimal 作为基准环境？

网络热词里高频出现的 “vmware虚拟机安装centos 7” 和 “centos 7 minimal 下载”，恰恰印证了这是最主流的部署场景。Minimal 版本只包含最精简的系统组件（无 GUI、无邮件服务、无打印服务），磁盘占用约 600MB，内存占用低于 300MB，极大降低了编译过程中的依赖冲突概率。我对比过 Desktop 版本的编译失败率：Desktop 默认安装了libjpeg-turbo-devel、libpng-devel等图像库，但版本往往比 pagespeed 编译要求的低（pagespeed 1.13.x 要求 libpng >= 1.6.34），导致make过程中psol（PageSpeed Optimization Library）子模块编译报错png_set_longjmp_fn undefined。而 Minimal 版本一片空白，我们可以精准控制每个依赖的版本：yum install gcc-c++ pcre-devel zlib-devel openssl-devel这四条命令就能搭起完整编译环境，后续再按需安装libpng-devel-1.6.37这样的精确版本。更重要的是，Minimal 的systemd服务脚本极其干净，不会像 Desktop 版那样自带一堆firewalld、NetworkManager的干扰服务，避免make install后systemctl restart nginx因服务依赖混乱而失败。所以，无论你是在 VMware Workstation Pro 里新建虚拟机，还是在物理服务器上重装系统，请务必选择 CentOS 7 Minimal ISO（sha256:e9c0b6a1...），这是整个项目的基石。

3. 核心细节解析与实操要点：编译前必须搞懂的五个生死参数

3.1 Pagespeed 模块版本与 Nginx 版本的黄金配对表

Pagespeed 不是向后兼容的“万能胶”，它对 Nginx 主版本有严格要求。官方 GitHub Release 页面明确标注了每个 pagespeed 版本支持的 Nginx 范围。例如，当前最新稳定版1.13.35.2仅支持 Nginx 1.16.x 至 1.22.x，完全不支持 Nginx 1.24+（因为 1.24 引入了新的ngx_http_v3协议栈，pagespeed 尚未适配）。而 CentOS 7 默认yum install nginx安装的是 1.16.1，这看似完美，但隐患在于：1.16.1 的 OpenSSL 库版本是 1.0.2k，而 pagespeed 1.13.35.2 要求 OpenSSL >= 1.0.2u 才能启用 TLS 1.3 优化。因此，我们必须升级 Nginx 到 1.20.2（它捆绑 OpenSSL 1.1.1k），这才是真正的“黄金组合”。我整理了一份经生产环境验证的配对表：

提示：不要贪新。我曾用 Nginx 1.22.1 + pagespeed 1.13.35.2 在某电商后台压测，发现高并发下pagespeed_statistics接口响应延迟飙升至 800ms，降级到 1.20.2 后稳定在 12ms。原因是 1.22 引入的ngx_http_upstream_check_module与 pagespeed 的共享内存锁存在竞争条件。所以，认准 1.20.2，这是经过千次压测验证的稳态版本。

3.2 configure 参数的取舍逻辑：哪些必须加，哪些必须砍

Nginx 的./configure命令有 50+ 个开关，但 pagespeed 编译只关心其中 7 个核心参数。我逐条解释其必要性：

1. --add-module=/path/to/ngx_pagespeed：绝对必需。这是告诉编译器“把 pagespeed 的源码目录当作一个模块加入构建流程”。路径必须是绝对路径，且目录名不能含空格或中文。我习惯把它放在/root/build/ngx_pagespeed。

2. --with-http_ssl_module：绝对必需。Pagespeed 的pagespeed EnableFilters collapse_whitespace,remove_comments等过滤器必须在 HTTPS 上才能对 HTML 进行安全重写，否则会触发浏览器混合内容警告。CentOS 7 Minimal 默认不装 OpenSSL 开发包，所以yum install openssl-devel是前置动作。

3. --with-http_v2_module：强烈推荐。HTTP/2 是 pagespeed 发挥最大效能的基础。pagespeed EnableFilters prioritize_critical_css依赖 HTTP/2 的服务器推送（Server Push）能力，将关键 CSS 直接推送给客户端，绕过 DNS 查询和 TCP 握手。不开启此模块，该功能自动降级为普通内联，效果打五折。

4. --with-compat：可选但建议开启。它让新编译的 Nginx 二进制文件能加载其他动态模块（如nginx-module-vts监控模块）。虽然 pagespeed 本身是静态的，但你未来可能需要添加日志分析模块，这个参数能避免二次编译。

5. --prefix=/etc/nginx：必须与现有环境一致。如果你的线上 Nginx 配置在/etc/nginx/，这里就必须设成一样，否则make install会把配置文件覆盖到/usr/local/nginx/conf/，导致服务启动失败。用nginx -V 2>&1 | grep prefix可查当前路径。

6. --sbin-path=/usr/sbin/nginx：必须匹配。CentOS 7 的 systemd 服务文件/usr/lib/systemd/system/nginx.service硬编码了ExecStart=/usr/sbin/nginx，如果这里设成/usr/local/nginx/sbin/nginx，systemctl start nginx会报No such file or directory。

7. --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions'：安全加固必需。CentOS 7 的 GCC 默认不开启栈保护和格式化字符串检查，而 pagespeed 的 C++ 代码量巨大（超 50 万行），开启这些编译选项能在编译期捕获 90% 的内存越界和格式化漏洞。-O2是性能与体积的黄金平衡点，-O3会导致 pagespeed 的psol子模块链接失败。

注意：必须砍掉--with-http_realip_module。这个模块与 pagespeed 的 IP 地址解析逻辑存在底层冲突，会导致pagespeed Statistics页面显示0.0.0.0而非真实访客 IP。我花了三天排查才定位到这个问题——当realip模块启用时，pagespeed 读取r->connection->addr_text得到的是代理 IP，而非X-Forwarded-For解析后的原始 IP。解决方案是：禁用realip，改用 pagespeed 自带的pagespeed XHeaderValue "X-Forwarded-For"指令。

3.3 Pagespeed 编译依赖的精确版本控制

Pagespeed 的编译不是“装完开发工具链就完事”，它有三组必须精确匹配的依赖库：

第一组：基础编译工具

yum install -y gcc-c++ make pcre-devel zlib-devel openssl-devel

• gcc-c++：必须 >= 4.8.5（CentOS 7 默认 4.8.5，够用）
• pcre-devel：必须 >= 8.32（CentOS 7 默认 8.32，够用）
• zlib-devel：必须 >= 1.2.7（CentOS 7 默认 1.2.7，够用）

第二组：图像处理库（决定 WebP 转换质量）

# 卸载系统默认的低版本 yum remove -y libpng-devel libjpeg-turbo-devel libtiff-devel # 安装精确版本（pagespeed 1.13.35.2 测试通过） yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libpng-devel-1.6.37-1.el7_9.x86_64.rpm yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libjpeg-turbo-devel-1.5.3-10.el7_9.x86_64.rpm yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libtiff-devel-4.0.3-35.el7_9.x86_64.rpm

• libpng-devel-1.6.37：修复了 pagespeed 1.13.x 中 PNG 透明通道丢失的 Bug
• libjpeg-turbo-devel-1.5.3：启用 SIMD 指令加速 JPEG 解码，实测 WebP 转换速度提升 3.2 倍

第三组：Brotli 压缩支持（pagespeed 1.13.35.2 新增）

# Brotli 是比 Gzip 高效 15% 的新压缩算法，pagespeed 用它压缩 CSS/JS cd /root/build && wget https://github.com/google/brotli/archive/refs/tags/v1.0.9.tar.gz tar -xzf v1.0.9.tar.gz && cd brotli-1.0.9 && ./configure-cmake && make && make install

• 必须用v1.0.9，v1.1.0会触发undefined reference to 'BrotliEncoderCreateInstance'链接错误

实操心得：我曾经跳过 Brotli 安装，以为只是“锦上添花”，结果上线后发现 pagespeed 的pagespeed EnableFilters rewrite_css,rewrite_javascript生成的资源 URL 里没有.br后缀，curl -H "Accept-Encoding: br" http://site/css/main.css返回 404。翻 pagespeed 源码才发现，psol的brotli子模块在 configure 阶段检测不到libbrotlienc.so就会静默禁用整个 Brotli 功能。所以，Brotli 不是可选项，是 pagespeed 1.13.35.2 的隐式依赖。

4. 实操过程与核心环节实现：从零开始的 45 分钟编译流水线

4.1 环境初始化：10 行命令打造纯净战场

在 VMware Workstation Pro 中安装好 CentOS 7 Minimal 后，执行以下命令初始化环境。每一步都有明确目的，不是无脑复制：

# 1. 关闭 SELinux（pagespeed 的共享内存段在 enforcing 模式下会被拦截） sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config setenforce 0 # 2. 更新系统并安装基础工具（Minimal 版本默认不装 wget/vim） yum update -y && yum install -y wget vim net-tools epel-release # 3. 创建统一构建目录，避免路径混乱 mkdir -p /root/build && cd /root/build # 4. 安装编译所需的核心开发包（注意：openssl-devel 必须在 configure 前装） yum install -y gcc-c++ make pcre-devel zlib-devel openssl-devel # 5. 下载 Nginx 1.20.2 源码（官方校验值：SHA256 3a7a...） wget https://nginx.org/download/nginx-1.20.2.tar.gz tar -xzf nginx-1.20.2.tar.gz # 6. 下载 Pagespeed 1.13.35.2 源码（官方校验值：SHA256 9b2c...） wget https://github.com/apache/incubator-pagespeed-ngx/archive/refs/tags/v1.13.35.2-stable.tar.gz tar -xzf v1.13.35.2-stable.tar.gz mv incubator-pagespeed-ngx-1.13.35.2-stable ngx_pagespeed # 7. 下载并编译 Brotli（pagespeed 1.13.35.2 的硬依赖） wget https://github.com/google/brotli/archive/refs/tags/v1.0.9.tar.gz tar -xzf v1.0.9.tar.gz && cd brotli-1.0.9 ./configure-cmake && make && make install cd .. # 8. 安装精确版本的图像库（解决 PNG/JPEG 兼容性） yum remove -y libpng-devel libjpeg-turbo-devel libtiff-devel yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libpng-devel-1.6.37-1.el7_9.x86_64.rpm yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libjpeg-turbo-devel-1.5.3-10.el7_9.x86_64.rpm yum install -y https://vault.centos.org/7.9.2009/os/x86_64/Packages/libtiff-devel-4.0.3-35.el7_9.x86_64.rpm # 9. 验证 Brotli 是否正确安装（关键检查点） ldconfig -p | grep brotli # 正常输出应包含：libbrotlienc.so.1 (libc6,x86-64) => /usr/local/lib/libbrotlienc.so.1 # 10. 进入 Nginx 源码目录，准备 configure cd nginx-1.20.2

注意：第 1 步关闭 SELinux 是必须的。我曾在一个政府项目中保留 SELinux enforcing 模式，pagespeed 启动后pagespeed Statistics页面始终 500 错误，/var/log/nginx/error.log里全是avc: denied { read } for pid=1234 comm="nginx" name="pagespeed" dev="dm-0" ino=123456 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file。这是 SELinux 策略阻止 nginx 进程读取 pagespeed 的共享内存文件。setenforce 0是最快解法，若必须开启 SELinux，则需编写自定义策略模块，耗时 2 小时以上，得不偿失。

4.2 configure 与 make：一行命令定生死

进入nginx-1.20.2目录后，执行以下configure命令。这是整个流程中最关键的一行，任何参数错误都会导致后续make失败：

./configure \ --prefix=/etc/nginx \ --sbin-path=/usr/sbin/nginx \ --modules-path=/usr/lib64/nginx/modules \ --conf-path=/etc/nginx/nginx.conf \ --error-log-path=/var/log/nginx/error.log \ --http-log-path=/var/log/nginx/access.log \ --pid-path=/var/run/nginx.pid \ --lock-path=/var/run/nginx.lock \ --http-client-body-temp-path=/var/cache/nginx/client_temp \ --http-proxy-temp-path=/var/cache/nginx/proxy_temp \ --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \ --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \ --http-scgi-temp-path=/var/cache/nginx/scgi_temp \ --user=nginx \ --group=nginx \ --with-compat \ --with-file-aio \ --with-threads \ --with-http_addition_module \ --with-http_auth_request_module \ --with-http_dav_module \ --with-http_flv_module \ --with-http_gunzip_module \ --with-http_gzip_static_module \ --with-http_mp4_module \ --with-http_random_index_module \ --with-http_realip_module \ --with-http_secure_link_module \ --with-http_slice_module \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-http_v2_module \ --with-mail \ --with-mail_ssl_module \ --with-stream \ --with-stream_realip_module \ --with-stream_ssl_module \ --with-stream_ssl_preread_module \ --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions' \ --with-ld-opt='-Wl,-z,relro -Wl,-z,now' \ --add-module=/root/build/ngx_pagespeed

解释几个易错点：

• --modules-path=/usr/lib64/nginx/modules：CentOS 7 的标准模块路径，必须与nginx -V输出一致，否则load_module会找不到文件。
• --with-http_realip_module：前面说过要禁用，但这里先保留，因为--with-http_ssl_module和--with-http_v2_module是强依赖，而realip模块本身不冲突，冲突只发生在 pagespeed 的 IP 解析逻辑里，我们会在 pagespeed 配置中绕过它。
• --with-ld-opt='-Wl,-z,relro -Wl,-z,now'：启用完整的 RELRO（Relocation Read-Only）和 NOW（Immediate Binding）链接选项，这是 CentOS 7 安全基线的硬性要求，能防止 GOT（Global Offset Table）劫持攻击。

执行完configure后，你会看到类似输出：

Configuration summary + using system PCRE library + using system OpenSSL library + using system zlib library + using system Brotli library + pagespeed is enabled + threads are enabled

重点看最后两行：pagespeed is enabled和using system Brotli library必须同时出现，缺一不可。如果只有pagespeed is enabled而没有 Brotli 行，说明libbrotlienc.so未被正确识别，需检查ldconfig -p | grep brotli输出。

接下来执行编译：

# 使用 2 核并行编译（Minimal 版本默认 2 vCPU，太多会 OOM） make -j2 # 编译成功后，安装到系统 make install

make -j2通常耗时 8-12 分钟。期间你会看到 GCC 编译ngx_pagespeed/psol子模块的日志，其中psol是用 C++11 编写的庞大优化库，占整个编译时间的 70%。如果卡在psol阶段超过 15 分钟，大概率是内存不足——CentOS 7 Minimal 默认只分配 1GB 内存，而psol编译峰值内存占用达 1.8GB。解决方案：swapoff -a && dd if=/dev/zero of=/swapfile bs=1G count=2 && mkswap /swapfile && swapon /swapfile，临时增加 2GB 交换空间。

4.3 配置 pagespeed：一份可直接上线的 nginx.conf 片段

编译安装完成后，Nginx 二进制文件已就位，但 pagespeed 还处于“待激活”状态。你需要在/etc/nginx/nginx.conf的http{}块内添加以下配置。这不是示例，是我在 37 个生产站点上验证过的最小可行配置：

# ========== Pagespeed 核心配置 ========== # 启用 pagespeed 模块（必须放在 http 块顶部） pagespeed on; # 设置 pagespeed 的缓存目录（必须是 nginx 用户可写） pagespeed FileCachePath "/var/cache/ngx_pagespeed/"; pagespeed FileCacheSizeKb 102400; pagespeed FileCacheCleanIntervalMs 3600000; pagespeed FileCacheInodeLimit 500000; # 启用最关键的 5 个过滤器（平衡效果与稳定性） pagespeed EnableFilters collapse_whitespace,remove_comments,rewrite_css,rewrite_javascript,convert_png_to_jpeg; # 针对图片优化的精细控制 pagespeed RewriteLevel CoreFilters; pagespeed EnableFilters convert_jpeg_to_webp; pagespeed EnableFilters convert_to_webp_lossless; pagespeed JpegQualityForWebp 85; pagespeed WebpQualityForSmallScreens 75; # 启用 Brotli 压缩（pagespeed 1.13.35.2 新增） pagespeed EnableFilters extend_cache,combine_css,combine_javascript; pagespeed EnableFilters rewrite_images; pagespeed ImageRecompressionLevel 80; # 统计页面（仅限内网访问，生产环境必须限制） location ~ "^/pagespeed_admin" { allow 127.0.0.1; allow 192.168.1.0/24; # 替换为你的运维网段 deny all; pagespeed Statistics on; } location ~ "^/pagespeed_global_admin" { allow 127.0.0.1; deny all; pagespeed GlobalStatistics on; } # ========== Pagespeed 安全加固 ========== # 禁用 realip 模块的 IP 覆盖，改用 X-Forwarded-For pagespeed XHeaderValue "X-Forwarded-For"; # 防止 pagespeed 对敏感路径进行重写（如 /wp-admin/） pagespeed Disallow "*/wp-admin/*"; pagespeed Disallow "*/wp-includes/*"; pagespeed Disallow "*/api/*"; # 设置 pagespeed 的日志级别（上线后调为 warn，调试时用 info） pagespeed LogDir "/var/log/nginx/pagespeed/"; pagespeed StatisticsLogging on; pagespeed StatisticsLoggingIntervalMs 60000;

关键配置说明：

• FileCachePath "/var/cache/ngx_pagespeed/"：必须手动创建并授权。执行mkdir -p /var/cache/ngx_pagespeed && chown nginx:nginx /var/cache/ngx_pagespeed，否则 pagespeed 启动时报failed to create cache directory。
• Convert_png_to_jpeg：PNG 转 JPEG 是 pagespeed 最“激进”的优化，但它能将 PNG 图片体积平均减少 65%。我测试过 1200 张 PNG，只有 3 张因 Alpha 通道丢失导致视觉异常，可通过pagespeed DisableFilters convert_png_to_jpeg;单独关闭。
• JpegQualityForWebp 85：WebP 压缩质量设为 85，这是 PSNR（峰值信噪比）与体积的最优交点。低于 75 会出现明显色块，高于 90 体积增长 40% 但肉眼无差别。
• Disallow规则：WordPress 站点必须加上*/wp-admin/*，否则 pagespeed 会重写/wp-admin/load-styles.php的 CSS URL，导致后台样式全部丢失。

4.4 启动与验证：三步确认 pagespeed 真正生效

配置完成后，执行以下三步验证，缺一不可：

第一步：语法检查与平滑重启

# 检查 nginx 配置语法 nginx -t # 正常输出：nginx: the configuration file /etc/nginx/nginx.conf syntax is ok # nginx: configuration file /etc/nginx/nginx.conf test is successful # 平滑重启（不中断现有连接） nginx -s reload

第二步：检查 pagespeed 模块是否加载

# 查看 nginx 加载的模块列表 nginx -V 2>&1 | grep -o "pagespeed" # 正常输出：pagespeed （出现即表示模块已编译进二进制） # 查看 pagespeed 运行时状态 curl -I http://localhost/ | grep X-Page-Speed # 正常输出：X-Page-Speed: 1.13.35.2-0

第三步：真实流量验证（最可靠）打开 Chrome 浏览器，访问你的站点，按 F12 打开开发者工具，切换到 Network 标签页，刷新页面。在请求列表中找一个.css文件，点击它，在 Headers 标签页中查找Content-Encoding字段：

• 如果看到br，说明 Brotli 压缩生效；
• 如果看到x-page-speed字段，且值为1.13.35.2-0，说明 pagespeed 正在工作；
• 点击一个.jpg图片请求，在 Response Headers 中查看X-Original-Content-Length和Content-Length，如果后者明显小于前者（如 120KB → 45KB），说明 WebP 转换成功。

实操心得：我曾遇到curl -I能看到X-Page-Speed，但浏览器 Network 里看不到，最终发现是 Cloudflare 的代理缓存了旧的index.html，里面<link>标签引用的 CSS 还是未优化的 URL。解决方案：在 Cloudflare 控制台清空整个站点缓存，或临时将域名 DNS 解析直连服务器 IP 进行验证。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在敲命令的坑

5.1 编译阶段典型故障与速查表