Which of your hostnames does a hosted browser provider's tunnel carry, and what happens to the rest?

## A tunnel is a route for names, not a mode for the browser The common mental model is that starting a tunnel puts the rented browser *inside* your network. It does not. The browser stays where it is, on somebody else's machine, and a tunnel gives it a way to reach a **set of names** that would otherwise resolve to nothing useful from out there — in this case a payroll portal whose staging host is built per branch and published nowhere public. Which names are in that set is a decision somebody makes, and it is separate from which tunnel a session attaches to. A session can attach to exactly the right tunnel and still be unable to reach the host it came for, because that host was never in the routed set. Diagnosing the two together is why these problems take a morning; they fail independently and should be ruled out one at a time. ## The two ends of the scope decision | | Everything through the tunnel | Only listed names through it | |---|---|---| | Where public requests go | back through your network, out by your egress | fetched directly by the far side | | What governs them | your outbound rules and filtering | the provider's own network | | If your path stutters | every request in the run is affected | only the internal ones are | | A missing entry costs | nothing; there is no list to miss | silence: the name is fetched from outside | | What the run resembles | a browser sitting on your network | a browser outside, with a door to a few hosts | Neither column is the safe default. Routing everything removes the silent-miss failure and pays for it in speed, in your outbound rules deciding whether third-party assets load at all, and in a much wider blast radius when your own side has a bad minute. Routing a list is narrower and quicker and leaves you one editing mistake from the worst failure on this page. ## The failure that has no error If a hostname is not in the routed set, the request is not refused. It is fetched the ordinary way, from wherever that name resolves publicly — and names collide with the public world more often than people expect: - A staging hostname under a domain the company also uses publicly, where a wildcard record answers everything. - A name that used to be public and still is, pointing at an old deployment nobody retired. - A parked or defensive registration that serves a placeholder page with a success status. - A name nobody owns, resolved by a search-and-redirect layer somewhere in the path. In each case something answers, the browser renders it, and the run continues. A suite written to check that a page loads will pass. A suite written to check the payroll portal's behaviour will fail on an assertion whose message is about a missing element, sending the reader to look for a front-end regression that does not exist. The defence is to make identity an assertion rather than an assumption: 1. **Assert on something only the internal target can produce**, as early in the run as possible — the branch name rendered in the page, a build identifier in a footer, a value the public site does not serve. 2. **Do it before the interesting assertions**, so a wrong-target run fails with a message that names the real problem rather than a downstream symptom. 3. **Record where the run believed it was**, so the next morning's question has a written answer. ## Keeping the set right when branches come and go Per-branch staging hosts are created and destroyed continuously, and a routed set maintained by hand goes stale exactly when a new branch needs it — the branch is new, the host is new, and the list is not. Two structural answers beat diligence: - **Route a pattern rather than an enumeration**, where the naming scheme allows it, so a new host that follows the convention is covered the moment it exists. - **Generate the set from whatever creates the environments**, in the same step, so the list and the hosts cannot disagree. A list edited afterwards by a human is one that will eventually be edited late. ## What you can observe, and what you must establish What a given provider does by default — whether an unlisted name is fetched directly, refused, or handled some third way — is that provider's own behaviour, and it is not something any artefact of yours can check. Treat it as a question to answer once, deliberately, rather than a fact to assume: - Ask what the default scope is, and write the answer down where the pipeline lives. - Prove it at least once, by pointing a run at a name you deliberately left out of the set and seeing what the browser does. - Re-prove it when the pipeline's shape changes: a default established for one configuration is evidence about that configuration only. The subject reduces to one sentence worth carrying into an interview: **a tunnel decides which names a remote browser can reach; anything outside that decision is still reachable — just not from you.**