mirror of https://github.com/ospab/ostp.git
ospab
c523b083cb
Matches a real report: traffic counters move (the OSTP tunnel handshakes fine) but sites don't open, or take very long - on a freshly deployed DigitalOcean droplet in Amsterdam. connect_target's fallback path handed the raw "host:port" string straight to TcpStream::connect, which resolves and tries addresses internally but shares ONE 10s timeout across the WHOLE attempt (all resolved addresses, not per-address). Some VPS hosts assign the machine an IPv6 address that the OS prefers by RFC 6724 ordering but that has no actually-working outbound route - the connect doesn't get refused, it just hangs. With a single shared budget, that one dead IPv6 candidate eats the entire 10s and the working IPv4 candidate is never even attempted: every dual-stack destination (i.e. most popular sites) times out, while IPv4-only destinations work fine. New connect_direct() resolves target itself via lookup_host, sorts IPv4 candidates first, and tries each with its own 3s budget (still bounded overall by the original 10s outer timeout as a backstop) so a hung IPv6 attempt can't starve the IPv4 fallback of a chance. Added tests: IPv4-first sort ordering (and stability within a family), a successful connect against a live local listener, and a refused-port connect failing well under the timeout (proving failures aren't needlessly slow). Scoped to connect_target's direct-connect paths; the SOCKS5/HTTP outbound-proxy paths and the fallback/camouflage TCP proxy (which targets a fixed admin-configured local address, not arbitrary dual-stack hostnames) are unaffected. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||