Give the SOCKS5 proxy test a hermetic target - #107
Merged
Conversation
`httpRequestThroughSOCKS5` curled gstatic through the engine. It uses `--socks5`, not `--socks5-hostname`, so curl resolves the name itself and the engine receives a raw IP literal to dial — which is the point of the test, since that is exactly what the transparent proxy hands it for every TCP flow. But it also means the assertion depends on that public IP being directly reachable, and on a network that blocks Google by address the DIRECT dial times out and the test fails for reasons that have nothing to do with the proxy chain. Serve the target locally instead. `LocalHTTPServer` binds 127.0.0.1 on a kernel-assigned port and answers `204 No Content`; the test curls that through the SOCKS5 listener. Same machinery under test — SOCKS5 CONNECT with ATYP=0x01, rule match, DIRECT dial to an IPv4 literal, bidirectional relay — with no internet in the loop. `connectionTracking` generated its traffic the same way. It never asserted on the curl result, so it passed regardless, but it burned the full 10s timeout and populated no connection to query. It now uses the local target too, which is what takes the suite from 41.9s to 21.3s. The curl helper gained `--noproxy ""`, and that flag is load-bearing: curl 7.86+ silently bypasses the proxy for localhost targets, so without it the request never reaches the engine and the test passes for the wrong reason. Verified by mutation — pointing the test at a dead SOCKS port fails with curl exit 7 (refused by the proxy), not a success that sneaked past it. `httpRequestThroughHTTPProxy` deliberately keeps the public hostname: an HTTP proxy is handed a name, not an address, so it is the only test covering rule matching on a hostname and resolution through the engine's own `dns:` section. Verified: swiftlint --strict (0 violations), BaoLianDengTests 213/213 on a network where the old test could not pass.
This was referenced Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
ProxyEngineIntegrationTests.httpRequestThroughSOCKS5curledwww.gstatic.comthrough the engine. It uses--socks5, not--socks5-hostname, so curl resolves the name itself and the engine receives a raw IP literal to dial — which is the point of the test, since that is exactly what the transparent proxy hands it for every TCP flow.But it also means the assertion depends on that public IP being directly reachable. On a network that blocks Google by address, the DIRECT dial times out and the test fails for reasons that have nothing to do with the proxy chain. It fails 100% of the time on the maintainer's network;
curl --resolvewith no proxy anywhere in the path times out identically.The fix
Serve the target locally.
LocalHTTPServerbinds127.0.0.1on a kernel-assigned port and answers204 No Content; the test curls that through the SOCKS5 listener. The machinery under test is unchanged — SOCKS5 CONNECT with ATYP=0x01, rule match, DIRECT dial to an IPv4 literal, bidirectional relay — with no internet in the loop.connectionTrackinggenerated its traffic the same way. It never asserted on the curl result, so it passed regardless, but it burned the full 10s timeout and populated no connection to query. It now uses the local target too, which is what takes the suite from 41.9s to 21.3s.--noproxy ""is load-bearingcurl 7.86+ silently bypasses the proxy for localhost targets. Without that flag the request never reaches the engine and the test passes for the wrong reason — a false green that looks identical to a real one.
Verified by mutation rather than assertion: pointing the test at a dead SOCKS port makes it fail with curl exit 7, refused by the proxy, rather than succeeding past it.
Left alone on purpose
httpRequestThroughHTTPProxykeeps the public hostname. An HTTP proxy is handed a name, not an address, so it is the only test covering rule matching on a hostname and resolution through the engine's owndns:section — pointing it at loopback would turn it into a second IP-literal test. There is now a comment saying so.Verification
swiftlint lint --strict— 0 violationsBaoLianDengTests— 213/213 pass, on a network where the old test could not pass