Repository navigation
Timeouts are not applied during socks5 initialization #3626
Description
I encountered a problem when using socks5 proxy.
Sometimes the server would not get a response during socks5 initialization, causing the thread to hang when using httpx.Client.
Based on this I checked the initialization of socks5 connection. And found that timeouts are not applied during socks5 initialization.
Activity
nightcityblade commentedon Oct 2, 2026
Hi, I'd like to work on this. I'll submit a PR shortly.
nightcityblade commentedon Oct 2, 2026
I have a tested fix ready in encode/httpcore, but GitHub is currently preventing this account from opening a pull request in that repository. The branch is available at https://github.com/nightcityblade/httpcore/tree/fix/issue-3626 for reference. I'm stepping back and unclaiming so someone else can take this.
tanveer-arch commentedon Oct 2, 2026
I'd like to work on this. The root cause is in httpcore, not httpx: httpcore's SOCKS5 handshake (_init_socks5_connection in httpcore/_async/socks_proxy.py / httpcore/_sync/socks_proxy.py) calls stream.read()/stream.write() without passing the configured connect timeout, so a proxy that accepts the TCP connection but never responds hangs the client forever.
My plan is an httpcore PR that (1) threads the request's connect timeout through every read/write of the SOCKS5 handshake (the stream backends already honor the timeout kwarg and raise ReadTimeout/WriteTimeout), (2) closes the proxy socket instead of leaking it when the handshake fails, and (3) adds regression tests: a mock-backend test asserting the timeout reaches all handshake stream ops, plus an end-to-end test with a non-responsive fake proxy asserting httpcore.ReadTimeout is raised. Verified locally: before the fix the client hangs indefinitely; after, it raises ReadTimeout after the configured timeout.
If that approach sounds good, I'll open the PR against encode/httpcore referencing this issue.
tanveer-arch commentedon Oct 3, 2026
@nightcityblade I see GitHub is blocking your account from opening the PR. I also have a tested fix ready for this (threads the connect timeout through all six stream ops of the SOCKS5 handshake, plus closes the proxy socket instead of leaking it on handshake failure, with an end-to-end black-hole regression test). Happy to open mine against encode/httpcore if your account issue persists just say the word, otherwise glad to stand down.