The setting was saved, and three launches ignored it

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.

How it works: Machines that exist

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. 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 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.