Every script I run that touches the outside world goes through a local proxy. So when one of them started failing this week, my first assumption was that the proxy had drifted. That assumption was right. The interesting part is that I almost reverted a correct fix because my verification step was measuring the wrong thing.
Here is what I saw.
networksetup -getwebproxy Wi-Fi reported Enabled: Yes, server 127.0.0.1, port 7900. Everything looked configured. But lsof -nP -iTCP:7900 -sTCP:LISTEN returned nothing. There was no process on that port. The proxy daemon had been started manually a few days earlier and was listening on 7897 instead — two proxy cores existed on the machine, one managed by a root service and one started by hand, and the GUI had pointed the system setting at the one nobody was running.
So I fixed it. No password needed:
networksetup -setwebproxy Wi-Fi 127.0.0.1 7897
networksetup -setsecurewebproxy Wi-Fi 127.0.0.1 7897
Then I re-ran my check to confirm. Still 000. Connection failed.
At this point I had two candidate explanations: the fix didn't take, or the check is lying. I spent a few minutes on the first one. It was the second one.
curl does not read the macOS system proxy setting. It reads http_proxy / https_proxy environment variables, and this machine doesn't set them. So a bare curl https://www.google.com goes out directly, hits a wall, and returns 000 — regardless of whether Wi-Fi's system proxy is perfectly configured. The system proxy panel applies to applications that go through the macOS network stack's proxy-aware APIs. curl is not one of them.
The moment I ran the same request with the proxy spelled out:
curl -s -o /dev/null -w "%{http_code}" -x http://127.0.0.1:7897 https://www.google.com
...it returned 200. The fix had worked the entire time. I had been about to undo it.
Two general lessons came out of this, and the second one is the one that keeps costing people hours.
First: "enabled" is not the same as "reachable." networksetup -getwebproxy will happily report Enabled: Yes for a port where nothing is listening. The flag tells you what the OS would do, not whether anything is there to receive it. If you want to know whether a local listener exists, ask the kernel — lsof -nP -iTCP:<port> -sTCP:LISTEN — not the preference pane.
Second, and the one I actually care about: when your verification disagrees with your fix, suspect the verification first. I have now watched this exact failure mode three times on three different projects. A check queries the system's own idea of its state and reports green while the outside world disagrees — a Sent folder that contains a message that never left the building, a publish API that returns 200 for an article that 404s, a proxy setting that says enabled with no listener behind it. In each case the fix was correct and the check was reading a confirmation the system had written about itself.
The habit that catches it: before you trust any "it worked" signal, ask what that signal actually observes. Does it read a record the system wrote for itself, or does it ask something outside the system to confirm? If it's the former, it can pass while the thing genuinely failed. If you can move the check to somewhere the outside world is able to say no, move it. My outbound scripts now do a real DNS lookup before sending; my publishing pipeline fetches the live URL after publishing and greps for its own content.
That last change came from a bad week. A publishing automation of mine reported success for 22 days while producing nothing visible, because it only ever checked the API response and never checked the page. One curl and one grep would have surfaced it on day one. It didn't, because I had never asked the check that question.
The uncomfortable version of this rule: a check that can't fail is not evidence. It's just a line in a log that makes you stop looking.
I build and fix small automation like this — scripted checks, site plumbing, SEO diagnostics — as a freelance service. If your pipeline is confidently reporting success at things that didn't happen, see what I do here: https://yongrui-services.pages.dev/
Top comments (0)