April 19, 2026

Stop Testing on Perfect Networks: Implementing Chaos Tunnels for Resilient UIs

InstaTunnel Team

Published by our engineering team

Stop Testing on Perfect Networks: Implementing Chaos Tunnels for Resilient UIs

In the modern web development workflow, “localhost” is a lie. We build applications on ultra-low latency fibre connections, running on machines with 32 GB of RAM, and testing against local servers that respond in sub-millisecond timeframes. Then we ship these applications to users on a crowded subway with a fluctuating 5G signal, or to a rural commuter dealing with high packet loss.

The result? Brittle user interfaces that hang, flicker, or crash the moment the “happy path” of a perfect network disappears.

To build truly resilient software, we must stop treating the network as a constant and start treating it as a variable. This is where chaos engineering on localhost comes into play. By implementing “Chaos Tunnels” — proxies that intentionally degrade your local connection — you can stress-test your UI’s error handling and state management before a single line of code reaches production.

The False Security of Localhost

When you develop locally, your fetch() requests aren’t travelling across the internet. They’re crossing a loopback interface with no jitter, no congestion, and no signal interference. In this sterile environment, race conditions stay hidden. Your loading spinners look perfect because they only appear for a fraction of a second.

But the real world is different. Research comparing 5G Standalone (SA) and Non-Standalone (NSA) public networks published in February 2026 found that public NSA 5G exhibited latency of around 54 ms on average — with jitter almost ten times higher than a private SA network, and occasional spikes of more than 50 ms above the median. Wikipedia’s 5G article notes that latency increases substantially during handovers between towers, ranging from 50 to 150 ms depending on network conditions.

That’s the gap your localhost environment is hiding from you.

Why Browser DevTools Aren’t Enough

Most developers reach for the “Throttling” tab in Chrome or Firefox for a quick sanity check. While useful, these tools have fundamental limitations:

Application-level only. They only affect the browser’s main thread and outgoing requests. They don’t simulate hardware-level issues or system-wide disruptions.

Predictable slowness. Standard throttling provides a flat rate, such as “Fast 3G.” It doesn’t simulate the chaos of a connection that is fast for two seconds and then drops 20% of packets for the next five.

No TCP-level simulation. DevTools cannot simulate a DNS failure or a TCP connection timeout that occurs halfway through a large payload.

Defining the Chaos Tunnel: A Network Degradation Proxy

A “Chaos Tunnel” is a middleman — a network degradation proxy — placed between your frontend application and your backend or external APIs. Unlike browser throttling, a chaos tunnel operates at the transport layer, allowing you to manipulate the raw stream of TCP data.

By routing local traffic through a tool like Toxiproxy, you can inject “toxics” into your connection:

Latency: Add a base delay (e.g., 500 ms) to every request.
Jitter: Add random variance to that delay (e.g., ±200 ms).
Bandwidth limiting: Cap throughput to simulate an edge 2G connection.
Slow close: Delay the closing of a connection to see how your UI handles hanging sockets.
Slicer: Cut data into small chunks to trigger edge cases in streaming or chunked uploads.
Reset peer: Abruptly terminate a connection mid-flight to simulate a dropped signal.

Setting Up Chaos Engineering on Localhost: A Step-by-Step Guide

We’ll use Toxiproxy, a TCP proxy framework originally created by Shopify to simulate network conditions. It has been actively maintained since 2014 and, according to a 2025 study analysing GitHub adoption, is among the three most widely used chaos engineering tools alongside Chaos Mesh and Netflix’s Chaos Monkey — together representing over 64% of the analysed repositories using chaos engineering tools.

Toxiproxy is language-agnostic, runs as a single binary, and exposes a simple HTTP management API, making it ideal for local development as well as CI pipelines.

Step 1: Install Toxiproxy

Install the server and CLI via Homebrew on macOS:

brew install toxiproxy

Or pull the Docker image (useful for CI environments and Docker Compose setups):

docker pull ghcr.io/shopify/toxiproxy:latest

Start the server in one terminal. It listens on port 8474 by default — this is the control plane API:

toxiproxy-server

Step 2: Create a Proxy Tunnel

Say your backend API runs on localhost:3000. Create a tunnel on localhost:4000 that passes traffic through to the real backend but lets you corrupt it on demand:

toxiproxy-cli create api_proxy --listen localhost:4000 --upstream localhost:3000

Update your frontend environment variable to point to the proxy:

# .env.local
API_URL=http://localhost:4000

From this point on, your app talks to Toxiproxy, which forwards to the real server. You control the chaos independently, without touching your application code.

Step 3: Inject Chaos

Now the useful part. Simulate a “flaky” public 5G connection — fast on paper, but prone to signal shadows and handover spikes.

Simulating 5G latency with jitter:

toxiproxy-cli toxic add api_proxy --type latency --attribute latency=100 --attribute jitter=500

This adds a base 100 ms latency with a 500 ms jitter window, meaning your UI will experience response times anywhere between 100 ms and 600 ms unpredictably — a fairly accurate simulation of public NSA 5G in a crowded environment.

Simulating packet loss:

toxiproxy-cli toxic add api_proxy --type limit_data --attribute bytes=0

Or use the reset_peer toxic to simulate abrupt disconnections.

Running multiple toxics simultaneously is also supported. You can stack a bandwidth limit on top of latency to recreate an edge network scenario.

Step 4: Use with Docker Compose

For teams running containerised stacks, Toxiproxy slots neatly into a Docker Compose file as a sidecar service. Your application services point their connection strings at Toxiproxy ports rather than directly at their dependencies:

services:
  toxiproxy:
    image: ghcr.io/shopify/toxiproxy:latest
    ports:
      - "8474:8474"   # Control plane API
      - "4000:4000"   # Proxy for your API

  api:
    build: ./api
    environment:
      - BACKEND_URL=http://toxiproxy:4000
    depends_on:
      - toxiproxy

This approach requires zero changes to application code beyond updating a connection string.

Specific Scenarios: What Are You Actually Testing?

The “Zombie” Connection (High Packet Loss)

Sometimes a connection isn’t down — it’s just so lossy it might as well be.

Experiment: Set 15% packet loss on your chaos tunnel using limit_data or reset_peer toxics.
What to observe: Does your UI trigger a timeout, or does it sit in a “loading” state forever? A resilient UI should detect that a request has likely died after a threshold and offer the user a “Retry” option rather than an infinite spinner.

The 5G Handover Spike

As users move between 5G towers or switch from mmWave to mid-band frequencies, latency can jump from under 20 ms to 150 ms or more for the duration of the handover.

Experiment: Script a toxic that fires a 1,000 ms latency spike for 5 seconds every 30 seconds.
What to observe: Does your UI handle a request that was in-flight during the spike? Do you get duplicate submissions? Do skeleton screens transition gracefully to a “Still working…” state?

The DNS Blackhole

What happens if your API is up, but the user’s DNS provider is failing or a non-essential third-party script can’t resolve?

Experiment: Use your proxy to block all traffic to a specific upstream (e.g., an analytics or A/B testing provider).
What to observe: Does your app fail to boot because a non-essential tracking script blocked the main thread? This is a common and easy-to-miss failure mode — chaos tunnels expose it instantly.

The Slow-Close / Hanging Socket

A connection that stays “open” without delivering data is one of the nastier real-world scenarios, especially on mobile where radio state machines try to conserve battery by suspending connections.

Experiment: Apply the slow_close toxic with a delay of several seconds.
What to observe: Does your UI set a meaningful request timeout? Or does it block indefinitely?

Designing for Resilience: Frontend Patterns to Adopt

Once you’ve seen your UI crumble under a chaos tunnel, you can implement defensive patterns with confidence and measure them empirically.

1. Optimistic UI with Rollbacks

Don’t wait for the server to confirm a “Like” or a form submission. Update the UI immediately. However, chaos engineering forces you to test the rollback path. If the tunnel eventually drops the connection, does your UI gracefully revert the action and surface a clear error message — or does it silently leave the user in a broken state?

2. Intelligent Skeleton Screens

Standard loading spinners are frustrating on high-latency networks. Skeleton screens provide a perceived performance improvement. By using a chaos tunnel with high latency, you can tune the timing of these skeletons empirically. If a request consistently takes more than two seconds, you might transition from a skeleton to a “Still working on it…” message, giving the user actionable information instead of uncertainty.

3. Circuit Breakers on the Frontend

Just like backend microservices, frontend components should have circuit breakers. The pattern — popularised at scale by Netflix’s Hystrix library — works equally well in client code. If an API call fails three times in a row through the chaos tunnel, the component should stop retrying and enter a “Degraded Mode,” perhaps rendering cached data rather than a broken empty state.

A client-side circuit breaker operates as a state machine: Closed (normal operation), Open (fast-failing without making requests), and Half-Open (allowing a probe request to check if the service has recovered). Libraries like opossum bring this pattern to Node.js; for pure frontend code, a lightweight implementation is straightforward to write by hand.

4. Explicit Request Timeouts

The chaos tunnel will expose any fetch() call with no timeout set. Always configure an AbortController with a reasonable timeout — typically 5–10 seconds for user-facing requests — so that hanging sockets don’t stall your UI indefinitely.

const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 8000);

try {
  const response = await fetch('/api/data', { signal: controller.signal });
  // handle response
} catch (err) {
  if (err.name === 'AbortError') {
    // show retry UI
  }
} finally {
  clearTimeout(timeoutId);
}

5. Non-Essential Scripts Must Not Block the Main Thread

Your analytics provider, A/B testing library, and ad scripts are non-essential. Load them with defer or async, and always verify (via the DNS blackhole scenario above) that their failure does not prevent your core application from booting.

The Chaos Frontend Toolkit

Beyond Toxiproxy, the ecosystem has grown. The GitHub awesome-chaos-engineering repository tracks an active community of tools, including a dedicated Chaos Frontend Toolkit — a set of tools specifically for applying chaos engineering to frontend applications. For browser-level simulation without a proxy, Mock Service Worker (MSW) can mock API responses with injected delays and error codes — useful for component-level testing in isolation.

Here is an updated comparison of the main tools:

Tool	Best For	Key Feature
Toxiproxy	Localhost / CI	Highly scriptable TCP proxy; great for automated tests and Docker setups
Pumba	Docker environments	Killing and throttling Docker containers and their network links
Chaos Mesh	Kubernetes	Full cluster-level fault injection; accepted into the CNCF as an incubating project
MSW (Mock Service Worker)	Component / unit tests	Browser service worker that intercepts fetch calls; no proxy needed
Network Link Conditioner	macOS system-wide	System-level throttling; useful for testing native apps and all browser traffic
Chaos Frontend Toolkit	Frontend-specific	Purpose-built for UI resilience experiments

Measuring Success: Resilience Metrics That Matter

Running chaos experiments is only useful if you track what changes. Define a “Resilience Profile” for each major feature and measure these metrics before and after:

Time to Interactive Under Stress (TTI-S): What is your Time to Interactive when there is 200 ms of jitter? Compare this against your baseline.

Error Recovery Rate: What percentage of failed requests result in a successful user-initiated retry? A well-designed retry UI can recapture a significant portion of users who would otherwise bounce.

Zombie State Duration: How long does a user sit on a screen with no feedback when the network is cut? This should be bounded by your request timeout and the subsequent UI update.

Non-Essential Script Failure Isolation: Does blocking your analytics provider affect TTI? It should not.

Integrating Chaos Testing into CI

A chaos tunnel is most valuable when it runs automatically. With Toxiproxy’s HTTP API and client libraries available for most languages, you can write test suites that:

Start a Toxiproxy instance as part of your Docker Compose test stack.
Configure a proxy pointing at your API.
Inject a toxic (e.g., 500 ms latency) before running your end-to-end test suite.
Assert that your UI surfaces the correct skeleton, timeout message, and retry button within specified time bounds.
Remove the toxic and verify normal operation resumes.

This transforms resilience from a manual exercise into a regression gate that runs on every pull request.

Conclusion: Make Chaos Part of the Definition of Done

The goal of chaos engineering isn’t to break things for the sake of it. It’s to build justified confidence. When you know your UI handles a simulated 5G handover spike, a DNS blackhole, and 15% packet loss on localhost, you can ship to production with fewer surprises.

The gap between a sterile localhost environment and real-world public 5G — where jitter can be nearly ten times higher than in a private network — is not a gap you should be discovering after a deploy. It’s a gap you should be engineering against from the start.

Stop testing on perfect networks. Set up a proxy, inject some toxics, and start treating network instability as a first-class citizen in your development process.

Summary Checklist

[ ] Install Toxiproxy (binary or Docker image) and expose the control plane on port 8474.
[ ] Create a proxy tunnel from a local port to your backend API.
[ ] Update your frontend environment variables to point at the tunnel.
[ ] Inject jitter (±500 ms) to expose race conditions and duplicate submissions.
[ ] Simulate a 5G handover spike (1,000 ms for 5 seconds) to test in-flight request handling.
[ ] Apply a packet loss / reset toxic to verify timeout and retry UI.
[ ] Run the DNS blackhole scenario — block your analytics provider and confirm the app still boots.
[ ] Implement AbortController timeouts on all user-facing fetch() calls.
[ ] Add a circuit breaker to components that call frequently-failing endpoints.
[ ] Load all non-essential scripts (analytics, A/B testing) with defer or async.
[ ] Wire your chaos scenarios into CI so resilience regressions are caught automatically.

Search This Blog

InstaTunnel