💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
💡 背景 一直在 WSL2 里面使用 codex-cli ，近期看到 Windows 端 App 支持联动手机 App 并能控制电脑，便打算安装体验一下。 代理软件使用 Clash 。 由于 Clash 的 TUN 模式 对 WSL2 的网络影响非常大，因此不考虑开启 TUN 模式。 不希望开启全局的 系统代理（ System Proxy ） 模式。 最终选择使用 Proxifier 进行进程级的代理接管。 ❌ 踩坑过程与问题现象 尝试方案 1：Proxifier 常规配置（失败） 在 Proxifier 中添加好本地代理服务器后，配置了一条常规规则：将 codex 和 Codex.exe 加入 Target Applications 列表，Action 设为 强制走代理（ Proxy ） 。 现象： Codex 界面可以打开，但个人资料无法读取、额度用量查看不了、模型问答一直卡在 thinking 状态。查看 Proxifier 日志未发现明显异常。 尝试方案 2：使用 .env 配置文件（失败） 关掉 Proxifier ，尝试在 Codex 目录中添加 .env 配置文件并写入代理环境变量（如 HTTP_PROXY / HTTPS_PROXY ）。 现象： Codex 打开速度极其缓慢，随后依然无法查看用量、个人资料，且 完全无法连接手机 APP 。 痛点： 坚决不想用系统代理，同时由于 WSL2 的存在，也无法使用 TUN 模式，一时间陷入僵局。 🔍 转机与排查思路 网上关于这个客户端类似问题的资料极少，各类 AI （ Gemini 、ChatGPT 、豆包等）给出的方案也大多是陈词滥调（比如盲目让你添加一堆别的无关进程规则），根本解决不了问题。 随后换了个提问思路： “为什么添加了 .env 代理后，部分本地服务反而无法正常打开？” AI 提示了一个关键点： Codex 的部分服务（如 UI 与后端核心进程的通信、手机 App 的本地配对等）会走本地回环（ Localhost ）。如果一股脑全把流量送去代理服务器，会导致本地通信死循环或被代理软件拦截。 这也是为什么别的帖子让人加一堆乱七八糟的进程规则都踩坑的原因——方向错了。 ✅ 解决方案 既然知道了症结在于“本地回传流量被误代理”，解决办法就很简单了。在 Proxifier 中为 Codex 单独做一下流量分流， 将本地回环（ Localhost ）强制直连 。 Proxifier 规则配置步骤： 保留 原本让 codex / Codex.exe 走代理的规则。 新增 一条排在最前方的优先级规则（ 确保这条规则在代理规则之上 ）： Applications: codex; Codex.exe Targets (目标地址): localhost; 127.0.0.1 Action: Direct (直连) 📌 核心逻辑： 必须确保目标是本地（ Localhost ）的流量强制走 Direct （直连），其余的外网请求再走 Proxy （代理）。 🎉 结果验证 保存规则并重新打开 Codex ，一切恢复正常： 界面秒开，展现速度极大提升。 个人资料、额度用量读取完全正常。 手机 APP 连接与电脑操控一切正常！ 总结： 遇到类似独立客户端网络异常时，除了盯着外网规则，不妨看一眼是不是本地回环（ Localhost ）被代理误伤了。希望这个思路能帮到遇到类似困境的朋友，少走弯路！
现在 desktop 做的这么好，大家在用 window 的时候还会用 wsl2 吗，现在好像只有 desktop 也很好用了
现在 desktop 做的这么好，大家在用 window 的时候还会用 wsl2 吗，现在好像只有 desktop 也很好用了
现在 desktop 做的这么好，大家在用 window 的时候还会用 wsl2 吗，现在好像只有 desktop 也很好用了
现在desktop做的这么好，大家在用window的时候还会用wsl2吗，现在好像只有desktop也很好用了 20 个帖子 - 10 位参与者 阅读完整话题
大伙都是怎么选择的呢？ 我看刚出了windows destop客户端 不知道该怎么选 10 个帖子 - 9 位参与者 阅读完整话题
最近想在我的 Windows 电脑上同时也安装 OpenClaw和 Hermes Agent 这两个本地AI工具，折腾半天有点纠结安装方式，想听听有经验的老哥们建议。 我的需求： • 主要在 Windows 日常使用，想尽量稳定、少踩坑 • 希望两个工具都能正常跑起来，性能不要太拉 • 以后可能还会加其他本地工具，所以最好有较好的扩展性 目前考虑的三种方案： 1. 纯 Node / 原生安装 —— 最简单，但担心 Windows 兼容性问题（尤其是 OpenClaw 的工具链） 2. WSL2（Ubuntu） —— 看起来兼容性最好，Linux 环境跑 Node/Bun/pnpm 很顺 3. Docker —— 隔离性强，环境干净，但性能和文件映射会不会麻烦？ Hermes Agent 官方说 Windows 原生支持（PowerShell 一键安装），但 OpenClaw 似乎更推荐 WSL2。 已经装好的朋友们，能分享下你们的实际方案吗？ • 你用的是哪种方式？ • 踩过什么坑？ • 两个工具一起用的时候有没有冲突？ • 日常维护和性能表现如何？ 感谢大佬们指点！ 5 个帖子 - 3 位参与者 阅读完整话题
环境概述： ide: VSCode OS: WSL2 on Win11 背景说明：由于codex此前的更新，对于部分未配置(codex-auto-review)的中转站，Codex VSCode设置permission为Approve for me时，会遇到错误 尝试操作： 在CCSwitch新版(3.16.1)中为Codex启用路由后添加模型codex-auto-review无效 实际问题：是否需要引入Axonhub之类的进行模型映射？以及有哪些解决方案呢？提前感谢佬们的回答 6 个帖子 - 3 位参与者 阅读完整话题
WSL2 Kali Linux 使用 Clash Verge 代理的网络配置教程 背景 最近实在是受不了win原生的垃圾命令行了，而又没有mac，所以我想着着手转wsl做开发，没想到wsl的网络配置极其诡异，折腾了一整晚上才找到一个比较完美的配置方案，所以把它整理下来分享给需要的佬友。 注：使用了codex和gemini辅助整理了我配置的整个流程，后来测试发现这套这对kali的网络配置方案在wsl ubuntu上一样好用。 本机环境： Windows 上运行 Clash Verge / Mihomo。 WSL2 中安装 Kali Linux。 WSL2 使用 NAT 网络模式。 Clash Verge 代理端口为 7897 。 Kali 默认用户为 hackx 。 遇到的问题： Kali Linux 中访问网络时偶尔卡住。 使用 Ctrl-C 中断后再次执行同一命令，经常又能恢复正常。 国内外网站都可能出现间歇性连接超时。 排查结论： Windows 侧 Clash Verge 代理端口 127.0.0.1:7897 正常。 Kali 默认 DNS 指向 10.255.255.254 ，域名解析结果会出现 198.18.x.x fake-ip 地址。 Kali 默认直连路径 50 次测试中出现 5 次连接超时。 Kali 显式走宿主机 Clash 代理 http://172.25.128.1:7897 后，50 次测试全部成功。 因此，建议保留 WSL2 NAT 模式，并在 Kali 中默认配置 HTTP/HTTPS 代理。 不推荐的方案：mirrored 网络模式 曾尝试将 %UserProfile%\.wslconfig 改为： [wsl2] networkingMode=mirrored dnsTunneling=true autoProxy=true 执行 wsl --shutdown 后，Kali 启动时报错： ConfigureNetworking/0x8007054f networkingMode Mirrored ... fallback to networkingMode None 结果是 Kali 中只剩 lo 回环网卡，网络不可用。因此当前机器不建议继续使用 mirrored 模式。 Windows 侧 WSL 配置 文件位置： C:\Users\Lenovo\.wslconfig 推荐保持 NAT 配置： [wsl2] networkingMode=nat memory=8GB processors=4 swap=2GB localhostForwarding=true 修改后执行： wsl --shutdown 然后重新打开 Kali。 备份 Kali 的 bashrc 在修改 Kali 用户配置前，先备份： cp ~/.bashrc ~/.bashrc.backup-$(date +%Y%m%d-%H%M%S) 本次实际备份文件为： /home/hackx/.bashrc.backup-20260515-223308 配置 Kali 默认走 Clash Verge 代理 编辑 Kali 中的： ~/.bashrc 将下面配置放到 .bashrc 靠前位置，最好放在这段之前： # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac 代理配置如下： # WSL host Clash Verge proxy. # Uses the current WSL default gateway so it continues to work after WSL restarts. if command -v ip >/dev/null 2>&1; then WSL_HOST="$(ip route | awk '/default/ {print $3; exit}')" if [ -n "$WSL_HOST" ]; then export http_proxy="http://${WSL_HOST}:7897" export https_proxy="$http_proxy" export HTTP_PROXY="$http_proxy" export HTTPS_PROXY="$https_proxy" export no_proxy="localhost,127.0.0.1,::1" export NO_PROXY="$no_proxy" fi fi 说明： WSL_HOST 会自动读取 WSL2 默认网关，例如 172.25.128.1 。 7897 是当前 Clash Verge / Mihomo 监听的 HTTP 代理端口。 WSL2 每次重启后网关 IP 可能变化，所以不要把 172.25.128.1 写死。 no_proxy 用于避免本机地址走代理。 让当前 shell 立即生效： source ~/.bashrc 新打开的 bash 会话会自动生效。 验证配置 查看代理环境变量： echo "$http_proxy" echo "$https_proxy" echo "$no_proxy" 预期类似： http://172.25.128.1:7897 http://172.25.128.1:7897 localhost,127.0.0.1,::1 检查 Clash 代理端口是否可达： host=$(ip route | awk '/default/ {print $3; exit}') timeout 3 bash -lc "</dev/tcp/$host/7897" && echo proxy_tcp_ok || echo proxy_tcp_fail 预期： proxy_tcp_ok 测试国内网站： curl -k -L -I https://www.baidu.com/ curl -k -L -I https://www.qq.com/ curl -k -L -I https://mirrors.aliyun.com/ 测试国外网站： curl -k -L -I https://www.google.com/generate_204 curl -k -L -I https://github.com/ curl -k -L -I https://www.cloudflare.com/ 也可以查看耗时： curl -k -L -sS --connect-timeout 5 --max-time 12 \ -o /dev/null \ -w 'code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} total=%{time_total}\n' \ https://github.com/ 如果 dns 和 connect 都非常小，例如： code=200 dns=0.000016 connect=0.000269 total=2.124553 说明 curl 已经通过环境变量使用了本地代理。 适用范围 这种方式会让支持 http_proxy / https_proxy 环境变量的软件默认走代理，包括： curl wget git 的 HTTP/HTTPS 请求 很多 Python、Node.js、Go 的 HTTP 客户端 部分包管理器，例如配合 sudo -E apt update 这种方式不会代理所有网络流量，例如： ping ssh 原始 TCP/UDP 程序 不读取代理环境变量的软件 DNS 查询本身 如果某个程序不识别环境变量，需要在该程序自己的配置里单独设置代理。 apt 使用建议 普通用户环境变量不会默认传给 sudo 。如果需要让 apt 使用代理，可以使用： sudo -E apt update 如果希望 apt 永久使用代理，可以创建 apt 配置文件： sudo nano /etc/apt/apt.conf.d/95proxies 写入： Acquire::http::Proxy "http://172.25.128.1:7897/"; Acquire::https::Proxy "http://172.25.128.1:7897/"; 但不建议写死网关 IP。更通用的做法是优先用 .bashrc 的动态环境变量，再通过 sudo -E 执行。 回滚方法 如果要恢复 .bashrc ： cp ~/.bashrc.backup-20260515-223308 ~/.bashrc source ~/.bashrc 如果要临时取消当前 shell 的代理： unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY 如果误改了 Windows 的 .wslconfig ，恢复 NAT： [wsl2] networkingMode=nat memory=8GB processors=4 swap=2GB localhostForwarding=true 然后在 PowerShell 中执行： wsl --shutdown 最终建议 当前机器上最稳定的方案是： Windows 侧保持 WSL2 NAT。 Clash Verge 保持运行，确保 7897 端口可用。 Kali 的 ~/.bashrc 中动态读取 WSL 默认网关。 默认导出 http_proxy / https_proxy ，让常用 HTTP/HTTPS 工具走宿主机代理。 这种方案绕开了 WSL2 默认直连路径里偶发卡住的问题，同时不需要修改系统级全流量代理。 6 个帖子 - 6 位参与者 阅读完整话题
最近想认真把 WSL2 配起来，当成主力开发环境用。 主要原因是现在很多 CodeAgent ，比如 Claude Code 、Codex 、Gemini CLI 、Harnss 这类东西，感觉放在 Linux 环境里会更自然一点。跑命令、装依赖、跑测试、读写项目文件，应该都比在 Windows 原生环境下少一点奇怪问题。 但我平时又不是纯 CLI 开发，有时候会用 Windows 上的 desktop 软件，比如 VS Code 、Cursor 、浏览器、文件管理器，还有一些其他 GUI 工具。 所以现在有点纠结，想问问大家实际怎么搭工作流。 我目前想到的方案是： 项目放 WSL2： /home/me/projects/xxx Agent 也在 WSL2 里跑： Claude Code / Codex / Harnss / 其他 CLI agent Windows 这边负责图形界面： VS Code / Cursor 用 Remote WSL 文件管理器通过 \wsl.localhost 访问 需要的时候在 WSL 里 explorer.exe . 这样看起来比较合理，但是还有几个点不太确定： 1.如果 Windows desktop 软件不支持 Remote WSL ，直接打开 \wsl.localhost\Ubuntu\home\me\projects\xxx 会不会很难用？ 2.agent 跑在 WSL2 里，想打开 Windows 浏览器或者控制 Chrome ，一般是怎么做？ Playwright MCP ？ Chrome DevTools MCP ？ 3.有没有人试过 Harnss 跑在 WSL2 里，然后 GUI 通过 WSLg 显示到 Windows ？ 4.项目到底应该坚持放 WSL 的 /home ，还是为了兼容 Windows 软件放 /mnt/c ？ 5.有没有什么比较舒服的“WSL2 + Windows desktop + AI coding agent”的完整方案？ 我个人倾向是把 WSL2 当主开发机，Windows 当图形外壳。 但还没实战太久，想听听大家有没有更成熟的方案，或者有没有什么坑需要提前避开。