Go服务必须绑定127.0.0.1，否则绕过Nginx导致TLS终止、限流等功能失效；Echo需显式设e.Start("127.0.0.1:8089")；proxy_pass末尾斜杠必须与路由前缀严格匹配；必须透传Host、X-Forwarded-For、X-Forwarded-Proto三头，WebSocket还需Upgrade和Connection头；upstream块须定义并启用健康检查。
Go服务必须绑定127.0.0.1，否则Nginx反向代理形同虚设——这是所有问题的起点，不是建议，是硬性前提。
Go Echo服务监听地址必须显式设为127.0.0.1
Echo默认不强制绑定地址，开发时写e.Start(":8080")等价于监听0.0.0.0:8080，外部可直连，绕过Nginx的TLS、限流、日志等全部能力。
- 正确写法：
e.Start("127.0.0.1:8089")（端口建议避开80/443/8080等常见值） - 若用
http.Server手动启动，必须设置srv.Addr = "127.0.0.1:8089" - Docker场景下注意：
127.0.0.1在容器内只指向自己，Nginx与Echo不在同一容器时，upstream应改用宿主机别名（如host.docker.internal）或Docker网络服务名 - Linux内核若启用
net.ipv4.ip_nonlocal_bind=1，127.0.0.1绑定可能被绕过，建议配合iptables -A INPUT -p tcp --dport 8089 -s ! 127.0.0.1 -j REJECT加固
Nginx proxy_pass末尾斜杠决定路径重写行为
404错误里有近七成源于proxy_pass末尾斜杠缺失或冗余，它直接控制URL路径是否被截断。
- 若Echo注册路由为
e.GET("/health", handler)（无全局前缀），Nginx应写：location / { proxy_pass http://go_backend; }（proxy_pass末尾无/） - 若Echo使用
e.Group("/api")，且你希望/api/users转发到后端/users，Nginx必须写：location /api/ { proxy_pass http://go_backend/; }（两个/都不可少） - 错误示例：
location /api/ { proxy_pass http://go_backend; }→ 请求变成http://go_backend/api/users，Echo收不到/users
必须透传Host、X-Forwarded-For、X-Forwarded-Proto三头
Echo中调用c.Request().Host或生成OAuth回调链接时，若没透传原始Host，链接会变成127.0.0.1:8089，用户点击即失效。
立即学习“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"; - 如果Echo用了
e.Use(middleware.ProxyHeaders())，它依赖X-Forwarded-*头还原真实请求信息，缺一不可
upstream块必须定义，不能直接proxy_pass硬编码IP
写proxy_pass http://127.0.0.1:8089看似简单，但会导致健康检查失效、连接无法复用、扩实例时要改多处配置。
- 正确定义upstream：
upstream go_backend { server 127.0.0.1:8089 max_fails=3 fail_timeout=30s; } -
max_fails和fail_timeout让Nginx在Echo进程panic僵死但端口仍通时主动摘除节点 - 后续横向扩展只需加
server 127.0.0.1:8090;，无需动proxy_pass或location块 - 若Echo用systemd管理，建议配
Restart=on-failure和StartLimitIntervalSec=60，与Nginx健康检查节奏对齐
最常被忽略的是Docker网络语境下的127.0.0.1语义漂移，以及upstream未启用健康检查导致故障节点持续接收流量——这两点在压测或上线后突发异常时才暴露，但修复成本远高于部署前确认。
