mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-18 23:54:48 +03:00
therealaleph
e575bf6bf4
The Apps Script relay is HTTP-only, and the SNI-rewrite tunnel only works for Google-hosted domains — so MTProto / IMAP / SSH / anything else used to drop to a direct-TCP passthrough, which provides zero circumvention. Users behind a DPI that blocks Telegram saw constant disconnect/reconnect loops because the raw TCP ran right into the block. Fix: add an optional 'upstream_socks5' config field. When set, the raw-TCP fallback chains the flow into that SOCKS5 proxy (typically a local xray / v2ray / sing-box with a VLESS / Trojan / Shadowsocks outbound to your own VPS) instead of connecting directly. The whole rest of the pipeline is unchanged: - HTTP / HTTPS still MITMs and relays via Apps Script - SNI-rewrite suffixes (google.com, youtube.com, …) still hit the direct Google-edge tunnel (so YouTube stays fast) - Only the raw-TCP bucket (Telegram MTProto, SSH, IMAP, …) gets the new upstream chain Changes: - config.rs: add Option<String> upstream_socks5 field - proxy_server.rs: thread it through RewriteCtx; rewrite plain_tcp_passthrough to call a new socks5_connect_via() helper when configured, with graceful fallback to direct - ui.rs: new 'Upstream SOCKS5' input with tooltip + placeholder, ConfigWire round-trip - README.md: new 'Pair with xray for Telegram' section (EN + FA) with the architecture diagram and example config Verified end-to-end in Docker: xray with the user's working VLESS Reality config, mhrv-rs with upstream_socks5 pointing at it. - HTTPS via mhrv-rs SOCKS5: origin = Google IP (Apps Script path) ✓ - Raw TCP to 3 Telegram DCs + api.telegram.org: all SOCKS5 rep=0, log shows 'tcp via upstream-socks5 127.0.0.1:50529 -> …' ✓ - youtube.com / google.com: 'SNI-rewrite tunnel' (unchanged) ✓ - Real Telegram Desktop stayed connected cleanly (user-confirmed).