| Filename | Latest commit message | Latest commit date |
|---|---|---|
loop-uh
8ad4ac9ba7
Some checks failed
ZaStoGram source guards / guards (push) Failing after 30s
Build three ZaStoGram APKs / build (armeabi-v7a, ZaStoGram-standalone-armeabi-v7a, Armv7, armv7) (push) Failing after 1m57s
Build three ZaStoGram APKs / build (x86, ZaStoGram-standalone-x86, X86, x86) (push) Failing after 1m59s
Build three ZaStoGram APKs / build (arm64-v8a, ZaStoGram-standalone-arm64-v8a, Arm64, arm64) (push) Failing after 2m0s
WEB-прокси попадает в tgnet как обычный MTProxy на 127.0.0.1:<порт> — локальный мост в WebView-носитель. Из-за этого его соединения проходили через ту же очередь подключений к одному адресу, кулдаун эндпоинта и reconnect-backoff, что и настоящий MTProxy, хотя на loopback нет ни удалённого релея, ни DPI: это только замедляло установку соединений. Так же десктоп исключил WEB из своего пейсинга (62fb6be3eb). Java помечает мост явно: MtProxyOptions.webBridge() — те же выключенные режимы, что disabled(), плюс флаг webBridge, который JNI читает в нативный MtProxyOptions. Для такого сокета ConnectionSocket пропускает TCP connect gate, кулдаун эндпоинта, admission, DNS coalesce и не поднимает cooldown-hold, а Connection не применяет reconnect-backoff и оставляет штатный таймер tgnet. Настоящие MTProxy-соединения, ClientHello и stealth-режимы не меняются. Страж check_web_proxy_isolation.py проверяет флаг на всех уровнях и что каждый гейт выходит для моста раньше, чем применяет MTProxy-политику. |
||
| .. | ||
| config | ||
| emoji | ||
| jni | ||
| lib | ||
| libs | ||
| src/main | ||
| build.gradle | ||
| google-services.json | ||
| proguard-rules-beta.pro | ||
| proguard-rules.pro | ||