# [2026-09-18] SearXNG's ESH SOCKS5 egress — one day live, reverted, and it fixed nothing

On 2026-09-17, at operator request, SearXNG's search egress was moved from
nh3-docker's direct residential path to `socks5h://10.0.50.65:1080` on **esh-scale**
(CT 108 on esh-pve) — an application-level proxy, no host route or exit-node change.
Reverted 2026-09-18.

## Why it was reverted, and why the STATED reason was wrong

It was reverted on a diagnosis that turned out to be false: that the move had cost
three of four search engines to CAPTCHAs. Reverting to direct NH3 egress produced a
**byte-identical** result — same three engines down — which falsified it. A live
`!ddg` bang probe on a freshly restarted container also CAPTCHA'd, ruling out stale
suspension timers too.

The real cause was elsewhere (see [[2026-09-18-searxng-one-engine-to-seven]]).

**The revert still stands on its own merits**: ESH egress bought no measurable
improvement while making all fleet search depend on ESH WAN and mesh availability.
The simpler configuration is the better one. It is simply not the fix for the engines.

## What was built, because it was built correctly

The proxy side was not at fault and is worth keeping as a pattern. `microsocks` ran
as `nobody` under `searxng-egress.service`, bound `10.0.50.65:1080` only, and allowed
source `10.100.50.40` alone — everything else had to supply a password regenerated at
each start and never distributed. Allowed-host egress and denied-host rejection were
both tested. The unit is kept at `configs/esh-scale/searxng-egress.service`; the
service is **stopped and disabled** on esh-scale, and `tailscaled` there was not
touched (CT 108 is ESH's whole-site mesh SPOF).

Measured egress was `128.177.138.182` in use and `154.50.58.126` at cutover — ESH's
WAN address moves and nothing pins it, so the number in the stack README is historical.

## The transferable lesson

⚠ **I asserted causation from correlation with no baseline.** The only evidence that
residential egress avoided CAPTCHAs was a config comment dated 2026-09-03, which was
no longer true of that address. Five samples of the post-change state and zero of the
working state is not a comparison. The rollback WAS the counterfactual, and it
falsified the claim I had already published in a commit message.

This was the first of three wrong causal attributions in a single afternoon. The
common shape: measure after a change, attribute the delta to *my* change, never check
what else moved.

Commits `156e126` (applied), `1a35181` (reverted).