Kailangan ni Charles ang HTTP tunnel ng Tor para sa rutang HTTPS na ito
Gamitin ang secure-web upstream configuration ni Charles kasama ang lokal na Tor HTTP CONNECT listener, sa halip na ang walang kaugnayang SOCKS field nito.
Ang pahina ng External Proxies ni Charles ay naghihiwalay ng web upstreams mula sa setting ng SOCKS. Itinatalaga ng dokumentasyon nito ang setting ng SOCKS na iyon sa trapikong hindi HTTP(S), gaya ng port forwarding; ang pagpuno nito ay hindi pumipili ng SOCKS upstream para sa mga nakuhang HTTPS request.
Para sa umiiral na serbisyo ng Tor, makapagbibigay ang HTTP tunnel listener ng interface na inaasahan ng HTTPS upstream ni Charles. Ang torrc entry para sa loopback lamang ay maaaring:
HTTPTunnelPort 127.0.0.1:8118Pumili ng hindi pa nagagamit na lokal na port at ilapat ang pagbabago sa pamamagitan ng normal na configuration lifecycle ng deployment ng Tor na iyon. Sa Charles, i-enable ang External Proxies at i-configure ang Secure Web Proxy (HTTPS) endpoint bilang 127.0.0.1 kasama ang port na iyon.
Pinipili ng setting na HTTPS ang mga request na HTTPS ang destinasyon. Tinatanggap ng listener ng Tor ang HTTP CONNECT para dalhin ang kanilang TCP stream; hindi ito TLS-encrypted na HTTPS proxy listener.
Ang kaayusang ito ay partikular na rutang HTTPS. Hindi ipinapatupad ng HTTPTunnelPort ang absolute-URL GET handling ng ordinaryong forward proxy, kaya huwag ipagpalagay na ang parehong entry ay humahawak din ng simpleng HTTP browsing.
Panatilihing hiwalay ang listener ni Charles na nakaharap sa client mula sa upstream endpoint na ito. Kumokonekta ang browser kay Charles; kumokonekta si Charles sa tunnel listener ng Tor.