Go Gin 项目部署到云服务器后无法被公网访问，90% 是因服务绑定 127.0.0.1 而非 0.0.0.0；正确写法为 router.Run(":8080") 或 "0.0.0.0:8080"，并用 netstat -tuln | grep :8080 验证监听地址是否为 *:8080 或 0.0.0.0:8080。
Go Gin 项目部署到云服务器后无法被公网访问，90% 的情况不是安全组没开、也不是防火墙拦了，而是服务根本没监听在外部网卡上——它只绑定了 127.0.0.1。
router.Run("127.0.0.1:8080") 是最常见错误写法
本地开发时用 router.Run("127.0.0.1:8080") 没问题，curl 能通；但一上云服务器，这个地址就变成“只给自己看”的回环地址。操作系统内核压根不会把来自 eth0 的请求转发给它，哪怕安全组全放行也没用。
- 正确写法是
router.Run(":8080")（等价于"0.0.0.0:8080"）或显式写成"0.0.0.0:8080" -
":8080"在 Gin 中会自动解析为 IPv4 所有接口，也隐式支持 IPv6（若系统启用） - 别写
"localhost:8080"——它在某些系统上会解析为::1（IPv6 回环），同样对外不可达
确认服务是否真在监听 0.0.0.0
光改代码不够，得验证运行时行为。登录 EC2 实例后执行：
netstat -tuln | grep :8080
看到类似 tcp6 0 0 :::8080 :::* LISTEN 或 tcp 0 0 *:8080 *:* LISTEN 才算对；如果只显示 127.0.0.1:8080，说明代码没生效或没重启进程。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否用了旧二进制——改完代码后忘了
go build或docker build - 如果是 systemd 管理的服务，记得
systemctl daemon-reload && systemctl restart your-app - 用
lsof -i :8080辅助确认监听地址和 PID
端口能连通但返回空响应或 connection reset
这通常不是 Gin 层的问题，而是基础设施层干扰：
- AWS 安全组必须放行入方向（Inbound）的 TCP 端口（如 8080），且源 IP 设置为
0.0.0.0/0或指定范围 - EC2 实例所在 VPC 的网络 ACL（Network ACL）默认允许全部流量，但如果手动改过，需确认入站规则含对应端口
- 某些云厂商（如腾讯云、阿里云）还有“实例安全组”和“子网 ACL”两级控制，缺一不可
- 避免用
curl http://<your-ec2-public-ip>:8080</your-ec2-public-ip>测试——公网 IP 可能受 NAT 或 EIP 映射影响；优先用curl http://localhost:8080（验证服务本身）+telnet <your-ec2-public-ip> 8080</your-ec2-public-ip>（验证网络连通性）分步排查
日志里看不到请求，但 telnet 能通
说明连接建立成功，但 Gin 没收到 HTTP 请求——大概率是反向代理或负载均衡器配置问题：
- 如果你在 Nginx 前置了反向代理，检查
proxy_pass是否指向了http://127.0.0.1:8080（正确），而不是http://localhost:8080（可能失败） - Nginx 需设置
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;，否则 Gin 的c.ClientIP()可能取不到真实 IP - Cloudflare、AWS ALB 等托管 LB 默认不透传原始 Host 头，Gin 路由匹配可能失败；加个
router.ForwardedByClientIP = true并配置可信代理 IP 段可缓解
真正卡住人的地方往往不在 Gin 本身，而在“谁在把请求递给 Gin”——从网卡收包，到内核协议栈，再到用户态进程绑定，每层都可能静默丢弃流量。先确认 0.0.0.0 监听，再逐层向上验证，比反复改中间件更省时间。
