Windows Server部署ASP.NET Core应用后，先不要急着重装或反复重启：先从客户端确认域名解析到了哪个地址，再测试外部网络能否连接预期端口；随后在服务器本机检查端口监听、IIS或反向代理转发，以及应用进程和日志。若服务器本机能访问、外部访问失败，优先排查监听范围、入站防火墙和公网入口；若本机也无法访问，则继续检查应用是否启动、端口是否匹配及站点配置。

开始前准备服务器管理权限、应用部署目录、访问域名、对外端口和应用托管方式（例如 IIS、Windows 服务或其他方式）。记录当前 IIS 绑定、应用配置和防火墙规则；修改前备份原值，确保可以恢复。以下命令适用于 Windows Server PowerShell。example.com、C:\Sites\MyApp、5000、MyApp 和 MyAppPool 均为示例值，执行前请替换为实际域名、目录、端口、服务名和应用程序池名称。

一、先从外部确认域名与网络入口

1. 核对域名解析结果

在出现访问问题的客户端上查询域名：

Resolve-DnsName example.com

检查 A 记录是否指向预期的公网 IPv4 地址；若存在 AAAA 记录，也要确认对应 IPv6 地址确实已配置并能提供服务。域名解析到了未启用的 IPv6 地址时，部分客户端可能优先尝试 IPv6，出现连接超时或失败。

需要了解客户端使用的 DNS 服务器和缓存时，可执行：

ipconfig /all
ipconfig /displaydns

若客户端和服务器的解析结果不同，分别记录结果再判断：只有客户端异常时，重点检查客户端使用的 DNS、缓存和域名记录；两端结果都不符合预期时，核对 DNS 管理平台中的记录值和记录类型。修改记录后，客户端缓存更新可能需要时间，不能只凭服务器本机查询就认定所有客户端已使用新记录。

判断边界：域名解析成功只表示域名取得了一个地址，不表示该地址上的端口可以连接，也不表示应用已经正常运行。

2. 确认公网入口是否对应当前服务器

在 Windows Server 上查看网卡地址：

Get-NetIPConfiguration

将网卡地址与域名解析结果、预期公网入口对照。服务器位于云平台、路由器或负载均衡设备之后时，公网地址可能不会直接配置在 Windows 网卡上。此时还要在对应管理平台核对公网地址映射、后端服务器和入站访问规则。

可用以下现象初步划分故障范围：

• 服务器本机访问成功、外部访问失败：优先检查监听地址、Windows 入站防火墙及上游入口规则。
• 同一内网设备可以访问服务器内网地址，公网客户端不通：优先检查公网映射、上游访问控制和服务器入站规则。
• 服务器本机和内网设备都无法访问：继续检查端口监听、IIS 站点或应用进程。
• IP 地址可以访问、域名无法访问：检查 DNS、IIS 主机名绑定；若使用 HTTPS，还要检查证书与域名是否匹配。

如果对外使用 HTTPS，还应确认公网入口的 HTTPS 配置和证书匹配。不要为排障将正式站点长期改为明文访问。

二、分清对外端口与应用监听端口

3. 检查服务器上是否有端口监听

在服务器上查询预期端口。以下以 5000 为例：

Get-NetTCPConnection -State Listen -LocalPort 5000

也可以使用：

netstat -ano | findstr :5000

若有监听记录，记下进程 ID，并核对对应进程：

Get-Process -Id 1234

将 1234 替换为实际进程 ID。没有监听记录，表示该端口当前没有进程接收连接；应检查应用是否启动、启动参数是否正确，以及应用配置中的监听地址和端口是否与预期一致。

要区分服务器本机和外部网络的 TCP 连通性，可在外部客户端运行：

Test-NetConnection example.com -Port 443

将域名和端口替换为实际对外入口。TcpTestSucceeded : True 表示从当前测试位置到目标地址的 TCP 连接已建立，不代表 HTTP 请求正常，也不能证明应用业务功能无误。若测试失败，应结合服务器本机监听结果检查地址、上游入口、入站防火墙和监听端口。

4. 判断应用监听地址是否匹配访问方式

应用只监听 127.0.0.1 时，通常只能接受服务器本机连接。若 IIS 或本机反向代理需要转发到 Kestrel，这种本机监听可能符合设计；若客户端要直接访问应用端口，则应确认应用监听了客户端可到达的网卡地址，并且对应入站访问已获准。

通过 IIS 对外提供服务时，用户通常访问 IIS 绑定的 HTTP 或 HTTPS 端口，而不是 Kestrel 的内部端口。此时要分别验证两段连接：

1. 客户端到 IIS 对外端口是否可达。
2. IIS 到应用监听地址和端口的转发是否正常。

不要把 IIS 对外端口和 Kestrel 内部端口混为一谈；端口不同并不必然是故障，关键是绑定和转发配置相互匹配。

三、核对防火墙与上游入站规则

5. 查看 Windows 防火墙状态和现有规则

查看防火墙配置文件状态：

Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction

查询目标端口相关的已启用入站规则，以下以 TCP 443 为例：

Get-NetFirewallRule -Enabled True -Direction Inbound |
    Get-NetFirewallPortFilter |
    Where-Object { $_.LocalPort -eq '443' }

替换为实际端口。发现规则不等于连接一定被允许，还要核对规则是否启用、适用的网络配置文件、协议、远程地址范围和程序限制。若服务器使用云平台或其他网络设备，还要单独检查上游入站规则；Windows 防火墙放行不能替代上游放行。

6. 必要时只新增最小范围的入站规则

只有在确认目标端口已有合法监听、业务确实需要对外开放该端口，并记录了当前规则状态后，才考虑新增规则。以下示例允许 TCP 443 入站，规则名应保持唯一：

New-NetFirewallRule `
    -DisplayName "MyApp-HTTPS-443" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow `
    -Profile Domain,Private,Public

该命令会改变服务器的入站访问面。生产环境应根据实际用途缩小适用配置文件和远程地址范围，不要为排障关闭整个 Windows 防火墙，也不要开放业务不需要的端口。创建规则后，从外部重新运行 Test-NetConnection，再发起 HTTP 或 HTTPS 请求验证。

如果规则无效或不再需要，只删除本次新增且确认名称匹配的规则：

Remove-NetFirewallRule -DisplayName "MyApp-HTTPS-443"

如果修改的是已有规则，应恢复修改前记录的配置；不要误删原有业务规则来代替回滚。

四、检查 IIS、反向代理与站点绑定

7. 核对 IIS 站点、绑定和应用程序池

若应用通过 IIS 对外服务，在服务器 PowerShell 中查看站点与绑定：

Import-Module WebAdministration

Get-Website |
    Select-Object Name, State, PhysicalPath, ApplicationPool

Get-WebBinding |
    Select-Object protocol, bindingInformation, ItemXPath

确认站点处于启动状态，物理路径指向实际发布目录，绑定中的协议、IP、端口和主机名符合访问方式。多个站点共用同一 IP 和端口时，主机名绑定不匹配可能导致请求进入其他站点或找不到对应站点。使用 HTTPS 时，还要确认 IIS 绑定的证书有效并匹配访问域名。

检查应用程序池状态：

Get-WebAppPoolState -Name "MyAppPool"

若站点或应用程序池已停止，先查看事件日志和 IIS 日志，确认停止原因后再按变更流程启动。不要在没有保存错误信息的情况下反复重启。

IIS 托管 ASP.NET Core 应用时，还要确认服务器安装了与应用部署方式匹配的 ASP.NET Core Hosting Bundle，并检查发布目录文件和 web.config 是否符合当前应用配置。应用程序池常见设置包括“无托管代码”；应结合实际托管方式和现有站点配置核实，不要直接套用到其他站点。修改应用程序池或站点配置前，先记录原值。

8. 检查反向代理到应用的转发

若 IIS 或 Nginx 等反向代理负责转发请求，分别检查前端监听端口、代理服务状态、后端地址和端口，以及代理错误日志。确认代理配置中的后端地址与应用当前监听地址一致。不要同时修改前端端口、后端端口和应用监听地址，否则难以判断是哪一项变化影响了故障。

在服务器本机测试应用端口，可使用：

curl.exe -I http://127.0.0.1:5000/

此命令适用于服务器上存在 curl.exe 的情况；端口应替换为实际应用监听端口。如果应用要求特定主机名或 HTTPS，应按实际站点配置测试。收到 HTTP 响应说明请求到达了某个 Web 服务，但仍需确认响应来自目标站点；连接被拒绝通常表示目标端口没有监听或本机访问被拦截；请求超时则要继续检查监听地址和本机规则。

五、确认应用进程、托管状态和日志

9. 按实际部署方式检查运行状态

如果应用以 Windows 服务运行，可按真实服务名查询：

Get-Service -Name "MyApp"

服务名应从实际服务配置中核对。服务不存在时，先确认应用部署方式和注册名称，不要假设所有应用都注册为 Windows 服务。服务停止时，先查明启动失败原因，再决定是否启动。

如果应用通过 IIS 托管，检查站点和应用程序池状态，并查看 Windows 事件查看器的 Windows 日志 → 应用程序。关注与应用、IIS 或 ASP.NET Core Module 相关的错误，例如启动失败、运行时缺失、配置格式错误或文件访问被拒绝。

IIS 日志常见位置为：

C:\inetpub\logs\LogFiles

管理员可能修改过实际日志路径，应以 IIS 配置为准。结合日志中的 HTTP 状态码、子状态和时间戳定位问题：连接超时更应先核对网络入口或连接路径；IIS 返回 404 时检查站点绑定、路径和路由；500 系列错误应结合 IIS 日志和应用异常日志判断，不能仅凭状态码认定为防火墙故障。

10. 用本机 HTTP 请求区分网络故障与应用错误

在服务器本机请求应用或站点：

curl.exe -I http://127.0.0.1:5000/

将地址和端口替换为应用实际监听值。若应用要求指定主机名或通过 HTTPS 服务，应使用与站点配置相符的测试地址。此步骤用于确认本机请求能否到达服务；它不能代替外部客户端验证，也不能单独证明完整业务功能正常。

六、按测试结果确定下一步

表中的判断用于缩小范围，不是对故障原因的单项定论。例如 TCP 连接成功只说明连接建立，不保证目标站点、路由或应用逻辑正确；HTTP 状态码也需要与 IIS 和应用日志一起核对。

七、失败处理、变更回滚与验收

需要重启站点、应用程序池或服务时，先保存当前状态和相关日志，并确认操作不会影响同一服务器上的其他站点。只处理目标组件；若重启后问题恶化或无法验证，恢复变更前记录的配置，再根据事件日志、IIS 日志和测试结果继续定位。不要在证据不足时同时重装运行时、修改端口并扩大防火墙范围。

完成处理后，从服务器本机和至少一个外部客户端分别验收：

• 域名解析结果与预期入口一致，A/AAAA 记录没有指向未启用的地址。
• 预期端口存在监听；外部 TCP 测试结果符合当前入口设计。
• IIS 站点或目标服务处于运行状态，站点绑定、证书、应用路径和转发地址正确。
• HTTP 或 HTTPS 请求返回预期页面或接口响应，应用日志没有新的启动异常。
• 防火墙仅保留业务需要的规则；新增规则的名称、端口和来源范围已记录。

若验收失败，删除本次确认无用的防火墙规则，或恢复备份的 IIS、应用和入口配置；随后重新检查端口监听、站点状态与日志。保留事件日志、IIS 日志和测试结果，再决定下一步操作，避免在原因未明时扩大变更范围。