nginx 默认不压缩 xml 文件，因 text/xml 不在 gzip_types 默认列表中，需手动添加 text/xml、application/xml 等类型并验证响应头与大小。
Gzip 压缩 XML 文件在 Nginx 下默认不生效，因为 text/xml 不在 Nginx 默认的 gzip_types 列表里，必须显式添加。
为什么 text/xml 需要手动加进 gzip_types
Nginx 的 gzip_types 默认只包含常见 MIME 类型（如 text/plain、text/css、application/javascript），text/xml 被排除在外——哪怕你配了 gzip on，XML 也不会被压缩。
- 浏览器请求带
Accept-Encoding: gzip没用，Nginx 根本不匹配 MIME 类型 - 用
curl -H "Accept-Encoding: gzip" -I http://example.com/data.xml查看响应头，Content-Encoding: gzip不会出现 - 常见场景：后端吐出的
.xml接口、Sitemap 文件、SOAP 响应体
如何正确配置 gzip_types 支持 XML
在 http、server 或 location 块中补全类型声明，注意顺序和继承关系：
- 必须写成
gzip_types text/xml application/xml application/rss+xml;（application/xml更常用，建议一并加上） - 不要只写
text/xml—— 很多 XML 响应实际返回的是application/xml，比如 Spring Boot 默认、PHPheader('Content-Type: application/xml') - 如果用了
gzip_vary on（推荐开启），Nginx 会加Vary: Accept-Encoding头，避免 CDN 或代理缓存错乱 - 确保
gzip_min_length不设得过高（默认 20 字节足够，XML 文件通常远超此值）
验证是否真正生效的三步检查法
别只信配置文件，实测才可靠：
- 用
curl -H "Accept-Encoding: gzip" -s -D - http://localhost/data.xml -o /dev/null看响应头里有没有Content-Encoding: gzip - 对比响应体大小：
curl -s http://localhost/data.xml | wc -cvscurl -H "Accept-Encoding: gzip" -s http://localhost/data.xml | gunzip | wc -c，两者应明显不同 - 检查 Nginx error log：若配置语法错误（比如漏分号、类型名拼错），会报
unknown directive "gzip_types"或类似提示
容易被忽略的兼容性细节
XML 压缩本身没问题，但下游系统可能对压缩后的响应更敏感：
- 老版本 IE（≤8）处理
Content-Encoding: gzip+Content-Type: application/xml时偶发解析失败，现代环境基本无碍 - 某些 XML 解析库（如 Python 的
xml.etree.ElementTree）不自动解压，需自行调用gzip.decompress()；而浏览器、curl、大多数 HTTP 客户端会自动解压 - 如果 XML 是通过
XSLT或前端 JS 动态加载的，确保XMLHttpRequest或fetch()没有禁用自动解压（默认都开启）
最常卡住的地方不是配置语法，而是没意识到 Nginx 默认根本不碰 text/xml——它连试都不试，所以日志里也看不到压缩相关记录。
