Go服务必须绑定127.0.0.1:8080并由Nginx代理，禁用0.0.0.0监听以防绕过TLS、限流等安全策略；proxy_pass路径斜杠需与Go路由前缀严格匹配；必须透传Host、X-Forwarded-For、X-Forwarded-Proto三请求头，WebSocket还需Upgrade和Connection头；推荐使用upstream块支持健康检查与横向扩展。
Go 服务不能直接监听 0.0.0.0:8080 暴露到公网，必须绑定 127.0.0.1:8080 并由 Nginx 统一代理——这不是可选项，是生产环境安全与功能可用的底线。
Go 服务必须显式绑定 127.0.0.1，否则会绕过 Nginx
开发时常用 http.ListenAndServe(":8080", handler)，它等价于监听 0.0.0.0:8080，意味着任何能访问该机器 IP 的客户端都可直连 Go 进程，彻底绕过 Nginx 的 TLS 终止、限流、日志和安全策略。
- 正确写法是：
http.ListenAndServe("127.0.0.1:8080", handler)或设置http.Server.Addr = "127.0.0.1:8080" - Docker 场景下需注意：
127.0.0.1在容器内只指向自身，若 Nginx 与 Go 不在同容器，应改用宿主机 IP（如host.docker.internal）或 Docker 网络别名 - Linux 内核参数
net.ipv4.ip_nonlocal_bind=1可能让127.0.0.1绑定被绕过，建议配合iptables或nftables显式拒绝外部对 8080 端口的访问
proxy_pass 路径末尾斜杠决定路径重写行为
Nginx 的 proxy_pass 值是否带末尾 /，直接影响 URL 路径如何转发到 Go 后端，这是 404 最常见根源。
- 若 Go 路由注册为
r.HandleFunc("/health", ...)（无全局前缀），Nginx 应写：location / { proxy_pass http://go_backend; }（proxy_pass末尾无/） - 若 Go 使用
r.PathPrefix("/api").Handler(...)，且你希望请求/api/users转发为/users，Nginx 应写：location /api/ { proxy_pass http://go_backend/; }（两个/都要存在） - 错误示例：
location /api/ { proxy_pass http://go_backend; }→ 请求/api/users会变成/api/users转发，而 Go 未注册该路径，返回 404
必须透传 Host 和协议头，否则 Go 业务逻辑会失效
Go 中常依赖 r.Host 构造 OAuth 回调地址、邮件链接或重定向 URL；若 Nginx 不透传原始 Host，这些链接将变成 127.0.0.1:8080 或空值，导致用户无法登录、跳转错乱。
立即学习“go语言免费学习笔记（深入）”；
- 关键三行不能少：
proxy_set_header Host $host;（不是$http_host）、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;、proxy_set_header X-Forwarded-Proto $scheme; - WebSocket 必须额外加两行：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，缺一则握手失败返回 400 - Go 中判断 HTTPS 应用：
r.Header.Get("X-Forwarded-Proto") == "https"，而非检查r.TLS（它始终为 nil）
upstream 块不是“过度设计”，而是健康检查和扩展前提
直接写 proxy_pass http://127.0.0.1:8080 看似省事，但会导致连接复用失效、无法主动摘除僵死实例、后续扩容需修改多处配置。
- 哪怕只有一台后端，也应定义
upstream块：upstream go_backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; } -
max_fails和fail_timeout让 Nginx 在 Go 进程 panic 后仍监听端口但不响应时，自动将其从负载池中剔除 - 后续加实例只需追加
server 127.0.0.1:8081;，无需改动proxy_pass或 location 块
最容易被忽略的是 Go 服务自身的超时控制：应关闭 http.Server.ReadTimeout 和 WriteTimeout，把超时决策权完全交给 Nginx，否则两者冲突会导致连接提前中断或响应截断。这和你习惯的“服务自己管超时”直觉相反，但恰恰是反向代理模式下的正确分工。
