最近在自己的 Windows 开发机上跑 Codex遇到一个很典型的套接字权限错误failed to start login server: 以一种访问权限不允许的方式做了一个访问套接字的尝试。 (os error 10013)。这个报错我在社区里看到不少人问过但很多答案只说个大概要么让你换端口要么让你关防火墙却没有把背后的原因讲透。我前前后后折腾了两天把 Windows 下常见的触发条件和有效解法都跑了一遍今天把完整的排查思路和可复现的方案写下来希望能帮你少走几个弯路。如果你在用命令行 AI 编程工具的时候终端里突然冒出这句“无法启动登录服务器”大概率不是 Codex 本身的问题而是 Windows 的端口绑定权限被系统拦住了。简单说Codex 的登录服务要在本机开一个本地端口做登录回调但这个端口因为权限、保留规则或占用冲突没有绑定成功于是整个登录流程卡死。下面我按从易到难的顺序把我知道的方案逐个拆开讲清楚。1. 问题现象与根因分析1.1 报错出现的典型场景我遇到的情况是这样的在 PowerShell 里输入启动命令后Codex 准备进入登录流程会先拉起一个本地登录服务然后提示用户打开浏览器完成授权。结果还没到浏览器那一步终端直接抛出一段错误说登录服务启动失败错误码是 10013。注意这里的failed to start login server是它自己的提示真正有用的信息是后面那句“以一种访问权限不允许的方式做了一个访问套接字的尝试”以及括号里的os error 10013。在 Windows 平台这个错误码对应的就是WSAEACCES也就是套接字层面的访问被拒绝。常见于两种场景一是当前进程没有足够权限去绑定某个端口二是要绑定的端口被系统保留、被其它进程占用或是被防火墙/安全软件拦截。我在不同机器上测试过排在第一的原因其实不是权限不够而是端口被 Windows 的“保留端口段”占了。这个问题非常隐蔽因为你用netstat查端口占用可能什么都查不到但系统就是告诉你没权限写入。1.2 为什么会出现 10013端口保留与权限策略Windows 从某个版本开始会因为 Hyper-V、WSL2、Windows 沙盒等虚拟化功能在系统层面保留一段 TCP 端口。这样做的理由是给 NAT 和 DHCP 这类内部服务预留可用的动态端口区间。问题是保留的范围往往不是小端口而是动态生成的一大段。比如你的 Codex 刚好落在某个保留范围内就会触犯“访问权限不允许”的规则报出 10013。更坑的是这个保留区间不是固定的可能每次开机都不一样所以今天能用明天可能就挂了。另一个常见原因是权限级别。如果你在普通权限的终端里运行 Codex而它需要绑定 1024 以下的端口或者要绑定一个已经被系统服务占用的端口同样会报 10013。还有少数情况是安全软件拦截了套接字创建或者另一个程序抢先绑定了同一个端口。下面我会按这几类原因分别给你对应的操作步骤。2. 方案一用管理员权限运行并更换端口2.1 先做最简单的验证管理员身份启动虽然听起来老套但这确实是我实际测试中最快能确认问题方向的一步。右键点击开始菜单里的“Windows PowerShell”或“终端”选择“以管理员身份运行”然后再次输入启动 Codex 的命令。如果登录服务能正常拉起来那基本可以断定是权限级别不够。这种情况常见于系统开启了 UAC 强化或者你当前登录的账户是标准用户而不是管理员。如果你确实需要管理员权限才能跑但又不想每次都有 UAC 弹窗可以给 Codex 的启动快捷方式手动设置“以管理员身份运行”。在桌面或开始菜单找到快捷方式右键点属性在“兼容性”选项卡里勾选“以管理员身份运行此程序”。这个设置对后面每次启动都生效但要注意如果 Codex 在工作目录里生成文件权限变化可能导致一些缓存目录的读写路径不一致需要留意。2.2 给 Codex 换一个端口很多这类工具支持通过环境变量或启动参数指定登录服务的监听端口。我用的 Codex 版本支持在启动命令后面加端口参数具体参数名你可以先敲一下codex --help或查看官方文档确认。如果支持建议直接指定一个高位端口比如 8000、1455 或 8080避开系统动态保留的高风险区间。注意选端口的时候不要选 5000 和 6000 这类常见程序默认端口容易撞车。实际操作中我一般用环境变量方式设置比如在 PowerShell 里先设置$env:CODEX_LOGIN_PORT 1455再执行启动命令。如果工具没有提供端口配置选项也可以用 PowerShell 的端口转发功能把本地端口转发到另一个高位端口但这样配置比较绕通常只在没有自带端口参数时才需要。总之先尝试显式指定一个端口很多情况下这一步就能解决问题。3. 方案二清理 Windows 端口保留规则3.1 查看系统排除了哪些端口段如果你切换到管理员权限还是报 10013而端口号也换过还是不行那就要去看看 Windows 是不是把这块端口区间保留掉了。用管理员身份打开 PowerShell执行下面这条命令netsh interface ipv4 show excludedportrange protocoltcp回车之后你会看到类似这样的输出协议 tcp 端口排除范围 开始端口 结束端口 ---------- -------- 1300 1399 5000 5099 6000 6199这些就是系统当前保留的端口段。如果你的 Codex 登录端口正好落在某个 “开始端口” 到 “结束端口” 之间那么不管你怎么换用户权限系统都会拒绝你的套接字绑定请求报出 10013。这个原因解释起来很简单Windows 把这些端口预留给它自己的虚拟网络服务了不允许普通进程抢占。我测试时遇到过最夸张的机器保留范围从 5000 一直延续到 5499刚好把很多开发工具的默认端口全包进去了。如果你看到类似的输出而且 Codex 默认端口就在这个区间里那这就是根因。3.2 让 Hyper-V 动态保留区间让路最常见的保留区间来源是 Hyper-V、WSL2、Windows 沙盒这类功能。它们会在每次系统启动时向 TCP/IP 协议栈申请一段动态范围用来做 NAT 转发。要彻底杜绝这个问题可以考虑关闭这些虚拟化相关功能但代价是会失去 WSL2 和沙盒能力很多开发者接受不了。更靠谱的方式是让 Codex 避开这些区间。你可以反复执行上面那条查看命令记下每次开机的保留范围。因为保留区间是动态的你换一个在这个区间之外的端口就能正常启动。我个人的做法是在 Codex 的启动脚本里写一个检测逻辑先读取netsh的输出然后自动选一个不在排除范围内的端口再用这个端口启动 Codex。这样就算 Windows 重启后保留区间变了脚本也能自己匹配到可用端口。如果你不想写脚本也有一个简化方法打开“Windows 功能”面板取消勾选“Hyper-V”和“适用于 Linux 的 Windows 子系统”重启后那些保留端口段一般会消失。但这个方法只适合你确实用不到这些虚拟化功能的情况。我建议优先考虑避开保留段而不是关闭功能。3.3 使用注册表调整高危非必要不推荐网上有些教程会教你直接改注册表来固定端口范围比如给TcpPortRangeTest或ExcludedPortRange添加数值。如果你不是 Windows 内核网络这块的熟手我非常不建议乱改注册表因为会影响系统网络栈的稳定性还有可能让 NAT 功能失效。我这里不展开具体参数想深入研究的可以查微软官方文档。对于多数人来说只要把 Codex 端口换到保留段外面问题就解决了没必要冒这个风险。4. 方案三检查端口占用与防火墙拦截4.1 用 netstat 查端口被哪个进程占用有时候 10013 是因为端口被其它程序占用了尤其是某些后台服务偷偷占用了一大堆端口。和保留端口不同这种问题用管理员权限也绕不过去因为 TCP 端口同一时间只能被一个进程监听。你可以在普通 PowerShell 里执行netstat -ano | findstr 1455把1455替换成你实际设置的端口。如果输出里有记录看最后一列的 PID然后在任务管理器里找到这个 PID 对应的进程。如果确认是你的服务可以停掉它如果是系统服务最好换一个端口不要跟它抢。有一个容易踩的坑有时候你用netstat查端口没看到占用但绑定还是失败。这种情况大概率是端口处于TIME_WAIT状态。TIME_WAIT 是 TCP 连接关闭后必须等待的一段时间通常持续 30 秒到 2 分钟。在这期间重新绑定同一端口会失败。解决办法很简单等一会儿再启动或者用pidof找到旧进程先杀掉。如果频繁出现 TIME_WAIT你可以在 Codex 启动遇到冲突时换一个端口就先不用管这个了。4.2 防火墙和杀毒软件过度防御怎么放行Windows 自带的 Defender 防火墙一般不会拦本地端口绑定但第三方杀毒软件或安全卫士可能会对“命令行程序尝试监听本地端口”这类行为做限制。如果你装了这类软件并且发现其他方案都无效可以暂时把 Codex 所在目录加入信任区再重新启动。我遇到过一台机器安全软件把控制台应用的所有本地监听行为都拦了不只是端口问题连登录页面都打不开。把 Codex 的可执行文件加进白名单之后10013 就没再出现过。不过要提醒一下如果你是在公司电脑上工作安全策略可能由 IT 部门统一管理自己加白名单不一定生效。这种情况下建议直接用高位端口同时绕开可能被监控的常用端口。5. 方案四深入排查动态保留区间与 WSL2 冲突5.1 一小时内遇到多个错误码的复现我印象最深的是一次排障我在同一台机器上一小时内连续试了三个端口结果全部报 10013。当时以为是端口都占用了后来用netsh命令一查发现这三个端口全落在保留区间里面。而保留区间之所以这么大是因为这台机器同时装了 Docker Desktop 和 WSL2它们两个在启动时会各申请一段动态端口范围叠加之后就形成了巨大的禁区。如果你也遇到“换了好几个端口都不行”的情况先别急着加大范围先跑一次查看命令。我当时看到输出里从 2000 到 2999 整段被保留就知道换端口这个思路没错只是要避开这个段。后来我把端口换到了 10000 以上问题立刻消失。所以关键不是换端口而是知道系统到底把哪些端口藏起来了。5.2 避免和 Docker/WSL 的 NAT 范围重复如果机器上安装了 Docker Desktop 或 WSL2你还要考虑它们自己的 NAT 内部端口范围虽然这部分通常不会和主机 TCP 端口冲突但偶尔会出现边缘重叠。最稳妥的做法是让 Codex 的端口尽可能靠后比如 18000 到 20000 之间同时避开 5000、8000、8080 这些开发圈常用端口。经过这几轮测试我基本把端口固定在 18080 这个位置它没有被系统保留也基本不会和主流开发工具冲突。6. 常见问题速查表与排坑心得6.1 排查过程中的关键命令汇总为了方便你直接上手把这次用到的命令整理成一个表格。注意所有涉及管理员的命令都要用管理员身份打开 PowerShell 执行。命令/操作作用是否需要管理员codex --help查看工具支持的启动参数确认端口配置项否netstat -ano | findstr 1455查看指定端口是否被占用找到 PID否netsh interface ipv4 show excludedportrange protocoltcp查看系统保留的 TCP 端口段是get-service查看与 Docker/WSL 相关服务确认相关服务是否在运行否netsh winsock reset然后重启重置 Winsock 目录解决协议栈异常是关于netsh winsock reset这是我最后才知道的一个办法。如果 10013 出现得非常诡异比如没有任何端口占用、也不在保留范围、管理员权限也正常那可能是 Winsock 目录被搞坏了。执行这条命令后会要求重启重启后一般能恢复。不过用之前备份一下当前的 Winsock 状态避免某些网络配置丢失。6.2 我踩过的几个印象很深的坑第一个坑是“用管理员权限就一定能解决”的误区。实际上如果端口落在保留区间管理员权限照样报 10013因为系统不是按账户权限来拒绝而是按协议栈规则来拒绝。你必须有意识地避开那个段才行。第二个坑是“关掉 Hyper-V 就一劳永逸”。我一开始以为关了 Hyper-V 就没事了结果发现 Windows 沙盒又申请了新的动态端口。所以如果你还开着其它虚拟化组件关闭一个并不代表完全解决。后来我干脆不再纠结保留范围而是让 Codex 的端口配置自动从 21000 开始往上找才真正清净下来。第三个坑是“杀掉旧进程后马上重试”。一开始遇到失败我是直接杀掉占用端口的进程然后立即重新启动结果还是失败。后来发现是 TIME_WAIT 状态在作祟。如果你也遇到这种情况杀完进程后等一两分钟再启动大概率就成功了。第四个坑和网络环境有关某些本地网络工具会修改系统的路由表或 NAT 配置间接导致程序绑定套接字时权限检查失败。这个情况比较隐蔽光看端口和保留范围都发现不了。如果你把 Codex 跑到另一台干净机器上没有任何问题说明你自己机器上的某些网络相关工具在底层做了手脚。遇到这种情况我只能建议你排查一下新装过的网络工具或者暂时关闭它们再运行 Codex 试试。6.3 关于 Codex 登录流程的一点补充Codex 的登录服务器本质上是一个临时的本地 HTTP 服务它监听一个随机端口浏览器登录完成后会跳转到这个本地地址完成令牌接收。因此只要这个本地端口能被正常绑定登录就能继续。如果你前面所有方法都试过还是失败可以考虑换一个网络环境再试因为某些环境里系统网络策略会限制本地端口监听这个跟 Codex 本身没关系纯属运行环境限制了套接字操作。我在实际使用中发现只要端口绑定正常登录流程一般不会超过一分钟。如果你在浏览器里能正常完成授权但终端迟迟没有反应那可能是刚才的本地端口连接被外部网络环境阻断或者某个安全组件把回环连接拦了。这个时候可以检查浏览器是否能访问http://127.0.0.1:端口这个地址能访问就说明端口已经通了问题出在令牌回传阶段不能访问就还是绑定环节的问题。最后分享一个小技巧如果你经常在 Windows 上跑类似需要本地端口绑定的命令行工具可以先在系统启动时预检一次端口可用性用脚本随机挑一个可用端口再启动工具。我在自己的开发机里写了一个几十行的 PowerShell 脚本核心逻辑就是调用netsh查看排除范围然后选择一个不在范围内的端口再设置环境变量。这套方案我用了将近两个月没有再被 10013 卡过。如果你不想写脚本手动按我这篇文章的步骤操作其实也够用了。