WEB proxy stays connected but never passes MTProto DATA (12-byte WINDOW frames only)

[Valtarean]

Summary

A WEB proxy created from current master is accepted by Telegram Desktop and the relay session stays alive, but Telegram never finishes connecting. The client keeps opening short-lived MTProxy streams. Every stream gets only a 12-byte WINDOW frame back and no useful MTProto DATA.

The public hostname, IP address, WEB secret, bridge capability, and raw request logs are intentionally omitted.

Environment

Server

• Ubuntu 24.04.4 LTS
• Linux 6.8.0-138-generic x86_64
• Caddy 2.6.2
• Go 1.22.2
• tproxy-server commit: 2873a08806d6e4d84830b9b5c4b0ec0f46af91f8
• VCS modified: false
• official MTProxy built by the repository installer
• public IPv4 assigned directly to the main interface; an additional VPN interface also exists

Client

• Windows 11 Home Insider Preview, build 26220
• Telegram Desktop 7.1.1.0
• Microsoft Edge WebView2 152.0.4191.41

The same visible symptom was also reproduced from a second Windows PC.

Steps to reproduce

1. Deploy current tproxy-server with the official MTProxy backend.
2. Use a direct DNS A record, a valid Caddy certificate, and the reference HTTPS carrier configuration.
3. Add the hostname and matching 16-byte secret as a WEB proxy in Telegram Desktop.
4. Enable the WEB proxy.
5. Observe that the proxy appears connected, but Telegram keeps loading indefinitely.

Expected result

Telegram should establish normal MTProto sessions and transfer messages/media through the WEB carrier.

Actual result

Telegram remains in the connecting/loading state. Its local log contains:

Web Proxy Error: WebView carrier failed: bridge reported failure

After a clean relay restart, two test clients reconnected and the metrics reached:

tproxy_sessions_live 2
tproxy_streams_live 4
tproxy_streams_opened_total 366
tproxy_streams_rejected_total 0
tproxy_backend_dial_failures_total 0
tproxy_bytes_up_total 94926
tproxy_bytes_down_total 4392
tproxy_limit_hits_total 0

4392 == 366 * 12: each opened stream produces only one 12-byte WINDOW frame. There are no backend dial failures, stream rejections, or limit hits. The client then resets/reopens streams continuously.

Verbose MTProxy logging confirms that the loopback connections created by tproxy-server contain valid MTProxy handshakes, for example:

tcp opportunistic encryption mode detected, tag=efefefef, target=2/-2

The same MTProxy process accepts direct clients on a separate public listener, and those connections transfer application bytes in both directions.

Diagnostics already performed

• Confirmed all four services are active: Caddy, tproxy-firewall, MTProxy, and tproxy-server.
• /readyz returns ready.
• Confirmed valid HTTPS/certificate and external TCP 443.
• Confirmed backend ports remain blocked externally.
• Verified the installed relay is the exact current upstream commit with no local modifications.
• Replaced Caddy configuration with the repository reference settings (HTTP/1.1 + HTTP/2, reference timeouts, no raw URI logging).
• Tested both https and websocket carrier modes; behavior was identical.
• Refreshed the official MTProxy secret and routing configuration.
• Added AF_NETLINK to the MTProxy systemd address-family allowlist.
• Applied explicit --nat-info local:public mappings for the VPN-selected local address and loopback. MTProxy middle-end connections then remained established, but the WEB symptom did not change.
• Forwarded the relay backend through a temporary loopback socket to the proven public MTProxy listener; the result was still exactly 12 bytes per stream.
• Reset the Telegram Desktop WebView profile and allowed WebView2 to create a clean one; the failure reproduced immediately.
• No conntrack exhaustion, port collision, relay limit hit, or backend dial failure was observed.

Questions

1. Is there a known protocol/lifecycle incompatibility between Telegram Desktop 7.1.1 and this tproxy-server revision on Windows/WebView2?
2. Is there a supported way to enable a more detailed client-side bridge failure reason than bridge reported failure?
3. Which additional sanitized relay or MTProxy diagnostics would be useful?

[tral]

I had the problem of the desktop client infinitely "Connecting", the problem was because of my VPS provider's NAT. This PR should fix that (fixed for me): #4
Also check other 2 PRs with bugfixes, thanks!
#3
#2

[Valtarean]

I had the problem of the desktop client infinitely "Connecting", the problem was because of my VPS provider's NAT. This PR should fix that (fixed for me): #4 Also check other 2 PRs with bugfixes, thanks! #3 #2

Root cause found.

The active config had:

max_pending_items_per_session = 4096

With max_streams_per_session=64, pendingControlReserve consumes 208 items.
pendingUplinkReserve then consumes MaxBatchFrames=4096 items.

Therefore downlinkPendingLimits() returned item_limit=0. Every backend reader
blocked forever in nextReadAllowance(), despite send_credit=4194304 and an
empty pending queue.

Runtime debug values:

send_credit=4194304
pending_cost=0
cost_limit=5187136
item_limit=0

This exactly explained the symptom: one 12-byte WINDOW per stream and no DATA.
2736 streams produced exactly 32832 bytes_down_total.

Changing max_pending_items_per_session to 16384 fixed the relay immediately.

[Valtarean]

Fixed by changing max_pending_items_per_session to 16384