刚来L站,也不知道分享点啥，分享点还没用完得动态IP代理 : US: socks5://admin:[email protected]:7777 JP: socks5://admin:[email protected]:8888 1 个帖子 - 1 位参与者 阅读完整话题
name = “codex” wire_api = “responses” supports_websockets = false base_url = “ https://x666.me/v1 ” env_key = “OPENAI_API_KEY” 报错 Unexpected status 403 Forbidden: Image generation is not enabled for this group, url: https://x666.me/v1/responses , cf-ray: a09c5e942b4eea91-ICN 5 个帖子 - 5 位参与者 阅读完整话题
每次想在 VPS 上开个 SOCKS5 ，流程都差不多：装东西、写配置文件、配开机自启、再自己想个账号密码记下来。一套下来十几分钟，换台机器又来一遍。 所以我写了 next-socks5 ，把这套流程压成一条命令： # 二进制安装,启用认证(自动生成用户名/密码),随机端口: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh | sh # 带参数，指定端口: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh \ | sh -s -- --port 1080 # 也支持 docker 安装 curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh | sh -s -- --method docker --auth --port 1080 跑完它会自动生成账号密码、挑一个没被占用的端口、装好 systemd 服务并设成开机自启，最后把完整的代理地址打印出来——复制粘贴就能用，不用再去翻配置。不想装二进制的话加个 --method docker ，给你起一个会自动重启的容器。 几个我自己比较在意、也是和其他轻量 SOCKS5 不太一样的地方： 支持 UDP ，不只是 TCP 。 很多轻量实现只做了 CONNECT ，UDP ASSOCIATE 直接缺席，导致一些走 UDP 的场景用不了。这个两样都有。并且支持 UDP 端口范围和设置通告公网 IP 默认不是开放中继。 内网地址、回环、云厂商的元数据接口默认全都拦着。不用担心刚开起来就被人拿去探你的内网，或者变成别人的免费跳板。想放开也行的。 够小。 镜像 3.5MB ，二进制是静态 musl 、没有运行时依赖，x86_64 和 aarch64 都有预编译包。软路由、小盒子上跑也无所谓。 自带实时面板。 这是我个人最喜欢的一点。装好之后 next-socks5 attach 进去，能直接看到当前每一条连接、上下行流量、出错日志，一目了然——不用再 tail 系统日志去猜服务器上到底在跑什么。SOCKS5 带这种东西的不多。 Rust 写的，开源。如果你也经常需要临时搭代理，可以试试，有问题欢迎提 issue 。 GitHub: github.com/ZingerLittleBee/next-socks5
每次想在 VPS 上开个 SOCKS5 ，流程都差不多：装东西、写配置文件、配开机自启、再自己想个账号密码记下来。一套下来十几分钟，换台机器又来一遍。 所以我写了 next-socks5 ，把这套流程压成一条命令： # 二进制安装,启用认证(自动生成用户名/密码),随机端口: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh | sh # 带参数，指定端口: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh \ | sh -s -- --port 1080 # 也支持 docker 安装 curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh | sh -s -- --method docker --auth --port 1080 跑完它会自动生成账号密码、挑一个没被占用的端口、装好 systemd 服务并设成开机自启，最后把完整的代理地址打印出来——复制粘贴就能用，不用再去翻配置。不想装二进制的话加个 --method docker ，给你起一个会自动重启的容器。 几个我自己比较在意、也是和其他轻量 SOCKS5 不太一样的地方： 支持 UDP ，不只是 TCP 。 很多轻量实现只做了 CONNECT ，UDP ASSOCIATE 直接缺席，导致一些走 UDP 的场景用不了。这个两样都有。并且支持 UDP 端口范围和设置通告公网 IP 默认不是开放中继。 内网地址、回环、云厂商的元数据接口默认全都拦着。不用担心刚开起来就被人拿去探你的内网，或者变成别人的免费跳板。想放开也行的。 够小。 镜像 3.5MB ，二进制是静态 musl 、没有运行时依赖，x86_64 和 aarch64 都有预编译包。软路由、小盒子上跑也无所谓。 自带实时面板。 这是我个人最喜欢的一点。装好之后 next-socks5 attach 进去，能直接看到当前每一条连接、上下行流量、出错日志，一目了然——不用再 tail 系统日志去猜服务器上到底在跑什么。SOCKS5 带这种东西的不多。 Rust 写的，开源。如果你也经常需要临时搭代理，可以试试，有问题欢迎提 issue 。 GitHub: github.com/ZingerLittleBee/next-socks5
复杂局域网里的 WebRTC 稳定性，重点不只是 WebRTC offer/answer 怎么转发，还包括外围控制链路如何恢复。 这个场景不是 2C 通话，而是更接近医疗、养老等机构里的设备群：大量共享设备长时间在线，集中运维，现场环境可能比较嘈杂，同时还要保证一定收音距离和通话音质。 我遇到的核心问题是：长连接不一定会明确断开，有时会出现“看起来还连着，但应用消息已经不通”的状态。结果是设备页面显示在线，但呼叫事件发不到对端，超时、挂断、多人通话清理都会变得不一致。 这篇文章聚焦几个点： WebSocket 长连接假连接为什么危险 为什么只依赖客户端主动重连不够 gRPC Gateway 如何做双向控制 自动发现和主节点状态表怎么帮助恢复 呼叫超时、自动挂断、一对一挂断、多人挂断如何收敛 嘈杂环境下，音频可观测性为什么也属于稳定性的一部分 我的结论是：这不是简单的 WebSocket 换 gRPC ，而是要补齐发现、状态和恢复闭环。媒体链路仍然走 WebRTC ，Go/gRPC 更适合做控制面和状态收敛。 原文地址： https://www.lodan.me/posts/webrtc-grpc-gateway-discovery-recovery/ 想听听大家在局域网、弱网、设备长时间运行场景里，是怎么处理长连接假在线和通话状态恢复的。
复杂局域网里的 WebRTC 稳定性，重点不只是 WebRTC offer/answer 怎么转发，还包括外围控制链路如何恢复。 这个场景不是 2C 通话，而是更接近医疗、养老等机构里的设备群：大量共享设备长时间在线，集中运维，现场环境可能比较嘈杂，同时还要保证一定收音距离和通话音质。 我遇到的核心问题是：长连接不一定会明确断开，有时会出现“看起来还连着，但应用消息已经不通”的状态。结果是设备页面显示在线，但呼叫事件发不到对端，超时、挂断、多人通话清理都会变得不一致。 这篇文章聚焦几个点： WebSocket 长连接假连接为什么危险 为什么只依赖客户端主动重连不够 gRPC Gateway 如何做双向控制 自动发现和主节点状态表怎么帮助恢复 呼叫超时、自动挂断、一对一挂断、多人挂断如何收敛 嘈杂环境下，音频可观测性为什么也属于稳定性的一部分 我的结论是：这不是简单的 WebSocket 换 gRPC ，而是要补齐发现、状态和恢复闭环。媒体链路仍然走 WebRTC ，Go/gRPC 更适合做控制面和状态收敛。 原文地址： https://www.lodan.me/posts/webrtc-grpc-gateway-discovery-recovery/ 想听听大家在局域网、弱网、设备长时间运行场景里，是怎么处理长连接假在线和通话状态恢复的。
复杂局域网里的 WebRTC 稳定性，重点不只是 WebRTC offer/answer 怎么转发，还包括外围控制链路如何恢复。 这个场景不是 2C 通话，而是更接近医疗、养老等机构里的设备群：大量共享设备长时间在线，集中运维，现场环境可能比较嘈杂，同时还要保证一定收音距离和通话音质。 我遇到的核心问题是：长连接不一定会明确断开，有时会出现“看起来还连着，但应用消息已经不通”的状态。结果是设备页面显示在线，但呼叫事件发不到对端，超时、挂断、多人通话清理都会变得不一致。 这篇文章聚焦几个点： WebSocket 长连接假连接为什么危险 为什么只依赖客户端主动重连不够 gRPC Gateway 如何做双向控制 自动发现和主节点状态表怎么帮助恢复 呼叫超时、自动挂断、一对一挂断、多人挂断如何收敛 嘈杂环境下，音频可观测性为什么也属于稳定性的一部分 我的结论是：这不是简单的 WebSocket 换 gRPC ，而是要补齐发现、状态和恢复闭环。媒体链路仍然走 WebRTC ，Go/gRPC 更适合做控制面和状态收敛。 原文地址： https://www.lodan.me/posts/webrtc-grpc-gateway-discovery-recovery/ 想听听大家在局域网、弱网、设备长时间运行场景里，是怎么处理长连接假在线和通话状态恢复的。
新增 Socks5/Forward 两个工作模式 1. 通过本地的 Socks5 服务访问 WireGuard 网络 2. 把本地服务 Forward 到 WireGuard 网络 免费下载使用 https://github.com/wuruxu/wgx/releases
skill信息: GitHub - op7418/guizang-social-card-skill: 🪧 Claude Code / Codex skill — generate Xiaohongshu carousels & WeChat 21:9+1:1 cover pairs. Editorial × Swiss visual systems, 28 layouts, 10 themes, single-file HTML → PNG. 小红书图文 + 公众号封面对 · GitHub 大家有什么好玩的skill 吗，最近在尝试这些 2 个帖子 - 2 位参与者 阅读完整话题
整了个付费中转，仅支持内地使用，但我的 VPS 是 AWS 的 Lightsail，境外节点用不了。Sub2API 仅支持 SOCK5/HTTP/HTTPS 代理，我的 Clash 回国又用不了。有什么免费/便宜的 HTTP/SOCK5 回国代理，最好延迟低一点，谢谢 1 个帖子 - 1 位参与者 阅读完整话题
英伟达正准备在下周的 Computex 大会上，与微软和 ARM 一同公布一项重大的全新处理器合作项目，其中最受关注的就是代号为 N1x 的新款 SoC。尽管官方尚未披露详细规格，但目前曝光的 Geekbench 6 预发布成绩显示，这款芯片在性能上尚未能全面追上苹果于 2023 年推出的 M3 Max 处理器。 据业内消息，N1x 被普遍认为是为 DGX Spark 迷你主机提供动力的 GB10 SoC 的修改版本，采用由联发科设计的 20 核 ARM CPU，集成大致相当于 GeForce RTX 5070 级别的 GPU，并使用 LPDDR5X 统一内存架构，由 CPU 与 GPU 共享同一内存池。 Geekbench 6.2.2 Linux AArch64 预览版的数据库显示，这颗 N1x 在 Ubuntu 24.04.1 LTS 系统下，搭配 HP 8EA3 主板，单核得分为 3096，多核得分为 18837。 这些 N1x 的预发布成绩是在 2025 年 6 月录得的，但由于其结果与 GB10 芯片此前的表现高度吻合，反而增强了此次对比的可信度。为方便对照，媒体还调取了苹果 M3 Max 在 16 英寸 MacBook Pro（2023 年 11 月版）上的 Geekbench 6 数据，该机型的单核得分为 3124，多核得分为 18920。 从表面分数来看，两者相对接近，但整体仍是 M3 Max 略胜一筹。 更具话题性的是，这一代际错位的对比凸显出苹果在芯片架构设计上的优势。N1x 传闻采用 20 核 CPU，而 M3 Max 仅为 14 核，却在单核与多核成绩上都仍保持领先。 分析人士认为，除了架构本身的差距之外，苹果在 macOS 与 MacBook Pro 整体生态上的深度优化，也在一定程度上放大了 M3 Max 的性能优势；相比之下，当前 N1x 所处的平台仍属于未完全优化的早期硬件环境。 当然，N1x 的现有结果仍存在多重“但书”。其一，如前所述，这是一份时间点在 2025 年中的早期跑分，随着产品接近量产，驱动、固件以及系统生态的持续打磨，后续成绩有望出现一定提升。 其二，Geekbench 这类合成测试主要反映的是通用计算能力，并不能完整刻画 N1x 在实际 Windows ARM 笔记本或其他终端产品中的功耗表现及图形性能潜力。 目前外界普遍预期，N1x 将搭载在新一代 Windows 笔记本等终端中，成为英伟达与微软、ARM 联手推动的“PC on ARM”阵营的核心一员。 不过就已知信息来看，这款新品若想在综合性能与能效上完全压过 M3 Max 这样的成熟产品，仍需依赖后续软硬件协同优化以及终端厂商的整体设计能力。 业界正密切关注下周 Computex 上英伟达对 N1x 的正式解读以及更完整的技术细节披露。 查看评论
IT之家 5 月 30 日消息，宏碁 (Acer) 昨日宣布了三款基于联发科技 SoC 的平板电脑产品，统一采用 3:2 比例屏幕，至高配备天玑 8300 芯片，皆可选配主动式触控笔等配件。 Iconia Duo S14 其采用 14.2" 2880×1840 120Hz 400nits OLED 屏幕，具备 91% 屏占比和 100% DCI-P3 色域。该平板电脑 基于联发科的天玑 8300 ，内置存储配置可达 8GB + 256GB，具备 10000mAh 电池，厚 6.2mm，重 0.73kg。 该型号支持 Wi-Fi 6E，拥有 13MP 后摄与 8MP 前摄、四扬声器，提供 2 个 USB-C 和 microSD 读卡器。 Iconia Duo S12 其采用 12.2" 2800×1840 600nit OLED 屏幕，色域完整覆盖 DCI-P3。该型号 基于联发科天玑 7400 ，内置存储配置可达 8GB + 256GB，具备 8000mAh 电池，厚 6.5mm，重 0.58kg。 Iconia Duo S12 支持 Wi-Fi 6，拥有 13MP 后摄与 8MP 前摄、双扬声器，提供 USB-C 和 microSD 读卡器。 Iconia Duo D12 这款产品则 基于联发科曦力 G99 ，提供 12.2" 2400×1600 90Hz 屏幕，内置存储配置可达 8GB + 128GB（支持 microSD 拓展），集成 8000mAh 电池，厚 7.5mm，重 0.62kg。其支持 Wi-Fi 6，拥有 8MP 后摄与 5MP 前摄，内置双扬声器，提供 USB-C 接口。
各位大佬，Codex使用WebSocket连接后开始频繁出现以下报错，请问这是哪里的问题？是上游报错，还是我的客户端和代理出现了问题呢？ stream disconnected before completion: WebSocket protocol error: Connection reset without closing handshake 3 个帖子 - 2 位参与者 阅读完整话题
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。 比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。 我们做了一个小项目 Hermes： https://github.com/cloudpilot-ai/hermes 想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。 这次用 EKS + Karpenter 跑了一个简单对比，镜像是： 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 大概 10.8GB 。 普通节点上，从 Pod 调度到节点后，到容器 Running/Ready： 5m04s - 29s = 4m35s 开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下： 44s - 30s = 14s 也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。 需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。 Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似： apiVersion: hermes.cloudpilot.ai/v1alpha1 kind: HermesPolicy metadata: name: prod-large-images spec: paused: false imageSelectors: - imageRegex: ".*vllm.*" platforms: - linux/amd64 目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes
连续5次stream disconnected before completion: websocket closed by server before response.completed 好好的怎么突然就坏了。 9 个帖子 - 3 位参与者 阅读完整话题
Tibo发布推特正在解决,一直思考是官方原因，非节点问题 4 个帖子 - 3 位参与者 阅读完整话题
CPA 代理 Codex 卡在"正在思考"的排查与 WebSocket 解决方案 使用 CPA 代理 Codex / Codex CLI / Codex Desktop 时，可能会遇到这些现象： 卡在"正在思考"，长时间没有输出。 请求反复失败，偶发超时。 CPA 代理下 HTTPS / SSE 转发不稳定。 codex doctor 显示 WebSocket 失败，随后 fallback 到 HTTPS。 这类问题不一定和出口 IP 区域有关，更常见的关键点是 Codex 到 CPA、CPA 到 OpenAI 这两段是否真的走了 WebSocket。本文整理完整配置方式，以及如何确认链路是否已经变成全程 WebSocket。 目标链路 理想的全程 WebSocket 链路是： Codex ---ws---> CPA ---wss---> OpenAI / ChatGPT Codex backend 也就是： Codex -> ws://localhost:8317/v1/responses CPA -> wss://chatgpt.com/backend-api/codex/responses 注意，这里有两段链路： Codex -> CPA ：由 Codex provider 配置决定。 CPA -> OpenAI ：由 CPA 当前选中的 Codex OAuth auth 文件决定。 只配置其中一段，可能只能得到半程 WebSocket。 解决方案：开启全程 WebSocket 目标是让 Codex 到 CPA 使用 WebSocket，同时 CPA 到 OpenAI 也使用 WSS。 1. 修改 Codex 配置 编辑 Codex 配置文件： ~/.codex/config.toml 找到 CPA 对应的 provider，例如： [model_providers.cliproxyapi] base_url = "http://localhost:8317/v1" 在这个 provider 下添加： supports_websockets = true 完整示例： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://localhost:8317/v1" wire_api = "responses" supports_websockets = true 这个配置必须放在 [model_providers.cliproxyapi] 下面，不要放到 [features] 下面。 2. 不要乱配 feature flag 不要盲目在 [features] 下添加： responses_websockets_v2 = true 部分 Codex 版本中相关 feature flag 已经被移除或默认内置。可以用下面命令确认： macOS: /Applications/Codex.app/Contents/Resources/codex debug features Windows 示例： codex debug features 如果输出里显示类似： responses_websockets: removed responses_websockets_v2: removed 说明这个开关已经不再需要，也不应该再配。关键配置是 provider 里的 supports_websockets = true 。 3. 修改 CPA 的 Codex auth 文件 只改 Codex 配置，通常只能保证： Codex ---ws---> CPA 要实现： CPA ---wss---> OpenAI 还需要让 CPA 当前使用的 Codex OAuth auth 开启 WebSocket。 CPA 的 Codex OAuth auth 文件一般在： macOS 常见位置： ~/.cli-proxy-api/ Windows 运行包常见位置示例： <CPA_RUNTIME_DIR>\auth\ 文件名通常类似： [email protected] [email protected] 编辑 CPA 实际选中的 Codex auth 文件，在 JSON 顶层添加： "websockets": true 示例结构： { "websockets": true, "access_token": "...", "account_id": "...", "email": "...", "refresh_token": "...", "type": "codex" } 注意： websockets 是 JSON 顶层字段。 不要放进 metadata 、 attributes 或其他嵌套对象里。 如果有多个 Codex auth 文件，要改 CPA 实际选中的那个。 CPA 日志中的 Use OAuth provider=codex auth_file=... 会显示当前使用的是哪个 auth 文件。 验证步骤 1. 用 Codex doctor 验证 Codex 到 CPA macOS: /Applications/Codex.app/Contents/Resources/codex doctor Windows / PATH 已配置时： codex doctor 成功时应看到类似： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://localhost:8317/v1/... 这说明： Codex ---ws---> CPA 已经成立。 2. 用 CPA Manager 监控辅助判断 CPA Manager 的监控列表也可以作为一个直观信号。开启 WebSocket 后，监控里对应模型的请求方法通常会显示为： GET /v1/responses 这和普通 HTTP/SSE 请求不一样。之前走 HTTP/SSE fallback 时，请求通常是： POST /v1/responses Accept: text/event-stream 原因是 WebSocket 握手本身是 HTTP GET + Upgrade: websocket ，成功后才升级成 WebSocket 连接。所以在 CPA Manager 里看到连续成功的 GET /v1/responses ，基本可以说明 Codex -> CPA 这一段已经在走 WebSocket 路由。 不过它只能证明下游请求进入了 CPA 的 WebSocket handler。要确认 CPA -> OpenAI 也变成 WSS，还需要继续看 main.log 里是否有 codex websockets: upstream connected ... url=wss://... 。 3. 打开 CPA 日志验证 CPA 到 OpenAI 这一步不是长期必需，只建议临时打开用于验证。编辑 CPA 配置文件。 macOS Homebrew 常见位置： /opt/homebrew/etc/cliproxyapi.conf Windows 运行包示例： <CPA_RUNTIME_DIR>\config.yaml 临时打开： debug: true request-log: true logging-to-file: true 然后重启 CPA。 日志文件常见位置： macOS: ~/.cli-proxy-api/logs/main.log Windows 运行包示例： <CPA_RUNTIME_DIR>\auth\logs\main.log 用 rg 检索关键日志： macOS: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" ~/.cli-proxy-api/logs/main.log Windows: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" <CPA_RUNTIME_DIR>\auth\logs\main.log 成功时会看到类似： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex [email protected] ... codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 这就说明链路已经是： Codex ---ws---> CPA ---wss---> OpenAI 验证完成后，建议把 CPA 日志开关关回去： debug: false request-log: false logging-to-file: false 然后再次重启 CPA。 原因是 request-log: true 可能记录完整请求 payload，包括对话内容、工具调用参数等，长期打开会增加磁盘占用和敏感信息落盘风险。 常见误区 误区 1：把 supports_websockets 放错位置 错误写法： [features] supports_websockets = true 正确写法： [model_providers.cliproxyapi] supports_websockets = true supports_websockets 是 provider 能力配置，不是 feature flag。 误区 2：只开了 Codex 到 CPA 如果 CPA 日志里只有： responses websocket: client connected 但没有： codex websockets: upstream connected ... url=wss://... 说明大概率只是： Codex ---ws---> CPA 还没有实现： CPA ---wss---> OpenAI 这时继续检查 CPA 当前选中的 Codex auth 文件是否有： "websockets": true 误区 3：被本机代理环境变量干扰 有时环境里设置了： HTTP_PROXY HTTPS_PROXY http_proxy https_proxy 但 NO_PROXY 没包含本地地址，导致 ws://127.0.0.1:8317 也被拿去走外部代理。 典型报错可能是： HTTP CONNECT failed with status 504 Proxy URL scheme not supported 临时验证时可以设置： macOS / Linux: NO_PROXY=127.0.0.1,localhost no_proxy=127.0.0.1,localhost codex doctor Windows PowerShell: $env:NO_PROXY = "127.0.0.1,localhost" $env:no_proxy = "127.0.0.1,localhost" codex doctor 如果这样就恢复 HTTP 101 Switching Protocols ，说明本地代理绕过规则需要补齐。 误区 4：cc-switch 端口能监听但不支持 WebSocket 路由 有些情况下 Codex provider 指向了 cc-switch.exe 暴露的端口，例如： ws://127.0.0.1:15721/v1/... codex doctor 可能显示： supports websockets true Responses WebSocket failed HTTP 405 Method Not Allowed 这说明： Codex 端已经尝试 WebSocket。 配置也认为 provider 支持 WebSocket。 但本地 cc-switch / COA 的 /v1/... WebSocket 路由没有正确接住。 实际请求会 fallback 到 HTTPS/SSE，仍可能卡在"正在思考"。 实践建议：如果你的目标只是让 Codex 通过 CPA 访问上游，并且 CPA 已经能提供 http://127.0.0.1:8317/v1 这类 OpenAI-compatible provider，那么可以先关掉 cc-switch ，让 Codex 直接指向 CPA。这样链路更短，排查也更清楚。除非你明确依赖 cc-switch 做模型切换或其他额外能力，否则它在这条 WebSocket 修复链路里通常不是必需层。 排查方向： 确认 Codex provider 是否应该指向 CPA，而不是 cc-switch 临时端口。 确认 base_url 是否为 CPA 端口，例如 http://127.0.0.1:8317/v1 。 用 Get-NetTCPConnection / lsof 查监听进程，确认端口背后到底是谁。 如果必须经过 cc-switch，确认该版本是否支持 Codex Responses WebSocket 路由。 Windows 查看监听进程示例： Get-NetTCPConnection -LocalPort 8317 | Select-Object LocalAddress,LocalPort,State,OwningProcess Get-CimInstance Win32_Process | Where-Object { $_.ProcessId -eq <PID> } | Select-Object ProcessId,Name,CommandLine macOS 查看监听进程示例： lsof -nP -iTCP:8317 -sTCP:LISTEN Windows 实测参考 以下是一组 Windows 上验证成功的关键点，路径仅作示例： Codex 配置： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://127.0.0.1:8317/v1" supports_websockets = true wire_api = "responses" CPA 进程： <CPA_RUNTIME_DIR>\cli-proxy-api.exe CPA 配置： <CPA_RUNTIME_DIR>\config.yaml CPA auth 目录： <CPA_RUNTIME_DIR>\auth\ CPA 日志： <CPA_RUNTIME_DIR>\auth\logs\main.log 成功日志关键行： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex auth_file=codex-...-plus.json for model gpt-5.5 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 成功后 codex doctor 关键行： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://127.0.0.1:8317/v1/<redacted> 快速判断表 现象 含义 下一步 websocket connected (HTTP 101) Codex 到 CPA 已经是 WS 继续看 CPA 日志确认上游 WSS CPA Manager 显示 GET /v1/responses 下游大概率已走 WS upgrade 路由 继续看 main.log 确认上游 WSS responses websocket: client connected CPA 收到了下游 WS 继续找 upstream connected codex websockets: upstream connected ... wss://... CPA 到 OpenAI 已经是 WSS 全程 WebSocket 成功 HTTP 405 Method Not Allowed 本地服务没接住 WS 路由 检查端口背后是不是 cc-switch/旧 COA HTTP CONNECT failed 504 本地 WS 被错误送去代理 设置 NO_PROXY=127.0.0.1,localhost POST /v1/responses + Accept: text/event-stream 可能仍在 HTTP/SSE fallback 检查 Codex provider 与 CPA auth 最终检查清单 Codex provider 下有 supports_websockets = true 。 Codex provider 的 base_url 指向 CPA，而不是不支持 WS 的中间服务。 CPA 当前使用的 Codex auth JSON 顶层有 "websockets": true 。 codex doctor 显示 HTTP 101 Switching Protocols 。 CPA main.log 显示 responses websocket: client connected 。 CPA main.log 显示 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 。 验证完成后关闭 debug 、 request-log 、 logging-to-file 。 4 个帖子 - 4 位参与者 阅读完整话题
CPA 代理 Codex 卡在"正在思考"的排查与 WebSocket 解决方案 使用 CPA 代理 Codex / Codex CLI / Codex Desktop 时，可能会遇到这些现象： 卡在"正在思考"，长时间没有输出。 请求反复失败，偶发超时。 CPA 代理下 HTTPS / SSE 转发不稳定。 codex doctor 显示 WebSocket 失败，随后 fallback 到 HTTPS。 这类问题不一定和出口 IP 区域有关，更常见的关键点是 Codex 到 CPA、CPA 到 OpenAI 这两段是否真的走了 WebSocket。本文整理完整配置方式，以及如何确认链路是否已经变成全程 WebSocket。 目标链路 理想的全程 WebSocket 链路是： Codex ---ws---> CPA ---wss---> OpenAI / ChatGPT Codex backend 也就是： Codex -> ws://localhost:8317/v1/responses CPA -> wss://chatgpt.com/backend-api/codex/responses 注意，这里有两段链路： Codex -> CPA ：由 Codex provider 配置决定。 CPA -> OpenAI ：由 CPA 当前选中的 Codex OAuth auth 文件决定。 只配置其中一段，可能只能得到半程 WebSocket。 解决方案：开启全程 WebSocket 目标是让 Codex 到 CPA 使用 WebSocket，同时 CPA 到 OpenAI 也使用 WSS。 1. 修改 Codex 配置 编辑 Codex 配置文件： ~/.codex/config.toml 找到 CPA 对应的 provider，例如： [model_providers.cliproxyapi] base_url = "http://localhost:8317/v1" 在这个 provider 下添加： supports_websockets = true 完整示例： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://localhost:8317/v1" wire_api = "responses" supports_websockets = true 这个配置必须放在 [model_providers.cliproxyapi] 下面，不要放到 [features] 下面。 2. 不要乱配 feature flag 不要盲目在 [features] 下添加： responses_websockets_v2 = true 部分 Codex 版本中相关 feature flag 已经被移除或默认内置。可以用下面命令确认： macOS: /Applications/Codex.app/Contents/Resources/codex debug features Windows 示例： codex debug features 如果输出里显示类似： responses_websockets: removed responses_websockets_v2: removed 说明这个开关已经不再需要，也不应该再配。关键配置是 provider 里的 supports_websockets = true 。 3. 修改 CPA 的 Codex auth 文件 只改 Codex 配置，通常只能保证： Codex ---ws---> CPA 要实现： CPA ---wss---> OpenAI 还需要让 CPA 当前使用的 Codex OAuth auth 开启 WebSocket。 CPA 的 Codex OAuth auth 文件一般在： macOS 常见位置： ~/.cli-proxy-api/ Windows 运行包常见位置示例： <CPA_RUNTIME_DIR>\auth\ 文件名通常类似： [email protected] [email protected] 编辑 CPA 实际选中的 Codex auth 文件，在 JSON 顶层添加： "websockets": true 示例结构： { "websockets": true, "access_token": "...", "account_id": "...", "email": "...", "refresh_token": "...", "type": "codex" } 注意： websockets 是 JSON 顶层字段。 不要放进 metadata 、 attributes 或其他嵌套对象里。 如果有多个 Codex auth 文件，要改 CPA 实际选中的那个。 CPA 日志中的 Use OAuth provider=codex auth_file=... 会显示当前使用的是哪个 auth 文件。 验证步骤 1. 用 Codex doctor 验证 Codex 到 CPA macOS: /Applications/Codex.app/Contents/Resources/codex doctor Windows / PATH 已配置时： codex doctor 成功时应看到类似： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://localhost:8317/v1/... 这说明： Codex ---ws---> CPA 已经成立。 2. 用 CPA Manager 监控辅助判断 CPA Manager 的监控列表也可以作为一个直观信号。开启 WebSocket 后，监控里对应模型的请求方法通常会显示为： GET /v1/responses 这和普通 HTTP/SSE 请求不一样。之前走 HTTP/SSE fallback 时，请求通常是： POST /v1/responses Accept: text/event-stream 原因是 WebSocket 握手本身是 HTTP GET + Upgrade: websocket ，成功后才升级成 WebSocket 连接。所以在 CPA Manager 里看到连续成功的 GET /v1/responses ，基本可以说明 Codex -> CPA 这一段已经在走 WebSocket 路由。 不过它只能证明下游请求进入了 CPA 的 WebSocket handler。要确认 CPA -> OpenAI 也变成 WSS，还需要继续看 main.log 里是否有 codex websockets: upstream connected ... url=wss://... 。 3. 打开 CPA 日志验证 CPA 到 OpenAI 这一步不是长期必需，只建议临时打开用于验证。编辑 CPA 配置文件。 macOS Homebrew 常见位置： /opt/homebrew/etc/cliproxyapi.conf Windows 运行包示例： <CPA_RUNTIME_DIR>\config.yaml 临时打开： debug: true request-log: true logging-to-file: true 然后重启 CPA。 日志文件常见位置： macOS: ~/.cli-proxy-api/logs/main.log Windows 运行包示例： <CPA_RUNTIME_DIR>\auth\logs\main.log 用 rg 检索关键日志： macOS: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" ~/.cli-proxy-api/logs/main.log Windows: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" <CPA_RUNTIME_DIR>\auth\logs\main.log 成功时会看到类似： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex [email protected] ... codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 这就说明链路已经是： Codex ---ws---> CPA ---wss---> OpenAI 验证完成后，建议把 CPA 日志开关关回去： debug: false request-log: false logging-to-file: false 然后再次重启 CPA。 原因是 request-log: true 可能记录完整请求 payload，包括对话内容、工具调用参数等，长期打开会增加磁盘占用和敏感信息落盘风险。 常见误区 误区 1：把 supports_websockets 放错位置 错误写法： [features] supports_websockets = true 正确写法： [model_providers.cliproxyapi] supports_websockets = true supports_websockets 是 provider 能力配置，不是 feature flag。 误区 2：只开了 Codex 到 CPA 如果 CPA 日志里只有： responses websocket: client connected 但没有： codex websockets: upstream connected ... url=wss://... 说明大概率只是： Codex ---ws---> CPA 还没有实现： CPA ---wss---> OpenAI 这时继续检查 CPA 当前选中的 Codex auth 文件是否有： "websockets": true 误区 3：被本机代理环境变量干扰 有时环境里设置了： HTTP_PROXY HTTPS_PROXY http_proxy https_proxy 但 NO_PROXY 没包含本地地址，导致 ws://127.0.0.1:8317 也被拿去走外部代理。 典型报错可能是： HTTP CONNECT failed with status 504 Proxy URL scheme not supported 临时验证时可以设置： macOS / Linux: NO_PROXY=127.0.0.1,localhost no_proxy=127.0.0.1,localhost codex doctor Windows PowerShell: $env:NO_PROXY = "127.0.0.1,localhost" $env:no_proxy = "127.0.0.1,localhost" codex doctor 如果这样就恢复 HTTP 101 Switching Protocols ，说明本地代理绕过规则需要补齐。 误区 4：cc-switch 端口能监听但不支持 WebSocket 路由 有些情况下 Codex provider 指向了 cc-switch.exe 暴露的端口，例如： ws://127.0.0.1:15721/v1/... codex doctor 可能显示： supports websockets true Responses WebSocket failed HTTP 405 Method Not Allowed 这说明： Codex 端已经尝试 WebSocket。 配置也认为 provider 支持 WebSocket。 但本地 cc-switch / COA 的 /v1/... WebSocket 路由没有正确接住。 实际请求会 fallback 到 HTTPS/SSE，仍可能卡在"正在思考"。 实践建议：如果你的目标只是让 Codex 通过 CPA 访问上游，并且 CPA 已经能提供 http://127.0.0.1:8317/v1 这类 OpenAI-compatible provider，那么可以先关掉 cc-switch ，让 Codex 直接指向 CPA。这样链路更短，排查也更清楚。除非你明确依赖 cc-switch 做模型切换或其他额外能力，否则它在这条 WebSocket 修复链路里通常不是必需层。 排查方向： 确认 Codex provider 是否应该指向 CPA，而不是 cc-switch 临时端口。 确认 base_url 是否为 CPA 端口，例如 http://127.0.0.1:8317/v1 。 用 Get-NetTCPConnection / lsof 查监听进程，确认端口背后到底是谁。 如果必须经过 cc-switch，确认该版本是否支持 Codex Responses WebSocket 路由。 Windows 查看监听进程示例： Get-NetTCPConnection -LocalPort 8317 | Select-Object LocalAddress,LocalPort,State,OwningProcess Get-CimInstance Win32_Process | Where-Object { $_.ProcessId -eq <PID> } | Select-Object ProcessId,Name,CommandLine macOS 查看监听进程示例： lsof -nP -iTCP:8317 -sTCP:LISTEN Windows 实测参考 以下是一组 Windows 上验证成功的关键点，路径仅作示例： Codex 配置： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://127.0.0.1:8317/v1" supports_websockets = true wire_api = "responses" CPA 进程： <CPA_RUNTIME_DIR>\cli-proxy-api.exe CPA 配置： <CPA_RUNTIME_DIR>\config.yaml CPA auth 目录： <CPA_RUNTIME_DIR>\auth\ CPA 日志： <CPA_RUNTIME_DIR>\auth\logs\main.log 成功日志关键行： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex auth_file=codex-...-plus.json for model gpt-5.5 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 成功后 codex doctor 关键行： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://127.0.0.1:8317/v1/<redacted> 快速判断表 现象 含义 下一步 websocket connected (HTTP 101) Codex 到 CPA 已经是 WS 继续看 CPA 日志确认上游 WSS CPA Manager 显示 GET /v1/responses 下游大概率已走 WS upgrade 路由 继续看 main.log 确认上游 WSS responses websocket: client connected CPA 收到了下游 WS 继续找 upstream connected codex websockets: upstream connected ... wss://... CPA 到 OpenAI 已经是 WSS 全程 WebSocket 成功 HTTP 405 Method Not Allowed 本地服务没接住 WS 路由 检查端口背后是不是 cc-switch/旧 COA HTTP CONNECT failed 504 本地 WS 被错误送去代理 设置 NO_PROXY=127.0.0.1,localhost POST /v1/responses + Accept: text/event-stream 可能仍在 HTTP/SSE fallback 检查 Codex provider 与 CPA auth 最终检查清单 Codex provider 下有 supports_websockets = true 。 Codex provider 的 base_url 指向 CPA，而不是不支持 WS 的中间服务。 CPA 当前使用的 Codex auth JSON 顶层有 "websockets": true 。 codex doctor 显示 HTTP 101 Switching Protocols 。 CPA main.log 显示 responses websocket: client connected 。 CPA main.log 显示 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 。 验证完成后关闭 debug 、 request-log 、 logging-to-file 。 2 个帖子 - 2 位参与者 阅读完整话题