In Cypress, what happens to a request whose host matches a `blockHosts` pattern?

## What a block actually does `blockHosts` is a Cypress configuration option that takes a host pattern, or an array of them. When a request's host matches one, **Cypress ends the request itself**: nothing leaves your machine, no connection is opened to that third party, and the browser is answered with - status **`503`**, and - an **`x-cypress-matched-blocked-host`** response header naming the pattern that matched. That header is the debugging affordance. When a bank-statement suite blocks four telemetry hosts and one page still stalls, opening the browser's network panel and reading which rule matched tells you in seconds whether the block fired at all. Because the request never goes out, blocked requests resolve **immediately**. That is why blocking analytics, error-monitoring and A/B-testing hosts is a standard way to take dead time out of a suite: the third-party PDF viewer embedded in the statements page may ping a metrics endpoint on every render, and none of it is under test. ## Writing the pattern Patterns are matched with the `minimatch` library (also exposed to specs as `Cypress.minimatch`) against the **host** of the URL, after the protocol and the default ports are stripped. That gives four rules: - ✅ Pass **only the host**: `metrics.pdfviewer.example`. - ❌ Never include the protocol: `https://metrics.pdfviewer.example` matches nothing. - ✅ Use `*` wildcards: `*pdfviewer.example`, `*.pdfviewer.example`. - ✅ Include the port **when it is not `80` or `443`**: `localhost:1234` needs its port, an `https` host on `443` does not. Given `https://metrics.pdfviewer.example/collect`, all three of `metrics.pdfviewer.example`, `*.pdfviewer.example` and `*pdfviewer.example` match. Given `http://localhost:1234/statements.json`, only `localhost:1234` matches — `localhost` alone does not. ## The subdomain trap This is the mistake that costs an afternoon. For a URL with **no subdomain** — say `https://pdfviewer.example/embed.js`: 1. `pdfviewer.example` matches. 2. `*pdfviewer.example` matches, because the wildcard can expand to nothing. 3. `*.pdfviewer.example` does **not** match, because the literal dot has nothing before it. So a list written as `*.pdfviewer.example` silently lets the apex domain through, and the block appears not to work. When a pattern is not behaving, test it against the URL directly rather than staring at it. ## Where it sits relative to the network path `blockHosts` is enforced in Cypress's **request middleware**, which is shared by both transports: the native browser network used by Chrome, Chromium and Edge as of Cypress 16, and the legacy proxy path used by Firefox, WebKit and Electron. **The behaviour is identical on both**, so a cross-browser suite does not need a second rule set. That is worth knowing because several other network behaviours *do* differ by browser in Cypress 16, and this one deliberately does not. ## What it is not for - It is not a stub. A blocked host returns `503`; if your app needs a *shaped* response from that endpoint, blocking is the wrong tool. - It is not a security control. It removes noise from a test run; it says nothing about what your application does in production. - It is not a per-command switch. `blockHosts` is resolved as configuration, and the scope you set it at decides which tests see it — a suite or test configuration object is the way to narrow it to the specs that need it. - It is not a substitute for asking why the request exists. If the statements page fires a telemetry call on every scroll, blocking it in tests hides a question worth asking of production. ## Reading a block that did not fire When a suite is still slow and the telemetry request is still in the network panel, work the evidence rather than the pattern list: 1. Look for the **`x-cypress-matched-blocked-host`** header on the request. If it is there, the block fired and something else is costing the time. 2. If it is absent, compare the request's **host** — not its full URL — against your patterns, and remember that the path, the query string and a default port are not part of the match. 3. Check for the apex-domain case above; a `*.` prefix is the single most common reason a pattern looks right and matches nothing. 4. Check the **scope** the option was resolved at. `blockHosts` is configuration, so a value set on one suite does not apply to a spec that never enters it. ## Recognising a good answer A strong answer names the `503`, names host-only matching, and mentions at least one of the wildcard or port rules unprompted. It also treats blocking as a **suite-hygiene** decision rather than a per-test trick: a short, reviewed list of analytics, error-monitoring and A/B hosts that the whole suite blocks is maintainable, whereas a dozen ad-hoc patterns scattered through specs is not. A weak answer says "it blocks the request" and then writes `https://` into the pattern.