# Proxy setting saved but not applied: where it drops

> Our rotation setting was stored, reported back by the API, and ignored by three launches. A mapper had copied every field of the proxy except the new one.

Source: https://mosaicbrowser.com/blog/setting-saved-launch-ignored

## The setting was saved, and three launches ignored it

Our rotation setting was stored, reported back by the API, and ignored by three launches. A mapper had copied every field of the proxy except the new one.

![1 exit: Saved, reported, and ignored three times](https://mosaicbrowser.com/covers/setting-saved-launch-ignored.webp)

When a proxy setting is saved but not applied, look first at the gap between the record on disk and the object the launcher reads. In September we added `rotateOnLaunch` to Mosaic's saved proxies, the API echoed it back as `true`, and three launches in a row still came out of one IP address. The value had been lost in a short mapper nobody had opened. We found it by launching three times and reading the exit, which took about a minute.

## What we built

`rotateOnLaunch` is a flag on a saved proxy. With it on, every launch mints a fresh session id on the seller's sticky port: one exit while the browser is open, a different one next time. A seller's rotating port is a different product. It changes exit per connection and answers a session token with `400 "Can not use -session- on rotating ports"`. We ship the flag off, and the editor prints the cost beside it. A profile that signs in to a site from Chicago one day and from Denver the next has told that site something no fingerprint work takes back.

The flag went into the store. `GET /proxies/:id` returned it, set to `true`. The editor showed the switch on. Every place a person could look said the setting was saved.

Mosaic is a desktop app

Email yourself the link and open it on your computer.

[How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints)

## What three launches said

Three launches in a row came out of the same address. Then we ran the comparison properly, one proxy and one profile, with only the flag moving:

```
rotation on    35.132.79.114 · 38.45.221.194 · 71.199.128.198
rotation off   69.245.49.160 · 69.245.49.160 · 69.245.49.160

```

That table is from after the fix. Before it, the first row looked like the second.

The cause was one function. `store.effectiveProxy` turns a `SavedProxy`, the record on disk, into a `ProxyConfig`, the object the launcher reads. It does that field by field: host, port, type, username and so on, each copied across by name. The new field was not in its list. So the value was stored correctly, reported correctly, and dropped on the way to the only code that acts on it.

Code review missed it because the bug was a line that did not exist. The diff had the new field in the type, the validator, the editor and the launcher. `effectiveProxy` was not in the diff at all, so a reviewer had nothing there to read.

## The second hole, found on the same pass

The proxy routes checked `host`, `port` and `type` and took any other key without a word. Send `rotateOnLuanch`, with the `a` and `u` swapped, and you got `200 OK` and nothing stored. That is the first bug again seen from the caller's chair. Now `PATCH /api/v1/proxies/:id` answers `400` and names the key it did not recognise.

## The third place a proxy setting drops: the browser was already open

Nobody's code is wrong in this case. Chromium reads `--proxy-server` from its command line at startup and offers no door to change it afterwards. Run `chrome --user-data-dir=/tmp/a --proxy-server=host:8080`, then run it again with port 9090 while the first window is open. The second process finds the first one holding the folder's lock, passes it the URL and exits. You get a new tab in the old browser, still on 8080.

Mosaic reads a profile's proxy at launch too, so a proxy edited under a running profile waits for the next start. Press Stop, change it, press Start. Before the window opens, the launch checks that the new proxy answers and tunnels; if either step fails, the profile stays closed and the message names the step.

## How to check any setting like this

The general shape of the fault is a value with more than one description: the record on disk and a copy of it somewhere else, kept in step by hand. Our own notes already had that rule for fingerprint values. The mapper was the same rule in a different place.

1. Do not trust the settings screen or the API's echo. Both read the store, which is the part that worked.
2. Read the effect. For a proxy that is the exit: open an IP lookup in the profile and write down the address.
3. Repeat it. One launch tells you almost nothing about a rotation setting. Three with it on and three with it off is a table you can read.
4. Change one thing between the two runs. Same proxy, same profile, only the flag.

The three rotated launches above all stayed on `America/Chicago`, because Mosaic matches the timezone to each launch's measured exit; why that matters for a profile is in [Introducing Mosaic](https://mosaicbrowser.com/blog/introducing-mosaic). If a rotation setting gives you a `400` instead of a new address, the port is the problem, and [a session token on a rotating port](https://mosaicbrowser.com/blog/session-token-on-rotating-port) has the seller's own reply. What a browser per account is for in the first place, proxy and all, is in [what an anti-detect browser is](https://mosaicbrowser.com/guides/what-is-an-anti-detect-browser).

## Questions

### Why is my proxy setting saved but not applied?

Two causes cover most cases. The value was stored by one piece of code and dropped before it reached the launcher, or the browser was already open when you changed it. Chromium reads --proxy-server at startup only.

### Does changing a proxy apply to a Chrome window that is already open?

No. A second chrome command with a new --proxy-server and the same --user-data-dir gives its URL to the browser already holding that folder and quits, so you get a tab on the old proxy. Close every window of that profile first.

### How do I check that a proxy setting really took effect?

Read the exit, not the settings screen. Launch, open an IP lookup, note the address, and repeat. For a rotation setting, do it three times with the setting on and three with it off, and compare.

### Does Mosaic accept a misspelled field on a proxy?

No. The proxy routes refuse an unknown key and name it, so a typo like rotateOnLuanch gets a 400 instead of a 200 that stored nothing.

## Related

[A session token on a rotating port is a 400, not a no-op](https://mosaicbrowser.com/blog/session-token-on-rotating-port): "Can not use -session- on rotating ports" means the port, not the username, decides stickiness. We had written the opposite, until we asked the gateway.

[Introducing Mosaic, an anti-detect browser that lives on your machine](https://mosaicbrowser.com/blog/introducing-mosaic): Mosaic runs its own Chromium, draws each profile from a real machine and matches it to the proxy exit. Profiles stay on disk. One plan, no per-profile fees.

[What is an anti-detect browser?](https://mosaicbrowser.com/guides/what-is-an-anti-detect-browser): An anti-detect browser gives each profile its own fingerprint, proxy and cookies, so sites see separate visitors. What it changes, how, and its limits.

[Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host.

[The RTT client hint, read off the wire](https://mosaicbrowser.com/blog/rtt-on-the-wire): ECT, RTT and Downlink headers behind a proxy, measured: a claimed round trip moved JavaScript to 300 and left the RTT header at 50. So we claim neither.

[Two WebRTC flags we used never existed in Chromium](https://mosaicbrowser.com/blog/webrtc-flags-chromium-ignores): Chrome has one WebRTC command line flag for leaks: --webrtc-ip-handling-policy. We also sent two that don't exist, and Chromium accepted both in silence.

[Same IPHey score, opposite reasons](https://mosaicbrowser.com/blog/iphey-same-score-different-signal): IPHey Unreliable on a normal Chrome is usually the exit. Our profile and a stock Chrome both got MX 90, for a browser signal and a location signal.

[Why IPHey's location card can be greener on a profile than on Chrome](https://mosaicbrowser.com/blog/iphey-location-card): On one US exit in one minute, stock Chrome got IPHey's masked or inconsistent location data and our profile got green. The difference was the timezone.

## Mosaic, on your own computer

The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number.

Mosaic is a desktop app

Email yourself the link and open it on your computer.
