Categories compared · no product claims · updated 2026-09-17

Five ways to point a frontend at another backend environment — compared, including where each one wins

A dev-server proxy, a system capture proxy, an API client, a header-modifying extension and editing your application's own config are all real answers to cross-environment debugging. They differ in four concrete costs: what you have to change, how long it lasts, whether it survives a page reload, and how far the traffic has to go before the tool stops seeing it. This page states those costs, and says plainly where a browser rule is the wrong choice.

Product overview View source on GitHub

Written by the extension's author Categories, not brands Includes where we lose

The one-sentence version: If the request is made by a page you have open, and you want it answered by a different environment without touching that page's code, a browser rule is the shortest path — because the request is issued by the extension, so the page's Access-Control-Allow-Origin check never runs. If the traffic is not from a browser page, use a system capture proxy instead.

5approaches compared

4costs that decide it

0named products in the matrix

1section on our own limits

Pick by the situation, not by the tool

Each row is one situation and the approach that costs the least in it. "This extension" means Cross-Origin Proxy.
Your situation	Cheapest correct fix	Why
A page on FAT must call UAT, and you do not own the backend	Browser rule	No redeploy, no gateway ticket, applies to every project in the browser at once
Local dev server must forward `/api` to a backend for everyone on the team	Dev-server proxy	It lives in the repo, so it is committed, reviewed and identical for colleagues
You need to see or change traffic from a mobile app, a desktop app or a server process	System capture proxy	It sits at the OS or network layer; a browser extension can only see browser pages
The endpoint does not exist yet and you need to agree its shape with a backend engineer	API client	Requests are shareable artefacts there; a browser rule lives in your Chrome profile
You only need to add or swap one request header on a live page	Header-modifier extension	Smallest tool for the smallest change — until you also need a different host
The environment difference is permanent product behaviour	App config	Correct-by-source beats a rule that only exists on your machine

The last row matters more than the first. A browser rule is a debugging instrument: it is the fastest way to see a behaviour and the wrong place to park a decision. Once "this page talks to that host" is permanent, move it into the application's configuration.

The five approaches, each on its own terms

Every entry starts with what the approach is genuinely good at. Categories only: capabilities vary inside a category, so verify against the tool you actually run.

Dev-server proxy

What it is. A proxy table in the build tool — Vite, webpack-dev-server and friends forward /api to another origin, so the browser sees one origin and CORS never enters the conversation.

What it is genuinely good at. It is committed, reviewed and identical for everyone on the team, it needs no browser extension, and it is the right default for a project's own local development.

Where it stops. It is per project and per dev server: a new repo means a new table and a restart. It only sees traffic routed to that dev server, so a page calling a second host directly is outside its reach. And it forwards — it does not rewrite responses, mock an endpoint that does not exist, or add latency on demand.

How it relates to a browser rule. Complementary. Keep the repo's proxy table for the project's normal development; add browser rules for the cross-environment cases that are yours alone.

System capture proxy

What it is. A process on your machine that the operating system or browser is told to route through (mitmproxy is the open-source reference in this category). To read HTTPS it must act as a certificate authority your clients trust.

What it is genuinely good at. Nothing beats it for reach: browser, mobile app, desktop app and server process, all in one place, with full request and response inspection, breakpoints, scripting and saved session files.

Where it stops. The setup cost is the answer. Installing a trusted root certificate changes your machine's security posture, some clients pin certificates, and on a corporate laptop it may need approval. It is also system-wide: it keeps intercepting when you stop debugging, and it is the kind of tool that gets turned off before you can trust a result.

How it relates to a browser rule. A browser rule cannot do system-wide traffic and does not try to. It gives up that reach in exchange for needing no certificate, no system setting, and nothing to remember to switch off outside the browser.

API client

What it is. A standalone tool where you build a request by hand, send it, and read the response — with collections, environments and mock servers.

What it is genuinely good at. Contract work. Designing and agreeing an endpoint shape with a backend engineer, keeping a shared library of requests, and testing an API with no UI attached to it.

Where it stops. The response goes to the client, not to your application code. So the UI path, the axios interceptor, the error branch and the retry logic all stay unverified. Anything your page does with the payload — cookies, redirects, same-origin credentials, streaming — is outside what a client can prove.

How it relates to a browser rule. Best used in sequence. Design the mock in the client, paste the same body into a rule's mock response, and let the real page consume it. That combination covers the gap neither tool closes alone.

Header-modifier extension

What it is. A lightweight browser extension that rewrites request or response headers by URL pattern — often the declarative request-redirect APIs under the hood.

What it is genuinely good at. One-off header changes: accept-language, a cache-control override, a debugging flag. Low concept count, instant effect.

Where it stops. The header is the whole surface. It typically does not replace a request body, cannot answer with a mock body of your own, has no per-request delay or retry, and cannot touch a WebSocket connection.

How it relates to a browser rule. This extension uses the same network-layer mechanism for the subset of rules that only rewrite a URL, and adds the service-worker channel on top when a rule needs header, body or response rewriting. So it is a superset in practice, at the cost of more to learn.

Editing the application's own config

What it is. The honest option: change the base URL, the environment file, or the token in source, rebuild, and let the app call the other environment directly.

What it is genuinely good at. It is reproducible for everyone, it works in CI, and it survives your machine being wiped. When the difference is permanent, this is the correct place for it.

Where it stops. A rebuild cycle per attempt, a diff you must remember to revert, and the CORS question you cannot avoid — the page now calls a foreign origin, so the backend must allow it, which means a gateway change and a redeploy.

How it relates to a browser rule. A rule is the temporary version of the same edit, applied outside the source tree. Same effect on the request, none of the revert risk in review.

The same comparison as a matrix

Green is favourable for that row, orange is partial, grey is absent. Columns are categories, so read a cell as "typical for this category", not as a statement about a specific product.

Cross-environment debugging and request rewriting, the usual ways.
Approach	This extension	Dev-server proxy	System capture proxy	API client	Header-modifier extension	Editing app config
Needs a backend or gateway change	No	Often, for CORS	No	No	No	No
Configured per project	No — browser-wide	Yes	System-wide	Per collection	Per rule set	Yes
Survives a page reload without re-doing work	Yes	Yes	Yes	Not applicable	Yes	Until you revert it
Rewrites responses (status, headers, JSON fields)	Yes	No	Yes	Mock servers, not live pages	Headers only	No
Mock / delay / block / retry from the UI	Yes, conditional mock included	With extra plugins	Yes	Yes	Mock only, typically	No
Covers WebSocket traffic	Yes	Rarely	Yes	No	No	Depends on the app
Needs a local CA certificate to read HTTPS	No — runs inside the browser	No	Yes	No	No	No
Reaches non-browser traffic (mobile, desktop, server)	No — browser-scoped	No	Yes	Only its own requests	No	Depends
Shareable with the team as a reviewed artefact	Export JSON to the repo	Yes — in the repo	Session files	Yes — collections	Often cloud-synced	Yes — in the repo
Works in CI without a browser profile	No	Yes	Yes	Yes — CLI runners	No	Yes

Read the last two rows as the honest boundary. This extension loses on system reach and on team reproducibility, and it wins on the two things that decide daily debugging: nothing outside the browser has to change, and the rule is still there after you reload.

Where this extension is the wrong tool

A comparison that only lists wins is advertising. These are the cases where you should pick something else.

Traffic that does not come from a browser page

A server-to-server call, a mobile app, a desktop process, a curl in a script — none of them load a content script. Use a system capture proxy or fix the route in infrastructure.

Anything that must be true for the whole team

Rules live in your Chrome profile. If the correct behaviour belongs to the project, it belongs in the repo: a dev-server proxy entry or an application config value. You can export JSON for a colleague to import, but that is a handoff, not a source of truth.

Continuous integration

There is no headless mode for a browser extension's rule set. Test automation should call the backend directly or run behind a proxy configured in the pipeline.

Pages Chrome does not let extensions touch

chrome:// pages, the Chrome Web Store and other extensions' pages are off-limits to content scripts, so the interception channel cannot run there. Network-layer redirect rules still apply to requests those pages make.

A pure URL rewrite against a host that does not allow your origin

If a rule only rewrites the URL, the browser performs a redirect and still validates Access-Control-Allow-Origin on the redirected response. Add any capability to the rule — a response header override is the cheapest — and it moves to the channel where the extension issues the request.

Reading a request that never leaves the browser

Service workers using some caching strategies, and traffic through a proxy already configured at the OS level, may not be intercepted the way you expect. Confirm with the URL match tester before trusting a negative result.

Switching: what actually moves

From a dev-server proxy

Take the /api prefix you were forwarding and express it as one wildcard rule: https://fat-api.example.com/* → https://uat-api.example.com. Leave the repo's proxy table alone — other developers and CI still depend on it.

From a capture proxy

Recreate the rewrite as a rule and keep the capture proxy for what it is better at: non-browser clients and deep inspection. Turn off system proxy routing while you test the rule, or two layers will fight over the same request.

From an API client

Paste the mock body into the rule's mock response with the status and content type you had agreed. Importing a HAR export of real traffic creates rules automatically, which is usually faster than retyping them.

From a header in source

Move the token out of code and into the rule's request header overrides, then revert the source change. The value stops appearing in diffs, and switching the rule off is the whole rollback.

Comparison questions

The product's own FAQ — limits, privacy, permissions, how the two channels work — lives on the product overview. These answers are only about choosing between approaches.

Is a browser extension a replacement for a dev-server proxy?

For browser pages, usually yes, and it is broader in one direction: one rule set covers every project in the browser instead of a proxy table per project, and it can rewrite responses instead of only forwarding. It does not replace the dev-server proxy for non-browser clients, for CI, or for anything that talks to the dev server outside Chrome.

When is a system capture proxy the better tool?

When the traffic is not from a browser page. Server-to-server calls, mobile apps routed through a workstation, desktop applications, and anything you want recorded in a shared session file all belong to a system-wide proxy. It reads HTTPS by standing in as a trusted certificate authority, which is exactly the setup cost an in-browser extension avoids.

Why not just replay the request in an API client?

An API client proves the endpoint behaves; it does not prove your page handles it. The response reaches the client, not the application code, so UI paths, interceptors and error handling stay untested. Use it to design the mock, then load the same body into a browser rule so the real page consumes it.

A header-modifier extension already changes requests. What is the difference?

Header editors rewrite request and response headers inside the browser, which is the smallest slice of this problem. They generally do not redirect the request URL to another host, do not replace the request body, cannot substitute a whole mock response, and have nothing to say about WebSocket connections — and the redirect is the part that removes the need for a backend CORS change.

Can I use two of these approaches together?

Yes, and that is normally the right answer. A dev-server proxy stays where it is needed for local build tooling, a capture proxy stays for non-browser traffic, and browser rules take over the day-to-day case of “this page should be talking to that environment”. The only thing to avoid is two rules rewriting the same request at once, which makes the result hard to reason about.