TGLock: a local proxy that rewraps Telegram traffic in WebSocket

A proxy on your own machine, for one protocol

TGLock is described in the README as a local proxy on the user's computer that accepts both MTProto and SOCKS5. It intercepts Telegram connections, wraps them in WebSocket, and sends them to Telegram's own web infrastructure over several routes at once, switching to the next one when the current one stops responding. From the network's point of view, what it sees is ordinary HTTPS.

The problem it addresses is stated at the top of the README in one line: Telegram has become slow or stopped opening at all. The tool's answer is to change the transport Telegram uses, without requiring a VPN, a proxy server of your own, a subscription or an account.

The scope is deliberately narrow, and the README is explicit about the cases it fits. Telegram opens every other time, messages go out with a delay, photos and videos do not load. DPI tools such as GoodbyeDPI, Zapret or ByeDPI no longer help because the provider is shaping traffic by IP. You want a graphical interface on macOS. You need something for Windows, macOS or Linux without subscriptions and without running your own server. And you need a variant for a server or a machine with no monitor, which is what tglock-cli is for.

The implementation is Rust, with an egui interface mentioned in the project description, MIT licensed, on the main branch, with the last push on 2026-09-19. The releases are all beta: v2.0.0-beta.15 from 2026-09-19, beta.14 and beta.13 both from 2026-08-26. The homepage recorded for the project is a Telegram bot rather than a site, which is a small sign of where this project lives.

What the tool says it cannot do

The README has a section titled what TGLock does not do, and it is written in the tone of someone who has answered too many support questions. It is the most useful part of the documentation for anyone evaluating the project.

Voice and video calls are out, because they go over UDP and TGLock proxies only TCP, so nothing changes for calls. Anything other than Telegram is out, because TGLock only unwraps MTProto, the protocol used nowhere else. YouTube, Discord, Instagram and ChatGPT will not start working through it.

Mobile is partial. Android has an experimental APK and a verification guide, and the README says background operation on physical devices requires checking. iOS has no application at all, and the LAN mode is offered instead, one proxy for the whole network segment.

And the comparison with a VPN is drawn in the other direction. TGLock works only with Telegram, everything else goes directly, nothing slows down, and mobile data is not spent on traffic that does not need it.

There is a further transport detail worth knowing. For the CDN DC203 there is a separate route using MTProto over TCP to its pinned address, because that CDN may not accept WebSocket. If its IP is blocked, what remains is a user-configured Worker. The diagnostics show which transport was selected.

So the honest summary of the tool is narrow on purpose: one application, one protocol, one transport change, with an explicit list of what will still not work.

Two binaries from one crate, and the bug that shaped the features

The Cargo manifest is where this project explains itself best, because the feature flags are documented with the reasoning that produced them.

The default feature set is gui, which pulls in Tauri, tauri-build and the opener plugin. The comment on the gui feature says that turning it off drops Tauri, the system WebView and the frontend bundle from the build, which is what makes headless servers and machines without a GPU or monitor able to build and run TGLock at all.

The cli feature is deliberately not in default, and the comment records a real bug. When both binaries existed in one build, the Tauri bundler picked the wrong one as the application, packaging tglock-cli and shipping it as the app in v2.0.0-beta.2 and v2.0.0-beta.3. Keeping the CLI behind its own non-default feature means it simply does not exist during an application build, so there is nothing to pick wrongly.

The manifest also explains a small choice that would otherwise look arbitrary. The CLI configuration file is TOML rather than JSON, because the file is edited by hand and needs comments.

Two binaries are declared. The tglock binary comes from src/main.rs and requires the gui feature, while tglock-cli comes from src/bin/cli.rs and requires the cli feature. The library target is built as a staticlib, a cdylib and an rlib, and the package is set to edition 2021 with a rust-version of 1.88.

The runtime dependencies match the design. tokio provides the asynchronous runtime with the multi-thread scheduler, networking, timers, synchronisation and signal handling, tokio-tungstenite provides the WebSocket transport over rustls, serde and serde_json handle serialisation, and clap and toml are the optional CLI dependencies.

The web layer is a separate project. The package.json is named tglock-ui, it is private, and it depends on the Tauri API and CLI. The dev script runs Vite on port 1420, the build script runs tsc and then vite build, and there is a test script that runs the worker tests with the experimental VM modules flag enabled. The repository also contains a worker directory, a tauri.conf.json, a tauri.android.conf.json, a vite.config.ts and a tglock.example.toml, which is the CLI configuration example.

Where the files come from

The download table is a plain list of artefacts per platform, and it includes the headless build as its own row rather than as a footnote.

For Windows 10 and 11 on x64 there is an x64 setup executable. For macOS, on both Apple Silicon and Intel, there is a universal disk image. For Linux on x86-64 there is a deb package and an AppImage, and the README notes that all the builds weigh a few megabytes, with the AppImage as the exception because it carries its own environment and is therefore larger.

For a server, a container or a machine without a monitor there are tglock-cli archives, and the README says this has been available since v2.0.0-beta.2. It also flags a specific issue for anyone who grabbed beta.2: the application did not open, and that was a build error, fixed in beta.3.

There are also extra builds in the GitHub Actions artefacts rather than in the releases: an Android ARM64 APK and a static ARM64 CLI for OpenWrt. The README is careful to say that these do not mean a new release has been published, which is a small but useful distinction for anyone tracking versions.

The user interface is a Tauri application, so the window comes from the system WebView, and the front end is a Vite and TypeScript project. That explains the two dev servers, or rather the one dev server on port 1420 for the front end plus the Rust side that talks to it through the Tauri bridge, and it explains why the gui feature is the one that drags in a web view at all.

The OpenWrt and Android artefacts also hint at where the author expects this to run. A static ARM64 CLI for a router is a different deployment target from a macOS app, and the LAN mode for iOS users, one proxy for the whole apartment, is a third.

Antivirus warnings, and how to read them

The README has a section headed antivirus complains, SmartScreen warns, VirusTotal shows detections, and its opening line is that this is going to happen.

What you will see is described concretely. On Windows, the message that Windows protected your PC, from SmartScreen. On VirusTotal, detections from some of the engines, usually single digits out of roughly sixty.

The explanation offered is that two things combine. The installer is not signed with a certificate, and unsigned files are checked by heuristics far more strictly than signed ones. And the behaviour of the program itself, opening a local port, declaring itself a proxy server, and writing itself into the Telegram connection settings, is precisely the profile that endpoint security products are tuned to be suspicious of.

That is a real and honest piece of engineering communication, because it tells a reader what they will see before they install it, and it explains it without asking for trust. A tool that opens a listening socket, acts as a proxy and rewrites your application's network configuration is going to look like what it is to a heuristic engine, and the mitigations are limited to what a small project can control.

The README says it will explain the mechanism and give ways to check, without taking the author's word for it. That is the right posture for a binary distributed outside the official app stores, and it is worth reading that section in full before you install, because the checks available to you are the only verification you will have.

The MIT licence, the source in the repository and the published artefacts are what you can verify yourself, and the README's promise of ways to check is the part to use.

Sponsorship, licence and the state of the project

The first thing in the README is a sponsor block, and it is large. RoseVPN is presented as a fast VPN for Russia, with YouTube without buffering, Discord, Instagram and ChatGPT working again, a free trial connected through a Telegram bot, and no registration and no card required. A set of badges repeats the promise for each of those services, and there is a link at the top of the page.

That is a factual feature of the repository, and it affects how you read the rest of it. The tool is free and MIT licensed, and the project also carries a commercial service promotion placed above the project's own content. Nothing is hidden, and nothing is wrong with it, but a reader who came for a censorship circumvention tool is also being sold a VPN, and the ordering means the sponsor is the first thing they see.

On the licence itself, the Cargo manifest declares license = "MIT" and the repository carries a LICENSE file, so the code can be read, modified and redistributed under MIT terms. This is not legal advice, and the distinction between the MIT licensed tool in this repository and the commercial service promoted in it is worth keeping in mind if you are assessing what you are actually installing.

The maintenance picture is a beta with a recent commit. The version in both manifests is 2.0.0-beta.15, matching the newest release tag, and the last push was on 2026-09-19. The repository is not archived. The releases in August and September 2026 show an active iteration rate on a 2.0 beta line, and the version numbering has been through fifteen beta builds, which is what a project looks like when it is still changing its packaging.

The documentation is in Russian, which is the language the project is written for, and it is a genuine barrier for anyone outside that audience, including a maintainer who wanted to contribute an English translation. The repository also has an AGENTS-style set of files for tooling, a HABR.md, a docs directory, a capabilities directory and a scripts directory, which suggests a project that is set up for automated contribution workflows.

Editorial conclusion

Adopt TGLock if your problem is specifically that Telegram is slow or blocked on your connection while the rest of the internet works, and you accept that it is a beta that only affects Telegram. Do not adopt it as a general VPN, because it proxies MTProto and nothing else, and do not adopt it for voice or video calls, which travel over UDP and are explicitly out of scope. Before you install it, read the section on antivirus warnings so you can tell a heuristic flag from a real detection, verify the release you download against the checksums your platform expects, and if you need it on a server, use the tglock-cli build rather than the desktop application.

Frequently asked questions

Official sources

1. by-sonic/tglock on GitHub
2. License: MIT
3. Project website
4. README
5. Releases