Charles Needs Tor’s HTTP Tunnel for This HTTPS Route
Use Charles’s secure-web upstream configuration with a local Tor HTTP CONNECT listener, rather than its unrelated SOCKS field.
Charles’s External Proxies page distinguishes web upstreams from its SOCKS setting. Its documentation assigns that SOCKS setting to non-HTTP(S) traffic, such as port forwarding; filling it in does not select a SOCKS upstream for captured HTTPS requests.
For an existing Tor service, an HTTP tunnel listener can provide the interface Charles’s HTTPS upstream expects. A loopback-only torrc entry can be:
HTTPTunnelPort 127.0.0.1:8118Choose an unused local port and apply the change through that Tor deployment’s normal configuration lifecycle. In Charles, enable External Proxies and configure the Secure Web Proxy (HTTPS) endpoint as 127.0.0.1 with that port.
The HTTPS setting selects requests whose destination uses HTTPS. Tor’s listener accepts HTTP CONNECT to carry their TCP stream; it is not a TLS-encrypted HTTPS proxy listener.
This arrangement is specifically an HTTPS route. HTTPTunnelPort does not implement an ordinary forward proxy’s absolute-URL GET handling, so do not assume the same entry also handles plain HTTP browsing.
Keep Charles’s client-facing listener separate from this upstream endpoint. The browser connects to Charles; Charles connects to Tor’s tunnel listener.