I needed to know exactly one thing: what IP address does my browser actually go out on?
Not what my proxy config says. Not what a curl command returns. What the browser itself presents to the outside world. There was a signup form on the other end that cared about the difference, and the two things look nothing alike from where it was sitting.
Here is the sequence, and why almost every step of it tried to lie to me.
The setup. The macOS system proxy was on: HTTP, HTTPS and SOCKS all enabled, pointing at 127.0.0.1:7900. I opened Safari, went to ipinfo.io/json, and read the answer: 104.250.149.155, AS53850, GorillaServers, Inc. — a Los Angeles data center.
The fix. Turn the proxy off:
networksetup -setwebproxystate Wi-Fi off
networksetup -setsecurewebproxystate Wi-Fi off
networksetup -setsocksfirewallproxystate Wi-Fi off
All three reported Enabled: No. I reloaded ipinfo.io in Safari.
Still 104.250.149.155. Still GorillaServers.
This is where I nearly drew the wrong conclusion. The obvious reading is "the proxy didn't really turn off." That reading is wrong, and if I had acted on it I would have spent an afternoon hunting through launch daemons and preference plists for a proxy that was already gone.
What was actually happening: Safari already had an established HTTPS connection — really a CONNECT tunnel — to ipinfo.io from before I turned the proxy off. Flipping a system setting does not tear down sockets that are already open. My request was still riding out through the old tunnel, through the proxy, out of the data center. The setting was correct. The measurement was stale.
Three things I tried, in order:
A cache-buster. ipinfo.io/json?nocache=8573. Useless. It changes the URL, not the connection. Same socket, same tunnel, same answer.
A different domain. api.ipify.org returned "Safari can't connect to the server." Which turned out to be the most useful thing I saw all afternoon. It proved the proxy was genuinely off: with no tunnel available and that host not resolving locally, there was nothing left to connect through. A failure was the first honest signal I got.
Quitting Safari completely and reopening it. Now ipinfo.io returned 183.197.62.85, AS24547, Hebei Mobile Communication — a residential carrier, no data-center traits. That was the real answer, and it had been the real answer for the previous ten minutes. My browser just wasn't reporting it.
The order that works, and the one I'll use next time: turn the proxy off → quit the browser fully, not just close the window → reopen → measure. Skipping the quit is the entire bug.
Two habits came out of this that generalize well past proxies.
One: a measurement that reuses state from before your change is measuring the old system. This shape shows up everywhere. A build that passes because a stale artifact from the previous run is still on disk. A test that's green because a service from the last session is still listening. A health check that reads a status file the process wrote about itself. Before you trust a post-change reading, ask whether anything in the path is holding state from before the change. If something is, you are not measuring what you think you're measuring.
Two: prefer a signal that can fail in the direction you don't want. My successful-looking measurements were the worthless ones. The one that moved me forward was "can't connect to the server" — a failure. And I could reason about it: with the proxy off and this host unresolvable locally, a connection attempt should fail, so a failure confirms the proxy is off. A check whose result would look identical whether your change worked or not is not a check. Sometimes the useful test is the one you expect to break.
That second rule has a corollary I keep relearning: when two tools disagree, don't average them — work out which one is answering the question you actually asked. curl --noproxy '*' ipinfo.io told me the machine's own address was residential. Safari told me it was a data center. Both were true about what they were observing. Only one of them was about my question, because the form on the other end only ever sees the browser.
(If you ever need to sort this out yourself: don't judge an IP by how it looks as four numbers. Read the org and ASN fields and check whether it's a carrier or a hosting company. I have logged addresses as "clean" in the past that turned out to be GorillaServers and Leaseweb hosts. Both looked perfectly ordinary.)
The whole detour cost me twenty minutes. It would have cost me a rejection if I had trusted the first three readings and concluded the environment simply couldn't be fixed.
I do this kind of work as a freelance service — scripted checks, network and environment diagnostics, site plumbing, SEO diagnostics. If your tooling is confidently telling you something that isn't true, that is usually fixable in an afternoon: https://yongrui-services.pages.dev/
Top comments (0)