Stable · v1.0.0> windows / home network gateway
Turn a Windows 10/11 PC into a home qWDTT gateway with Docker Desktop, Direct routing, server-side DNS-over-HTTPS, and a separate Cloudflare WARP path.
The project packages a modified qWDTT-compatible server for a Windows home setup, generates Android connection profiles, prepares router forwarding data, and exposes one management entry point through service.cmd. Telegram Proxy is optional and isolated from the main gateway.
> context
WDTT is not a system VPN client for Windows. The Windows machine hosts the server-side path used by qWDTT on Android and exposes only the network entry points deliberately configured by the user.
A working remote qWDTT setup involves a Windows host, Docker, a reachable router port, Android profiles, DNS policy, optional alternate routing, diagnostics, backups, and secrets. Handling each layer manually is fragile.
The project keeps Docker Desktop as an explicit prerequisite and manages only WDTT-owned resources. service.cmd coordinates install, start/stop, Doctor, router data, profiles, resources, backup/update flows, optional Telegram Proxy, and experimental features.
> modes
Modes change which Docker services are active. Direct and WARP are separate routing policies, not automatic fallbacks.
Main WDTT server only.
Main server plus server-side DNS-over-HTTPS.
Server + DNS + separate Cloudflare WARP gateway.
$ traffic paths
The design deliberately keeps routing choices observable. DNS can change resolution without changing public IP; WARP changes the route only for clients assigned to the WARP policy.
Uses the home public IP. This is the normal route for Home - Direct.
Available in CoreDns and Full. Android Private DNS or application-level DoH can bypass this server-side DNS path.
Available in Full. If the WARP gateway fails, the WARP profile must fail instead of silently returning to Direct.
Optional Flowseal/tg-ws-proxy service inside the WDTT network namespace. A proxy failure must not break the main WDTT server.
> service.cmd
The Windows package intentionally uses a text-based management panel instead of hiding Docker and network state behind a separate GUI.
> setup
The normal path keeps Windows prerequisites, router configuration, and external reachability checks separate.
Install and start Docker Desktop manually. If Docker uses WSL 2, prepare WSL outside WDTT.
Choose install/check settings and select Core, CoreDns, or Full plus port, DNS, resources, and adapter.
Use ROUTER-SETUP.txt to reserve the PC LAN address and forward the selected UDP port.
Reveal the Direct/WARP credentials only when needed and import the generated qwdtt:// data.
Run Status/Doctor locally, then test from a phone over mobile data; local checks cannot prove inbound ISP/router reachability.
$ architecture
Each optional capability is a separate Compose service/profile where practical, which limits blast radius and keeps the main server path understandable.
Windows 10/11 x64, Docker Desktop, Windows PowerShell 5.1, service.cmd and management scripts.
Privileged qWDTT-compatible Go server, TUN access, WireGuard wdtt0, Direct policy and published WDTT port.
Optional dnsproxy service sharing wdtt-server network namespace; ordinary DNS is redirected to a configured DoH upstream.
Optional Cloudflare WARP Linux client in its own Docker network; policy routing sends only WARP-assigned WDTT client IPs through it.
Optional Flowseal/tg-ws-proxy image sharing the WDTT namespace; no extra Docker port publication by default.
Local .env/data, generated setup-output, backup/restore, resource profiles, Status/Doctor, update and uninstall scripts.
> engineering
The project avoids several tempting shortcuts because they would make a home gateway harder to reason about or less safe.
WDTT does not install Docker Desktop, WSL, winget, Virtual Machine Platform, or change BIOS/UEFI. Missing prerequisites fail with targeted diagnostics.
A WARP profile must never silently reveal the home Direct IP if Cloudflare WARP is unavailable.
ANDROID-PROFILES.txt is redacted; real passwords and qwdtt:// links appear only after explicit disclosure.
Normal setup needs the selected WDTT UDP endpoint. DNS ports, internal WireGuard ports, Docker API, and admin surfaces are not intended for internet exposure.
Enable/update/rollback/health operations are isolated so proxy failure does not take down the main WDTT stack.
The separate no-DTLS listener is disabled by default and is not part of Core/CoreDns/Full normal operation.
> technology
> security
LOCAL SECRETSBackups, .env, private keys, WARP state, Telegram secrets, profile passwords and import links can expose access to the gateway. The project documents explicit boundaries for logs, generated files and published ports.
> origin
The gateway contains a modified qWDTT server component derived from SpaceNeuroX/proxy-turn-vk-android. It is not an official qWDTT/SpaceNeuroX release. Telegram Proxy integration separately uses Flowseal/tg-ws-proxy as an optional component.
> limitations
EXPLICIT PREREQUISITESNormal external use needs a reachable UDP endpoint. CGNAT or double NAT may require provider changes or another network design. WARP depends on Cloudflare, and local Doctor checks cannot prove that inbound UDP is actually reachable from the internet.
$ stable_release
v1.0.0 is the first stable public release. The Windows ZIP is built from an allowlist, PowerShell and shell files are validated, and the finished archive is extracted into a separate temporary directory and validated again.
54CDD3BAE5EC4369DEE442D31E832014821047FD21A3CD72E341F9C42B459516> project links
GitHub is the source of truth for releases, user guides, security notes, upstream compatibility, and issue tracking.