在服务器上通过 localhost 访问网站正常，但使用 公网IP:端口号 从外部访问，浏览器返回 HTTP ERROR 502
“我在本地/服务器上访问网站一切正常，但用公网IP就是访问不了！”
这句话可能是每个部署Web应用的开发者都遇到过的经典难题。随之而来的，往往是那个令人困惑的 HTTP ERROR 502 Bad Gateway 错误。
最近，我就经历了一次这样的完整排查过程。这个问题看似复杂，涉及IIS、Windows Server、应用程序本身以及云服务器环境。但通过系统性的、由外到内的排查方法，我们最终定位并解决了问题。这篇博客将复盘整个过程，希望能为您提供一份清晰的排查路线图。
IIS网站服务器本机可访问，其它电脑不能访问，绑定是全部未分配；外网计算机与网站服务器可Ping通；网站服务器打开防火墙添加了端口的入站规则；身份验证允许匿名身份验证；其他计算机访问公网ip:9001报错HTTP ERROR 502
1. 环境与问题描述
-
环境: ASP.NET Core 应用，通过 IIS 部署于阿里云 ECS Windows Server。
-
目标: 在公网通过
9001端口访问应用。 -
问题:
localhost访问正常。公网 IP 访问返回HTTP ERROR 502。
2. 排查过程
2.1. 应用层诊断
2.1.1. IIS 应用程序池
-
检查: 确认目标应用程序池处于“已启动”状态。
-
操作: 执行回收（Recycle）操作。
-
结果: 状态正常，问题无变化。
2.1.2. Windows 事件查看器
-
检查: 分析“Windows 日志” -> “应用程序”分类下的日志。重点关注来源为
IIS-W3SVC-WP,WAS,.NET Runtime的错误。 -
结果: 在触发 502 错误时，未产生任何相关的错误或警告日志。
-
结论: 请求未到达 .NET 应用层面，或应用未发生可记录的崩溃。问题点位于应用进程的前端。
2.2. 基础设施诊断
2.2.1. 操作系统防火墙
-
检查: 确认 Windows 防火墙已为 TCP
9001端口配置入站规则。 -
操作: 为排除干扰，临时禁用 Windows 防火墙。
-
结果: 问题依旧。
2.2.2. 云平台安全组
-
检查: 审查阿里云 ECS 实例绑定的安全组入站规则。
-
结果: 未发现针对
9001端口的放行规则。 -
操作: 添加新规则：
-
协议:
TCP -
端口:
9001/9001 -
源:
0.0.0.0/0
-
-
结果: 再次测试，问题依旧。表明存在多个故障点。
2.3. 隔离测试 (绕过 IIS)
为区分是应用问题还是 IIS 代理问题，执行以下操作。
-
操作 1: 在 IIS 管理器中停止目标网站，以释放
9001端口。 -
操作 2: 在应用发布目录中，通过命令行直接启动 Kestrel 服务器，并强制其监听所有网络接口。
dotnet YourApp.dll --urls "http://*:9001"
-
结果: 控制台成功输出
Now listening on: http://[::]:9001，进程正常运行。 -
结论: 应用程序本身功能完好，且能够成功绑定到指定端口。问题与应用代码无关。
2.4. 定位根本原因
-
检查: 核对客户端用于访问的 URL。
-
发现: 客户端使用的 URL 为
http://。/9001 -
分析: 该 URL 格式错误。它访问的是服务器
80端口下的/9001路径，而非9001端口。 -
更正: 使用正确的 URL
http://进行访问。:9001 -
最终结果: 访问成功。
3. 结论
本次 502 错误由两个独立问题共同导致：
-
基础设施配置错误: 阿里云安全组未开放所需端口，导致外部流量无法到达服务器上的应用端口。
-
客户端请求错误: 使用了错误的 URL 格式（
IP/port而非IP:port）。
修复其中任一问题都无法完全解决症状，必须两者都得到修正。
4. 标准排查清单
-
验证客户端请求: 确认 URL 格式 (
:vs/) 和目标端口是否正确。 -
审查云平台网络策略: 检查安全组、网络 ACL 等，确保端口已对公网开放。
-
审查操作系统防火墙: 确认入站规则已正确配置。
-
隔离应用进行测试: 绕过反向代理（IIS, Nginx），直接启动应用进程，验证其自身功能。
-
分析日志: 仔细审查 Web 服务器日志和应用框架日志，定位错误信息。
