how our in-house go proxy rewrite made wakeups 92% faster

agents working in the browser can often sit idle for hours while they wait for human approval or other async outcomes. when agents come back online, they need the same cookie and session state as before, and they need to connect to the internet as if nothing happened.

we rebuilt browser proxies as a host-side proxy service to decouple network connection management from the browser vm itself. this architecture change has improved reliability and reduced latency while providing better error reporting and more network traffic configuration options.

the problem with running the proxy inside the browser

in our previous architecture, every browser vm ran its own instance of envoy, a proxy service that handled the browser’s network traffic. as a resource management strategy, we put browsers in standby mode while agents are idle, preserving browser and cookie state for when the workload comes online again. but this in turn would put envoy on standby and lead to vms waking up with stale network state the proxy service still assumed was fresh. out-of-sync KERNEL configurations and invalid upstream connections could cause request timeouts and failures for browsers coming back online.

debugging these issues wasn’t easy either. envoy was effectively a black box inside each browser vm. when a request failed, we had limited visibility into what envoy was doing internally, whether its credentials were current, or which stale connection state was responsible.

while customers who created and deleted browsers frequently were less exposed to these issues, others felt the impact, especially customers running large dedicated browser pools that could sit idle for hours before a burst of work brought them back online. we measured first-connection request failures after idle sessions at a rate of 20–26.7%.

moving the proxy out of the browser vm

to solve this, we needed to decouple the proxy from the browser. we could have moved envoy outside the browser vm; instead, we decided to build our own host-side proxy service to maintain control over KERNEL-specific customer, domain, and business logic.

building our own host-side proxy service was a lot more work, as there was no off-the-shelf proxy framework that met our requirements. we forked and modified established open-source go packages to build the core framework. the full build took roughly 3–4 months. owning the implementation was worth it, though, to have a single place to make the proxy service fast, observable, and customizable.

the end result: the new proxy service acts as an always-on network layer separated from the browser vm. while the browser can be put on standby and then wake up, the proxy never sleeps; it maintains current network state and ensures that browser traffic is always routed to fresh request paths.

the new separation allows us to run proxy service hosts at the metro level, bringing the data as geographically close to the client as possible — important for speed and continuous availability.

measuring the impact

before release, we benchmarked the new proxy service in a test harness using KERNEL’s own browser-pool infrastructure. this way the team could exercise the new architecture the same way a customer would.

test patterns included creating large pools, hot-swapping proxies, acquiring browsers from a pool 2,000 times in a row, and leaving browsers idle for periods of up to 2 hours before waking.

the following table shows the improvements in post-standby latency, which is the time it took the browser to make a successful first network request after waking:

post-standby reliability, or the percentage of requests completed in a given time period, drastically improved as well:

with actual cohorts in production, we’ve eliminated a class of chromium errors and reduced median latency by 83% in proxy change operations while maintaining the same reliability as the envoy proxy service.

better error handling and more configurations

before, envoy’s limited error surfacing made it difficult to debug network issues in the browser vm, but owning the new proxy service enables us to log signals for every traffic request a user makes. a generic browser failure used to leave several plausible causes: a problem with the browser, the proxy, or something upstream. now, failures are surfaced faster with better attribution. In addition, developers can now perform proxy health checks with custom target endpoints (instead of KERNEL’s default test urls).

with the new service, we can now route browser traffic through a wider range of proxy servers, providing enhanced privacy, flexibility, and bot detection avoidance. for instance, a datacenter proxy is best for high-volume, predictable automation where speed and cost matter most, while a mobile proxy is better when you need traffic to resemble a real carrier-backed mobile user to avoid bot detection and ip-based blocking.

better network error surfacing and testing, more configuration options, and browser-network independence combine to enable you to act on a failing or blocked proxy ip error by immediately hot-swapping your proxy mid-session without interrupting your browser state or your agent’s workflow.

where this is heading

KERNEL users don’t need to do anything to unlock this feature; the architecture change is invisible at the browser boundary but removes an entire class of stale-state issues. in addition, our new proxy architecture gives us an independent network layer we can extend to unlock entirely new use cases. since proxies sit between the agent’s browser and the internet, we can modify or redirect requests dynamically at egress time. we’re working on new security boundaries, agent runtime guardrails, and sensitive data handling at the transport layer. stay tuned for more updates.

in the meantime, try proxies today: https://www.kernel.sh/docs/proxies