Nginx 参数解析
约 5199 字大约 17 分钟
2025-10-24
参数解析
http
http 块是 Nginx 中用于配置 HTTP 服务器相关所有设置的容器指令，它定义了 Web 服务器的全局行为和默认值。
配置结构
# 全局配置（main context）
user nginx;
worker_processes auto;
http {
# HTTP 服务器全局配置
include /etc/nginx/mime.types;
default_type application/octet-stream;
# 日志格式
log_format main '$remote_addr - $remote_user ...';
# 服务器配置
server {
listen 80;
server_name example.com;
# 虚拟主机配置...
}
server {
listen 80;
server_name api.example.com;
# 另一个虚拟主机...
}
}主要作用
定义全局默认值
- 所有
server块继承http块的配置 - 提供统一的基准配置
包含多个服务器
- 可以包含多个
server块（虚拟主机） - 每个
server处理不同的域名或端口
配置共享资源
- 日志格式、MIME 类型、超时设置等
- 上游服务器定义（upstream）
包含的主要配置类别
| 类别 | 示例指令 | 作用 |
|---|---|---|
| 基础配置 | include, default_type | 基本设置和文件包含 |
| 性能优化 | sendfile, gzip, keepalive_timeout | 服务器性能调优 |
| 日志配置 | access_log, error_log, log_format | 访问和错误日志 |
| 超时控制 | client_timeout, send_timeout | 各种超时设置 |
| 缓冲区 | client_body_buffer_size | 请求缓冲区设置 |
| 上游服务 | upstream | 负载均衡后端定义 |
| 服务器定义 | server | 虚拟主机配置 |
继承机制
http {
# 全局设置，所有server继承
gzip on;
keepalive_timeout 65s;
server {
# 可以覆盖全局设置
server_name site1.com;
keepalive_timeout 30s; # 覆盖为30秒
}
server {
# 继承全局的65秒超时
server_name site2.com;
}
}模块化配置
http {
# 引入外部配置文件
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
# 主配置文件中只保留核心设置
}配置层次结构
nginx.conf
├── main context (全局设置)
└── http block (HTTP服务器设置)
├── upstream blocks (上游服务器)
├── server blocks (虚拟主机)
│ ├── location blocks (URL路径)
│ └── location blocks
└── server blocks配置集中化：所有 HTTP 相关配置在一个地方管理
维护方便：修改全局设置影响所有虚拟主机
性能优化：在合适的作用域设置性能参数
灵活扩展：可以轻松添加新的虚拟主机
include
include 指令允许在一个配置文件中包含并加载其他配置文件，实现配置的模块化和复用。
include file_pattern;file_pattern：文件路径，支持通配符
基本包含
# 主配置文件 nginx.conf
http {
include /etc/nginx/mime.types; # 包含 MIME 类型配置
include /etc/nginx/conf.d/*.conf; # 包含所有 .conf 文件
}通配符使用
# 包含多个目录
include /etc/nginx/sites-enabled/*; # 虚拟主机配置
include /etc/nginx/conf.d/*.conf; # 通用配置片段
include /etc/nginx/modules-enabled/*.conf; # 模块配置相对路径
# 相对于 nginx.conf 所在目录
include conf.d/*.conf;
include sites-enabled/*;配置模块化
# nginx.conf - 主配置文件
http {
include config/gzip.conf; # 压缩配置
include config/security.conf; # 安全配置
include config/proxy.conf; # 代理配置
include sites/*.conf; # 站点配置
}配置复用
# common.conf - 通用配置
gzip on;
gzip_types text/plain text/css application/json;
# 多个服务器块复用通用配置
server {
include common.conf;
server_name site1.com;
}
server {
include common.conf;
server_name site2.com;
}环境特定配置
# 根据环境加载不同配置
http {
include config/common.conf;
# 开发环境
include config/development.conf;
# 生产环境（注释掉上面的，取消注释下面的）
# include config/production.conf;
}实际目录结构示例
/etc/nginx/
├── nginx.conf # 主配置文件
├── conf.d/
│ ├── gzip.conf # 压缩配置
│ ├── security.conf # 安全头配置
│ └── proxy.conf # 代理设置
├── sites-available/ # 可用的站点配置
│ ├── example.com.conf
│ └── api.example.com.conf
├── sites-enabled/ # 启用的站点配置（符号链接）
│ ├── example.com.conf -> ../sites-available/example.com.conf
│ └── api.example.com.conf -> ../sites-available/api.example.com.conf
└── modules-enabled/ # 模块配置
└── ngx_http_geoip.conf典型 nginx.conf 结构
# 主配置文件
user www-data;
worker_processes auto;
events {
worker_connections 768;
}
http {
# 基础配置
include /etc/nginx/mime.types;
include /etc/nginx/conf.d/*.conf;
# 虚拟主机配置
include /etc/nginx/sites-enabled/*;
}优势好处
- 维护性：配置分散到多个小文件，易于管理
- 可读性：功能相关的配置集中在一起
- 复用性：通用配置可以多处引用
- 灵活性：轻松启用/禁用特定配置
- 团队协作：不同人员负责不同配置文件
注意事项
- 加载顺序：文件按字母顺序加载，后面的配置可能覆盖前面的
- 错误处理：如果包含的文件不存在，Nginx 会启动失败
- 循环包含：避免配置文件相互包含形成循环
- 权限问题：确保 Nginx 进程有读取包含文件的权限
生产环境最佳实践
# 主配置文件保持简洁
http {
# 基础设置
include /etc/nginx/conf.d/base.conf;
# 性能优化
include /etc/nginx/conf.d/performance.conf;
# 安全设置
include /etc/nginx/conf.d/security.conf;
# 各站点配置
include /etc/nginx/sites-enabled/*.conf;
# 默认服务器（放在最后）
include /etc/nginx/conf.d/default_server.conf;
}default_type
default_type 定义了当 Nginx 无法确定文件的确切 MIME 类型时使用的默认内容类型。
default_type mime_type;
# 默认值 text/plain;基本配置
http {
# 设置默认 MIME 类型为纯文本
default_type text/plain;
# 或者设置为二进制流（更安全）
default_type application/octet-stream;
}配合 mime.types 文件
http {
# 包含 MIME 类型定义
include /etc/nginx/mime.types;
# 设置默认类型（当 mime.types 中找不到匹配时使用）
default_type application/octet-stream;
}请求处理流程：
客户端请求文件 → Nginx 查找文件扩展名
↓
在 mime.types 中匹配类型 → 找到 → 使用匹配的 MIME 类型
↓
未找到 → 使用 default_type 指定的类型未知文件类型
# 对于没有扩展名或未知扩展名的文件
location /downloads/ {
default_type application/octet-stream; # 作为二进制流下载
}动态内容
# 对于动态生成的内容
location /api/ {
default_type application/json; # 默认返回 JSON
}安全考虑
# 避免浏览器错误解析未知文件
default_type application/octet-stream; # 强制下载而不是执行常用 MIME 类型
| MIME 类型 | 说明 | 适用场景 |
|---|---|---|
text/plain | 纯文本 | 日志文件、配置文件 |
text/html | HTML 文档 | 网页文件 |
application/octet-stream | 二进制流 | 下载文件、未知类型 |
application/json | JSON 数据 | API 响应 |
text/xml | XML 文档 | 数据交换 |
生产环境推荐配置
http {
# 包含标准 MIME 类型定义
include /etc/nginx/mime.types;
# 设置安全的默认类型（强制下载而不是执行）
default_type application/octet-stream;
server {
location / {
# 对于已知类型，使用正确的 MIME 类型
# 对于未知类型，使用 application/octet-stream
}
location /api/ {
# API 接口默认返回 JSON
default_type application/json;
}
}
}注意事项
- 安全考虑：使用
application/octet-stream比text/plain更安全，避免浏览器错误解析 - 浏览器行为：不同的 MIME 类型会影响浏览器如何处理内容
- 与 mime.types 配合：通常与
include mime.types一起使用 - 位置作用域：可以在
http、server、location不同作用域设置
当访问未知类型文件时：
default_type text/plain→ 浏览器尝试显示文本内容default_type application/octet-stream→ 浏览器弹出下载对话框
log_format
这是一个 Nginx 的 日志格式配置，用于定义访问日志的记录格式。
定义 Nginx 访问日志中每条记录包含哪些信息和排列顺序。
各变量含义
| 变量 | 说明 |
|---|---|
$remote_addr | 客户端 IP 地址 |
$remote_user | 认证用户名（基本认证） |
$time_local | 访问时间和时区 |
$request | 请求方法 + URL + 协议版本 |
$status | HTTP 状态码 |
$body_bytes_sent | 发送给客户端的字节数 |
$http_referer | 来源页面 URL |
$http_user_agent | 客户端浏览器信息 |
$http_x_forwarded_for | 代理链中的客户端真实 IP |
启用日志格式（去掉注释）：
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';在 server 或 http 块中应用：
access_log /var/log/nginx/access.log main;实际日志示例
192.168.1.100 - - [25/Dec/2023:10:30:45 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" "192.168.1.1"rewrite_log
开启 URL 重写相关的调试日志，用于调试 rewrite 规则。
rewrite_log on | off;server {
rewrite_log on;
error_log /var/log/nginx/error.log notice; # 必须配合适当的错误日志级别
location / {
rewrite ^/old-url$ /new-url permanent;
rewrite ^/test/(.*)$ /new-test/$1 last;
}
}在 error_log 中会看到类似信息：
2023/12/25 10:30:45 [notice] 1234#0: *1 "^/old-url$" matches "/old-url", client: 192.168.1.100, server: example.com, request: "GET /old-url HTTP/1.1", host: "example.com"
2023/12/25 10:30:45 [notice] 1234#0: *1 rewritten data: "/new-url", args: "", client: 192.168.1.100, server: example.com, request: "GET /old-url HTTP/1.1", host: "example.com"注意事项
- 日志级别：需要将
error_log级别设置为notice或info才能看到重写日志 - 性能影响：生产环境建议关闭，仅在调试时开启
- 日志位置：重写日志会输出到
error_log，而不是access_log
使用场景
- 调试复杂的重写规则
- 排查 URL 重定向问题
- 理解重写规则的执行顺序
error_log
error_log 文件路径 日志级别;
error_log file [level];file：日志文件路径或特殊值
- 路径：
/var/log/nginx/error.log - 特殊值：
stderr：输出到标准错误syslog:server=address：发送到 syslogmemory:size：缓存到内存
level：日志过滤级别（从严格到宽松）
debug- 最详细（需编译时开启调试）info- 基本信息notice- 正常但重要的事件warn- 警告信息error- 错误信息（默认级别）crit- 严重错误alert- 需要立即行动emerg- 系统不可用
示例
# 使用默认错误级别 (error)
error_log /var/log/nginx/error.log;
# 指定警告及以上级别
error_log /var/log/nginx/error.log warn;
# 调试时使用更详细级别
error_log /var/log/nginx/error.log debug;不同作用域配置
# 全局配置（main 作用域）
error_log /var/log/nginx/error.log warn;
http {
# HTTP 块级别
error_log /var/log/nginx/http_error.log info;
server {
# 虚拟主机级别
error_log /var/log/nginx/example.com_error.log notice;
location /debug/ {
# 位置块级别（仅支持指定级别，不能改变文件）
error_log notice;
}
}
}特殊输出目标
# 输出到标准错误
error_log stderr;
# 发送到 syslog
error_log syslog:server=192.168.1.10:514;
# 缓存到内存（32k大小）
error_log memory:32k debug;sendfile
sendfile 是一个系统调用，允许在内核空间直接从一个文件描述符向另一个文件描述符传输数据，完全绕过用户空间。
sendfile on | off;传统方式（sendfile off）
应用进程 (Nginx)
↓
用户空间缓冲区 (read)
↓
内核缓冲区 (从磁盘读取)
↓
用户空间缓冲区 (write)
↓
内核缓冲区 (发送到网络)
↓
客户端Sendfile 方式（sendfile on）
应用进程 (Nginx)
↓
系统调用 sendfile()
↓
内核直接处理
↓ (零拷贝)
客户端优势：2次上下文切换 + 1次数据拷贝
基本配置
http {
sendfile on;
server {
listen 80;
# 其他配置...
}
}配合其他优化参数
http {
sendfile on;
tcp_nopush on; # 在sendfile开启时优化网络包
tcp_nodelay on; # 针对小文件实时传输
# 静态文件服务优化
server {
listen 80;
location /static/ {
sendfile on;
tcp_nopush on;
# 其他静态文件配置...
}
}
}推荐开启的场景
静态文件服务（CSS、JS、图片等）
大文件下载
视频流媒体
任何需要高效文件传输的场景
可能不适用的情况
- 需要内容修改的文件传输
- 某些特殊的代理场景
- 老旧系统兼容性考虑
性能优势
- 减少CPU占用：避免用户空间和内核空间之间的数据拷贝
- 减少内存占用：不需要在用户空间分配缓冲区
- 提高吞吐量：更少的上下文切换和系统调用
- 降低延迟：数据传输路径更短
实际测试数据
在典型的静态文件服务器上：
- CPU使用率：降低 20-30%
- 吞吐量：提升 15-25%
- 内存使用：减少 40-50%
注意事项
操作系统支持：需要操作系统支持 sendfile 系统调用
- Linux 2.4+ 原生支持
- FreeBSD、macOS 也支持
网络环境：在高延迟网络中效果更明显
文件大小：对大文件优化效果更显著
配合其他优化：
location /download/ { sendfile on; aio on; # 异步IO directio 4m; # 大文件直接IO output_buffers 1 128k; }
生产环境建议
http {
# 全局开启 sendfile
sendfile on;
# 针对大文件进一步优化
location ~* \.(mp4|avi|zip|tar)$ {
sendfile on;
tcp_nopush on;
# 大文件专用配置...
}
# 针对小文件实时性优化
location ~* \.(html|css|js)$ {
sendfile on;
tcp_nodelay on;
}
}总之，sendfile on 是 Nginx 性能调优的必备选项，对于静态文件服务能带来显著的性能提升。
tcp_nopush
tcp_nopush 实际上是设置了 TCP 的 TCP_CORK 选项（在 Linux 下），它的主要作用是减少网络中小数据包的数量。
tcp_nopush on | off;默认值：tcp_nopush off
当 tcp_nopush on 时：
内核会累积数据，直到满足以下条件之一才发送：
- 数据包达到 MSS（最大报文段长度）
- 收到对方的 ACK
- 超时（一般为 200ms）
- 明确取消
CORK状态
当 tcp_nopush off 时：
- 有数据就立即发送，不等待填满数据包
推荐开启的场景
- 静态大文件传输（图片、视频、下载文件）
- 高吞吐量服务
- 带宽敏感的环境
- 与
sendfile on配合使用时
不建议开启的场景
- 实时应用（如 SSH、游戏）
- 交互式应用
- 小文件频繁请求
与相关指令的关系
tcp_nopush 和 tcp_nodelay
| 特性 | tcp_nopush | tcp_nodelay |
|---|---|---|
| 目的 | 减少包数量 | 降低延迟 |
| 机制 | 累积数据填满包 | 禁用 Nagle 算法 |
| 适用 | 大文件传输 | 实时交互 |
| 效果 | 提高带宽利用率 | 减少传输延迟 |
推荐组合配置
http {
# 场景1：静态文件服务器（推荐）
sendfile on;
tcp_nopush on; # 填满数据包再发送
tcp_nodelay off; # 允许一定的延迟以填满包
# 场景2：API/实时服务
sendfile off;
tcp_nopush off; # 立即发送
tcp_nodelay on; # 禁用Nagle，降低延迟
}开启 tcp_nopush 的优势：
- 减少网络包数量：提高网络利用率
- 降低协议开销：减少 TCP/IP 头部的开销
- 提高带宽利用率：更有效地使用可用带宽
- 减少系统调用：合并多个小写操作
可能的缺点：
- 增加延迟：数据可能等待更长时间才发送
- 不适合实时应用：对延迟敏感的应用不友好
实际网络包示例
未开启 tcp_nopush：
[小包1] → [小包2] → [小包3] → [小包4] → ...
（多个小网络包）开启 tcp_nopush：
[=========大包1=========] → [=========大包2=========] → ...
（较少的大网络包）生产环境配置建议
http {
# 全局配置 - 适合大多数Web场景
sendfile on;
tcp_nopush on;
# 针对不同内容类型优化
server {
# 静态资源 - 最大化带宽利用
location ~* \.(jpg|png|gif|css|js|pdf)$ {
sendfile on;
tcp_nopush on;
tcp_nodelay off;
expires 30d;
}
# API接口 - 低延迟优先
location /api/ {
sendfile off;
tcp_nopush off;
tcp_nodelay on;
}
# 大文件下载
location /downloads/ {
sendfile on;
tcp_nopush on;
tcp_nodelay off;
aio on;
}
}
}注意事项
- 需要 sendfile 支持：
tcp_nopush与sendfile on配合效果最佳 - Linux 系统：在 Linux 下实现为
TCP_CORK - FreeBSD：在 FreeBSD 下是原生的
tcp_nopush - 监控效果：使用网络监控工具观察包大小分布
keepalive_timeout
keepalive_timeout 用于设置服务器在关闭 keepalive 连接之前等待下一个请求的最长时间。
keepalive_timeout timeout [header_timeout];- timeout：连接保持时间（秒）
- header_timeout：（可选）在响应头中设置的 Keep-Alive 超时时间
工作原理
没有 Keep-Alive
客户端 → 请求1 → 服务器 → 响应1 → 关闭连接
客户端 → 请求2 → 服务器 → 响应2 → 关闭连接
（每次请求都建立新连接）有 Keep-Alive
客户端 → 请求1 → 服务器 → 响应1 → （连接保持）
客户端 → 请求2 → 服务器 → 响应2 → （连接保持）
...（在超时时间内可复用连接）基本配置
http {
# 保持连接 30 秒
keepalive_timeout 30s;
server {
listen 80;
# 其他配置...
}
}设置不同的超时时间
http {
# 保持 60 秒，在响应头中告诉客户端超时为 50 秒
keepalive_timeout 60s 50s;
}针对不同服务器配置
http {
keepalive_timeout 65s;
server {
listen 80;
server_name example.com;
keepalive_timeout 30s; # 这个站点30秒超时
}
server {
listen 80;
server_name api.example.com;
keepalive_timeout 10s; # API站点10秒超时
}
}超时时间选择
| 超时时间 | 适用场景 | 优缺点 |
|---|---|---|
0 | 禁用 Keep-Alive | 避免连接占用，但性能差 |
5s-15s | 高并发API服务 | 快速释放连接，减少资源占用 |
30s-60s | 一般Web应用 | 平衡性能和资源 |
60s+ | 静态资源/CDN | 最大化连接复用 |
第二个参数的作用
keepalive_timeout 60s 50s;这会在响应头中返回：
Keep-Alive: timeout=50告诉客户端服务器期望的超时时间，但服务器实际会使用 60 秒。
性能影响
适当超时时间的优势：
- 减少TCP握手：降低连接建立开销
- 降低延迟：后续请求无需握手
- 提高吞吐量：更高效的连接利用
- 减少资源消耗：减少端口和内存使用
超时过长的缺点：
- 连接资源占用：空闲连接占用服务器资源
- 服务器负载：可能达到连接数上限
- 内存消耗：每个连接都需要内存维护
超时过短的缺点：
- 频繁重建连接：增加TCP握手开销
- 性能下降：无法充分利用持久连接
配合 keepalive_requests
http {
keepalive_timeout 60s;
keepalive_requests 100; # 每个连接最多处理100个请求
}完整连接优化配置
http {
# 连接保持配置
keepalive_timeout 60s;
keepalive_requests 100;
# TCP层优化
tcp_nodelay on;
tcp_nopush on;
# 连接限制
client_header_timeout 15s;
client_body_timeout 15s;
send_timeout 15s;
}常规Web服务器
http {
keepalive_timeout 65s;
keepalive_requests 100;
}高并发API服务
http {
keepalive_timeout 15s;
keepalive_requests 1000; # 每个连接处理更多请求
}静态资源服务器
http {
keepalive_timeout 120s;
keepalive_requests 500;
}负载均衡器
http {
keepalive_timeout 75s;
keepalive_requests 100;
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
# 到后端服务器的keepalive连接
keepalive 32;
}
}查看连接状态
# 查看 Keep-Alive 连接
netstat -an | grep :80 | grep ESTABLISHED
# 使用 nginx status 模块
curl http://localhost/nginx_status在 access_log 中观察连接复用情况：
192.168.1.100 - - [25/Dec/2023:10:30:45 +0800] "GET /style.css HTTP/1.1" 200 1234
192.168.1.100 - - [25/Dec/2023:10:30:46 +0800] "GET /script.js HTTP/1.1" 200 5678
# 同一客户端IP在短时间内多次请求，说明连接复用注意事项
- 客户端行为：实际超时取决于客户端和服务器中的较小值
- 负载均衡：上游服务器也需要适当配置 keepalive
- 超时协调：与
client_header_timeout、client_body_timeout协调配置 - 资源监控：监控服务器连接数，避免连接耗尽
gzip
gzip 通过对 HTTP 响应内容进行压缩，减少传输数据大小，提高页面加载速度。
gzip on | off;默认值：gzip off
基本配置
http {
# 开启 gzip 压缩
gzip on;
# 压缩级别 (1-9)
gzip_comp_level 5;
# 最小压缩长度
gzip_min_length 1024;
# 压缩类型
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}完整优化配置
http {
gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_buffers 16 8k;
gzip_proxied any;
gzip_vary on;
gzip_types
text/plain
text/css
text/xml
text/javascript
application/json
application/javascript
application/xml+rss
application/atom+xml
image/svg+xml;
# 对代理请求也启用压缩
gzip_proxied expired no-cache no-store private auth;
# 禁用 IE6 的 gzip
gzip_disable "MSIE [1-6]\.";
}gzip_comp_level
压缩级别 (1-9)：
1：压缩速度最快，压缩率最低9：压缩速度最慢，压缩率最高- 推荐：
5或6（平衡点）
gzip_comp_level 6;gzip_min_length
启用压缩的最小响应长度：
gzip_min_length 1024; # 小于1KB的内容不压缩gzip_types
指定需要压缩的 MIME 类型：
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml;gzip_buffers
压缩缓冲区设置：
gzip_buffers 16 8k; # 16个8k的缓冲区gzip_vary
添加 Vary: Accept-Encoding 响应头：
gzip_vary on; # 帮助缓存服务器识别压缩内容gzip_proxied
对代理请求的压缩策略：
gzip_proxied any; # 对所有代理请求压缩压缩效果对比
| 文件类型 | 原始大小 | 压缩后大小 | 压缩率 |
|---|---|---|---|
| HTML 文件 | 50KB | 10KB | 80% |
| CSS 文件 | 100KB | 20KB | 80% |
| JavaScript | 200KB | 50KB | 75% |
| JSON 数据 | 150KB | 30KB | 80% |
推荐压缩的内容
- 文本文件：HTML、CSS、JS、JSON、XML
- 代码文件：各种编程语言源代码
- 配置文件：YAML、INI 等
不建议压缩的内容
- 已压缩的文件：图片（JPEG/PNG）、PDF、ZIP
- 小文件：小于 1KB 的文件
- 二进制文件：可执行文件、字体文件
现代浏览器都支持 gzip 压缩：
- Chrome/Firefox/Safari/Edge：完全支持
- IE6+：支持（但 IE6 有问题）
优势：
- 减少带宽使用：节省 60-80% 流量
- 加快页面加载：减少传输时间
- 提升用户体验：特别是移动用户
- 降低服务器负载：减少网络 I/O
代价：
- CPU 开销：压缩需要计算资源
- 轻微延迟：压缩需要时间
通用 Web 服务器
http {
gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml
text/xml;
}高流量网站优化
http {
gzip on;
gzip_comp_level 4; # 稍低的压缩级别，减少CPU压力
gzip_min_length 512;
gzip_buffers 32 4k;
gzip_vary on;
gzip_proxied any;
gzip_types
text/plain
text/css
text/xml
text/javascript
application/javascript
application/json
application/xml+rss;
}API 服务
http {
gzip on;
gzip_comp_level 6;
gzip_min_length 100; # API响应可能较小
gzip_types
application/json
application/javascript
text/plain
text/css;
}对特定路径禁用压缩
server {
location /downloads/ {
# 下载目录禁用压缩（文件通常已压缩）
gzip off;
}
location /images/ {
# 图片目录禁用压缩
gzip off;
}
location / {
# 其他位置启用压缩
gzip on;
}
}测试压缩是否生效
# 检查响应头
curl -I -H "Accept-Encoding: gzip" http://example.com/style.css
# 应该看到：
Content-Encoding: gzip
Vary: Accept-Encoding检查压缩效果
# 比较压缩前后大小
curl -H "Accept-Encoding: gzip" http://example.com/style.css | wc -c
curl -H "Accept-Encoding: identity" http://example.com/style.css | wc -c注意事项
- CPU 平衡：高压缩级别会增加 CPU 负载
- 缓存考虑：确保配置
gzip_vary on避免缓存问题 - 代理穿透：配置
gzip_proxied确保通过代理也能压缩 - IE6 兼容：使用
gzip_disable避免 IE6 问题