TrustTunnel: AdGuard VPN protocol goes open-source

2026-01-2117:2120366adguard-vpn.com

Today is a big day for us, and for everyone who cares about transparency, privacy, and having full control over their own traffic. We’re finally open-sourcing the protocol that powers AdGuard VPN. And…

Today is a big day for us, and for everyone who cares about transparency, privacy, and having full control over their own traffic. We’re finally open-sourcing the protocol that powers AdGuard VPN. And it now has a name: TrustTunnel.

For a long time, we’ve wanted to make the protocol public. Many of you asked for it, and we always said: yes, we will, it’s only a matter of time. Well, the time has come.

TrustTunnel is now open-source, free to explore, audit, build upon, and use in your own projects.

What is TrustTunnel?

At its core, TrustTunnel is a modern, secure, mobile-optimized VPN protocol. It’s the very same technology that has been running inside all AdGuard VPN apps: on mobile, desktop, and browser extensions.

Why TrustTunnel? Because we needed something better

There are plenty of VPN protocols out there, so why create our own, some might ask. That is because we’ve seen in practice the faults of popular VPN protocols, especially in countries with tight restrictions on internet access. Protocols like OpenVPN, WireGuard, and IPSec share common weaknesses: they are easy to detect and block at the network level, and attempts to conceal VPN traffic often reduce speed. Traditional approaches “wrap” VPN data in a TCP connection and mimic normal web traffic, but TCP’s way of confirming every piece of data creates delays and makes the connection slower.

Unlike those conventional VPN protocols, TrustTunnel is engineered to blend in with regular HTTPS traffic, making it far harder to throttle or block and helping it slip past deep-packet inspection, all while preserving strong privacy and security. It achieves this through TLS-based encryption, the same standard that secures HTTPS, and by leveraging HTTP/2 or HTTP/3 transport, which are ubiquitous on the web. Each connection runs on its own dedicated stream, which combines packets for faster, more efficient transmission. It is also optimized for mobile platforms and performs well even in unstable network conditions.

A protocol you can use, run, tweak, extend, and build upon

By releasing TrustTunnel, we hope to achieve two things. First of all, we want to finally show our users what protocol is powering AdGuard VPN, thus allowing them to audit it openly. At AdGuard, we have always been staunch supporters of the idea of open-source software, and many of our products have long been open source. AdGuard VPN was lagging behind in this regard, but with TrustTunnel being released publicly, it is starting to catch up.

But most importantly, we want to change the status quo in the world of VPN protocols and offer an alternative to existing solutions. That said, we do not want it to be just a PR stunt, when the protocol’s code is de-facto ‘open source,’ but only one VPN service actually runs it. We believe in free and open-source software (FOSS) and want TrustTunnel to be used widely, including by other VPN services. We believe this is the right way to go about open source development, and we hope the community will participate in the TrustTunnel evolution. We welcome any contribution, whether it is a feature request, a bug report, or even a direct contribution to the app’s development.

What have we done to make this possible?

  1. We are publishing the first version of the TrustTunnel specification.
  2. We are releasing the complete code of our reference implementation of the TrustTunnel server and its clients under a very permissive license.

You don’t have to install AdGuard VPN to use TrustTunnel. You can configure your own server and use open source TrustTunnel clients:

  • Command-line TrustTunnel clients support Linux, Windows, and macOS

  • We are also releasing two client apps for iOS and Android

TrustTunnel clients already have a lot of functionality, they allow you to:

  • Use flexible routing rules to decide which requests go through the tunnel and which stay on the local network

  • Exercise fine-grained control, separating work and personal traffic, routing specific domains or apps, and tuning network behavior without complicated setup

  • Benefit from a real-time request log that provides full transparency into where the device sends traffic, how routing rules apply, and which connections use the tunnel

This is a long-awaited moment for us. We promised to open-source our protocol, and today we’re delivering on that promise. With TrustTunnel now open source, users and developers alike can explore, self-host, and build on the technology.

To get started, check out the following resources:
TrustTunnel website
TrustTunnel open-source repository on GitHub
TrustTunnel app for iOS
TrustTunnel app for Android

Use any browser or app and never worry about your anonymity again. The entire world is at your fingertips with AdGuard VPN.
In just two clicks, select a city from anywhere in the world — we have 80+ locations — and your data is invisible to prying eyes.
Remain anonymous wherever you go with AdGuard VPN! Dozens of locations, fast and reliable connection — all in your pocket.
Boost your online protection by taking it with you wherever you go. Use AdGuard VPN to enjoy your favorite movies and shows!
Discover AdGuard VPN for Android TV! Enjoy seamless streaming, enhanced security, and easy setup.
Hide your true location and emerge from another place in the world — access any content without speed limits and preserve your web anonymity.
Learn more
Get to a different location in one click, hide your IP, and make your web surfing safe and anonymous.
Learn more
Protect your privacy, hide your real location, and decide to where you need the VPN and where you don't!
Learn more
Be a ninja in your Opera browser: move quickly to any part of the world and remain unnoticed.
Learn more
Install AdGuard VPN on your router to secure your entire network. Decide which devices to protect and when
This option is only available with an AdGuard VPN subscription
Get the best free VPN for Linux and enjoy seamless web browsing, enhanced security, Internet traffic encryption, and DNS leak protection. Choose from multiple VPN servers and access the locations you want
Discover AdGuard VPN for Apple TV! Enjoy seamless streaming, enhanced security, and easy setup
This option is only available with an AdGuard VPN subscription
Protect your Xbox with AdGuard VPN and enjoy seamless online gaming, enhanced security, and easy setup
This option is only available with an AdGuard VPN subscription
Protect your PlayStation with AdGuard VPN and enjoy seamless online gaming, enhanced security, and easy setup. Choose from multiple VPN servers and access the locations you want
This feature is only available with an AdGuard VPN subscription
Install AdGuard VPN on your Google TV (Chromecast Gen 4) or on your network router (Chromecast Gen 3) and enjoy streaming content with Chromecast while staying anonymous online and accessing content from anywhere. For Chromecast Gen 3, you need an AdGuard VPN subscription

AdGuard VPN

download has started

Click the button indicated by the arrow to start the installation.

Scan to install AdGuard VPN on your mobile device


Read the original article

Comments

  • By stefanha 2026-01-2123:293 reply

    Link to the protocol specification: https://github.com/TrustTunnel/TrustTunnel/blob/master/PROTO...

    It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.

    It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!

    • By dixie_land 2026-01-225:16

      Looks very similar to the HBONE protocol the istio folks created for ambient mesh: https://istio.io/latest/docs/ambient/architecture/hbone/

    • By mintflow 2026-01-2215:13

      just did some spec reading, it's quite clear and nit.

      I can understand that put UDP payload into a single HTTP stream, at least when QUIC transport is in use, there is no UDP in TCP case.

      The Source Address/Port in the UDP payload message serve as key to handle to the tunnel client if I understand correctly?

    • By userbinator 2026-01-225:551 reply

      Basically a CONNECT proxy? That's definitely not a difficult thing to write.

      • By ameshkov 2026-01-226:451 reply

        More or less, built on top of it with added udp/icmp.

        When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.

        • By eptcyka 2026-01-227:011 reply

          QUIC CONNECT supports UDP too now.

          • By ameshkov 2026-01-227:152 reply

            We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.

            And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.

            We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.

            • By eptcyka 2026-01-2212:551 reply

              Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.

              • By ameshkov 2026-01-2214:551 reply

                Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.

                • By eptcyka 2026-01-2216:38

                  Unfortunately, I am no stranger to embedding a whole userspace networking stack into a VPN client either.

            • By xtacy 2026-01-2213:401 reply

              > QUIC is not bad, but there are places where it either does not work at all or works too slow.

              Curious: in your experience where does QUIC work bad/slow?

              • By ameshkov 2026-01-2214:56

                For example, in some countries it's either slowed down or outright blocked.

  • By mrbluecoat 2026-01-221:58

    Very cool! Thanks for supporting open source (unlike a half-hearted attempt, like ExpressVPN's Lightway). Quick question: the website animated gif has no arrows from the website to the VPN server. Am I missing something?

    Update: just followed the quickstart and worked great; speed is virtually line speed - impressive!

  • By ameshkov 2026-01-2122:344 reply

    Hi, I’m one of the people working on this.

    One clarification that may not be obvious: open-sourcing this isn’t primarily about signaling or auditability. If that were the goal, a standalone protocol spec or a minimal reference repo would have been enough.

    Instead, we’re deliberately shipping full client and server implementations because the end goal is for this to become an independent, vendor-neutral project, not something tied to AdGuard.

    We want it to be usable by any VPN or proxy stack and, over time, to serve as a common baseline for stealthy transports — similar to the role xray/vless play today.

    Happy to answer questions or clarify design choices.

    • By rfv6723 2026-01-221:092 reply

      Does your team have Chinese memebers?

      GFW has been able to filter SNI to block https traffic for a few years now.

      • By ameshkov 2026-01-226:292 reply

        We do, and from what we know a bigger problem in China is detecting traffic patterns. SNI filtering is not that big of a deal, in order to block your domain it needs to first learn which one you’re using. What for the traffic patterns, people in China prefer to selectively route traffic to the tunnel. For instance, the client apps allow you to route *.cn domains (or any other domains) directly. It makes it harder to detect that you’re using a VPN.

        • By rfv6723 2026-01-228:211 reply

          In Fujian province, all foreign domains which aren't in white list are blocked.

          This results that proxy server needs to use a fake sni in white list or ditch https.

          • By ameshkov 2026-01-2211:101 reply

            This is actually supported by both the client and the server.

            To use it in mobile clients you need to specify two domain names like that: fake-sni.com|domain.com where “fake-sni.com” is the domain thay will be in the SNI and “domain.com” is the domain in your TLS certificate (used to check the server’s authenticity)

            • By Pesevere 2026-01-243:17

              I tried the method you suggested on the Android client, but it doesn't seem to work. After setting the domain name to two domains connected by `|`, the client fails to connect to the server and remains stuck in a “connecting” state.

              Is this feature not yet supported on Android?

        • By eptcyka 2026-01-227:011 reply

          How do you do this on iOS?

          • By ameshkov 2026-01-227:18

            You mean in TrustTunnel apps? You can create a routing profile there and select which domains/ips are bypassed, and then select that routing profile in the vpn connection settings.

      • By gruez 2026-01-222:381 reply

        >GFW has been able to filter SNI to block https traffic for a few years now.

        SNI isn't really the threat here, because any commercial VPN is going to be blocked by IP, no need for SNI. The bigger threat is tell-tale patterns of VPN use because of TLS-in-TLS, TLS-in-SSH, or even TLS-in-any-high-entropy-stream (eg. shadowsocks).

        • By rfv6723 2026-01-223:052 reply

          > because any commercial VPN is going to be blocked by IP, no need for SNI.

          Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

          This is why GFW develops SNI filter, Cloudflare is too big to block.

          • By gruez 2026-01-223:44

            >Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

            cloudflare doesn't support domain fronting so any SNI spoofing won't work.

          • By eptcyka 2026-01-227:02

            CDN traffic is quite expensive, don’t believe it would be feasible to provide a VPN product for that. But for individuals, sure.

    • By vitorsr 2026-01-2123:053 reply

      Thanks for all impressive work on AdGuard.

      Any particular reason to adopt Rust for this project instead of Go as many of your other products?

      Because I think since you have quite extensive Go codebase I would imagine you had to rewrite possibly a significant amount of code.

      • By ameshkov 2026-01-226:39

        Performance reasons aside, TrustTunnel is developed by the team whose main language is C++ (and the client library is actually written in C++) so Rust was a more natural choice for them.

      • By rcoder 2026-01-220:27

        Likewise interested in the authoritative answer, but: if I needed to write a decent chunk of code that had to run as close to wire/CPU limits as possible and run across popular mobile and desktop platforms I would 100% reach for Rust.

        Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.

      • By eptcyka 2026-01-227:04

        Embedding Go code into other binaries sucks ass. Debugging is worse, it installs some signal handlers.

    • By kumrayu 2026-01-229:431 reply

      I can't thank Adguard enough for providing so much to the community, they are a BIG part of my privacy-funded lifestyle.

      Out of the topic — but if you by any chance work on the mobile apps.

      Do you know why the iOS version is still sub-par compared to Android? You all add more features for rooted Android but what about Jailbroken iOS devices?

      I have bought 20+ Adguard licenses and have never regretted buying them. Only if the iOS version could be much better.

      • By ameshkov 2026-01-229:511 reply

        Hi, thank you very much for supporting AG!

        We are very cautious with Apple as we suffered from them before [1]. So we're trying to stick to the APIs they provide. I hope the new URL filtering API [2] will improve the situation with the system-wide filtering, but our request for API access is still being reviewed by Apple.

        Regarding jailbroken iOS devices, unlike Android the numbers are really marginal so it won't be feasible to support them.

        [1]: https://adguard.com/en/blog/adguard-pro-discontinued.html

        [2]: https://adguard.com/en/blog/apple-url-filter-system-wide-fil...

        • By kumrayu 2026-01-2212:131 reply

          Thank you so much, I also regularly read your blogs.

          I am looking forward for better iOS support. :) Hope Apple can be much reasonable.

          Also, what network trackers do you think are most harmful for privacy? — WebRTC, hardware fingerprinting, etags, cookies? Do you think Adguard will hone themselves much more in the future from just being an ad-blocker to evolving into an all-in-one privacy protector?

          Also, I apologize for asking too many questions, I just got a bit excited when I saw you comment.

          • By ameshkov 2026-01-2212:45

            Uh, I guess it's a little bit off-topic here:) It's hard to say what's more harmful, I'd say cookies still take #1, but I think we're not far from the moment when your email address or its derivative will be used as the main advertising ID. Regarding evolution, well, definitely possible, the time will show.

    • By tommica 2026-01-2211:58

      So happy that you guys are doing this!

HackerNews