中文界面版本#

如果英文界面不顺手，可以参考 1564307973/Proxifier-CN。这个仓库整理了 Proxifier 中文本地化包和便携版，适合对照中文菜单配置代理服务器、代理规则和 DNS 解析。

注意：

• 汉化包通常有版本适配限制，安装前先确认支持的 Proxifier 版本。
• 汉化不等于破解。Proxifier 仍是商业软件，长期使用需要正版授权。
• 如果已经安装官方新版 Proxifier，不要直接覆盖不匹配版本的汉化文件，避免程序异常。

添加代理服务器#

进入：

1
Profile -> Proxy Servers -> Add

填写本地代理：

1
Address: 127.0.0.1
2
Port: 7890
3
Protocol: SOCKS Version 5

如果你的本地 SOCKS5 端口是 1080，就改为 1080。

弹出是否设为默认代理时，建议选择“否”。不要让 Proxifier 一开始接管所有程序。

添加代理规则#

进入：

1
Profile -> Proxification Rules -> Add

为 Codex 添加规则：

1
Name: Codex
2
Applications: Codex.exe; codex.exe
3
Target Hosts: Any
4
Target Ports: Any
5
Action: Proxy SOCKS5 127.0.0.1:7890

两个进程都要包含：Codex.exe 是桌面界面，codex.exe 是后台 app-server。只代理前者时，窗口可能能打开，但“用量”、设置和对话请求会长时间等待。

不要从 Proxifier 右键菜单临时执行 Proxify Application。这种手动接管会跳过普通规则，包括 Localhost 直连规则；应当始终通过 Profile -> Proxification Rules 配置。

Claude Code 常见还需要把 Node 运行时纳入规则：

1
Name: Claude Code
2
Applications: claude.exe; node.exe
3
Action: Proxy SOCKS5 127.0.0.1:7890

如果担心 node.exe 范围太大，可以先只加 claude.exe，观察 Proxifier 日志里实际发起连接的进程，再补充更精确的路径规则。

DNS 也要走代理#

截图里的 Linux.do 经验重点是：问题不一定出在 Codex 进程没有代理，而是 DNS 解析没有按预期通过代理。

典型现象：

• 已经在 Proxifier 中加入 codex.exe，但响应非常慢。
• 需要多次 reconnect 才有响应。
• 甚至无法登录。
• 使用系统代理时也要尝试多次 reconnect。

处理方式：

1
Profile -> Name Resolution

在 Name Resolution 中：

1
关闭：Detect DNS setting automatically
2
开启：Resolve hostnames through proxy

这样让目标进程的主机名解析也通过代理完成。开启后再完全退出 Codex，并重新启动测试。

公司网络需要保留内网 DNS 时，优先使用 Resolve ONLY the following，只让下列公网域名通过代理解析：

1
*.chatgpt.com
2
*.openai.com
3
*.oaistatic.com
4
*.oaistatsig.com
5
*.oaiusercontent.com

这样不会把所有域名都交给代理端解析，也能减少对公司内网和 split DNS 的影响。

如果使用 SOCKS5，尽量选择支持远端 DNS 的方式。某些命令行工具支持 socks5h://127.0.0.1:7890，其中 h 表示 hostname 交给代理端解析；不支持时再退回 socks5://。

实测案例：Codex 可以，Claude 仍打不开#

本机配置中已经把 Codex 和 Claude 的程序路径都加入 Proxifier。现象是：

• Codex 可以正常打开。
• Claude Desktop 仍显示 Couldn't connect to Claude。
• 错误提示中出现 Your network redirected this request to www.anthropic.com。

这说明 Proxifier 的路径规则不一定有问题，真正的问题可能是名称解析仍然走了本地网络，被公司网络、DNS 策略、网关或安全软件重定向。

处理方式：

1. 打开 Proxifier 日志，确认 Claude 对 www.anthropic.com:443、claude.ai:443 或相关域名的连接是否命中代理规则。
2. 如果规则已命中，但 Claude 仍提示网络被重定向，进入 Profile -> Name Resolution。
3. 关闭 Detect DNS setting automatically。
4. 开启 Resolve hostnames through proxy。
5. 完全退出 Claude Desktop 后重新打开。

同理，Proxifier 日志里如果已经能看到类似：

1
codex.exe - chatgpt.com:443 open through proxy 127.0.0.1:7890 SOCKS5

只能说明连接动作命中了代理规则，不代表 DNS 解析一定正确。遇到发送字节但收不到响应、反复 close、应用层报网络重定向时，应继续检查名称解析。

Name Resolution 选项理解#

Name Resolution 决定“域名变成 IP”这一步在哪里发生。

常见理解：

对 Codex、Claude 这类公网 AI 工具，如果已经按进程代理但仍打不开，优先尝试 Resolve hostnames through proxy。

可能的副作用：

• 公司内网域名可能无法解析，因为代理节点不知道公司内部 DNS。
• 某些依赖本地 DNS 分流的服务可能走到错误地区或错误出口。
• 代理服务端会看到访问的域名，隐私边界从本机 DNS 转移到代理侧。
• 如果代理节点的 DNS 质量不好，可能出现解析慢、解析到不可用 IP、地区不匹配等问题。
• Windows hosts 和公司 VPN 的 split DNS 结果可能不再按预期生效。

所以不要把 Proxifier 的默认规则改成全局代理。推荐只代理 Codex、Claude 等公网 AI 工具，代理软件自身、公司内网工具、VPN 客户端和企业安全软件保持 Direct。

规则顺序#

Proxifier 规则从上往下匹配，建议：

不要把代理软件自身也放进代理规则，否则可能出现代理套代理、循环连接或节点频繁断开。

使用 Proxifier 时，让本地代理核心保持监听即可，同时关闭代理软件的“系统代理”和 TUN/虚拟网卡。多层接管会形成重复代理，常见表现就是 Codex 启动慢、用量迟迟不显示。

Codex Desktop#

完全退出 Codex 后，用 BAT 启动：

1
@echo off
2
chcp 65001 >nul
3
set HTTP_PROXY=http://127.0.0.1:7890
4
set HTTPS_PROXY=http://127.0.0.1:7890
5
set ALL_PROXY=socks5://127.0.0.1:7890
6
start "" "D:\软件\codex\Codex.exe" --proxy-server=http://127.0.0.1:7890

注意：

• 把 D:\软件\codex\Codex.exe 替换成你的真实 Codex 路径。
• Codex Desktop 是单实例应用。已经运行时再执行 BAT，只会唤醒旧进程，新的代理变量不会注入。
• 测试时先退出所有 Codex 窗口，再从脚本启动。
• --proxy-server 是 Chromium/Electron 常见启动参数，Codex 当前本地实践可用；如果后续版本行为变化，以实际验证为准。

Claude Code#

Claude Code 是命令行工具，优先在启动它的终端里设置环境变量：

1
$env:HTTP_PROXY = "http://127.0.0.1:7890"
2
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
3
$env:ALL_PROXY = "socks5://127.0.0.1:7890"
4
claude

如果希望每次 Claude Code 都带这些变量，可以写入 %USERPROFILE%\.claude\settings.json 的 env：

1
{
2
  "env": {
3
    "HTTP_PROXY": "http://127.0.0.1:7890",
4
    "HTTPS_PROXY": "http://127.0.0.1:7890",
5
    "ALL_PROXY": "socks5://127.0.0.1:7890"
6
  }
7
}

这个方式适合 Claude Code 本体和它启动的子进程。若只想临时测试，不要写入 settings.json，直接在当前终端设置环境变量即可。

Claude Desktop 或其他 Electron 应用#

如果是桌面版 Electron 应用，可以尝试用启动参数：

1
@echo off
2
chcp 65001 >nul
3
set HTTP_PROXY=http://127.0.0.1:7890
4
set HTTPS_PROXY=http://127.0.0.1:7890
5
set ALL_PROXY=socks5://127.0.0.1:7890
6
start "" "C:\Path\To\App.exe" --proxy-server=http://127.0.0.1:7890

这类参数并不是每个软件都会公开承诺支持。判断标准很简单：启动后能登录、能对话、公司网络不受影响，就保留；无效就切换到 Proxifier。

Git 配了代理，为什么 gh auth login 仍打不开#

Git 和 GitHub CLI 是两个独立的网络客户端：

即使 .gitconfig 使用不限定域名的通用 http.proxy，也只是 Git 的配置，不会自动变成 GitHub CLI、PowerShell 或 Windows 的全局代理。gh auth login 还需要先在命令行中访问 GitHub 获取设备登录信息；这一步失败时，浏览器可能不会正常打开。

GitHub CLI 没有单独的 proxy 配置项。它的 HTTP 请求使用进程继承到的 HTTP_PROXY、HTTPS_PROXY 等环境变量。如果不希望永久修改用户环境变量，可以用 PowerShell 包装函数只在 gh.exe 运行期间注入代理。

让 gh 自动复用 Git 的代理#

把下面函数加入 PowerShell 的 $PROFILE：

1
function gh {
2
    # 读取 Git 对 GitHub 最终匹配到的全局代理；
3
    # 同时支持 http.https://github.com/.proxy 和通用 http.proxy。
4
    $proxyUrl = & git.exe config --global --get-urlmatch `
5
        http.proxy `
6
        https://github.com/ 2>$null
7

8
    if ([string]::IsNullOrWhiteSpace($proxyUrl)) {
9
        Write-Warning 'Git 全局配置中没有找到 GitHub 代理，gh 将直接连接。'
10
        & gh.exe @args
11
        return
12
    }
13

14
    $proxyUrl = $proxyUrl.Trim()
15
    $oldHttpProxy = $env:HTTP_PROXY
16
    $oldHttpsProxy = $env:HTTPS_PROXY
17

18
    try {
19
        $env:HTTP_PROXY = $proxyUrl
20
        $env:HTTPS_PROXY = $proxyUrl
21

22
        & gh.exe @args
23
    }
24
    finally {
25
        [Environment]::SetEnvironmentVariable(
26
            'HTTP_PROXY',
27
            $oldHttpProxy,
28
            'Process'
29
        )
30

31
        [Environment]::SetEnvironmentVariable(
32
            'HTTPS_PROXY',
33
            $oldHttpsProxy,
34
            'Process'
35
        )
36
    }
37
}

这个函数有三个边界：

• 用 git.exe 读取 Git 针对 https://github.com/ 最终匹配到的代理，因此兼容 GitHub 专用规则和通用 http.proxy。
• 使用 --global，只读取用户级 Git 配置，不让某个仓库的局部设置意外改变全部 gh 命令。
• 显式调用 gh.exe，避免函数递归；命令结束后恢复原来的进程环境变量，不影响同一终端中的其他程序。

安装并验证包装函数#

创建并打开 PowerShell 配置文件：

1
if (!(Test-Path -LiteralPath $PROFILE)) {
2
    New-Item -ItemType File -Path $PROFILE -Force
3
}
4

5
notepad $PROFILE

粘贴函数并保存，然后立即重新加载：

1
. $PROFILE

确认 gh 已被包装函数接管，并检查 Git 能返回代理值：

1
Get-Command gh
2
git config --global --get-urlmatch http.proxy https://github.com/

Get-Command gh 的 CommandType 应为 Function。之后仍按原方式使用：

1
gh auth login -h github.com
2
gh api user
3
gh pr list

需要临时绕过包装函数并直接运行 GitHub CLI 时，显式调用：

1
gh.exe auth status

以后代理端口变化，只需修改 Git 配置：

1
git config --global http.https://github.com/.proxy http://127.0.0.1:新端口

PowerShell 函数无需同步修改。

pwsh.exe 商店别名导致沙箱启动失败#

如果 Codex 顶部持续出现“设置智能体沙盒以继续”，日志中又有类似错误：

1
CreateProcessAsUserW failed: 1920

可能是 Microsoft Store 安装的 PowerShell 7 注册了 pwsh.exe 应用执行别名。沙箱用户无法通过这个别名启动真实程序，而系统自带的 Windows PowerShell 可以正常运行。

处理步骤：

1. 打开 Windows“设置 -> 应用 -> 高级应用设置 -> 应用执行别名”。
2. 关闭 Microsoft PowerShell 对应的 pwsh.exe 别名。
3. 完全退出并重新启动 Codex。
4. 新会话应使用 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe。

修复后可让 Codex 执行普通命令，并确认进程身份包含 codexsandboxoffline，再测试工作区文件的创建、读取和删除。出现这个身份说明智能体沙箱已经生效。

Windows 10 显示“工作区依赖未安装”#

这和沙箱不是同一个功能。当前 Codex 的工作区依赖要求 Windows 11 22H2 或更高版本；Windows 10 即使反复点击“诊断”或“重新安装”，仍可能显示“未安装”或“无法重新安装”。

在 Windows 10 上可以关闭“Codex 依赖项”开关并忽略该提示，代码编辑、命令执行和沙箱仍可正常使用。若确实需要随附的 Node.js、Python 工具链，再升级到受支持的 Windows 11 版本。

系统代理开了，为什么 Codex 还是不通？#

很多桌面软件、命令行工具或其子进程不一定读取 Windows 系统代理。Codex 这类 Electron 应用还可能有自己的网络栈。用启动脚本或 Proxifier 直接约束目标进程更可靠。

为什么不推荐长期全局 TUN？#

TUN 是更底层的接管方式，适合兜底，但会影响默认路由、DNS、公司 VPN、内网域名和安全软件。AI 工具只需要访问少量公网服务时，进程级代理的副作用更小。

HTTP_PROXY 和 HTTPS_PROXY 要填 HTTP 还是 SOCKS？#

如果代理工具提供 HTTP 入站端口，优先写：

1
http://127.0.0.1:7890

ALL_PROXY 可以写 SOCKS5：

1
socks5://127.0.0.1:7890

如果工具明确支持 socks5h://，可用它解决 DNS 走代理问题；不支持时可能会报协议错误。

Claude Code 的 settings.json 在哪里？#

Windows 下 ~/.claude 等价于：

1
%USERPROFILE%\.claude

用户级配置文件通常是：

1
%USERPROFILE%\.claude\settings.json