上一篇
Nginx配置站点怎么做，具体有哪些步骤？
Nginx 配置站点的本质是「请求分发」的精准控制
无论你是部署一个静态博客、一个 PHP 应用，还是负载均衡集群，Nginx 站点配置的核心逻辑只有一条：让进入服务器的 HTTP 请求，按照你定义的规则，被正确转发到对应的文件目录或后端服务，掌握这个本质，你就不会被繁杂的指令吓倒，本文将用一套可复用的配置框架，带你从零到一完成站点配置，并给出生产环境中的独立优化建议。
配置前的三个必要认知
- 站点配置文件存放路径：通常位于 /etc/nginx/conf.d/ 或 /etc/nginx/sites-available/，具体取决于你的系统发行版。建议使用 conf.d 下的独立 .conf 文件，便于维护和排查。
- 配置生效机制：Nginx 主配置文件 nginx.conf 中通过 include 指令加载所有子配置，修改子配置后，必须先执行 nginx -t 检查语法，再 nginx -s reload 平滑重载，不要直接 restart，否则会瞬间断开所有连接。
- 权限与用户：Nginx 工作进程通常以 www-data 或 nginx 用户运行，务必确保站点根目录对该用户有读取权限，否则会出现 403 错误。
最小可用配置：一个静态站点的完整范例
server { listen 80; server_name example.com www.example.com; root /var/www/example; index index.html; location / { try_files $uri $uri/ =404; } access_log /var/log/nginx/example.access.log; error_log /var/log/nginx/example.error.log; }
这段配置的核心点在于 try_files $uri $uri/ =404，它告诉 Nginx：先尝试按实际文件访问，再尝试按目录访问，都找不到就返回 404，这是静态站点最稳健的规则，能有效避免因路径缺失导致的错误跳转。
动态站点配置：PHP 与反向代理的关键区分
如果你的站点需要运行 PHP（如 WordPress）或是一个独立后端服务（如 Java、Node.js），配置思路截然不同。
PHP 站点配置侧重于「将请求交给 PHP-FPM 处理」：
location ~ .php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.1-fpm.sock; }
- 使用正则匹配 .php$ 结尾的请求。
- 必须显式指定 SCRIPT_FILENAME，否则 PHP-FPM 无法找到脚本。
- 建议使用 Unix Socket 而非 TCP 端口（0.0.1:9000），Unix Socket 延迟更低，性能更高。
反向代理配置则更简洁，核心是 proxy_pass 指令：
location /api/ { proxy_pass http://127.0.0.1:8080;
这里有一个最容易踩的坑：proxy_pass 末尾是否带斜杠，会改变转发路径的拼接规则，如果写成 proxy_pass http://127.0.0.1:8080;生产环境务必根据后端接口设计确认这一点。
性能与安全增强：达到生产级标准的必备项
很多新手配置完站点能访问就觉得完成了,但距离真正可用还差三步。
-
开启 Gzip 压缩，减少传输体积：
-
设置静态资源缓存，提升二次访问速度：
location ~ .(jpg|png|css|js)$ { expires 30d; add_header Cache-Control "public, immutable"; } -
限制请求方法并隐藏版本号，降低风险：
if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; } server_tokens off; - 后端服务未启动或端口错误，确认 proxy_pass 或 fastcgi_pass 指向的服务是否真的在监听。
- Unix Socket 文件权限不对，PHP-FPM 的 socket 文件被其他用户占用。
- 防火墙拦截了本机回环地址，但这种情况一般少见。
你先执行 curl -I http://127.0.0.1
独立见解：很多文章强调大量安全策略，但对于中小站点，优先加固「入口访问控制」比堆砌安全模块更有效，例如在 server 块中限制仅允许特定 IP 访问后台路径 location /admin/，使用 Nginx 自带的 allow 和 deny 指令即可实现，这比安装第三方防火墙更直接、更可控。
西西云实战经验案例：多站点隔离与资源冲突
在我们服务客户的过程中,曾遇到一个典型场景：同一台西西云云服务器上需要部署两个流量相差悬殊的网站，如果使用默认配置，当 A 站遭遇突发流量时，会占满所有 worker 进程，导致 B 站响应超时。
我们在西西云上的解决方案是：利用 Nginx 的 limit_req_zone 和 upstream 权重分配，为两个站点设置独立的请求速率限制。
首先在 http 块中定义共享内存区域：
limit_req_zone $binary_remote_addr zone=site_a_limit:10m rate=10r/s; limit_req_zone $binary_remote_addr zone=site_b_limit:10m rate=30r/s;
然后在各自的 server 块中应用限制：
# A 站配置 location / { limit_req zone=site_a_limit burst=5 nodelay; }
这样即使 A 站刷量，B 站依然稳如磐石。这是 Nginx 多站点隔离的一个关键细节：资源限制必须基于站点维度，而不是全局统一，很多用户把限流写在 server 外的 location 上，导致限流失效，值得警惕。
我们还利用西西云的高防 IP 与 Nginx 的 real_ip 模块配合，让 Nginx 正确识别经过 CDN 后的真实客户端 IP，从而有效实施基于 IP 的访问控制。
对于部署在云上的站点，这项配置往往是安全审计的前提条件。
相关问答模块
问题1：修改 Nginx 配置后，访问站点出现 502 Bad Gateway，可能是什么原因？
答：502 表示 Nginx 无法与后端服务通信，最常见的三个原因：
问题2：如何实现 Nginx 配置的快速回滚？
答：我在生产环境中的做法是每次修改配置前先备份 nginx.conf 和所有 conf.d 下的文件，命令很简单：cp -r /etc/nginx /etc/nginx.bak.$(date +%Y%m%d%H%M)，修改后执行 nginx -t 确认无误再加载。reload 后发现异常，直接 cp 回备份文件并再次 reload 即可。不建议依赖 nginx -s stop 再启动，因为这会短暂断开所有连接；轻度回滚用 reload 足够，重度异常（如配置文件丢失）再考虑完全重启。
你的下一步行动
配置 Nginx 站点并不神秘，先做最小可用配置，再逐步加性能和安全项，每一步都用 nginx -t 验证再上线，如果你在配置过程中遇到具体错误码，欢迎在评论区留言，我会结合西西云的常见运维场景给出针对性建议。动手实践一次，比读十篇教程更有用。 现在就去检查你的 server 块，看是否已经补全了 try_files 和 proxy_set_header 这两个关键指令。
