Windows 幽灵端口占用HNS 如何无声地偷走你的端口起因事情发生在调试一个本地 Python 代理服务deepseek-web-agent时。用uvicorn启动 FastAPI 服务绑定127.0.0.1:48391结果报错OSError: [WinError 10048] 通常每个套接字地址(协议/网络地址/端口)只允许使用一次。第一反应端口被占了。于是netstat-ano|grep48391空的。没有任何进程在用这个端口。换了个思路用 Python 直接试importsocket ssocket.socket(socket.AF_INET,socket.SOCK_STREAM)s.bind((127.0.0.1,48391))报错变成了OSError: [WinError 10013] 以一种访问权限不允许的方式做了一个访问套接字的尝试。10013不是 10048。这不是端口被占用而是权限拒绝。端口没人用但系统不让你绑。第一嫌疑人防火墙查看 Windows 防火墙规则Get-NetFirewallRule|Where-Object{($_.DisplayName-like*python*)-and$_.Action-eqBlock}果然找到了两条Block 规则DisplayNameDirectionActionProgramPythonInboundBlockcpython-3.11.15\python.exePythonInboundBlockcpython-3.11.15\python.exe这是 Windows 防火墙的查询用户规则 — 当程序首次尝试联网时弹窗询问如果用户选了不允许或弹窗超时Windows 就自动生成一条 Block 规则。而且Block 规则优先级高于 Allow 规则。在管理员 PowerShell 里删掉Get-NetFirewallRule|Where-Object{($_.DisplayName-like*python*)-and$_.Action-eqBlock}|Remove-NetFirewallRule满怀信心再试……还是 10013。第二嫌疑人端口排除范围Windows 有端口排除机制某些系统服务会预留端口范围netsh interface ipv4 show excludedportrange protocoltcpProtocol tcp Port Exclusion Ranges Start Port End Port ---------- -------- 5357 5357 50000 50059 * 55778 55778 *48391 不在任何排除范围内。排除嫌疑。动态端口范围也不覆盖这个区间netsh int ipv4 show dynamicport tcp# Start Port: 49152, Number of Ports: 16384关键发现大范围端口扫描到这里常规排查已经穷尽了。于是做了一件该早点做的事 —全端口扫描importsocketforportinrange(47000,49153):try:ssocket.socket(socket.AF_INET,socket.SOCK_STREAM)s.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)s.bind((127.0.0.1,port))s.close()exceptOSError:failed.append(port)结果失败范围: 47000-48715整整1716 个端口一整块全部 10013。再往其他范围扫8848: FAIL 9000-9001: FAIL 9200: FAIL 9848-9849: FAIL 9876: FAIL一些散落的知名端口也被拦了。但 8080、30000、40000、49000 全部畅通。这不是防火墙的行为模式。防火墙是按规则匹配的不会精确地只拦某个端口段。这是一种更底层的、系统级的端口预占。真凶HNSHost Network Service查看正在运行的服务Get-Service|Where-Object{$_.Status-eqRunning-and($_.Name-like*hns*-or$_.Name-like*vm*-or$_.Name-like*wsl*)}hns 主机网络服务 Running vmcompute Hyper-V 主机计算服务 Running WSLService WSL Service Running三个全在跑。HNSHost Network Service是 Windows 为 Hyper-V 和 WSL2 提供虚拟网络的核心服务。它会在启动时动态预留一大块端口范围用于 NAT、端口转发和虚拟交换机通信。关键问题是HNS 的端口预留不会出现在netsh show excludedportrange里。这是 Windows 的已知行为 — HNS 通过 WFP (Windows Filtering Platform) 直接在内核层面锁定端口绕过了传统的端口排除机制。所以你用netstat看不到、用netsh查不到、用Get-NetTCPConnection也查不到。端口表面上空闲但实际上被内核级的网络过滤器锁住了。为什么 8080 能用因为 HNS 预留的是47000-48715这个区间以及一些散落的常用端口用于内部服务通信。8080 不在这个范围内自然不受影响。解决方案方案 1换个端口推荐零成本用 49152 以上的端口这是 Windows 动态端口范围的起点HNS 通常不会碰PORT49152# 在 HNS 管辖范围之外方案 2手动预留端口需要重启在注册表中添加端口预留让系统在 HNS 之前先占住这个端口# 管理员 PowerShellnetsh int ipv4 add excludedportrange protocoltcp startport48391 numberofports10 storepersistent然后重启电脑。但问题是 HNS 可能在你重启后重新抢走这个范围。方案 3调整 HNS 配置治本但有副作用可以限制 HNS 的动态端口范围但这会影响 WSL2 和 Hyper-V 虚拟机的网络功能。除非你真的需要那些端口否则不建议动。教训netstat看不到不代表端口没被占。Windows 有内核级的网络过滤机制不走传统的端口注册。WinError 10013 和 10048 的区别很重要。10048 是端口被占用别人在用10013 是权限拒绝系统不让你用。排查方向完全不同。开了 WSL2/Hyper-V 就等于让 HNS 接管了一部分端口空间。这个在任何文档里都不会告诉你。大范围端口扫描是最有效的排查手段。当netstat和netsh都说没问题的时候直接上 Python 扫一遍几分钟就能画出完整的端口地图。Windows 的网络栈比你想象的复杂得多。防火墙、HNS、WFP、http.sys、动态端口……每一层都可能在你不知情的情况下拦截你的连接。写于 2026 年 6 月 26 日深夜在被 Windows 折磨了两个小时之后。
Windows 幽灵端口占用HNS 如何无声地偷走你的端口起因事情发生在调试一个本地 Python 代理服务deepseek-web-agent时。用uvicorn启动 FastAPI 服务绑定127.0.0.1:48391结果报错OSError: [WinError 10048] 通常每个套接字地址(协议/网络地址/端口)只允许使用一次。第一反应端口被占了。于是netstat-ano|grep48391空的。没有任何进程在用这个端口。换了个思路用 Python 直接试importsocket ssocket.socket(socket.AF_INET,socket.SOCK_STREAM)s.bind((127.0.0.1,48391))报错变成了OSError: [WinError 10013] 以一种访问权限不允许的方式做了一个访问套接字的尝试。10013不是 10048。这不是端口被占用而是权限拒绝。端口没人用但系统不让你绑。第一嫌疑人防火墙查看 Windows 防火墙规则Get-NetFirewallRule|Where-Object{($_.DisplayName-like*python*)-and$_.Action-eqBlock}果然找到了两条Block 规则DisplayNameDirectionActionProgramPythonInboundBlockcpython-3.11.15\python.exePythonInboundBlockcpython-3.11.15\python.exe这是 Windows 防火墙的查询用户规则 — 当程序首次尝试联网时弹窗询问如果用户选了不允许或弹窗超时Windows 就自动生成一条 Block 规则。而且Block 规则优先级高于 Allow 规则。在管理员 PowerShell 里删掉Get-NetFirewallRule|Where-Object{($_.DisplayName-like*python*)-and$_.Action-eqBlock}|Remove-NetFirewallRule满怀信心再试……还是 10013。第二嫌疑人端口排除范围Windows 有端口排除机制某些系统服务会预留端口范围netsh interface ipv4 show excludedportrange protocoltcpProtocol tcp Port Exclusion Ranges Start Port End Port ---------- -------- 5357 5357 50000 50059 * 55778 55778 *48391 不在任何排除范围内。排除嫌疑。动态端口范围也不覆盖这个区间netsh int ipv4 show dynamicport tcp# Start Port: 49152, Number of Ports: 16384关键发现大范围端口扫描到这里常规排查已经穷尽了。于是做了一件该早点做的事 —全端口扫描importsocketforportinrange(47000,49153):try:ssocket.socket(socket.AF_INET,socket.SOCK_STREAM)s.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)s.bind((127.0.0.1,port))s.close()exceptOSError:failed.append(port)结果失败范围: 47000-48715整整1716 个端口一整块全部 10013。再往其他范围扫8848: FAIL 9000-9001: FAIL 9200: FAIL 9848-9849: FAIL 9876: FAIL一些散落的知名端口也被拦了。但 8080、30000、40000、49000 全部畅通。这不是防火墙的行为模式。防火墙是按规则匹配的不会精确地只拦某个端口段。这是一种更底层的、系统级的端口预占。真凶HNSHost Network Service查看正在运行的服务Get-Service|Where-Object{$_.Status-eqRunning-and($_.Name-like*hns*-or$_.Name-like*vm*-or$_.Name-like*wsl*)}hns 主机网络服务 Running vmcompute Hyper-V 主机计算服务 Running WSLService WSL Service Running三个全在跑。HNSHost Network Service是 Windows 为 Hyper-V 和 WSL2 提供虚拟网络的核心服务。它会在启动时动态预留一大块端口范围用于 NAT、端口转发和虚拟交换机通信。关键问题是HNS 的端口预留不会出现在netsh show excludedportrange里。这是 Windows 的已知行为 — HNS 通过 WFP (Windows Filtering Platform) 直接在内核层面锁定端口绕过了传统的端口排除机制。所以你用netstat看不到、用netsh查不到、用Get-NetTCPConnection也查不到。端口表面上空闲但实际上被内核级的网络过滤器锁住了。为什么 8080 能用因为 HNS 预留的是47000-48715这个区间以及一些散落的常用端口用于内部服务通信。8080 不在这个范围内自然不受影响。解决方案方案 1换个端口推荐零成本用 49152 以上的端口这是 Windows 动态端口范围的起点HNS 通常不会碰PORT49152# 在 HNS 管辖范围之外方案 2手动预留端口需要重启在注册表中添加端口预留让系统在 HNS 之前先占住这个端口# 管理员 PowerShellnetsh int ipv4 add excludedportrange protocoltcp startport48391 numberofports10 storepersistent然后重启电脑。但问题是 HNS 可能在你重启后重新抢走这个范围。方案 3调整 HNS 配置治本但有副作用可以限制 HNS 的动态端口范围但这会影响 WSL2 和 Hyper-V 虚拟机的网络功能。除非你真的需要那些端口否则不建议动。教训netstat看不到不代表端口没被占。Windows 有内核级的网络过滤机制不走传统的端口注册。WinError 10013 和 10048 的区别很重要。10048 是端口被占用别人在用10013 是权限拒绝系统不让你用。排查方向完全不同。开了 WSL2/Hyper-V 就等于让 HNS 接管了一部分端口空间。这个在任何文档里都不会告诉你。大范围端口扫描是最有效的排查手段。当netstat和netsh都说没问题的时候直接上 Python 扫一遍几分钟就能画出完整的端口地图。Windows 的网络栈比你想象的复杂得多。防火墙、HNS、WFP、http.sys、动态端口……每一层都可能在你不知情的情况下拦截你的连接。写于 2026 年 6 月 26 日深夜在被 Windows 折磨了两个小时之后。
