Sometimes "works on my machine" really means "works from my country." A site might choose a different language or redirect visitors to a different page based on where their connection comes from. To investigate, you need to send your request from somewhere else.
Shellroute gives each shell its own proxy IP. Pick a country and use the terminal normally. Your commands still run on your machine; clients such as curl send their requests through that country's proxy IP.
Let's try a concrete example: Google Store redirects the same URL to different language settings. We'll run one short command on our normal connection, through the US, and through Germany, then compare the redirect addresses.
Recorded on 17 September 2026 with Shellroute v0.1.4. These are the actual responses from that run, not guaranteed results for every connection.
1. Check the redirect on your normal connection
Use a macOS or Linux terminal with curl installed. We'll install Shellroute when we open the first routed terminal.
In your normal terminal, run:
curl -sSI https://store.google.com/ | grep -i '^location:'
The command shows just the redirect address, not a page full of HTML. In our recording, the normal connection returned:
location: https://store.google.com/?hl=lt
-I asks for headers only, using a HEAD request. -sS hides the progress meter but keeps errors visible. The pipe passes the headers to grep, which keeps the Location line.
Don't add -L: that would follow the redirect instead of stopping at the first response. If no line appears, run curl -sSI https://store.google.com/ without the filter to see the full headers and status. Your normal connection may return a different language setting.
Keep this terminal open so you can compare its result with the routed requests.
2. Run the request through the US
Open another terminal. Install Shellroute with npm and log in:
npm install -g shellroute
shellroute login
Enter your email and the code sent to it. A successful new login opens an interactive Shellroute session. If you're already logged in, run shellroute to open one. Other installation options are in the quickstart.
Inside that session, select the US:
/connect US
Once the connection succeeds, run the same command:
curl -sSI https://store.google.com/ | grep -i '^location:'
In the recording, this returned:
location: https://store.google.com/?hl=en-US
Keep this terminal open to test other pages or repeat the request through the US.
3. Repeat from Germany
Open a third terminal and start Shellroute using your saved login:
shellroute
Inside it, connect to Germany:
/connect DE
Once the connection succeeds, rerun your request:
curl -sSI https://store.google.com/ | grep -i '^location:'
Our German connection returned:
location: https://store.google.com/?hl=de
The US shell gives you a second routed comparison. A difference on only one route is a different lead from both proxy routes behaving differently from the normal connection.
4. Compare what the application returns
We sent the same request in every terminal. In this run, the redirect's language setting changed with the connection:
| Connection | Redirect language setting |
|---|---|
| Normal | hl=lt |
| US | hl=en-US |
| Germany | hl=de |
That shows a real response difference worth investigating. It doesn't tell us exactly how Google chose each destination, or what the full page would display. We checked redirect headers with HEAD, not a complete browser visit.
To investigate your own site, replace the Google Store URL with the page a customer reported. Run the same command in each terminal.
For example, suppose a German customer says your checkout opens in English. You expect /checkout to redirect to /de/checkout, but the German terminal shows /en/checkout. You now have a request that reproduces the wrong redirect. Note when you ran it, find that request in your site's server logs, and check which redirect rule chose the English page. Did the site identify the connection as German? Did a language setting override that choice?
If the simple requests don't show the customer's problem, country may not be the only difference. Your site might remember a language the customer selected earlier. Use a test account with that language selected, then copy its browser request as described below. Run that identical request through the US and Germany. Next, change only the language selection and repeat. Keeping the URL and account the same helps you distinguish the effect of the connection from the saved preference.
When finished, type /exit in each Shellroute session to end its route and return to your normal shell. /disconnect ends the route but keeps the Shellroute session open.
Reproduce a full page or API request
HEAD is useful for this short redirect check, but a site can handle it differently from GET. To fetch a page and inspect its headers and body, use lowercase -i:
curl -i 'https://YOUR_APP.example/checkout'
Replace the placeholder with your authorized endpoint and use the same command in each routed shell. With HTTPS through a proxy, curl may also print 200 Connection established. That's the proxy handshake, not your application's status; inspect the response that follows it.
For an existing browser request, don't reconstruct it by hand. In the browser's developer tools, select Network, reload the page, then right-click the relevant request and choose Copy → Copy as cURL. Keep its method, headers, and body unchanged across routes. Add -i to inspect response headers and remove -L if you want to examine the first redirect. Chrome documents this workflow.
Copied requests can contain cookies or credentials. Use a test account, inspect the command, and don't share those values or private responses publicly.
Just need one request?
Once you're logged in, you can skip the interactive session:
shellroute run DE -- curl -sSI https://store.google.com/ | grep -i '^location:'
Shellroute connects, runs curl through Germany, then closes the session. The local grep simply filters curl's output. Shellroute prints a session summary to stderr; add --no-stat before DE if you don't want that summary.
How it works
Shellroute starts a local proxy and sets proxy environment variables for the shell or command it launches. Curl honors those settings. Other terminals keep their existing connection.
It isn't a system-wide VPN: tools that ignore proxy settings need their own configuration, and it doesn't route arbitrary TCP or UDP traffic. See the compatibility guide before using a different client.
You can now rerun a real request from different countries without reconfiguring each command. Keep the shells open for an investigation, or use shellroute run for a single check.
Open your first routed shell with the quickstart. The CLI is open source on GitHub.
Disclosure: I built Shellroute and operate the service the CLI connects to.
Top comments (0)