What it does
Toxiproxy is a self-managed network fault-injection tool for development, testing and CI. A TCP proxy sits between an application and a dependency; developers then use a client or its HTTP control API to apply conditions such as latency, bandwidth limits, timeouts or connection failures. This lets a test exercise retry and fallback behavior under repeatable network disruptions instead of relying on naturally occurring outages.
Put the dependency behind a test proxy
Toxiproxy’s repository documents a two-part setup: run its TCP proxy and control it through an HTTP API or a client library. Configure the test application to connect to the dependency through the proxy, then apply a selected “toxic” only for the operation under test. For example, a resilience test can add response latency before calling a database-backed action, or take a cache connection down while checking the application’s fallback path. These are illustrative scenarios; no proxy or test was run for this listing.
The README lists conditions including latency, bandwidth, timeout, connection reset, packet loss and taking a proxy down. It also describes deterministic tampering as well as randomized chaos. This makes Toxiproxy useful for checking how an application responds to failure, but it does not diagnose or repair that failure for you.
The key setup constraint is routing: only connections configured to pass through the proxy are affected. Teams need a test environment and a client or direct HTTP calls to manage proxy state. The project is distributed under the MIT License; the listing is for the Shopify-hosted open-source repository, not a managed testing service.
Strengths
- Network faults can be applied deliberately in tests, including latency, bandwidth changes, timeouts, packet loss and connection failures.
- An HTTP control API and client libraries let test code change proxy behavior around a specific operation.
- The MIT-licensed project can be used in local development, CI or other self-managed test environments.
Watch out for
- The application’s test connections must be routed through Toxiproxy; traffic that bypasses the proxy is not affected.
Best for
- Testing retries, timeouts and fallback behavior for database, cache or other TCP dependencies.
- Adding repeatable network-failure scenarios to integration tests or CI.
- Developers who can run a local or CI proxy and control it from test code.
Sources
- Toxiproxy (Oct 25, 2026)
- The MIT License (MIT) (Oct 25, 2026)