Gin 默认绑定 127.0.0.1:8080，仅监听回环接口，外部无法访问；需显式调用 router.Run("0.0.0.0:8080") 监听所有 IPv4 接口，并配合系统防火墙、云安全组及反向代理（如 Nginx）才能实现外部可达。
为什么 gin.Default() 启动的服务器在防火墙后无法被访问
因为 gin.Default() 默认绑定 localhost:8080（即 127.0.0.1:8080），只接受本机回环地址请求，外部网络（包括同一局域网其他机器、NAT 后的客户端、防火墙策略允许的上游代理）根本连不上——这不是防火墙“拦住”了，而是服务压根没监听外网接口。
如何让 Gin 监听所有 IPv4 接口（0.0.0.0）
必须显式调用 Run() 并传入 0.0.0.0:端口号，不能依赖默认行为：
router := gin.Default()
// ✅ 正确：监听所有 IPv4 接口
router.Run("0.0.0.0:8080")
// ❌ 错误：等价于 "localhost:8080"，仍只绑本地
// router.Run(":8080")
// router.Run("8080")
- 若需同时支持 IPv6，用
[::]:8080，但多数企业防火墙策略只处理 IPv4，优先用0.0.0.0 - 绑定
0.0.0.0后，仍需确认宿主机防火墙（如ufw、firewalld）放行该端口 - 云服务器还需检查安全组规则（如阿里云/腾讯云控制台）是否允许入向 TCP 流量
企业防火墙环境下不建议直接暴露 Gin 端口的原因
即使绑定了 0.0.0.0 且系统防火墙开放，大多数企业出口防火墙会主动拦截非标准端口（如 :8080、:3000），或只允许 :80/:443 出站。更关键的是：Gin 自带的 HTTP server 不支持 TLS 终止、HTTP/2、连接复用优化、WAF 规则注入等生产必需能力。
- 正确做法是前置反向代理（如 Nginx、Traefik、企业级 API 网关），由其监听
:443，再以 HTTP 或 HTTPS 转发到 Gin 的内网端口（如127.0.0.1:8080） - Gin 应禁用 HTTPS（不要调用
RunTLS()），避免证书管理复杂化；TLS 交由边缘设备统一处理 - 若必须穿透（如临时调试），可使用
ssh -R或frp，但 Gin 侧仍需确保监听0.0.0.0且本地防火墙放行内网端口
调试时快速验证端口是否真正可达
别只在浏览器里输 http://your-ip:8080 就下结论——先分层验证：
立即学习“go语言免费学习笔记（深入）”；
- 在 Gin 服务器本机执行：
curl -v http://127.0.0.1:8080/ping→ 确认服务启动且路由正常 - 从同局域网另一台机器执行：
telnet your-server-ip 8080或nc -zv your-server-ip 8080→ 判断系统防火墙和网络层是否通 - 若不通，检查
ss -tln | grep :8080输出是否含0.0.0.0:8080（而非127.0.0.1:8080） - 企业环境常禁用 ICMP，
ping失败不等于端口不通；务必用telnet/nc测试 TCP 连通性
router.Run("0.0.0.0:8080") 就以为万事大吉，却没意识到企业出口防火墙根本不转发这个端口——这时需要推动运维配置反向代理或申请端口白名单，而不是在 Gin 代码里加各种超时或重试。 
