Go服务必须绑定127.0.0.1并由Nginx反向代理，以保障TLS终止、限流与审计功能；Nginx需透传Host、X-Real-IP、X-Forwarded-For、X-Forwarded-Proto等请求头，并用upstream块管理后端，proxy_pass路径斜杠须严格匹配Go路由前缀。
Go服务不能直接暴露给公网，必须通过Nginx反向代理来承接外部请求。这不是性能优化的“加分项”，而是生产环境的安全底线和功能基础。
Go服务必须绑定127.0.0.1
开发时常用http.ListenAndServe(":8080", handler)，它等价于监听0.0.0.0:8080——任何能访问服务器IP的客户端都可绕过Nginx直连Go进程，导致TLS终止、限流、日志审计全部失效。
- 正确写法是：
http.ListenAndServe("127.0.0.1:8080", handler)或显式设置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端口仅允许本地访问
Nginx配置要透传关键请求头
Go业务逻辑常依赖原始Host、客户端真实IP和协议类型构造URL（如OAuth回调、邮件链接、重定向地址）。若Nginx不透传，这些链接会变成127.0.0.1:8080或空值，导致用户无法登录、跳转失败。
-
proxy_set_header Host $host：传递客户端请求的Host头（不含端口），不是$http_host -
proxy_set_header X-Real-IP $remote_addr：记录发起请求的真实客户端IP -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for：兼容多层代理场景 -
proxy_set_header X-Forwarded-Proto $scheme：确保Go中r.URL.Scheme返回https而非http
用upstream块替代硬编码proxy_pass
直接写proxy_pass http://127.0.0.1:8080看似简单，但会丢失连接复用能力、无法做健康检查、横向扩展时需反复修改location块。
立即学习“go语言免费学习笔记（深入）”；
- 推荐定义upstream块，即使只有一台后端：
upstream go_backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; }-
max_fails和fail_timeout让Nginx自动剔除僵死但端口仍通的实例（例如panic后未退出） - 后续增加实例只需在upstream中添加新
server行，无需改动proxy_pass指令
路径转发斜杠必须严格匹配
proxy_pass末尾是否带/，决定Nginx是否重写路径前缀——这是404最常见原因。
- 若Go路由为
r.HandleFunc("/health", ...)（无全局前缀），Nginx应写：location / { proxy_pass http://go_backend; }（末尾无/） - 若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会被原样转发到Go的/api/users路径，而Go未注册该路由，返回404
