RUN IT WELL

Route a browser through its own proxy

One browser can use an upstream proxy while the others keep their current routes. Set it when creating the browser, or stop an existing browser before changing its settings. This requires Tallylamp 0.5.0 or newer.

Tallylamp guides3 min readUpdated

Set the browser's route

  1. Enter the proxy server

    In New browser, enter an HTTP or HTTPS server URL such as https://proxy.example.com:8443. Keep the username and password in their separate fields, not in the URL.

  2. Add credentials if needed

    Supply both a username and password for Basic authentication, or leave both blank for a proxy with no login. An empty password is allowed with a nonempty username.

  3. Change an existing browser

    Stop it, choose Configure proxy in its sidebar, save the settings, and start it again. Only its owner or an administrator can edit the route. Clear the server and credentials to return to direct access.

The sidebar shows the saved server and whether it uses authentication; it cannot show the credentials again. Re-enter both when editing an authenticated proxy. Saving the setting does not test whether the proxy is reachable.

Configure it through API or MCP

Pass proxy to POST /api/v1/browsers or tallylamp_create_browser. For an existing stopped browser, pass it to PATCH /api/v1/browsers/{id} or tallylamp_update_browser.

Browser creation input
{
  "name": "Proxied browser",
  "proxy": {
    "server": "https://proxy.example.com:8443",
    "username": "your-user",
    "password": "your-password"
  }
}

An update replaces the whole proxy setting, including credentials. Omit proxy to leave it unchanged, or send null to remove it. Responses include only server and hasAuthentication. Settings survive browser and service restarts, but profile-template copies do not include them.

A borrower uses the browser's existing proxy and cannot change it. Lending closes loopback tunnels; it does not remove the upstream route.

What goes through the proxy

Routing rules
Traffic or settingBehaviour
HTTP and HTTPS websitesThe local safety proxy checks the destination, then connects through the upstream. WebSockets are supported too.
DNSResolved on the Tallylamp server, not through the upstream. Both the upstream and destination IPs are checked.
Loopback tunnelsA matching browser-specific tunnel takes precedence and keeps its own route.
Proxy outage or rejected credentialsThe request fails with 502. There is no direct fallback.
SOCKS and PACNot supported. Use an HTTP/HTTPS proxy that accepts CONNECT to IP addresses, including port 80 for plain HTTP.
UDPProxied browsers disable QUIC and WebRTC's non-proxied UDP. This is not an OS-level network sandbox.

Private-network checks still apply to the upstream and the website. The operator can relax them with TALLYLAMP_ALLOW_PRIVATE_NETWORK=1, but adding a proxy alone does not grant access to private addresses. The service's API, viewer and MCP connections keep their normal routes.

If pages fail to load, check the provider's host, port, credentials and CONNECT policy. Plain HTTP connections close after each request. A new exit IP does not guarantee that a website will accept automation or keep a login valid.

Protect the stored credentials

Prefer an HTTPS proxy. Basic-auth credentials sent to an HTTP proxy are unencrypted between Tallylamp and that proxy. HTTPS proxies need a trusted certificate for their hostname; website TLS remains between Chrome and the website.

Docs behind this guide

Based on Tallylamp's documented behaviour. See the source for API details and release-specific settings.

YOUR NEXT STEP

Put it to work.

Free, MIT-licensed software. You pay for your hosting.

Deploy on Railway