1. 先把现象说透什么样才算是“PermissionError 10013”1.1 完整报错长什么样直接看控制台最后几行通常长这样!!! Exception during processing !!! Traceback (most recent call last): ... PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions.如果你用的是秋叶整合包报错可能出现在启动阶段控制台窗口滚动几行后就卡住然后退出原生环境跑python main.py也一样。10013 这个错误码对应的其实是 WSAEACCES意思是“以访问权限禁止的方式访问套接字”。很多人第一反应是端口被占用于是去用netstat -ano查端口结果发现压根没有进程监听。然后换端口8188 不行换 81908190 不行换 88888888 不行换 6006……最后发现全都报一模一样的 10013。这时候问题基本可以确定不是“端口冲突”而是 Windows 权限层面对你绑定的这整批端口都做了限制。我建议你先做一个最小化复现确认问题存在且与 ComfyUI 本身无关。用一个极简的 Python socket 脚本去绑定报错端口import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: s.bind((127.0.0.1, 8188)) print(bind 8188 ok) except PermissionError as e: print(bind 8188 failed:, e)如果这个三行脚本在同样端口上也抛出 10013那说明你的系统环境在当前开机状态下就不允许普通用户进程碰这些端口。这时候再去折腾 ComfyUI 的工作流、节点、模型全都是白费功夫。1.2 为什么换了好几个端口还是一样报错关键在于10013 属于“权限错误”不是“占用错误”。端口被另一个进程监听时Windows 通常返回的是 WinError 10048表示“地址已被使用”netstat 里也能看到 LISTENING 状态。而 10013 的意思是Windows 根本不允许你这个进程去碰这一段端口可能是端口落在系统保留段里可能是安全软件拦截了 Socket 调用也可能是端口策略限制。为了说清楚这个区别我把几个初学者容易混淆的 WinError 码整理成一张表排查时先对号入座错误码WSA 名称含义常见场景10013WSAEACCES权限禁止访问套接字端口落在系统排除范围、安全软件拦截10048WSADDRINUSE端口已被占用端口被其他进程监听netstat 能查到10049WSAEADDRNOTAVAIL地址不可用端口号超出 0-65535或绑定了错误的 IP 地址10061WSAECONNREFUSED连接被拒绝目标端口没有服务在监听但这不是 bind 阶段报错你可以这么理解10048 是“这套房子已经有人住了”10013 是“物业根本不给你这套房子的钥匙”。很多网上的排查教程只教你查房子有没有人住根本没解决“为什么不给你钥匙”的问题。1.3 为什么“昨天还能用今天突然全不行”这个问题在开启 Hyper-V、WSL2 或者“虚拟机平台”相关功能的机器上尤其常见。系统每次开机时会为 NAT/ICS 等虚拟化网络服务动态保留一段 TCP 端口范围这段范围不是固定的可能今天保留的是 30000-40000明天就变成 45000-55000。所以你昨天用 5001 端口跑得好好的今天开机后 5001 恰好落在新的保留段里于是 ComfyUI 启动就报 10013。你以为是自己改错了配置其实什么都没变变的是系统内核的端口分配策略。这也是为什么这个坑特别容易让人怀疑人生。2. 根因分析谁把端口“焊死”了2.1 Windows 动态端口保留段最大嫌疑Windows 系统从 Vista 开始会维护一份“端口排除范围表”ExcludedPortRange。这份表里的端口普通用户态进程是不能 bind 的。你可以把它理解成已经划给内部系统使用的“内部车位”即使停车位上没有车也不允许你停进去。这个范围不仅包含 80、443 这类常见服务端口还可能包含一大段随机的高位端口。我在一台公司电脑上遇到过排除范围直接是39950-65535整整两万多个端口全军覆没包括 ComfyUI 想用的 8188。你换端口根本换不过来因为所有常用端口都在同一段范围内。查询方法很简单管理员身份打开 CMD 或 PowerShell执行netsh interface ipv4 show excludedportrange protocoltcp输出大致长这样协议 tcp 端口排除范围 开始端口 结束端口 ---------- -------- 80 80 443 443 2869 2869 39950 65535如果你的 ComfyUI 端口正好落在某个“开始端口-结束端口”区间内那就是撞上保留段了。注意这个表是开机动态生成的重启之后很可能变化所以不要拿网上别人贴的端口段套到自己机器上。2.2 Hyper-V / WSL2 带来的“重启随机排除”很多人的电脑上根本没主动装 Hyper-V但 Windows 功能列表里默认勾选了“虚拟机平台”“Windows Hypervisor Platform”WSL2 也要依赖这些组件。只要相关服务存在开机时系统就会为 NAT/ICS 预留一段端口。这个动态排他行为是导致“多端口绑定全部报错”的核心原因之一。因为保留段往往覆盖的是一个连续大段比如 40000-60000你换端口时只要换的还是这段区间内结果都一样。网上有些教程让你干脆关掉 Hyper-V但如果你在用 WSL2 或 Docker 虚拟化关了也会影响其他工作不一定是最优解。比较务实的做法是先接受“保留段存在”的事实然后用一个脚本在当前开机状态下扫描出真正可用的端口直接把 ComfyUI 切到那个端口上跑而不是去跟系统抢地盘。2.3 安全软件与防火墙的“误杀”另一种常见原因是国产安全软件、杀毒软件把 Python 或 ComfyUI 当成了“恶意监听程序”。它们会注入到 Socket 调用链里在 bind 阶段直接返回权限不足。这种问题表现与系统保留段一模一样但实际跟端口号无关换到任何端口都会报错。最典型的现象是同一台电脑上你用 PowerShell 跑一个简单的 Python HTTP 服务完全正常但双击秋叶整合包启动就报 10013。这是因为整合包里的python_embeded目录被安全软件专门盯着或者安全软件对“程序自动开启监听端口”这个行为有默认拦截策略。如果你发现换端口无效且excludedportrange查到的排除段并没有覆盖你使用的端口那么请优先检查安全软件。不要直接卸载而是打开它的“网络防护/访问保护”日志看有没有拦截记录。有些软件要在“信任区”里添加 ComfyUI 的启动目录才能放行。2.4 一个最容易忽略的原因ComfyUI 启动参数被整合包覆盖如果你用秋叶整合包先别急着改系统还有个大坑很多人以为改 ComfyUI 配置里的端口就行但秋叶包通过“启动ComfyUI.bat”脚本启动时会用脚本里的参数去覆盖默认值。你以为改了配置文件其实启动脚本压根没读那一层。所以在改端口之前一定要确认端口到底是从哪一层传入的直接命令行运行 ComfyUI端口参数来自你在终端敲的--port秋叶整合包双击运行端口参数来自“启动ComfyUI.bat”里的 set 变量或命令行某些第三方启动器端口参数可能来自启动器界面里的设置项。最好的确认方式不是猜而是看启动日志。ComfyUI 启动时会打印类似Starting server at 127.0.0.1:8188这个日志里显示哪个端口才是真正绑定的端口。如果你日志里显示的还是 8188那说明你改的配置可能根本没被加载。3. 实操从诊断到解决的完整链路3.1 第一步查清本机端口占用与保留段打开管理员权限的 PowerShell 或 CMD依次执行下面三条命令netstat -ano | findstr :8188netsh interface ipv4 show excludedportrange protocoltcpnetsh http show urlacl第一条看端口占用第二条看系统 TCP 排除范围这是最关键的一步第三条看 HTTP.sys 的 URL 保留项。虽然 ComfyUI 用的是原生 socket不走 HTTP.sys但顺手看一眼能排除干扰项。查完之后重点观察excludedportrange的输出。如果你要用的端口 8188 没有落在任何“开始端口-结束端口”区间内那么排除范围这个因素可以先放一边继续查安全软件和启动参数。3.2 第二步用一键扫描脚本找到“能用的端口”不要手动一个端口一个端口试写个几十行的 Python 脚本把候选端口段全部探测一遍。ComfyUI 常用端口集中在 8000 到 9000 附近但为了稳妥可以扫 5000 到 10000。import socket for port in range(5000, 10001): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: s.bind((127.0.0.1, port)) print(f{port} 可用) s.close() break except PermissionError: print(f{port} 被系统拒绝) except OSError as e: print(f{port} 其他错误: {e})脚本会依次尝试 bind碰到 10013 就跳过碰到能绑定的端口就打印并停在那里。这样找到的第一个“绿灯端口”就是当前开机状态下确定能用的端口。我实测下来这个方法在 Hyper-V 保留段随机变化的情况下最省事。不要迷信任何一个固定的“推荐端口”因为你的系统保留段跟我的可能完全不同。每次开机后花十秒扫一次比翻网上各种教程都靠谱。3.3 第三步修改 Windows TCP 动态端口范围如果扫描发现可用端口很少或者你不想每次开机都碰运气可以手动修改 TCP 动态端口范围。在管理员权限下执行netsh int ipv4 set dynamicportrange protocoltcp start49152 num10000这条命令的意思是把“动态端口范围”设置成从 49152 开始连续 10000 个端口。计算一下结束端口49152 10000 - 1 59151。也就是说动态端口范围变成 49152-59151。为什么要这样设置因为系统原本的默认动态范围是 49152-65535Hyper-V 和 WSL2 在开机时最容易保留这段区域里的子区间。你手动把动态范围收窄到 49152-59151系统在分配临时端口时会避开 59152-65535Hyper-V 即便想保留高位段对 ComfyUI 要使用的 5002、6006 这类端口影响也会小一些。不过要注意命令执行后并不代表所有保留段立刻消失Hyper-V 的排他段是内核层动态计算的。有些人执行完就生效有些人需要重启一次才生效。更稳妥的做法是把这一步跟扫描脚本结合改完范围后重新跑一遍扫描看可用端口有没有变多。3.4 第四步给 ComfyUI 指定新端口原生启动/秋叶整合包原生 Python 环境启动加--port参数即可python main.py --port 5002如果还要局域网访问再加--listen 0.0.0.0python main.py --listen 0.0.0.0 --port 5002秋叶整合包不太一样不要直接改某个配置文件而是用文本编辑器打开“启动ComfyUI.bat”找到类似下面的内容set PORT8188或者python_embeded\python.exe -s ComfyUI\main.py --port 8188把这里的 8188 改成你扫描到的可用端口比如 5002保存后重新双击启动。不要在 CMD 窗口里临时输入变量值因为秋叶包每次启动都会重置。如果你用的是 ComfyUI Desktop 或者其他启动器端口一般在 Settings 里的 Server 页面设置注意看界面上有没有“Port”字段改完后重启服务。3.5 第五步验证与固化配置启动成功后观察日志里是否出现Starting server at 127.0.0.1:5002同时浏览器访问http://127.0.0.1:5002能出现 ComfyUI 界面就算通了。如果只是单次命令行启动建议把参数固化到一个启动脚本里比如新建一个start_comfyui_with_port.batecho off cd /d D:\comfyui python_embeded\python.exe -s ComfyUI\main.py --port 5002 --listen 0.0.0.0 pause以后启动不用每次敲命令省得哪次手滑又回到 8188。这个脚本建议放在和“启动ComfyUI.bat”同级的目录不要覆盖秋叶包自带的启动脚本否则下次整合包更新时会被还原。4. 常见问题速查与避坑实录4.1 端口明明显示空闲为什么还是 10013网上很多教程会让你用netstat -ano确认端口没被占用然后告诉你“没占用就是能用”这是误导。netstat只能看到当前的 LISTENING 连接看不到系统保留段。你拿excludedportrange一查可能那个端口正躺在一个巨大保留区间里。比如我另外一台电脑excludedportrange显示2869-2869单看 netstat 一切正常但 bind 这个端口的程序一律报 10013。因为 2869 是 Windows 为某些设备服务保留的端口但系统不会显示任何进程在监听它。所以排查 10013 时第一命令应该是查排除范围而不是查 netstat。顺序反了你就会在错误的方向上绕很久。4.2 修改动态端口范围后要不要重启我实测过部分机器上执行netsh int ipv4 set dynamicportrange后立即生效但也遇到过需要重启的情况尤其是当 Hyper-V 的 NAT 服务已经把排除段加载到内核里之后。稳妥起见改完先不重启直接重新扫描一次端口如果问题依旧再重启一次。别反复重启浪费时间先看扫描结果。另外不要轻易尝试netsh int ipv4 reset这种重置协议栈的命令影响面太大有可能把虚拟网卡、WSL 网络全部搞乱。4.3 秋叶整合包自定义端口的老坑如果你在秋叶包里改了端口还是报 10013建议打开启动 bat 看几件事启动脚本是不是通过set PORT8188设置端口是不是存在多个 bat 文件比如“启动ComfyUI.bat”和“启动ComfyUI-CN.bat”你改了一个另一个还在用老端口控制台日志里显示的端口是不是你以为的那个避免端口没生效的错觉。秋叶包的启动脚本还经常自带--auto-launch它会自动打开浏览器访问http://127.0.0.1:8188。如果你改了端口这个自动打开的地址不一定跟着变所以不能只看浏览器打开没打开要看控制台日志里打印的实际监听端口。4.4 局域网访问和“--listen 0.0.0.0”会引发权限问题吗--listen 0.0.0.0本身不会导致 10013但如果你的网卡启用了“为启用的网络协议绑定服务”一类的策略或系统防火墙对非本机回环地址有额外限制可能出现诡异问题。不过绝大多数情况下10013 还是出在保留端口上。你可以先用--listen 127.0.0.1只绑回环地址测试如果这样不报错而0.0.0.0报错再去检查防火墙和虚拟网卡配置。反之如果回环地址也报错那就别在 bind 参数上浪费时间回到端口保留段和安全软件这两个大方向排查。4.5 扫雷清单这些操作千万别做别在系统正在跑 Hyper-V 虚拟机时强行去改排他端口范围改不好会把虚拟机网络搞挂。别为了抢端口去关掉系统关键服务比如HNS、HttpLogger这些关了之后网络栈容易出问题。别看到网上说“删除 urlacl”就去执行netsh http delete urlacl对 ComfyUI 这种原生 socket 程序基本没用删错了反而影响其他依赖 HTTP.sys 的服务。别用 Python 里的SO_REUSEADDR强行绕过保留段Windows 对这个选项的语义跟 Linux 不同重复绑定可能返回 10013 或其他权限错误解决不了根本问题。别在没确认保留段的情况下继续换端口因为如果你换的端口都在同一个被保留的大区间里换一百次也没用。这一套流程走下来我自己最后的做法是把秋叶启动 bat 里的端口改成扫描出来的可用端口同时在系统层面保留 Hyper-V 不动。说实在的最简单的长期方案就是“每次开机后花十秒扫描一次端口然后用扫描结果启动”。那个一键扫描脚本我已经存成固定工具了。如果你也被这个 10013 折腾到怀疑人生这招是真的能救命。