Case study · Network · CDN · Troubleshooting
Same URL,
different internet.
An internal web tool had been marked as fixed, but some colleagues still couldn't open it. “Works on my machine”, except the machines were in different countries.
- 6
- network paths tested
- 2
- different responses from one URL
- 0
- causes on the user’s side
Summary
Problem
An internal tool worked from some places and not from others, and every single-location test said “fixed”.
Solution
Test the same request across network paths, and escalate with evidence the log owners can act on.
NoteEverything described here is accurate. For confidentiality reasons, product and system names and exact figures are deliberately generalised.
Context
An internal web tool sat behind a CDN, the network that serves a site from many locations around the world. The issue had been closed as fixed, yet some colleagues kept getting an error page while others loaded it normally.
The problem
Every test from a single location confirmed the fix, so the ticket kept bouncing back. “It works” was true for whoever tested it and false for whoever reported it.
What I found
I changed one thing at a time: same computer, same request, only the network path varied: different CDN locations, mobile carriers, and anonymising networks.
- Some paths returned 200 OK: the page worked.
- Others returned a redirect to the error page, with an empty response, sent by the CDN itself, before any script, page or login was involved.
- For every test I recorded the CDN location and country, the response headers and the request ID, so each result could be traced in the logs.
Ruled out: the browser and cookies (the redirect came before the page existed), login (it happened before authentication), the office network (reproduced from outside), and the server being down (it answered fine elsewhere).
Main hypothesis: a routing or redirect rule on the CDN with a location condition, or settings that differed between locations. I couldn't prove which rule it was, and the pattern may follow the user's country rather than the CDN location. Comparing the two across tests would be the next step.
The escalation
The page loads (200) from every region.
Some locations get redirected to the error page.
Check the CDN's redirect rules, regional conditions and logs, using the recorded request IDs.
The redirect happened before the page ever reached the browser. Nothing on the user's side could change it.
Outcome
Escalated with reproducible evidence, so the team with log access could look for the rule instead of re-testing from one location.
What I'd do differently
Script the tests, with status, location and country logged automatically for every path, instead of running them by hand. Faster to repeat, and easy for someone else to rerun.
“A 200 from one city doesn't prove it works from another.”