Nginx绑定域名配置

引言

一台服务器跑多个站点，靠server_name区分访问哪个域名，配合DNS解析和站点根目录，Nginx按Host头把请求路由到对应虚拟主机。配置顺序写错或server_name不匹配，会落到默认站点。

基础域名站点

server {
    listen 80;
    server_name www.example.com example.com;
    root /var/www/example;
    index index.html index.php;
}

server_name可并列写主域名和裸域名，root指向站点目录。

裸域名跳转到www

server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

避免两个域名都解析内容造成重复收录，统一到一个规范域名。

多个域名并列

server_name api.example.com admin.example.com;

同一套站点对应多个子域名时直接空格分隔。

反向代理绑定域名

server {
    listen 80;
    server_name app.example.com;
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }
}

域名指向后端服务，记得把Host头透传给上游。

配置后检查重载

nginx -t
nginx -s reload

先测语法再平滑重载，reload不断连接。

匹配规则

• 精确域名优先，然后通配符，最后默认站点；
• 没匹配上server_name的请求落到default_server；
• 通配符*.example.com不能匹配example.com裸域；
• 多站点注意别让无关域名被默认站点接住。

注意事项

• DNS要先把A记录解析到服务器IP，否则域名打不开；
• server_name区分大小写但通常小写；
• 80改443需另配SSL证书块；
• return 301统一域名利于SEO避免重复；
• 防火墙和安全组放行80、443；
• 多个server块listen 80，靠server_name分流。

总结

server_name在server块绑定域名，可并列多个，裸域301跳www统一规范，反代时透传Host，改完nginx -t检查再reload。匹配精确优先于通配符，未命中走默认站点，前提是DNS解析到位、端口放行，统一域名有助于SEO避免重复收录。

Nginx监听端口配置

引言

listen是server块的第一行指令，决定Nginx在哪个端口接收请求。一个server监听一个端口加域名组合，多站点靠server_name区分，多端口靠listen叠加。配错端口是最常见的502和无法访问根源。

基础HTTP监听

server {
    listen 80;
    server_name example.com;
    root /var/www/site;
    index index.html;
}

监听80端口，匹配example.com域名的请求进这个站点。

HTTPS监听

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
}

443必须加ssl关键字，同时配证书和私钥路径。

监听多个端口

server {
    listen 80;
    listen 8080;
    server_name example.com;
}

一个server块写多行listen，80和8080都走同一套配置。

只监听指定IP

listen 127.0.0.1:8080;

只绑回环地址，外部访问不到，适合内部管理接口。

80跳转到443

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

单独一个80 server做永久跳转，把HTTP请求引导到HTTPS。

默认服务器

server {
    listen 80 default_server;
}

default_server指定未匹配域名时的兜底站点，防直接用IP访问暴露默认页。

注意事项

• 端口冲突先ss -tlnp查占用，别盲目改；
• 443漏写ssl会导致证书不生效；
• 云服务器还要在安全组放行对应端口；
• listen不带IP默认绑0.0.0.0全部网卡；
• 改端口后先nginx -t再reload；
• 301跳转的旧URL参数用$request_uri保留。

总结

listen 80配HTTP，listen 443 ssl配HTTPS并带证书，多行listen监听多端口，IP:端口限定绑定网卡，80 server用return 301跳HTTPS，default_server做域名兜底。改前ss查占用、nginx -t校验、安全组放行，绑定IP时注意内外网可达性，跳转用$host和$request_uri保住完整地址。

Nginx代理缓存配置

引言

反向代理每次都回源取页面，后端压力大、首屏慢。Nginx自带proxy_cache，把后端响应存到本地磁盘，命中时直接返回，既减轻源站又加快响应，适合静态资源和不常变的页面。

定义缓存区

http块里先声明缓存目录和大小：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=mycache:10m max_size=1g inactive=7d;

• keys_zone=mycache:10m 是缓存名和索引内存；
• max_size=1g 磁盘上限；
• inactive=7d 7天没访问自动清理。

代理站点启用缓存

server或location块：

location / {
    proxy_cache mycache;
    proxy_cache_key $host$uri$is_args$args;
    proxy_cache_valid 200 304 1h;
    proxy_cache_valid 404 1m;
    proxy_cache_methods GET HEAD;
    proxy_pass http://backend;
}

200/304缓存1小时，404只存1分钟。

命中状态标识

加响应头方便排查：

add_header X-Cache-Status $upstream_cache_status;

HIT命中、MISS未命中、EXPIRED过期、BYPASS绕过。

绕过缓存的场景

登录后动态内容不缓存：

proxy_no_cache $http_cookie;
proxy_cache_bypass $http_cookie;

带cookie时不读不写缓存。

主动清除缓存

# 配置删除接口需要第三方模块或手动删目录
rm -rf /data/nginx/cache/*

更新内容后清对应目录，或按URL前缀匹配删除。

注意事项

• 缓存目录要先mkdir并给nginx读写权限；
• 带POST的接口不要缓存；
• 频繁变动的页面缓存时间设短或不缓存；
• 缓存键要带参数，避免不同query串内容；
• 配置改完nginx -t校验再reload；
• 大文件下载用分片缓存更稳妥。

总结

proxy_cache_path在http块定义缓存区，location里proxy_cache启用、proxy_cache_valid设有效期、proxy_cache_key拼缓存键，用X-Cache-Status看命中。静态和低频页面开缓存扛压力，动态登录内容用cookie绕过，更新后及时清理。

Nginx代理WebSocket

引言

聊天、实时推送、在线协作这类场景用WebSocket长连接。前端经过Nginx访问后端WS服务时，如果只按普通HTTP反代配置，握手会失败，因为WebSocket要先发起Upgrade协议升级，Nginx必须把升级头透传给后端。

WebSocket握手原理

客户端先发HTTP请求，带Upgrade: websocket和Connection: Upgrade头，后端同意后把HTTP协议升级成持久双向长连接。Nginx默认不透传这两个头，导致握手400。

标准代理配置

location /ws/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
}

• proxy_http_version 1.1：WS基于HTTP/1.1；
• Upgrade $http_upgrade：透传客户端升级协议；
• Connection "upgrade"：标记连接升级；
• read_timeout拉长：长连接默认60秒无数据会被Nginx断开。

用map统一处理

不同location可能同时有HTTP和WS，写map避免硬编码：

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}
# location内
proxy_set_header Connection $connection_upgrade;

普通HTTP请求$http_upgrade为空时走close，WS请求走upgrade，一套配置兼容。

常见问题

• 握手400/502：没加Upgrade和Connection头；
• 连接几十秒自动断开：read_timeout太短，按需拉长或服务端发心跳；
• wss(HTTPS)走Nginx终止TLS后，后端用ws即可；
• 后端端口和proxy_pass写对，别漏http://。

注意事项

• 长连接超时靠心跳和read_timeout共同维持；
• 集群WS要配合粘性会话或后端共享状态，否则消息发不到正确连接；
• HTTPS页面必须用wss://，浏览器会拦截混合内容；
• 改配置nginx -t后reload。

总结

Nginx代理WebSocket核心是加proxy_http_version 1.1、透传Upgrade和Connection头、拉长read_timeout，用map兼容普通HTTP。握手失败先查这三个头，断线先查超时和心跳。

Nginx 反向代理配置

反向代理是 Nginx 最常用的功能之一，配置很简单。

1. 什么是反向代理

反向代理就是：用户访问 Nginx，Nginx 把请求转发给后端服务器，再把结果返回给用户。

作用：

• 隐藏后端服务器
• 负载均衡
• 统一入口
• 缓存静态内容

2. 基本配置

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

说明：

• proxy_pass：后端地址
• proxy_set_header：传递请求头

3. 常用请求头

location / {
    proxy_pass http://127.0.0.1:8080;

    # 传递域名
    proxy_set_header Host $host;

    # 传递真实IP
    proxy_set_header X-Real-IP $remote_addr;

    # 传递完整请求链
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # 传递协议
    proxy_set_header X-Forwarded-Proto $scheme;
}

4. 超时配置

location / {
    proxy_pass http://127.0.0.1:8080;

    # 连接超时
    proxy_connect_timeout 60s;

    # 发送超时
    proxy_send_timeout 60s;

    # 读取超时
    proxy_read_timeout 60s;
}

5. WebSocket 代理

location /ws {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;

    # WebSocket 升级
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

6. 负载均衡

# 定义后端服务器组
upstream backend {
    server 127.0.0.1:8080 weight=1;
    server 127.0.0.1:8081 weight=2;
    server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

7. 静态文件直接返回

server {
    listen 80;
    server_name example.com;

    # 静态文件直接处理
    location ~* \.(js|css|png|jpg|gif)$ {
        root /var/www/static;
        expires 30d;
    }

    # 其他请求转发后端
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }
}

8. 配置生效

# 检查配置
nginx -t

# 重载配置
nginx -s reload

9. 常见问题

1）502 Bad Gateway

• 后端服务没启动
• 后端端口不对
• 后端超时

2）504 Gateway Timeout

• 后端处理太慢
• 调整超时时间

3）获取不到真实IP

• 没配置 X-Real-IP
• 后端没读取请求头

4）WebSocket 连不上

• 没配置 Upgrade 和 Connection 头

10. 生产建议

1）一定要传请求头

• Host
• X-Real-IP
• X-Forwarded-For

2）合理设置超时

• 根据业务调整
• 不要太长也不要太短

3）静态文件 Nginx 直接处理

• 减轻后端压力
• 提高性能

4）开启 gzip 压缩

gzip on;
gzip_types text/css application/javascript;

总结

Nginx 反向代理配置要点：

• proxy_pass 指定后端地址
• 一定要传请求头
• 常用超时配置
• WebSocket 要升级头
• upstream 做负载均衡
• 静态文件直接返回
• 配置完 nginx -t 检查
• 502 检查后端是否启动
• 生产环境传全请求头

反向代理是 Nginx 基本功，一定要熟练掌握。

Nginx 反向代理原理

反向代理是 Nginx 最常用的功能，搞懂原理很有必要。

1. 什么是反向代理

正向代理：代理客户端，比如翻墙工具。
反向代理：代理服务器，客户端不知道真实服务器。

用户请求 Nginx，Nginx 再转发给后端服务器，用户以为自己直接访问的就是 Nginx。

2. 为什么用反向代理

1）隐藏真实服务器

• 后端服务器 IP 不暴露
• 更安全

2）负载均衡

• 多个后端服务器分摊请求
• 提高并发能力

3）统一入口

• 多个服务用一个域名
• 不同路径转发到不同服务

4）SSL 卸载

• HTTPS 证书在 Nginx 配置
• 后端用 HTTP 就行

5）缓存静态内容

• Nginx 直接返回静态资源
• 减轻后端压力

3. 基本配置

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

4. 常用代理头

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

后端通过这些头获取真实客户端信息。

5. 路径转发示例

# 根路径转发到PHP服务
location / {
    proxy_pass http://127.0.0.1:8080;
}

# /api 转发到后端接口
location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

# /static 直接读本地文件
location /static/ {
    root /var/www;
}

6. 超时设置

# 连接超时
proxy_connect_timeout 60s;

# 读取超时
proxy_read_timeout 60s;

# 发送超时
proxy_send_timeout 60s;

7. 常见问题

1）后端获取不到真实IP

• 检查 X-Real-IP 头是否设置
• 后端代码是否读取这个头

2）WebSocket 连接失败

• 需要添加 Upgrade 头
• 配置 HTTP/1.1

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;

3）大文件上传失败

• 修改 client_max_body_size
• 增加 proxy_read_timeout

总结

Nginx 反向代理要点：

• 代理服务器，隐藏真实后端
• 实现负载均衡、统一入口
• 配置 proxy_pass 转发
• 记得设置常用代理头
• 后端通过请求头获取真实客户端信息
• 注意超时和上传大小限制
• WebSocket 需要特殊配置

做 Web 开发，反向代理是必备技能。

Nginx 反向代理配置

反向代理是 Nginx 最常用的功能，前端请求 Nginx，Nginx 再转发给后端服务。

1. 什么是反向代理

• 正向代理： 代理客户端，比如翻墙
• 反向代理： 代理服务器，客户端不知道真正的后端

2. 基础配置

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

意思是：访问 80 端口的请求，转发到 8080 端口的服务。

3. 常用配置说明

location / {
    # 转发地址
    proxy_pass http://127.0.0.1:8080;

    # 传递真实IP
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # 超时设置
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

4. 按路径转发不同服务

# 访问 /api/ 转发到后端API服务
location /api/ {
    proxy_pass http://127.0.0.1:8080;
}

# 访问 /admin/ 转发到后台管理服务
location /admin/ {
    proxy_pass http://127.0.0.1:8081;
}

# 其他访问静态文件
location / {
    root /www/wwwroot/html;
}

5. 常见应用场景

1）前后端分离：

• 前端静态文件 Nginx 直接处理
• API 请求转发到后端服务

2）Node.js/Python 后端：

• Nginx 处理 80/443 端口
• 转发到 Node.js 的 3000 端口

3）负载均衡：

• 配合 upstream 转发到多台服务器

6. 常见问题

1）后端获取不到真实 IP：

• 要配置 X-Real-IP 和 X-Forwarded-For
• 后端从请求头里取

2）WebSocket 不支持：

• 需要加特殊头

  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

3）上传文件大小限制：

client_max_body_size 100m;

总结

Nginx 反向代理核心：

• proxy_pass 转发地址
• proxy_set_header 传递真实信息
• 按 location 转发不同服务
• 注意超时和文件大小限制

做 Web 开发，Nginx 反向代理一定要会配置。

前言

做实时聊天、推送、在线游戏，需要用 WebSocket。Nginx 当反向代理的时候，默认不支持 WebSocket 协议，需要额外配置。本文讲一下怎么配。

WebSocket 是什么

WebSocket 是一种全双工通信协议，浏览器和服务器建立连接后，可以一直保持连接，互相实时推送消息。

为什么需要特殊配置

普通 HTTP 请求是短连接，请求完就断了。WebSocket 是长连接，而且用的是 Upgrade 协议头。Nginx 默认的反向代理不支持这种升级，需要加特殊配置。

基础配置

location /ws/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

关键就是这三行：

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

完整配置示例

server {
    listen       80;
    server_name  www.example.com;

    root  /var/www/html;
    index index.html;

    # WebSocket 代理
    location /ws/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 300s;
    }

    # 普通 HTTP 代理
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

超时配置

WebSocket 是长连接，默认超时时间短了会自动断开。

proxy_read_timeout 300s;
proxy_send_timeout 300s;

意思是：5分钟没有数据传输才断开。

常见坑

坑1：WebSocket 连接失败

前端连 WebSocket 一直失败。

原因： Nginx 没配 Upgrade 和 Connection 头。

解决： 加上那三行关键配置。

坑2：连接几秒就自动断了

连上了，过一会儿就断了。

原因： Nginx 默认超时时间太短（60秒）。

解决： 调大 proxy_read_timeout。

坑3：HTTPS 下 WebSocket 连不上

HTTP 下正常，HTTPS 下连不上。

原因： 前端用了 ws://，但网站是 https 的，浏览器不让。

解决： 前端用 wss://（加密的 WebSocket）。

坑4：连接数太多被拒

很多人同时在线，新的连接被拒了。

原因： Nginx 或后端服务器连接数限制。

解决： 调大 Nginx 和后端的连接数限制。

总结

WebSocket 代理就三行核心配置：

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

记住： WebSocket 是长连接，记得调大超时时间，别让它自动断了。

遇到问题加QQ23979811 协助处理

前言

LNMP 架构里，Nginx 收到 PHP 请求之后，要转发给 PHP-FPM 处理。这个转发的配置就是 fastcgi_pass。本文讲一下完整的 Nginx 代理 PHP 服务配置。

两种代理方式

Nginx 代理后端服务有两种方式：

1. proxy_pass：代理 HTTP 服务（比如 Node.js、Java、Python）
2. fastcgi_pass：代理 FastCGI 服务（就是 PHP-FPM）

PHP 用的是 fastcgi_pass，不是 proxy_pass，别搞混了。

基础配置

完整 LNMP 配置示例

server {
    listen       80;
    server_name  www.example.com;

    root  /var/www/html;
    index index.php index.html;

    # 访问根目录
    location / {
        try_files $uri $uri/ =404;
    }

    # PHP 请求转发给 PHP-FPM
    location ~ \.php$ {
        root           /var/www/html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

关键参数说明

socket 方式 vs 端口方式

端口方式（TCP）

fastcgi_pass 127.0.0.1:9000;

优点：跨服务器可以用
缺点：多了一层 TCP 开销，稍微慢一点

Socket 方式（Unix Domain Socket）

fastcgi_pass unix:/run/php-fpm/www.sock;

优点：更快，少了 TCP 开销
缺点：只能在同一台服务器上用

生产环境推荐用 socket 方式，更快。

完整生产环境配置

server {
    listen       443 ssl http2;
    server_name  www.example.com;

    ssl_certificate      /etc/nginx/ssl/www.crt;
    ssl_certificate_key  /etc/nginx/ssl/www.key;

    root  /var/www/html;
    index index.php index.html;

    # 日志
    access_log  /var/log/nginx/www.access.log;
    error_log   /var/log/nginx/www.error.log;

    # 静态资源直接返回
    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires 30d;
    }

    # PHP 请求转发
    location ~ \.php$ {
        fastcgi_pass   unix:/run/php-fpm/www.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;

        # 超时设置
        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
    }

    # 禁止访问 .ht 等文件
    location ~ /\.ht {
        deny  all;
    }
}

常见坑

坑1：SCRIPT_FILENAME 路径不对

配置了 SCRIPT_FILENAME /var/www/html$fastcgi_script_name;，但 root 不是这个路径。

原因： 写死了路径，换个目录就错了。

解决： 用 $document_root：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

坑2：socket 路径不一致

Nginx 配置里写的 socket 路径和 PHP-FPM 实际的不一致。

检查 PHP-FPM 的 socket 路径：

grep listen /etc/php-fpm.d/www.conf

确保两边路径一模一样。

坑3：PHP 不解析，直接下载

访问 index.php，浏览器直接下载了文件，没解析。

原因： Nginx 没把 .php 请求转发给 PHP-FPM。

检查： 配置里有没有 location ~ \.php$ 这一段，有没有 fastcgi_pass。

坑4：404 Not Found

访问 PHP 文件报 404。

原因： SCRIPT_FILENAME 路径不对，PHP-FPM 找不到文件。

解决： 确认 root 和 SCRIPT_FILENAME 配置正确。

检查配置并重载

nginx -t
nginx -s reload

总结

记住： PHP 用 fastcgi_pass，不是 proxy_pass，别搞混了。

遇到问题加QQ23979811 协助处理

前言

前端页面和后端接口不在同一个域名下，浏览器报跨域错误。这是前后端分离开发最常见的问题。本文讲一下怎么用 Nginx 配置跨域。

什么是跨域

浏览器的同源策略：协议、域名、端口有一个不一样，就是跨域。

比如：

• 前端：https://www.example.com
• 后端接口：https://api.example.com

这两个域名不一样，浏览器就不让前端直接请求后端接口。

Nginx 配置跨域

简单配置（允许所有域名）

在接口的 server 块里加：

server {
    listen       443 ssl http2;
    server_name  api.example.com;

    # 跨域配置
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    # 处理 OPTIONS 预检请求
    if ($request_method = 'OPTIONS') {
        return 204;
    }

    root  /var/www/api;
    index index.php;
}

指定允许的域名（推荐）

生产环境不要用 *，指定具体域名更安全：

# 允许单个域名
add_header Access-Control-Allow-Origin https://www.example.com;

# 允许多个域名
set $cors_origin "";
if ($http_origin ~* "^https://(www\.example\.com|m\.example\.com)$") {
    set $cors_origin $http_origin;
}
add_header Access-Control-Allow-Origin $cors_origin;

带 Cookie 的跨域

如果跨域请求要带 Cookie，光加 * 不行：

add_header Access-Control-Allow-Origin $http_origin;
add_header Access-Control-Allow-Credentials true;

注意： 带 Cookie 的时候，Allow-Origin 不能用 *，必须指定具体域名。

完整配置示例

server {
    listen       443 ssl http2;
    server_name  api.example.com;

    ssl_certificate      /etc/nginx/ssl/api.crt;
    ssl_certificate_key  /etc/nginx/ssl/api.key;

    # 跨域配置
    set $cors_origin "";
    if ($http_origin ~* "^https://(www\.example\.com|admin\.example\.com)$") {
        set $cors_origin $http_origin;
    }

    add_header Access-Control-Allow-Origin $cors_origin;
    add_header Access-Control-Allow-Credentials true;
    add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    # 处理 OPTIONS 预检请求
    if ($request_method = 'OPTIONS') {
        add_header Access-Control-Allow-Origin $cors_origin;
        add_header Access-Control-Allow-Credentials true;
        add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
        add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    root  /var/www/api;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

检查配置并重载

nginx -t
nginx -s reload

常见坑

坑1：OPTIONS 请求 404

浏览器发 OPTIONS 预检请求，Nginx 直接返回 404。

原因： 没处理 OPTIONS 请求。

解决： 加上面那个 if ($request_method = 'OPTIONS') 的判断，直接返回 204。

坑2：跨域配置不生效

加了跨域配置还是报跨域错误。

原因1： PHP 后端也输出了跨域头，两边冲突了。

解决： 只留一处跨域配置，要么在 Nginx 配，要么在后端代码里配，不要两边都配。

原因2： Nginx 重载失败了。

解决： 确认 nginx -t 没问题，再 nginx -s reload。

坑3：带 Cookie 的跨域失败

配置了跨域，但是带 Cookie 请求还是失败。

原因： Allow-Origin 用了 *，浏览器不允许。

解决： 改成具体域名，加上 Access-Control-Allow-Credentials true。

坑4：POST 请求跨域失败

GET 请求没问题，POST 请求跨域了。

原因： 没允许 POST 方法或者 Content-Type 头。

解决： 把 POST 和 Content-Type 加到 Allow-Methods 和 Allow-Headers 里。

总结

生产环境建议： 不要用 *，指定具体域名更安全。

遇到问题加QQ23979811 协助处理

前言

502 Bad Gateway 是 Nginx 最常见的报错之一，尤其是 LNMP 架构下，Nginx 把 PHP 请求转发给 PHP-FPM，PHP-FPM 出问题了 Nginx 就报 502。本文讲一下完整的排查思路。

502 是什么意思

502 表示 Nginx 作为反向代理，去请求后端服务（PHP-FPM）的时候，后端没响应或者报错了。

注意： 502 不是 Nginx 的问题，是后端 PHP-FPM 的问题。

排查步骤

第一步：检查 PHP-FPM 服务是否在运行

systemctl status php-fpm

如果显示 inactive (dead)，说明 PHP-FPM 挂了，启动它：

systemctl start php-fpm
systemctl enable php-fpm

第二步：检查 Nginx 和 PHP-FPM 的通信配置

看 Nginx 配置里的 fastcgi_pass 对不对：

grep fastcgi_pass /etc/nginx/nginx.conf

常见的配置：

# 用 socket 文件
fastcgi_pass unix:/run/php-fpm/www.sock;

# 用 TCP 端口
fastcgi_pass 127.0.0.1:9000;

问题1：socket 文件路径不对

Nginx 配置里写的 socket 路径和 PHP-FPM 实际的不一致。

PHP-FPM 的 socket 路径在 /etc/php-fpm.d/www.conf 里：

grep listen /etc/php-fpm.d/www.conf

确保两边路径一致。

问题2：端口被占

如果用 9000 端口，检查一下是不是被别的进程占了：

lsof -i:9000

第三步：看错误日志

Nginx 错误日志：

tail -f /var/log/nginx/error.log

PHP-FPM 错误日志：

tail -f /var/log/php-fpm/error.log

PHP 慢日志：

tail -f /var/log/php-fpm/www-slow.log

根据日志里的报错信息找原因。

第四步：常见原因

原因1：PHP-FPM 进程数不够

访问量大的时候，PHP-FPM 进程都被占满了，新请求排队超时。

解决： 增加 PHP-FPM 进程数。

编辑 /etc/php-fpm.d/www.conf：

pm.max_children = 50
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

改完重启：

systemctl restart php-fpm

原因2：PHP 脚本执行超时

PHP 脚本执行时间太长，超过了 Nginx 的超时时间。

解决： 调大超时时间。

Nginx 配置里：

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

PHP 配置里：

max_execution_time = 300

原因3：PHP 内存不足

PHP-FPM 进程内存溢出，导致进程崩溃。

解决： 调大 PHP 内存限制：

memory_limit = 256M

或者减少 PHP-FPM 进程数，避免内存不够。

原因4：文件权限不对

Nginx 运行的用户和 PHP-FPM 运行的用户不一致，导致 PHP-FPM 读不到文件。

解决： 确保 Nginx 和 PHP-FPM 用同一个用户（一般是 www）。

PHP-FPM 配置 /etc/php-fpm.d/www.conf：

user = www
group = www

然后把网站文件的属主改成 www：

chown -R www:www /var/www/html

第五步：重启所有服务

改完配置后重启：

systemctl restart php-fpm
systemctl restart nginx

常见坑

坑1：只重启了 Nginx

改了 PHP 配置但只重启了 Nginx，PHP-FPM 还是老配置。

解决： PHP 配置改了要重启 PHP-FPM，Nginx 配置改了要重启 Nginx。

坑2：socket 文件权限不对

PHP-FPM 的 socket 文件权限是 600，Nginx 用户读不到。

解决： 改 socket 文件权限：

listen.mode = 0666

或者改 socket 文件的属主：

listen.owner = www
listen.group = www

坑3：PHP-FPM 挂了但没自动重启

PHP-FPM 进程崩溃了，没人自动拉起来。

解决： 配置 systemd 自动重启：

systemctl edit php-fpm

加：

[Service]
Restart=always
RestartSec=2

总结

502 排查步骤：

1. 先看 PHP-FPM 是不是挂了 → systemctl status php-fpm
2. 再看 Nginx 配置对不对 → fastcgi_pass 路径/端口
3. 看错误日志 → Nginx error.log + PHP-FPM error.log
4. 常见原因 → 进程数不够、超时太短、权限不对、内存不足

记住：502 问题出在后端，不是 Nginx 的锅。

遇到问题加QQ23979811 协助处理

前言

现在做后端开发，后端服务一般跑在 3000、8080 这种端口上，总不能让用户直接访问 IP:端口 吧？这时候就需要 Nginx 反向代理，把 80 端口的请求转发到后端服务。本文就讲一下 Nginx 反向代理的配置方法。

什么是反向代理

简单说，反向代理就是：

• 用户访问 Nginx（80 端口）
• Nginx 把请求转发给后端服务（比如 3000 端口）
• 后端服务返回结果给 Nginx
• Nginx 再返回给用户

用户不知道后端服务的存在，只跟 Nginx 打交道。

基本配置

最简单的反向代理

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

就这么简单，所有访问 www.example.com 的请求都会被转发到 http://127.0.0.1:3000。

检查并重载

nginx -t
systemctl reload nginx

常用配置项

proxy_pass 后端地址

proxy_pass http://127.0.0.1:3000;

后端服务的地址，可以是 IP 加端口，也可以是域名。

传递真实客户端 IP

默认情况下，后端服务看到的是 Nginx 的 IP，不是真实用户的 IP。需要加上几个请求头：

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

这样后端服务就能拿到真实用户的 IP 了。

代理 WebSocket

如果后端服务用了 WebSocket，需要额外配置：

location /ws {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

超时设置

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 60s;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

如果后端服务响应慢，可以把超时时间调大一点。

按路径分流

不同路径转发到不同后端服务：

server {
    listen 80;
    server_name www.example.com;

    location /api/ {
        proxy_pass http://127.0.0.1:3000;
    }

    location /admin/ {
        proxy_pass http://127.0.0.1:8080;
    }

    location / {
        root /var/www/html;
        index index.html;
    }
}

这样：

• /api/ 开头的请求 → 3000 端口
• /admin/ 开头的请求 → 8080 端口
• 其他请求 → 静态文件

常见坑

坑1：502 Bad Gateway

访问报 502，说明 Nginx 连不上后端服务。

排查：

1. 看后端服务有没有启动：curl http://127.0.0.1:3000
2. 看后端服务监听的地址对不对，是不是只监听了 127.0.0.1
3. 看防火墙有没有挡住

坑2：后端拿不到真实 IP

日志里全是 Nginx 的 IP，不是用户真实 IP。

解决： 加上那几个请求头：

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

坑3：静态资源 404

前端是 Vue/React 这种单页应用，刷新页面就 404。

原因： Nginx 找不到对应的静态文件。

解决： 加个 try_files：

location / {
    root /var/www/html;
    index index.html;
    try_files $uri $uri/ /index.html;
}

所有找不到的路径都返回 index.html，交给前端路由处理。

坑4：HTTPS 代理后端 HTTP

前端是 HTTPS，后端是 HTTP，浏览器报混合内容错误。

解决： 确保 Nginx 和后端之间是 HTTP 没问题，但要让后端知道原始请求是 HTTPS：

proxy_set_header X-Forwarded-Proto $scheme;

总结

Nginx 反向代理的核心就是 proxy_pass，把请求转发到后端服务。常用配置：

反向代理是 Nginx 最常用的功能之一，做 Web 开发必备。

遇到问题加QQ23979811 协助处理

Nginx 反向代理配置详解

Nginx 反向代理是最常用的服务器配置之一，把请求转发给后端服务。本文讲清楚核心配置。

1. 基本配置

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

2. 传递真实IP

后端服务要拿到用户真实IP，需要配置：

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

3. 负载均衡

多台后端服务器，用 upstream 做负载均衡：

upstream backend {
    server 127.0.0.1:8080 weight=1;
    server 127.0.0.1:8081 weight=2;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

4. 超时设置

proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

5. 静态文件处理

静态文件直接由 Nginx 处理，不用转发给后端：

location ~* \.(js|css|png|jpg|gif)$ {
    root /data/www;
    expires 30d;
}

6. HTTPS 反向代理

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

总结

Nginx 反向代理的核心就是 proxy_pass，配上 proxy_set_header 传递必要信息，再加上超时和静态文件处理，基本够用了。

前言

Nginx 是目前最流行的 Web 服务器和反向代理软件。很多人会写简单的配置，但对反向代理、负载均衡、缓存这些高级用法并不熟悉。本文带你从零开始，掌握 Nginx 的核心配置技巧。

一、反向代理基础

反向代理是 Nginx 最常用的功能之一。用户请求 Nginx，Nginx 再把请求转发给后端应用服务器。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

关键说明：

• proxy_pass：后端服务地址
• proxy_set_header：传递真实的客户端信息给后端，否则后端拿到的都是 Nginx 的信息

二、负载均衡

当后端有多台服务器时，可以用 Nginx 做负载均衡。

1. 轮询（默认）

upstream backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

2. 加权轮询

upstream backend {
    server 127.0.0.1:8080 weight=3;
    server 127.0.0.1:8081 weight=2;
    server 127.0.0.1:8082 weight=1;
}

weight 值越大，分配的请求越多。适合配置不同的服务器。

3. ip_hash 会话保持

upstream backend {
    ip_hash;
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

同一个 IP 的请求总是分配到同一台后端服务器，适合有 session 的场景。

三、缓存配置

Nginx 缓存可以大幅减轻后端压力，提升响应速度。

1. 配置缓存路径

http {
    # 定义缓存路径和参数
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_cache my_cache;
            proxy_cache_valid 200 302 10m;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status;
        }
    }
}

关键参数说明：

• keys_zone：缓存共享内存区大小
• max_size：缓存最大占用空间
• inactive：多久没访问就自动清理
• proxy_cache_valid：不同状态码的缓存时间
• X-Cache-Status：查看是否命中缓存（HIT/MISS/BYPASS）

2. 不缓存特定请求

location /admin/ {
    proxy_pass http://backend;
    proxy_cache off;  # 后台页面不缓存
}

四、HTTPS 配置

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

# HTTP 跳转 HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

五、常见问题排查

1. 502 Bad Gateway

通常是后端服务挂了或者端口不对：

# 检查后端服务是否在运行
netstat -tlnp | grep 8080

# 查看 Nginx 错误日志
tail -f /var/log/nginx/error.log

2. 上传文件大小限制

http {
    client_max_body_size 50M;
}

3. 超时设置

location / {
    proxy_connect_timeout 60s;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

总结

Nginx 配置的核心思路：

1. 反向代理：把请求转发给后端应用
2. 负载均衡：多台后端服务器分担流量
3. 缓存：静态内容缓存，减少后端压力
4. HTTPS：加密传输，安全第一

掌握这些配置，你就能应对大部分 Web 服务器场景了。Nginx 配置文件改完记得执行 nginx -t 检查语法，然后 nginx -s reload 重载生效。