msie_padding用于解决IE5.5–IE6对短响应体的解析缺陷，通过在响应末尾追加最多128字节空格规避截断问题，仅对匹配MSIE 5.5–6.x的请求生效且仅作用于非chunked响应。
这行配置是 Nginx 中专为老旧浏览器做的“兼容性兜底”——它不追求性能，而是确保页面能正常打开。
为什么专门屏蔽 IE 1–6？
IE6 及更早版本对 HTTP 响应头中 Vary: Accept-Encoding 的解析存在严重缺陷。当服务器返回 gzip 压缩内容并带上该响应头时，IE6 会错误地缓存压缩后的二进制数据，后续请求直接复用，导致页面显示乱码或空白。这不是压缩本身的问题，而是其缓存机制与现代压缩协商逻辑冲突。
这类浏览器早已停止更新、无安全补丁、不支持 HTTPS 现代特性，生产环境已无需主动服务，但若仍有极少量用户访问，宁可牺牲带宽也不应让用户看到不可用的页面。
正则表达式 "MSIE [1-6]\." 的实际匹配效果
该正则会精准命中以下典型 User-Agent 片段：
- MSIE 6.（IE6）
- MSIE 5.5 或 MSIE 5.01（IE5.x）
- MSIE 4.0（IE4）甚至更早（如 MSIE 2.0）
注意：不匹配 IE7+、Edge、Chrome 内核的 IE 兼容模式，也不影响现代 UA 字符串中偶然含 “MSIE” 的情况（如某些爬虫或测试工具），因为后面紧跟的是空格 + 数字 + 点号，结构严格。
它不是“禁用 Gzip”，而是“跳过压缩”
gzip_disable 不会关闭整个 Gzip 模块，它只对匹配到的请求临时绕过压缩流程，原样返回未压缩资源。其他所有客户端（包括 Chrome、Firefox、Safari、Edge、移动端 WebView）仍享受完整 Gzip 加速。
这意味着：
- 服务器 CPU 负担不受影响（IE6 请求不走压缩路径）
- 静态资源缓存策略、HTTP/2、HTTPS 等其他优化照常生效
- 你无需为 IE6 单独准备一套未压缩资源文件
生产部署建议
当前（2026 年）绝大多数真实业务已可安全移除此配置，但若需保留兜底：
- 放在 http 或 server 块顶层，避免被 location 覆盖
- 配合 gzip_vary on 使用，确保代理层（如 CDN）正确缓存不同编码版本
- 不要叠加写成
gzip_disable "MSIE [1-6]\."; gzip_disable "Trident/.*";—— 重复指令会被后一条覆盖，且 Trident 是 IE7+ 的内核标识，不应误伤 - 日志中可通过
$http_user_agent字段统计匹配量，若长期为 0，即可下线
