Titanium Web Proxy: a C# HTTP(S) interception library and reverse proxy CLI
A cross-platform asynchronous HTTP(S) proxy server in C.
At a glance
- What is it?
- Titanium Web Proxy bundles an embeddable .NET MITM library, a standalone reverse/edge CLI, and a Windows desktop Inspector. It is aimed at .NET teams that need to inspect or route HTTP(S) traffic, and the main cost is that it requires .NET 10 or later.
- Who is it for?
- Adopt Titanium Web Proxy if you are on .NET 10 or later and want HTTP(S) interception inside your own process, or a reverse/edge proxy you configure with a YAML file. Do not adopt it if you cannot move to .NET 10, or if you need a proxy for Android or another non-.NET runtime; the README documents no such target.
- 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 received new commits within the last day.
- 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 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Titanium Web Proxy solves, and who it is built for
Most teams that need to see HTTP(S) traffic reach for a separate debugging proxy and point their client at it. Titanium Web Proxy takes the other route: the interception engine is a .NET library you embed in your own application, so request and response handling happens in your process rather than in a tool sitting beside it. The README describes the core package as the way to "Embed a MITM and/or reverse proxy in a .NET app."
The repository ships several products rather than one. Titanium.Web.Proxy is the core library on NuGet. Titanium.Cli, invoked as titanium or twp, is a standalone reverse and edge proxy for any stack, with run, test, version and update commands. Titanium Inspector is a Windows desktop MITM debugger with a session grid, inspectors, AutoResponder, breakpoints and HAR export. Titanium.Plus adds a control plane, ops, observability and a dashboard, installed with titanium update --plus.
That split matters when you evaluate it. If your goal is to watch traffic from a browser or a mobile app, Inspector is the relevant product and it is Windows only. If your goal is to intercept traffic inside a test harness or a service, the NuGet library is the relevant product. If your goal is to route and balance traffic in front of services, the CLI is the relevant product. They share an engine but not an interface.
The audience is therefore narrower than the feature list suggests. You need .NET 10 or later, stated in the README as a requirement for the CLI and Plus, and you need to be comfortable with a library whose API surface changed in the current major line.
How interception works: endpoints, events and the certificate step
The mechanism is an explicit proxy endpoint that terminates client connections and raises events before and after the upstream call. In the quick start, an ExplicitProxyEndPoint is created on the loopback address at port 8000 with decryptSsl set to true, added to a ProxyServer instance, and paired with a BeforeRequest handler. The handler is where you read or rewrite the request.
Decrypting TLS is what makes the event model useful, and it is also the part with operational weight. The README is direct about the consequence: trusting a generated root certificate changes the current user's certificate store, and it says to do this only on a machine you control. Nothing in the quick start automates that trust decision, and the README does not document a rollback path for it.
Beyond the explicit endpoint, the README lists transparent and SOCKS4/5 endpoints. Protocol coverage is split across HTTP/1.x plain and TLS, HTTP/2 and HTTP/3. HTTP/2 is on by default and can be opted out through ProxyServer.EnableHttp2. HTTP/3 is opt-in through ProxyServer.EnableHttp3 = true and requires MsQuic; the README notes that CLI and Inspector release zips bundle the natives per runtime identifier. Upstream connections can go through HTTP, HTTPS or SOCKS proxies, with automatic system proxy detection, and the project lists proxy authentication, mutual TLS, Kerberos and NTLM.
Logging was reworked in this line. The README describes the built-in console sink as a bounded channel with a background writer, so LogInformation does not block a session thread on console I/O. The same section records a breaking change: ProxyServer.ExceptionFunc and SessionEventArgsBase.TimeLine were removed in favour of ProxyServer.Logging and EnableRequestTimingCapture. Anyone upgrading from an earlier major version will hit that.
Installing the NuGet package and running a first interception
The library installs from NuGet. The README gives the stable command and a prerelease variant:
dotnet add package Titanium.Web.Proxydotnet add package Titanium.Web.Proxy --prereleaseFor the CLI, Windows users can install through winget, or download the self-contained zips from GitHub Releases. The README warns that NuGet-only tags may not include Titanium.Cli-*.zip assets, so check the release before assuming a zip exists for your platform.
winget install justcoding121.TitaniumCliOnce the CLI is on the machine, the documented commands are run, test, version and update, all taking a configuration file through -c. Each CLI zip also contains a twp alias binary.
titanium run -c twp.yaml
titanium test -c twp.yaml
titanium version --check
titanium updateThe README does not print a full twp.yaml, so the schema has to come from the documentation site rather than the repository front page. Plus is enabled in config with plus.enabled: true and plus.controlPlane.sharedSecret, after running titanium update --plus; titanium version --check --plus reports whether it is active.
For the library path, the quick start creates the proxy server, sets proxyServer.Logging.MinimumLevel to LogLevel.Information, subscribes BeforeRequest, and adds an ExplicitProxyEndPoint on IPAddress.Loopback at port 8000 with decryptSsl: true. The client is then configured to use 127.0.0.1:8000 as both its HTTP and HTTPS proxy. The README example truncates mid-call at proxyServer.AddEndP, so expect to finish wiring the endpoint and start call yourself from the examples directory, which contains Basic, Shared, WindowsService and Wpf sample projects.
The .NET 10 floor and the missing rollback path
The clearest constraint is the runtime requirement. The README states that .NET 10 or later is needed. That is a hard gate for the CLI and Plus, and it shapes the library decision too, because a team on an older LTS cannot simply add the package and keep shipping on its current target.
The second constraint is the certificate. Interception of HTTPS only works when the client trusts the proxy's root certificate, and the README frames trusting it as a change to the current user's certificate store with an explicit warning to do it only on a machine you control. It does not describe how to remove that trust afterwards. If your adoption plan depends on a clean uninstall, that step is undocumented on the repository front page.
The third is documentation depth. The README covers the feature list well and the quick start partially, but the configuration schema for the CLI, the full set of event handlers, and the HTTP/3 packaging details live in the wiki and on titaniumproxy.com. The repository front page points at a protocol support matrix and an HTTP/3 wiki page for exact coverage and for every client-to-origin direction. That phrasing is worth taking literally: HTTP/2 and HTTP/3 support is described as a matrix, not as blanket support, so a specific client and origin combination should be checked rather than assumed.
There is also a scope question. The README names Windows, Linux and macOS for the CLI, and Inspector is distributed as a Windows MSI or portable zip. Nothing in the README describes an Android build or a mobile interception target, despite that being a common search around the project name.
Titanium Web Proxy compared with nginx and YARP
The README positions the project against two named alternatives in its performance section. It states that the proxy is typically at or above YARP, ahead of nginx on H2/H3 to H1 reverse, and near parity for the rest, with nginx still ahead on tiny keep-alive traffic. Those are the project's own claims, published with a link to a performance wiki page; no independent numbers appear in the README.
The more useful difference is not throughput but shape. nginx is a standalone server configured in its own directive language, and YARP is a .NET reverse proxy library that you host inside an ASP.NET Core application. Titanium Web Proxy overlaps with both: the CLI is the standalone-server shape, and the NuGet package is the in-process library shape. What distinguishes it from YARP specifically is the interception side. YARP is a reverse proxy; the BeforeRequest and response event model, the explicit and transparent endpoints, and the Inspector desktop application are about observing and modifying traffic, which is the part YARP does not set out to do. If your requirement is only to route requests to backends, YARP's tighter focus on that job is a reasonable reason to prefer it. If you need to see and rewrite what passes through, the reverse-proxy framing undersells what this project is for.
Maintenance, licensing and upgrade cost
The repository is not archived, and the last push was on 2026-08-28, which is the same timestamp as the 6.0.2 release. The 6.0.0 release landed on 2026-08-21, with 6.0.2-beta on 2026-08-28 before the stable 6.0.2. That is a recent release cadence in the 6.x line.
The licence is MIT, and the repository carries a LICENSE file plus a licenses/ directory and a CLA.md. MIT is permissive, so embedding the library in a commercial product is the kind of use the licence allows; the CLA and the licenses directory are worth reading if you plan to contribute rather than consume, and nothing here is legal advice.
The upgrade cost in this line is concrete. The README flags breaking changes: ProxyServer.ExceptionFunc and SessionEventArgsBase.TimeLine were removed in favour of the unified ProxyServer.Logging and EnableRequestTimingCapture APIs. Any code that hooked ExceptionFunc for error reporting, or read the session timeline for timing, needs rewriting rather than recompiling. The CLI adds its own maintenance surface through titanium update and titanium version --check, and Plus is a separate enablement step in config rather than something bundled by default.
Editorial conclusion
Adopt Titanium Web Proxy if you are on .NET 10 or later and want HTTP(S) interception inside your own process, or a reverse/edge proxy you configure with a YAML file. Do not adopt it if you cannot move to .NET 10, or if you need a proxy for Android or another non-.NET runtime; the README documents no such target. Before committing, verify three things: that the CLI release assets you need are published for your runtime identifier, that your client can trust the generated root CA on a machine you control, and that you have migrated off ProxyServer.ExceptionFunc and SessionEventArgsBase.TimeLine, which the README lists as breaking changes in favour of ProxyServer.Logging and EnableRequestTimingCapture.
Frequently asked questions
What exactly does Titanium Web Proxy do?
It is an HTTP(S) proxy that can intercept, inspect, modify, redirect or block traffic. The same engine is offered as a .NET library on NuGet, a standalone CLI for reverse and edge proxy workloads, and a Windows desktop Inspector for MITM debugging.
What are the risks of using Titanium Web Proxy?
The main one is documented in the README: trusting the generated root certificate changes the current user's certificate store, and it says to do this only on a machine you control. The README does not document how to remove that trust afterwards.
Why would someone use Titanium Web Proxy instead of a separate proxy browser?
Because the interception engine runs inside your own .NET application through the Titanium.Web.Proxy package, so request and response handling happens in-process via the BeforeRequest event and the endpoint classes rather than in a tool sitting beside your app.
What are the top web proxies to compare Titanium Web Proxy against?
The README names YARP and nginx in its performance section, claiming the proxy is typically at or above YARP and ahead of nginx on H2/H3 to H1 reverse. It does not publish a ranked list of proxies.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/justcoding121-titanium-web-proxy)