Dev Proxy: Simulate API Failures and Throttling Without Changing Your App's Code

The API Resilience Testing Gap Dev Proxy Fills

Most integration test suites exercise the happy path: the upstream API responds successfully and the app does the right thing. What happens when the API returns 429 Too Many Requests, a 503, or a response that takes ten seconds? Covering those cases usually means writing mock code that only runs in tests, standing up a fake server and updating your app's base URL, or accepting that those branches go untested.

Dev Proxy closes that gap at the network level. The README describes it as "an API simulator that helps you test how your app handles errors, throttling, and slow responses, without changing a single line of code." It is a command-line tool that works on any platform. Because it intercepts network requests at the OS level, it works with any language, framework, and API.

The target audience is application developers who depend on external APIs and want to verify error-handling logic and retry behavior against real traffic, without writing and maintaining mock infrastructure.

How Dev Proxy Intercepts Traffic Without Code Changes

The mechanism that makes Dev Proxy language-agnostic is OS-level network interception. Unlike a stub server that requires your app to be configured with a different base URL, Dev Proxy sits in the path of all outgoing requests without any change to the app's code or environment variables.

This has a concrete implication: you can test an existing app binary, a CLI tool, or a third-party dependency that makes API calls, and inject failure responses into its traffic. The app sees what looks like a real API response; the difference is that Dev Proxy generated it according to the failure scenario you configured.

The interception requires the app to trust Dev Proxy's root certificate. The Dockerfile shows the certificate is stored at a path controlled by the DEV_PROXY_CERT_PATH environment variable, defaulting to rootCert/rootCert.pfx inside the config directory. In a containerized deployment, this path is exposed as a volume so the certificate can be mounted externally. Apps that pin certificates or reject third-party root certificates will not work with this interception model, and the README does not document a workaround for that case.

Installing Dev Proxy and Running It the First Time

The README directs new users to a tutorial at https://aka.ms/devproxy/start for the first install on a local machine. The Dockerfile reveals the official install script, which is also used when building the Docker image:

/bin/bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)" -- v${DEVPROXY_VERSION}

This downloads and runs the setup script for a specific version. The Docker image exposes ports 8000 and 8897, uses ubuntu:26.04 as its base, and sets DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 to prevent a known .NET ICU resolution error that otherwise surfaces in environments where ICU packages are absent.

For Docker users, two volumes matter: /config holds your proxy configuration files, and /home/devproxy/.config/dev-proxy/rootCert holds the root certificate. You mount both at container start. The XDG_DATA_HOME variable is set to /home/devproxy/.config so that .NET's SpecialFolder.ApplicationData resolves correctly inside the container.

Testing AI Applications: LLM Failure Simulation

A documented feature that separates Dev Proxy from older API testing tools is LLM failure simulation. According to the README, Dev Proxy can route OpenAI-compatible requests to a local language model and simulate LLM failures. This allows developers to test how their AI-integrated apps respond when the language model endpoint is unavailable, returns an error, or is rate-limited.

The practical benefit is testing AI apps without consuming tokens on a live API. The app sends the same request it would normally send to an OpenAI-compatible endpoint; Dev Proxy intercepts it and delivers a configured failure response. The app's error-handling logic runs against that response as if the real endpoint had failed.

The README lists this alongside HTTP error injection and rate limiting as a standard capability, not an experimental one. Developers building on any OpenAI-compatible endpoint, whether a hosted API or a local model that implements the same interface, can use this for resilience testing.

CI/CD Automation and the MCP Server

Dev Proxy provides two paths for automation and integration. The first is a GitHub Actions integration through the dev-proxy-tools/actions repository. The README describes this as "automating resilience testing in your CI/CD pipeline" to "catch issues before your customers do." This turns Dev Proxy from a local testing tool into a gate that runs on every pull request.

The second is an MCP server published as @devproxy/mcp on npm. The README states you can "configure Dev Proxy in plain English using the Dev Proxy MCP server with your AI coding agent." The repository's top-level skills/ directory suggests Dev Proxy ships a Claude Code skill alongside the MCP server, though the README does not document the skill's contents in detail.

The MCP approach is notable because it makes configuration accessible without learning Dev Proxy's configuration syntax from scratch. You describe the failure scenario to an AI coding agent and the MCP server translates it into the required proxy config.

Limitations and a Comparison with WireMock

Several things the README does not document: how to target specific endpoints while passing others through unmodified, what happens to in-flight requests when Dev Proxy is stopped, and whether there is a replay or record mode for capturing real API responses and replaying them. The DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 requirement is a rough edge for containerized deployments that assume standard ICU availability.

The most significant structural constraint is the certificate trust requirement. Apps that pin certificates or run in locked-down environments where custom root certificates cannot be installed will not work with Dev Proxy's interception model. The README does not address this case.

A well-known alternative in this space is WireMock, an open-source HTTP mock server. WireMock requires your app to be configured with its base URL and provides a UI to inspect stub configurations and request logs. It does not intercept traffic transparently, which means you must change your app's configuration to use it, but it also means certificate pinning is not an obstacle. Dev Proxy's advantage is zero-code-change interception for any app; WireMock's advantage is precise, inspectable stub control.

Dev Proxy is under the .NET Foundation and maintained by Microsoft's dotnet organization. The last push was on 2026-09-25. Recent releases include v3.3.1 and beta builds toward v4.0.0, both dated 2026-09-22. The MIT license applies to the entire project.

Editorial conclusion

Dev Proxy is the right tool for app developers who need to test API error handling, rate-limit resilience, and slow-response affordances without writing mock code or modifying their app's configuration. It is a poor fit for scenarios that require selective endpoint stubbing with a visual inspection interface, where a tool like WireMock is more appropriate. Before adopting it in a containerized environment, review the certificate mount configuration shown in the Dockerfile (DEV_PROXY_CERT_PATH) and verify certificate trust in your target runtime.

Frequently asked questions

Official sources

1. dotnet/dev-proxy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases