WebDAV sync fails with socks5:// proxy, succeeds with http:// on same port

[JounQin]

Environment

• CC Switch: 3.15.0
• OS: macOS (Darwin)
• Proxy: Clash Verge (mihomo) mixed port 127.0.0.1:7890 — serves both HTTP CONNECT and SOCKS5

Summary

WebDAV cloud sync fails when cc-switch's outbound proxy is set to socks5://127.0.0.1:7890, but succeeds when set to http://127.0.0.1:7890/ — the same proxy server and port, only the scheme differs.

Repro

1. Set the outbound proxy (global_proxy_url) to socks5://127.0.0.1:7890.
2. Configure WebDAV sync and trigger it.
3. Sync fails; webdavSync.status.lastError reports e.g.:
   • WebDAV MKCOL 请求失败（连接失败）: https://<nas-host>:5006/misc/
   • WebDAV MKCOL 请求失败（请求超时）: https://<nas-host>:5006/misc/
4. Change the proxy to http://127.0.0.1:7890/ and re-trigger → sync succeeds immediately (lastError cleared, lastSyncAt updated).

Findings

• The WebDAV server is healthy: direct PROPFIND → 207, MKCOL on the existing dir → 405, all instant, both direct and via the proxy.
• So this is not a server/network problem. The only variable is the proxy scheme: socks5:// fails, http:// works on the same port.

Likely cause

cc-switch's outbound HTTP client treats socks5:// through a different code path than http:// (HTTP CONNECT). The SOCKS5 path appears flaky — "connection failed" at startup, then timeouts — while the HTTP CONNECT path is reliable. Side-effect worth noting: with socks5:// the host is resolved locally and an IP literal is tunneled (mihomo logs show match GeoIP/cn), whereas http:// sends the hostname to the proxy.

Expected

socks5:// and http:// should behave equivalently for the same proxy endpoint.

---

Note: this is distinct from #2686 (which is about MKCOL on an already-existing directory being misreported). Here the http:// path succeeds on 3.15.0, so the failure is specific to the SOCKS5 proxy path.