在 Windows Server 2012 上查看 80 端口是否启用，最直接的办法是在命令行执行 netstat -ano | findstr :80，只要出现 LISTENING 状态就说明本机有程序在监听这个端口；如果想确认外部能不能访问，还要再看防火墙入站规则和从其他机器发起的连通性测试。
80 端口是 HTTP 协议的默认端口，由 IANA（互联网数字分配机构）在端口分配表中固定下来，这就决定了它几乎是每台 Web 服务器的第一检查项，很多运维接手一台 2012 的老机器时，第一个问题就是“站为什么打不开”，答案往往藏在 80 端口的状态里。
win2012服务器怎么查看80端口是否开启
先弄清楚一件事：端口“开启”在服务器语境里有三层含义，第一层是本机有没有进程在监听；第二层是防火墙有没有放行；第三层是外部网络能不能实际连上来，三层里任何一层没打通，用户访问都会失败，所以查看 80 端口不能只敲一条命令就下结论，得按顺序把三层都过一遍。
用 netstat 看监听状态，这是最稳的起手式
按 Win+R 输入 cmd，右键以管理员身份运行命令提示符，之所以强调管理员，是因为不加权限时 netstat 看不到属于其他用户会话的进程名，查起来会很别扭。
执行下面这条命令：
netstat -ano | findstr :80参数含义要记住：-a 显示所有连接和监听端口，-n 用数字形式显示地址和端口（不做反向 DNS 解析，速度快），-o 输出对应的进程 PID。findstr :80 是过滤，只保留含 80 的行。
如果你还想直接把进程名带出来,可以用 -b 参数：
netstat -anob | findstr :80-b 会显示创建连接的可执行文件名，但必须管理员权限，而且速度慢一些。
看懂输出结果里的关键字段
输出一般是这样的格式：
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
TCP 127.0.0.1:80 0.0.0.0:0 LISTENING 4820第一列协议,第二列本地地址，第三列外部地址，第四列状态，第五列 PID，判断要点：
- 状态是
LISTENING，说明有程序在本机监听 80 端口，这是“启用”的直接证据。 - 本地地址是
0.0.0:80，表示监听所有 IPv4 网卡，外部可以连；如果是0.0.1:80，只监听本地回环，外面一律连不上，这是排查时最容易踩的坑。 - 出现
[::]:80说明 IPv6 侧也在监听，Windows Server 2012 默认启用 IPv6 双栈，看到它属于正常现象。 - 状态是
ESTABLISHED表示已经有活动连接，TIME_WAIT是连接关闭后的等待状态，都不代表端口“没开”。
PowerShell 的方式更适合写进脚本
Windows Server 2012 自带 PowerShell 3.0，NetTCPIP 模块可用，想一次性看清端口和进程的对应关系，可以这样写：
Get-NetTCPConnection -LocalPort 80 | Select-Object LocalAddress,LocalPort,State,OwningProcess想再进一步把进程名拿出来：
Get-NetTCPConnection -LocalPort 80 | ForEach-Object { Get-Process -Id $_.OwningProcess }这种方式的好处是输出结构化,配合 Export-Csv 就能做成定期巡检记录，比截图存档靠谱得多。
win2012服务器80端口被占用怎么查看和定位
80 端口“开了但开得不对”，多半是被别的程序抢占了，Windows Server 2012 上抢 80 端口的常见角色有：IIS 的 World Wide Web Publishing Service、SQL Server Reporting Services 的报表服务、第三方 Web 中间件如 Apache 或 Nginx 的 Windows 版本，还有一些远程管理类软件的内置 Web 控制台。
从 PID 反查进程，别凭感觉猜
拿到 netstat 输出的 PID 后，执行：
tasklist | findstr 4820或者用更精确的过滤语法：
tasklist /FI "PID eq 4820"看到进程名是 System 且 PID 为 4，说明 80 端口被 HTTP.sys 内核驱动接管，这通常意味着 IIS 或者某个注册了 HTTP.sys 的服务正在工作，此时应该去服务管理器里查 IIS 相关服务，而不是去杀进程，看到 sqlservr.exe 或者 ReportingServicesService.exe，说明是报表服务占用了 80，改它的端口或改 IIS 的绑定即可。
资源监视器给不习惯命令行的人留了后路
按 Win+R 输入 resmon 回车，切到“网络”选项卡，展开“侦听端口”列表，按端口号排序就能找到 80，这一屏会直接列出端口、协议、防火墙状态、地址和进程名，信息密度比命令行直观，适合远程桌面里临时看一眼，缺点是无法批量导出，也没法写进自动化脚本。
用测试命令验证外部可达性
本机监听正常,不代表外面能访问，在服务器本机执行：
Test-NetConnection -ComputerName 127.0.0.1 -Port 80TcpTestSucceeded 为 True 表示本机链路通，再换一台同网段机器，把 0.0.1 换成服务器内网 IP 再测一次，两次结果不一致，问题基本锁定在防火墙或者网络 ACL 上，老派的办法是用 telnet 服务器IP 80，但 Windows Server 2012 默认没装 telnet 客户端，需要在“服务器管理器添加角色和功能功能”里勾选安装。
防火墙与 IIS 绑定：80 端口看不见的两道关卡
入站规则是否放行
打开“高级安全 Windows Defender 防火墙”，点“入站规则”，找到名称里带“万维网服务（HTTP 流量入）”的那条，确认已启用且配置文件（域/专用/公用）与服务器当前网络位置匹配，命令行核对可以用：
netsh advfirewall firewall show rule name=all | findstr /C:"80" /C:"World Wide Web"行业内有个共识：相当一部分“端口不通”的工单，最后都落在防火墙配置文件选错了这一项上，服务器网卡被识别成“公用网络”，而规则只在“域”配置文件下启用，两边对不上，流量自然进不来。
IIS 站点绑定要顺手看一眼
如果确认 IIS 在跑，可以进“Internet 信息服务（IIS）管理器”，选中站点后点右侧“绑定”，看类型为 http 的那条绑定端口是不是 80、IP 地址是“全部未分配”还是某个具体网卡，绑定成具体 IP 而客户端访问的是另一个 IP，就会出现“本机 netstat 看到监听，外部却连不上”的怪现象。
常用查看方式对比，挑一个顺手的
| 方式 | 操作入口 | 能看到进程名 | 可否导出 | 适用场景 |
|---|---|---|---|---|
| netstat -ano | 命令提示符 | 需配合 tasklist | 可重定向到文件 | 快速排查、远程 SSH 式操作 |
| PowerShell Get-NetTCPConnection | PowerShell | 可管道输出 | 可导出 CSV | 批量巡检、脚本化 |
| 资源监视器 resmon | 运行框 | 直接显示 | 不支持 | 图形界面下临时确认 |
| 外部连通性测试 | Test-NetConnection 或 telnet | 否 | 否 | 验证防火墙与网络链路 |
据工信部历年发布的互联网基础资源相关统计,国内 Web 服务仍以 HTTP/HTTPS 为主要承载协议，80 端口因此长期是服务器侧最高频的检查对象，业内专家指出，端口排查的关键不在于工具多先进，而在于把“监听、放行、可达”三个层次分开验证，避免在错误的层面反复折腾。
关于win2012服务器80端口查看的常见疑问
Windows Server 2012 上 netstat 显示 80 端口 TIME_WAIT 是没开吗
不是。TIME_WAIT 是 TCP 连接正常关闭后的收尾状态，连接双方需要等待一段时间以确保最后一个确认包被正确处理，属于协议设计的正常环节，判断端口是否在提供服务，只看有没有 LISTENING，收缩状态的连接不参与这个判断。
80 端口查出来是 System 进程占用，能直接结束吗
不能,PID 4 对应的是 Windows 内核的 HTTP.sys 驱动，它承载 IIS 以及所有基于 HTTP Server API 的服务，结束它等同于让整台机器的 HTTP 服务栈失效，正确做法是去服务管理器里停用不需要的 Web 服务，或者调整它的端口绑定。
win2012服务器80端口启用但外网访问不了，先查哪里
先在同网段另一台机器上做 TCP 连通性测试，排除是客户端侧问题；接着核对防火墙入站规则的启用状态与网络配置文件是否匹配；最后检查 IIS 站点绑定里的 IP 地址是否与对外暴露的网卡一致，三步走完，绝大多数可达性问题都能定位到具体位置。
把监听状态、防火墙规则、外部连通性这三件事分开验证，再结合 netstat 和 tasklist 把 PID 落到具体进程名上，Windows Server 2012 的 80 端口排查就没什么玄学了，命令记不住没关系，把这几条存成一个巡检脚本，下次接手任何一台老服务器都能几分钟内给出结论。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783627.html
