proxy_pass 是 Nginx 实现反向代理的核心指令,支持 http:// 和 https:// 协议,需明确写出完整 URL;不支持 ftp:// 或 redis:// 等非 HTTP 协议,后者需用 stream 模块;常见陷阱包括协议不匹配、Host 头未透传及超时配置不当。

proxy_pass 是 Nginx 实现反向代理的核心指令,它不仅能转发请求到不同主机或端口,还能灵活适配不同协议(HTTP、HTTPS、甚至带认证或非标准端口的服务)。关键在于写法是否准确,以及后端服务是否可被正常访问。
proxy_pass 支持的协议类型与写法
Nginx 默认支持 http:// 和 https:// 协议前缀。只要在 proxy_pass 后明确写出完整 URL,Nginx 就会按对应协议发起上游连接:
-
转发到 HTTP 服务(常见)
proxy_pass http://192.168.1.100:8080;
-
转发到 HTTPS 服务(需注意证书验证问题)
proxy_pass https://api.example.com:443;
-
转发到带路径的后端(路径会被重写或继承,取决于写法)
# 不带尾部 /:原始 URI 完整拼接 proxy_pass http://backend/api; # 带尾部 /:location 匹配路径被替换为 /,再拼接目标路径 location /v1/ { proxy_pass http://backend/; }示例:请求
/v1/user→ 转发为http://backend/user
处理非标准端口与协议细节
-
后端监听非 80/443 端口时,必须显式写出端口号
proxy_pass http://127.0.0.1:3000; # Node.js 服务 proxy_pass https://10.0.0.5:8443; # 自签名 HTTPS 服务
-
若后端是 HTTPS 但证书不可信(如自签),需关闭 SSL 验证(仅限内网或测试环境)
proxy_ssl_verify off; proxy_ssl_trusted_certificate /dev/null; # 或指定 CA 文件
-
不支持直接写
ftp://或redis://等非 HTTP 协议 ——proxy_pass仅用于 HTTP/HTTPS 反向代理。其他协议需用 stream 模块(stream { ... }块)配合proxy_pass实现 TCP/UDP 层转发。
常见陷阱与建议
-
协议不匹配:前端用
https://访问 Nginx,但proxy_pass写成http://后端,属于混合内容,不影响代理本身,但可能触发浏览器安全策略(如Content-Security-Policy)。 -
Host 头未透传:默认
proxy_pass不修改Host请求头,若后端依赖 Host 判断租户或路由,需显式设置proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr;
-
超时与缓冲需同步调整:尤其转发至慢速后端(如 Python Flask)时,建议增加
proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; proxy_buffering off; # 或调大 buffer 参数
不复杂但容易忽略
文章来自机圈观察员网,发布者:,转载请注明出处:https://www.jqgcy.com/xitongjiaocheng/126613.html