Check failed Connection failed: error sending request for url - cc-switch
Quick fix
Toggle or switch the system proxy, then fully restart cc-switch. If needed, upgrade macOS or update to v3.16.3+, preferably 4.x.
Symptom
Section titled “Symptom”DeepSeek 检查失败 Connection failed: error sending request for url (https://api.deepseek.com/anthropic/v1/messages)DeepSeek check failed Connection failed: error sending request for url (https://api.deepseek.com/anthropic/v1/messages)
This error occurs when cc-switch's built-in connectivity check fails to make an outbound HTTPS request. It does not necessarily mean that the provider configuration is incorrect. Multiple issues show that the most common Windows trigger is a mismatch between the system proxy/TUN state and the global reqwest HTTP client cached when cc-switch starts. For example, if a proxy client such as Karing/Clash is enabled or disabled while cc-switch is running, the old connection pool continues using the proxy route from startup. Link tests, balance queries, and self-updates then all report `Connection failed: error sending request for url`, while restarting restores normal operation (#6041). In addition, #3437 found that older versions sent real model requests for link and latency tests and used a network stack different from proxy forwarding, which could stall because of differences such as TLS renegotiation. The maintainer confirmed that v3.16.3 changed this to a lightweight reachability probe and reused the same HTTP client as proxy forwarding, fixing this branch of the problem.
Another group of variants occurs on macOS. Logs in #3968 show rustls-platform-verifier reporting `invalid peer certificate ... not standards compliant: -67825` for every valid certificate on macOS 15, causing all provider checks and in-app updates to fail. Some users reported that upgrading macOS resolved the issue, while others still reproduced it on macOS 13 with cc-switch 3.17～3.20.1. In #3935, certain relay base_url values worked only after running `pkill -9 -f cc-switch` and deleting `~/.codex/.cache`. The maintainer stated that 4.0 reworked connectivity checks and local routing and recommended verifying the issue on the newer release. Overall, this error is more likely a network or client-layer problem than simply an incorrect API Key or model name.
First, test by changing the network state: disable the system proxy or TUN, such as Clash, Karing, or Skyline, then fully quit and restart cc-switch. If that fails, enable the proxy again or switch to another proxy node and retry. Multiple users recovered immediately by enabling, disabling, or switching the proxy.
If you frequently switch the proxy on and off, upgrade to a version with improved proxy routing. On Windows, check for an option such as “Follow system proxy / 跟随系统代理.” After changing it, reapply the settings as prompted or restart cc-switch so the shared HTTP client does not continue using the old proxy.
If Windows reports the error mainly during DeepSeek link or latency tests, upgrade to v3.16.3 or later. This version changed the test to a lightweight reachability probe and reused the same HTTP client as proxy forwarding.
If every provider and even in-app updates fail on macOS, check `~/.cc-switch/logs/cc-switch.log` for the rustls-platform-verifier `-67825` certificate validation error. If present, try upgrading macOS, then update to the latest cc-switch 4.x release and test again.
If a third-party relay intermittently works only after a restart, run `pkill -9 -f cc-switch` to clear remaining processes, then follow #3935 by deleting `~/.codex/.cache` before restarting. Also upgrade to 4.x to verify whether manual cleanup is still required.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 6 real issues
- #2796DeepSeek 检查失败
- #2946检查失败: Connection failed: error sending request for url (https://api.deepseek.com/anthropic/v1/messages)
- #3437DeepSeek Anthropic 接口"测试链接"和"延迟测试"始终失败，但代理转发正常工作
- #3935有些中转的baseurl出现需要杀死cc，然后清理缓存，才能链接
- #3968macOS 15.0 上 rustls-platform-verifier 校验所有有效证书均失败(-67825),导致全部 provider 检查与应用内更新不可用
- #6041[Bug][Windows][v3.19.1] Balance query and endpoint test fail after disabling proxy/TUN until restart
- Why can curl or a browser connect while the cc-switch test still fails?
- In older versions, the test path and the actual proxy-forwarding path might not use the same HTTP client, and cc-switch caches a global reqwest client. If the proxy/TUN state changes or macOS certificate validation fails, external tools may work while the in-app check still fails.
- Does toggling the proxy really help?
- Yes. Multiple users recovered after disabling the proxy and restarting cc-switch, enabling and then disabling it, or switching proxies. This usually forces the application onto another network path or rebuilds connections after restart.
- What is the most common DeepSeek configuration mistake?
- This error is not itself a configuration parsing error and is more often related to the network layer. However, a common configuration in the issues points `ANTHROPIC_BASE_URL` to `https://api.deepseek.com/anthropic` and changes the model name to something like `deepseek-v4-pro`.
- Which version fixes this issue?
- Not every variant was fixed in the same version. v3.16.3 explicitly fixed the link and latency test implementation. Proxy/TUN state caching and the 4.x redesign cover another set of cases. Users reported that the macOS `-67825` certificate issue disappeared after upgrading macOS.
- Is a relay that occasionally requires killing the process the same issue?
- The symptom is similar, but the trigger is more likely contaminated runtime state. As a temporary recovery, run `pkill -9 -f cc-switch` and delete `~/.codex/.cache`, then upgrade to 4.x and check whether it still occurs.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.