Dev Proxy: A Local Intercepting Proxy for Simulating API Failures in C#
Simulate API failures, throttling, and chaos — all from your command line.
At a glance
- What is it?
- Dev Proxy is a cross-platform command-line interceptor that sits between your app and the network so you can inject errors, throttling and latency without touching application code. It is most useful to teams that already test the happy path and want to see what happens when the API misbehaves.
- Who is it for?
- Adopt Dev Proxy if your app consumes third-party or internal HTTP APIs and you have no practical way to make those APIs fail on demand, and if you are comfortable running a local proxy and pointing your client at it. Do not adopt it if your testing already covers failure paths through injected HTTP clients or a service-virtualization platform, or if you cannot reroute traffic through a proxy in your test environment.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The testing gap Dev Proxy targets
Most applications are tested against APIs that work. The README frames the problem directly: you test your app to make sure it works as intended, but what happens when the APIs you use fail, and how do you test that? The stated answer is that simulating API failures is hard, so teams either write throwaway code that never ships or skip the test entirely. Dev Proxy exists to simulate API errors without changing your app's code.
The intended audience is anyone building a client that depends on HTTP APIs, which in practice means app developers rather than API authors. The README lists five outcomes: seeing how your app responds to API errors, verifying how it handles rate limits, seeing how it behaves against slow APIs, standing up mock APIs without writing code, and getting contextual guidance on API usage. The Microsoft 365 and Microsoft Graph topics on the repository suggest the maintainers pay particular attention to that ecosystem, though the proxy itself is described as working with any type of app and tech stack.
Why interception, not a mock library
The design choice that defines this project is that it is a proxy. The README states that because Dev Proxy intercepts network requests, it works with any type of app and tech stack. That is the mechanism: your app keeps making the same calls to the same hosts, and the proxy in front of it decides what comes back.
This matters for the failure cases the tool is aimed at. A mock library replaces the API at the call site, which means the client code under test is not quite the code you ship. A proxy leaves the call site alone and changes the response, so throttling, errors and latency are exercised through the same code path as production traffic. The cost is that your client has to be willing to talk through a proxy, which is trivial for most HTTP stacks and occasionally awkward for clients that pin certificates or ignore proxy environment variables.
The README does not describe the plugin architecture, the internal request pipeline or how responses are rewritten. Anything more specific than interception would be guesswork, so treat the plugin list in the official documentation as the source of truth.
Installing and running it
The README points to a getting-started tutorial at aka.ms/devproxy/start for installing and running Dev Proxy for the first time, and to aka.ms/devproxy for the documentation. It does not print install commands or configuration keys in the repository README, so the honest position is that the exact command names and config keys have to come from those pages rather than from this article.
What the material does establish is the shape of the thing. It is a command-line tool, it runs on any platform, and it is written in C#. The repository ships a stable 3.2.0 release and a 4.0.0 alpha line, with v4.0.0-alpha.4 published on 2026-07-24 and v3.2.0 on 2026-07-21, so the two lines are being maintained in parallel. If you are evaluating it for a team, pick the 3.2.0 line unless you specifically need something from the 4.0 alpha, and read the release notes for whichever you choose.
Because behaviour is driven by interception, the practical setup step in any environment is pointing your client at the proxy. The README does not document the port, the certificate trust step, or the environment variables involved. Verify those in the tutorial before you plan a rollout, especially on machines where TLS interception requires installing a local root certificate.
Where the README stops being useful
The README is a landing page, not a reference. It states the value proposition and links out. It does not enumerate the plugins, explain how to select a failure rate, show a configuration file, or describe how mock APIs are defined. Anyone who needs to know whether Dev Proxy can simulate a 429 with a Retry-After header, or whether it can throttle only a subset of endpoints, will not find the answer in the repository README.
That is a real cost during evaluation. You cannot judge fit from the README alone; you have to read the documentation site and probably the getting-started video linked from the README. The upside of a thin README is that it rarely goes stale relative to the docs, and the release cadence here is active enough that stale documentation would be a problem. The downside is that search results and repository browsing give you less to work with than the project's scope would justify.
One thing the README does commit to: it is open source and free to use, and the project is supported by the .NET Foundation. That is a governance signal, not a feature, and it does not tell you whether the failure simulation is expressive enough for your scenario.
Limits, failure modes and the wrong-tool case
The obvious limitation is that everything depends on traffic reaching the proxy. If your application code constructs its own HTTP client with a hardcoded base address and ignores proxy settings, or if you are testing a native mobile build where rerouting traffic is a build-time decision, the interception model stops being free. The README's claim that it works with any type of app and tech stack is about the interception mechanism, not about every deployment context.
There is a second, subtler limit. Because Dev Proxy sits in the network path, it can only simulate what happens at the HTTP boundary: status codes, timing, headers, bodies, connection behaviour. It cannot reproduce a failure that happens inside the remote service's business logic, and it cannot tell you whether your retry policy is correct in a distributed sense, only whether your client reacts to the responses it is given. For load and concurrency behaviour, a local proxy is also the wrong instrument, since it is simulating the API rather than stressing it.
Finally, the version situation is a genuine decision point. A 4.0.0 alpha published in July 2026 means the next major line is in flight. If your team has a policy against alpha dependencies in shared tooling, stay on 3.2.0 and accept that some newer behaviour documented on the site may not apply to your version.
Compared with WireMock and similar service virtualization
The closest category is service virtualization: WireMock is the reference example, where you run a server that stands in for the API and your app is pointed at that server's address. The difference in approach is where the substitution happens. WireMock replaces the API with a stub you address instead; Dev Proxy leaves the address alone and rewrites what comes back through an intercepting proxy.
That changes what you have to configure. With a stub server you change the base URL, usually through configuration, and you get a clean, fully controlled endpoint. With Dev Proxy you change the network path, keep the original URLs, and get the real client code path plus whatever TLS and proxy configuration your stack requires. If your goal is to test error handling in code you ship, the proxy approach exercises more of the real path. If your goal is a stable, shareable fake API for integration tests in CI, a stub server is easier to reason about and does not require certificate trust.
Dev Proxy also does something WireMock does not do by default, according to the README: it offers contextual guidance on how you use APIs, which is a linting-style capability rather than a simulation one. That combination of simulation and guidance is the project's distinctive angle.
Maintenance, versions and the MIT licence
The repository is not archived, the last push is dated 2026-09-10, and releases land regularly, with three published between July and September 2026 across the stable and alpha lines. For a tool that lives in your development workflow rather than your production path, that is a healthy signal: you are not adopting something abandoned.
The practical maintenance cost is version pinning. Because a 4.0.0 alpha exists alongside 3.2.0, any internal documentation you write should name the version you standardised on, and upgrades between major lines should be treated as a change that needs re-verification of your failure scenarios rather than a routine bump. There is no indication in the material of a long-term support policy for the 3.x line, so do not assume one.
The licence is MIT, which is permissive and places few obligations on internal or commercial use. This article is not legal advice; if you redistribute Dev Proxy or bundle it into a product, have your own counsel review the licence text and any third-party notices in the repository. The .NET Foundation backing is relevant context for governance questions, but it does not change the licence terms.
Editorial conclusion
Adopt Dev Proxy if your app consumes third-party or internal HTTP APIs and you have no practical way to make those APIs fail on demand, and if you are comfortable running a local proxy and pointing your client at it. Do not adopt it if your testing already covers failure paths through injected HTTP clients or a service-virtualization platform, or if you cannot reroute traffic through a proxy in your test environment. Before committing, verify which version you need (the 3.2.0 stable line or the 4.0.0 alpha line), confirm the exact plugin names and configuration keys against the documentation at aka.ms/devproxy because the README does not list them, and check that your target platform is covered by the install instructions in the getting-started tutorial.
Community notes