最近在自己的 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 protocol=tcp回车之后，你会看到类似这样的输出：
协议 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 protocol=tcp | 查看系统保留的 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 卡过。如果你不想写脚本，手动按我这篇文章的步骤操作，其实也够用了。
