记一次诡异的 8080 端口“幽灵占用”排查：竟是 Windows 更新惹的祸

问题描述

作为一名开发者，相信大家都遇到过端口被占用的问题。通常，我们一通 netstat -ano | findstr 8080 加上 taskkill /f /pid <PID> 的操作就能轻松搞定。

但这次，我遇到了一个“诡异”的情况：

1. 现象：本地启动 Spring Boot/Tomcat 服务失败，提示 8080 端口被占用。
2. 排查：使用 netstat 命令，确认 8080 端口没有被占用。
3. 灵异事件：使用 netstat -ano | findstr 8080 也查不到了占用端口的 PID，用 tasklist | findstr <PID> 也确认找不到任何进程。

这就好像端口被一个“幽灵进程”给占用了，杀都找不到对象。

排查过程与最终发现

在经过一系列重启、杀毒软件排查等无效操作后，我将怀疑目标锁定在了系统最近的变更上。我检查了 Windows 更新历史记录，发现了一个在 11月11日 安装的更新（具体更新编号可能因系统而异，我遇到的是与 HTTP.sys 相关的更新）。

这个更新的描述如下：

修复了 HTTP.sys 请求分析器中的问题…当前端代理是设置的一部分时，这可能会导致分析差异…若要关闭严格分析，请使用以下注册表项…

破案了！

根本原因：
这个更新修复了 Windows 底层 HTTP 驱动 HTTP.sys 对 HTTP/1.1 块扩展的解析逻辑，使其从“宽松模式”切换到了 “严格模式” 。在某些特定环境下，这个改动可能导致 HTTP.sys 驱动本身预先占用了 8080 端口，或者与尝试绑定该端口的应用程序发生了冲突。由于 HTTP.sys 是内核级驱动，其占用的端口有时不会在用户态的进程列表中明确显示，这就导致了我们看到的“幽灵占用”现象。

于是我尝试卸载Winsows11的更新，重启后问题解决了（印度啊三写的代码真拉跨。

解决方案（三种任选其一）

方案一：修改注册表（推荐，一劳永逸）

这是微软在该更新说明中官方提供的解决方案，它只关闭严格的块扩展解析，而不是回滚整个更新。

1. Win + R 打开运行，输入 regedit 回车，打开注册表编辑器。
2. 导航到以下路径：

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Http\Parameters
   

3. 在右侧空白处右键 -> 新建 -> DWORD (32位)值。
4. 将新值命名为 HttpAllowLenientChunkExtParsing。
5. 双击这个新建的值，将其数值数据设置为 1。
6. 点击确定，重启你的电脑。

完成此操作后，你的 8080 端口应该就被释放了，并且系统依然保持着该更新的其他安全修复。

方案二：卸载该更新

如果你觉得修改注册表麻烦，或者修改后问题依旧，可以选择卸载该更新。

1. 打开 设置 -> 更新和安全 -> 查看更新历史记录 -> 卸载更新。
2. 在列表中找到对应日期（例如11月11日）和描述的更新，将其卸载。
3. 重启电脑。

方案三：更改你的服务端口

这是最快捷的“绕行”方案。直接修改你本地服务的配置文件，将端口从 8080 改为其他未被占用的端口，例如 8081、8090 等。

• Spring Boot: 在 application.properties 中设置 server.port=8081
• Tomcat: 修改 conf/server.xml 中的 <Connector port="8080" ...> 为 8081

总结与反思

这次排查经历告诉我们：

1. 当常规手段失效时，要拓宽思路：当 netstat 和 taskkill 解决不了问题时，要考虑系统级别的变更，如 Windows 更新、驱动安装等。
2. 微软的更新日志是宝藏：更新日志里往往包含了问题描述和解决方案，一定要仔细阅读。
3. 推荐使用方案一：通过注册表微调特定行为，既能解决问题，又能保留系统的安全更新，是最优雅的解决方案。

希望这篇帖子能帮助到遇到同样“灵异”问题的你！如果觉得有用，欢迎点赞收藏！

---

参考链接：

• Microsoft Sysinternals TCPView：一个强大的图形化工具，可以查看所有进程的端口占用情况。