v0.89.0 — trusting the proxy it started
The proxy was asked a question it is designed to refuse
Detection asked the proxy for a certificate under a.<ending>. The proxy will not present one for a name with no key published in the registry — deliberately, because a TLS failure is something a browser knows how to explain and a reset mid-request is not. And dns enable cannot invent a name that somebody has registered: the registry lists endings, not names, so a.<ending> is the best it could ever construct, and that is exactly the shape being refused.
The check therefore could not pass on a correctly configured machine. Three lines apart, both true as written:
ok proxy holds 127.0.0.1:443
-- no pinned-TLS proxy on this machine
The bridge was then started without proxy mode, so every Moshpit name answered its origin directly and a stock client got a certificate no authority had signed — on a machine that had, in that same run, installed the proxy, started it, watched it take the port, and put the local root in the system trust store.
v0.88.0 made the probe name parseable. That moved the failure from ERR_INVALID_URL to ERR_TLS_CERT_ALTNAME_INVALID and no further, because a name that parses is still a name with no key published.
The probe was the wrong instrument for the question. It exists for a proxy that something else installed, where whose proxy it is genuinely is not known. That is not the situation after this command has written the unit, restarted it, and confirmed the port held — which is stronger evidence than any handshake could be. So that is what decides it now, and the probe stays for the case it was written for.
The tests drive dns enable itself rather than the helper, and one of them checks the thing that actually matters: that the bridge is told. Detecting a proxy and then not passing --proxy to the resolver leaves every name answering its origin, which looks exactly like detecting nothing at all.
Still true after this
A bridge that is already running keeps the mode it was started with. There is no channel to a detached resolver to change its mind, so on a machine with one already up, proxy mode arrives on the next restart of the bridge rather than immediately.