Titanium Web Proxy: A C# HTTP(S) Proxy That Spans Library, CLI, and Desktop Inspector

What Titanium Web Proxy Actually Solves

Titanium Web Proxy is a C# asynchronous HTTP(S) proxy engine that covers three distinct use cases in one codebase. For .NET developers, the Titanium.Web.Proxy NuGet package lets you embed a MITM or reverse proxy directly into an application. For operators, the Titanium.Cli provides a standalone reverse/edge proxy that runs on Windows, Linux, and macOS, with commands like run, test, version, and update. For debugging, the Titanium Inspector is a desktop application that acts as a MITM session grid with breakpoints, AutoResponder, and HAR export. The project's pitch is that one engine powers all three, so you can prototype interception logic in the Inspector and then ship the same behavior as a library or a CLI. That is a real advantage if you are already in the .NET ecosystem. The README states the core requires .NET 10 or later, which is a hard constraint that will rule out many production environments still on LTS versions like .NET 8.

How the Proxy Engine Works

The engine exposes explicit, transparent, and SOCKS4/5 proxy endpoints. Explicit means the client is configured to point at the proxy, which is the classic forward proxy model. Transparent mode intercepts traffic without client configuration, typically via network-level redirection. The core supports request and response body streaming across HTTP/1.x, HTTP/2, and HTTP/3. HTTP/2 is enabled by default and can be disabled via ProxyServer.EnableHttp2. HTTP/3 is opt-in via ProxyServer.EnableHttp3 = true and requires MsQuic, a native library. The README notes that CLI and Inspector release zips bundle natives per RID, but for library usage you must handle MsQuic packaging yourself. The proxy can also chain to upstream HTTP, HTTPS, and SOCKS proxies, with automatic system proxy detection. Authentication includes proxy auth, mutual TLS, Kerberos, and NTLM. The engine uses connection, certificate, and buffer pooling to reduce overhead. The logging design is notable: a built-in console sink uses a bounded channel and a background writer, so LogInformation never blocks a session thread on Console I/O. That is a concrete design choice that avoids a common performance pitfall in proxy servers.

Getting It Running: Commands and Config

For the library, installation is straightforward: dotnet add package Titanium.Web.Proxy. The quick start example creates a ProxyServer, sets Logging.MinimumLevel to LogLevel.Information, attaches a BeforeRequest event handler, and adds an ExplicitProxyEndPoint on 127.0.0.1:8000 with decryptSsl: true. Then you configure your client to use that address as its HTTP and HTTPS proxy. For the CLI, on Windows you can install via winget install justcoding121.TitaniumCli, or download self-contained zips from GitHub Releases. The CLI commands are titanium run -c twp.yaml, titanium test -c twp.yaml, titanium version --check, and titanium update. Each CLI zip includes a twp alias binary. The optional Plus features are enabled by running titanium update --plus and then setting plus.enabled: true and plus.controlPlane.sharedSecret in the config. The Inspector is a Windows MSI or portable zip, installable via winget id justcoding121.TitaniumInspector. The README warns that trusting a generated root certificate changes the current user's certificate store, so only do it on a machine you control. That warning is important for anyone testing MITM on a shared machine.

Protocol Support and Its Limits

The project claims HTTP/2 support on by default and HTTP/3 opt-in, but the exact coverage is in a protocol support matrix on the wiki. The README references a protocol bridge matrix for every client-to-origin direction. This is a key detail: HTTP/3 support is not universal. It requires MsQuic, and the matrix likely shows which combinations work. For example, HTTP/3 client to HTTP/1 origin might work, but HTTP/3 to HTTP/2 might not. The README also mentions that nginx still edges tiny keep-alive scenarios, so Titanium is not a universal performance winner. The performance claim is 'typically at or above YARP' and 'ahead of nginx on H2/H3 to H1 reverse, near parity for the rest.' That is a specific comparison, but it is a claim from the README, not an independent benchmark. You should verify against your own traffic patterns. The protocol support matrix is the first thing to read before committing, because the README does not list the exact matrix in the snippet.

A Real Limitation: Breaking Changes and .NET 10

The README calls out a breaking change: ProxyServer.ExceptionFunc and SessionEventArgsBase.TimeLine were removed in favor of unified Logging and EnableRequestTimingCapture APIs. That means any code written against older versions will break on upgrade. This is a maintenance cost that is easy to underestimate. Also, the requirement for .NET 10 or later is a hard limitation. If your organization standardizes on .NET 8 LTS, you cannot use this library without upgrading your entire runtime. The CLI and Inspector are self-contained, so they may work on systems without .NET 10 installed, but the library path is locked. Another limitation: HTTP/3 requires MsQuic, which is a native dependency. The CLI and Inspector bundle it per RID, but if you embed the library in a custom deployment, you must handle MsQuic yourself. That is a packaging burden that could be a dealbreaker for some teams.

Alternatives: YARP and nginx

The README explicitly compares performance to YARP and nginx. YARP is a .NET reverse proxy library from Microsoft. It is also in C#, but it does not do MITM or forward proxying as a primary focus. YARP is designed for reverse proxy scenarios with routing and load balancing, not for intercepting and modifying arbitrary client traffic. Titanium Web Proxy, especially the CLI, targets reverse/edge workloads, but the core library also does MITM, which YARP does not. nginx is a native C reverse proxy and web server. It is not a MITM tool and does not provide a .NET API. nginx is typically faster for simple keep-alive reverse proxying, as the README admits. The difference is approach: Titanium is a programmable proxy engine in C# with event hooks, while YARP is a config-driven reverse proxy and nginx is a static binary. If you need to intercept and modify traffic, Titanium is the only one of the three that does that out of the box. If you need a pure reverse proxy with minimal overhead, nginx might still win. The choice depends on whether you need MITM and .NET integration.

Maintenance, Licensing, and Upgrade Path

The project is MIT licensed, which is permissive and allows commercial use without copyleft obligations. The last push was August 2026, and the latest release is 6.0.2, so the project appears actively maintained. However, the breaking change in logging APIs indicates that upgrades are not free. The README points to a wiki section on breaking changes for unified logging and timing, so you should read that before upgrading from a previous major version. The CLI has an update command (titanium update) that simplifies upgrading the standalone tool. For the library, you manage upgrades via NuGet. The Plus edition is an optional paid feature, but the README does not specify pricing or terms. The maintenance cost is moderate: you must track breaking changes, handle MsQuic for HTTP/3, and keep up with .NET 10 runtime requirements. The project's use of SonarCloud badges suggests a focus on code quality, but that is not a substitute for your own testing.

Who Should Adopt It and What to Verify First

Titanium Web Proxy is a good fit for .NET teams that need a programmable proxy for testing, debugging, or edge routing. The Inspector is a practical tool for debugging HTTPS traffic without writing code. The CLI is useful for deploying a reverse proxy on Linux or macOS without a heavy runtime. It is the wrong tool if you are on an older .NET version, or if you need a pure high-performance reverse proxy with minimal overhead and no MITM requirements. Before adopting, verify the protocol support matrix for your specific client-to-origin directions, especially if you need HTTP/3. Test the logging APIs on your codebase to see how much refactoring the breaking changes require. Confirm that the CLI release assets include the native binaries for your target RID, or plan to install MsQuic separately. The README's performance claims are relative to YARP and nginx, but you should benchmark with your own workload. The project's active release schedule and MIT license are positive signs, but the .NET 10 requirement is a non-negotiable boundary.

Editorial conclusion

Adopt Titanium Web Proxy if you need a programmable MITM proxy or reverse proxy in .NET 10, or if you want a standalone edge proxy with CLI control and optional Plus ops. Do not adopt it if you are on .NET 9 or earlier, or if you require HTTP/3 without MsQuic packaging. Verify first: the exact protocol support matrix for your client-to-origin directions, the breaking changes in logging APIs (ExceptionFunc and TimeLine are removed), and whether the CLI release assets you download include the needed native binaries for your RID.

Official sources

1. Official README
2. Project repository
3. Release notes