Nginx配置中最容易犯的5个错误及快速修复方法

帮朋友排查网站问题这些年，Nginx配置错误占了将近一半。有些错很隐蔽——网站能打开，但性能差或者有安全隐患。整理了5个最常见的，附上检测命令和修复方法。

1. 上传文件大小限制没改

默认的 client_max_body_size 是1MB。用户上传个PDF或者图片就报413 Request Entity Too Large。很多人排查半天程序代码，结果是Nginx拦了。

修复：在 server 或 location 块里加一行 client_max_body_size 50m; 然后 nginx -t && nginx -s reload。

注意两个坑：一是如果前面有反向代理（CDN、负载均衡），代理层也得改。Cloudflare免费版默认限制100MB，超过也得在CF面板里调。二是改了client_max_body_size之后记得同步改PHP的 upload_max_filesize 和 post_max_size——不然Nginx放行了PHP又给拦了。

2. 没有配置安全头

用 securityheaders.com 扫一下你的站，大概率会发现少了几个关键响应头。最常见缺的是：

• X-Frame-Options: DENY（防点击劫持）
• X-Content-Type-Options: nosniff（防MIME嗅探）
• Strict-Transport-Security（强制HTTPS）
• Content-Security-Policy（防XSS）

加一个通用的安全头配置块到 nginx.conf 的 http 或 server 段：

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=63072000" always;

CSP比较复杂，建议先用浏览器的开发者工具测试，直接贴模板容易把正常资源拦住。

3. location 匹配顺序搞反了

Nginx的location匹配优先级从高到低是：= 精确匹配 → ^~ 前缀匹配 → ~ 正则匹配 → 普通前缀匹配。

一个经典错误：想用 location /api/ 代理到后端，又写了 location ~ \.php$ 处理PHP文件。当请求 /api/index.php 时，正则匹配 \.php$ 优先级高于普通前缀 /api/，所以请求被PHP-FPM处理而不是代理到后端。API接口报404，查了一下午。

修复：精确匹配用 location = /api/，或者用 ^~ 提升前缀匹配的优先级：location ^~ /api/。

4. gzip 没开或者配置太保守

2026年了还有不少站没开gzip。检查方法：curl -H "Accept-Encoding: gzip" -I https://你的域名，看响应头有没有 Content-Encoding: gzip。

不仅HTML要压，JSON、JS、CSS、SVG都要：

gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

最低压缩级别 gzip_comp_level 5，时间换压缩比，6以上CPU开销换来的压缩率提升微乎其微。开启后HTML文件传输体积平均减小70%。

5. worker_connections 用了默认值

默认的 worker_connections 512，对于高并发场景远远不够。一个简单原则：worker_connections 设置为 worker_processes × worker_connections = 预计最大并发连接数 × 2。

查当前值：nginx -T | grep worker_connections。一般4核机器设 worker_connections 2048 够用了。但记得同步检查系统的文件描述符限制——ulimit -n 至少得大于 worker_connections 的两倍。

调完用 wrk 或 ab 做一次压测，验证有没有512/502错误。

标签： Nginx 网站配置 问题排查 服务器运维 web服务器