Maxun is a point-and-click scraper you host yourself: you record a robot in a browser and it replays it. It has a proxy form and a test button, and both do slightly less than people assume. We read release 0.0.47 on 20 September 2026.
Where the setting lives
The form posts an address, a username and a password to the server, which encrypts all three and stores them against your user account. Not against the installation: two people on the same instance can have different addresses, and a robot uses the address of the user it belongs to.
Credit where it is due. Several tools in this series print the same values into a log. This one encrypts them at rest and decrypts them only when a browser needs them.
| Where | Does your proxy apply |
|---|---|
| Recording a robot | yes |
| Running a robot | yes |
| The test button | yes |
| Another user's robots | no, they have their own setting |
Half a login is dropped in silence
The code attaches the login only when the username and the password are both present:
...(proxyConfig.proxy_username && proxyConfig.proxy_password && { username, password })
Fill in one and leave the other blank, and the browser is handed your address with no login at all. What you see then is an authentication failure from the proxy, which looks like a credentials problem rather than a form problem. It is worth checking both fields before you check anything else.
Because the address goes to a browser context, that library's rules apply: the login travels in separate fields rather than inside the address, and a SOCKS address with a login is not available. We covered those rules in detail on our Playwright MCP page.
What the test button proves
The test opens a browser context with your proxy, loads https://example.com, waits for the document, and reports success if the response is fine. Thirty second limit.
That is a real test and a narrow one. It proves the line works and your login is accepted. It proves nothing about the site you actually want, because that site was never contacted.
So a green test and a refused robot are perfectly consistent. In our own paired measurement, four of thirteen sites refused both a server address and a residential one. Any of those four would fail a robot while this test stays green.
Which proxy type fits it?
Residential, for the sites that answer a hosting address differently. Our test is the size of that effect: 4 of 13 answers changed.
Two practical notes for this tool specifically. First, an allowed address avoids the pair rule completely: on a Residential Premium plan your machine's address can be allowed, up to 150 per plan, so there is no username and password to get half right. Second, this records and replays a real browser, so a run pulls images, fonts and scripts as well as data. On a per gigabyte line that is where the bill comes from, so size the plan for pages rather than for records.
A sticky port suits a robot that works through one site, with a retry in your schedule because a sticky address can change early when its device leaves the network. The residential proxies page lists the plans, and the plan API manages allowed addresses from code.
What breaks
- The proxy seems configured but nothing changes. Check which user owns the robot: the setting is per account.
- Authentication fails although you typed a password. One of the two fields is empty, so neither is sent.
- A SOCKS address with a login does nothing. That combination is not available in the browser layer.
- The test is green and the robot is refused. Expected. The test only loaded a harmless page.
- The traffic bill is larger than the record count suggests. A browser loads everything on the page.
What this page does not cover
We read the release as text and did not run the tool, so we did not watch a robot use the proxy, did not measure a run's traffic, and did not press the test button ourselves. The point about the browser layer's own proxy rules is carried over from our Playwright pages rather than re-derived here. We read the server route and the browser class closely, and the interface component only by name. This project ships every few weeks and the release we read was four days old, so check your version. We will read it again by 20 October 2026.
Where to go from here
Proxies for Playwright MCP covers the browser layer underneath this one, including why the login cannot travel in the address. Proxies for ScrapeGraphAI covers another tool with a pair rule, enforced differently. Proxies for Steel Browser covers a browser service that counts the bytes your line carried.
Sources
- The configuration route that encrypts and stores the proxy per user, and the test route that opens one page through it (server/src/routes/proxy.ts). The browser class that fetches the decrypted configuration by user id and puts it on the context, including the guard that requires both credentials (server/src/browser-management/classes/RemoteBrowser.ts). getmaxun/maxun, release v0.0.47 of 16 September 2026, read 20 September 2026.
- Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and sticky sessions. HProxy documentation, hproxy.com/docs, 20 September 2026.
