求助，人在香港，挂梯子codex桌面版一直这样，怎么办

ChatGPT 不支持香港 IP

呃呃，题设里说了挂了梯子了

试试tun模式，surge的话就是增强模式

麻烦好好看下题设，

gpt每次回答问题前都会先这样五次，然后回答，

如果送中了连进都进不去 而且是独享家宽不可能送中的

对不起刚刚火气有点大

你的图好像没传上来，麻烦改一下

codex会先尝试使用websocket，然后你的代理软件没有正确代理ws，ws没走代理连接不上，codex回落到用http了，所以后续能正常回答了

解决方法就是代理软件启用tun或配置环境变量让ws走代理，或者在codex配置文件里把ws关了

配置环境变量参考：

Codex 每次都重连5次——可能是 WebSocket 没走代理 - 世間的美好

codex关闭ws。如果你是用ChatGPT 账号登录 Codex，在~/.codex/config.toml 配置```
model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI"
requires_openai_auth = true
wire_api = "responses"
supports_websockets = false
```github.com/openai/codex

Recoverable reconnect loop before HTTP fallback when entering new or resumed thread

已打开 08:34AM - 22 May 26 UTC

General-Secretary-of-Dalaran

bug

app

connectivity

What version of the Codex App are you using (From “About Codex” dialog)?

26….519.31651

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

When I enter a new or resumed Codex Desktop thread, the first user turn often shows a recoverable reconnect loop:```text
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5
```The session eventually recovers and completes normally, so this is not a permanent connectivity failure.

From local logs, the pattern appears to be:

Codex first attempts responses_websocket against wss://chatgpt.com/backend-api/codex/responses.
The WebSocket startup prewarm / first turn stream fails or times out.
Codex retries several times.
Codex falls back to responses_http / SSE.
The turn completes successfully.
Representative sanitized log fragments:```text
startup websocket prewarm setup failed: timeout waiting for child process to exit
event.name="codex.websocket_connect" duration_ms=15002 success="false" error.message="timeout"
stream disconnected - retrying sampling request (1/5 ...)
stream_request:model_client.stream_responses_api ... transport="responses_http"
response.completed
```This happens in a proxied network environment using Shadowsocks + Clash Verge Rev with local mixed proxy 127.0.0.1:7897.

What steps can reproduce the bug?

1. Start Codex Desktop on macOS.
2. Open an existing workspace.
3. Create a new thread or resume an existing thread.
4. Send the first user message.
5. Observe Reconnecting... 2/5 through 5/5.
6. Wait for the retries to finish.
7. The session eventually becomes usable after HTTP/SSE fallback.

Additional experiments performed:

• codex app --disable plugins: reconnect still occurred.
• Clash Global mode with the same node: reconnect still occurred.
• Different proxy node type: reconnect still occurred.
• Minimal CLI control test via proxy completed successfully.
• Codex logs show traffic routed through 127.0.0.1:7897, so this does not appear to be missing proxy configuration.
• Plugin catalog endpoints may return Cloudflare 403, but model requests still succeed after fallback.

I can provide a sanitized diagnostic report if useful.

What is the expected behavior?

Codex Desktop should either:

1. establish the WebSocket transport successfully, or
2. fall back to responses_http / SSE quickly and quietly when WebSocket prewarm fails.

Ideally there should also be a documented local configuration option to force HTTP/SSE or disable responses_websocket in network environments where WebSocket is unreliable.

Additional information

Environment:

• macOS Tahoe 26.4.1, Apple Silicon
• Platform: Darwin 25.4.0 arm64 arm
• Codex CLI: 0.130.0
• Codex Desktop: 26.519.31651
• Network: mainland China network, Shadowsocks + Clash Verge Rev, local mixed proxy 127.0.0.1:7897

The issue is recoverable: after several reconnect attempts, the turn completes via HTTP/SSE fallback. The main impact is a consistent startup delay and confusing reconnect UI whenever entering a new or resumed thread.

看看有没有tun模式试试，你这个好像是因为CODEX优先走的WSS链接失败了 失败5次以后转http请求了。

我也发现貌似是这样了，但是我现在走的是socks协议，不知道有没有办法

可以让AI帮你修复，你跟他说明这个WSS失败5次的问题，好像可以在CODEX配置文件中强行关掉WSS的

有没有考虑他的AI已经G了 ^-^

然后才给出回答

并非已经G了 ^-^

我的也经常重连5次。晚点用佬友的方式试试优化下