Gin 做业务服务、Nginx 做反向代理是最稳妥易维护的组合；Gin 不应替代 Nginx 主反代，因其性能弱、无原生健康检查、进程崩溃即中断、SSL/HTTP2/缓存等需手动配置且易错。
直接说结论：Gin 做业务服务，Nginx 做反向代理，这是最稳妥、最易维护的组合。别把 Gin 当网关硬扛 proxy_pass 的活，除非你明确需要动态路由或服务发现能力。
为什么 Gin 不该替代 Nginx 做主反代？
很多人看到 gin/proxy 库就跃跃欲试，但实际线上环境里，它只适合特定场景——比如你正在做微服务网关原型、需要 API 热更新节点、或者后端服务本身就在 Go 里跑且规模极小。绝大多数情况，用 Gin 手写反代反而增加故障面：
-
proxy_pass是 Nginx 内置 C 模块，零拷贝、连接复用、超时控制精细；Gin 基于net/http/httputil，本质是用户态转发，性能和稳定性天然弱一档 - Gin 反代没
upstream健康检查的底层支持，靠轮询+简易 HTTP 探活，容易漏判长连接挂死、TCP 半开等真实故障 - 一旦 Gin 进程崩溃或 GC 暂停，整个代理链路中断；而 Nginx worker 进程隔离，单个 worker 挂了不影响其他请求
- SSL 终止、HTTP/2 支持、gzip 压缩、缓存策略这些，Nginx 开箱即用；Gin 要自己拼
http.Transport参数，极易配错
Nginx 配置 Gin 后端的关键点
你的 Gin 服务监听在 :8080，前端走 local.yoyuu.com，Nginx 就得干净利落地把流量导过去。重点不是“能不能通”，而是“通得稳不稳”：
-
proxy_pass末尾加不加/决定路径重写行为：写成proxy_pass http://127.0.0.1:8080/;会剥离location匹配前缀；写成proxy_pass http://127.0.0.1:8080;则原样透传（比如location /api/→/api/xxx会发给 Gin 的/api/xxx） - 必须设
proxy_set_header Host $host;，否则 Gin 的c.Request.Host会变成127.0.0.1:8080，影响 CORS、生成绝对 URL 等逻辑 - 默认
proxy_read_timeout是 60s，但 Gin 默认http.Server.ReadTimeout是 0（不限制），若后端处理慢，Nginx 先超时返回 504，而 Gin 还在跑——要对齐，建议都设为 30s - 如果 Gin 返回了
Set-Cookie，且域名是localhost，浏览器不会带；Nginx 加上proxy_cookie_domain localhost local.yoyuu.com;强制替换
本地开发联调时的典型配置
前端 localhost:3000，Gin 后端 localhost:8080，跨域报错？别改 Gin 的 CORS 中间件，直接用 Nginx 把它们揉成一个域名：
server {
listen 80;
server_name local.yoyuu.com;
location / {
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 /api/ {
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;
}
}
然后 hosts 加一行 127.0.0.1 local.yoyuu.com。前端代码里所有 /api/xxx 请求自动走同源，Gin 也不用开 CORS，干净。
502 错误排查优先看这三处
访问 local.yoyuu.com/api/xxx 返回 502，别急着查 Gin 日志：
- 先确认
nginx -t配置语法通过，再nginx -s reload—— 很多 502 是 reload 失败但进程还在跑旧配置 - 执行
curl -v http://127.0.0.1:8080/api/xxx，看 Gin 是否真能响应；如果连本地直连都 502，问题在 Gin 启动参数或路由注册，和 Nginx 无关 - 检查 Nginx error log：
tail -f /usr/local/nginx/logs/error.log，出现connect() failed (111: Connection refused)说明 Gin 没起来或端口不对；出现no live upstreams说明upstream定义里服务器全被标记为 down（健康检查失败）
真正难缠的是 504——那基本就是超时参数没对齐，或者 Gin 里某个 handler 死循环卡住，Nginx 等不及就断连。这时候看 proxy_connect_timeout 和 proxy_read_timeout 是否小于 Gin 的实际处理耗时。
