Nginx与Memcache、Gunzip及SSI模块协同工作异常问题排查

我来帮你揪出这个SSI失效的元凶！结合你的配置和Nginx模块的执行逻辑来看，问题大概率出在模块执行顺序和内容识别条件上——咱们一步步拆解：

核心原因分析 #

Nginx的各个模块是按阶段执行的：

• memcached_pass属于content阶段，直接从缓存拉取内容
• gunzip是filter阶段，负责解压内容
• ssi也是filter阶段，但它只会处理text/html类型且未压缩的内容

你的问题可能是这几个情况：

1. Gunzip没触发解压：如果Memcached返回的内容标记（flag）没被正确识别，或者响应头里没有Content-Encoding: gzip，gunzip模块就不会工作，SSI处理的就是压缩后的乱码，自然失效。
2. SSI没识别到正确的内容类型：memcached模块默认只返回body内容，若Nginx设置的default_type没生效，或者Content-Type不是text/html，SSI模块会直接跳过处理。
3. 模块执行顺序颠倒：如果SSI filter在gunzip filter之前执行，它会先处理压缩的乱码内容，直接失效。

修复后的配置示例 #

直接给你调整好的配置，每一步都加了注释：

location / {
    # 开启SSI，并明确指定处理的内容类型，避免类型不匹配跳过
    ssi on;
    ssi_types text/html;

    # Memcached相关配置
    set $memcached_key "$uri?$args";
    memcached_pass memcached.up;
    # 对应net.spy.memcached的压缩标记，确保Nginx识别到这是gzip内容
    memcached_gzip_flag 2;

    # 强制设置内容类型，确保SSI模块能识别
    default_type text/html;
    charset utf-8;

    # 开启gunzip，并配置足够的缓冲避免解压不完整
    gunzip on;
    gunzip_buffers 4 4k;

    # 强制添加Content-Type头，覆盖可能的异常响应头
    add_header Content-Type text/html always;
}

额外排查要点 #

除了配置，还要检查Memcached端的存储是否正确：

• 确认用net.spy.memcached存储时，是否开启了压缩选项，并且flag的第二字节确实是2（对应gzip压缩标记）。
• 手动解压Memcached中的内容，看看是不是包含正确的SSI标签（比如<!--#include virtual="/sidebar.html" -->），确保原内容没问题。
• 可以开启Nginx的debug日志（error_log /var/log/nginx/error.log debug;），查看日志里有没有ssi相关的处理记录，以及gunzip是否成功触发。

验证方法 #

修改配置后重启Nginx，然后：

1. 用curl -I访问页面，看响应头里有没有Content-Encoding（如果gunzip生效，这个头会被移除，返回解压后的内容）。
2. 查看页面源码，确认SSI标签已经被替换成实际内容，而不是原样输出。

内容的提问来源于stack exchange，提问作者demon101