Поддержка тестового окружения Telegram (тестовые DC)#1087
Conversation
|
А вы не проверяли? |
|
Ёмаё, не проверял. Извиняюсь, был неправ. |
Учтены замечания @Flowseal: тестовый трафик идёт обычным вебсокет-пайплайном и CF-релеями с путём `/apiws_test` вместо прямого TCP; IP тестовых DC остались только для фоллбэков
|
@Flowseal сделал нормальную реализацию |
There was a problem hiding this comment.
В GUI настройка force_test_dc точно не нужна
Оставить его нужно только через CLI и через конфиг-файл
TestDc.md без воды, просто зачем нужен и как/где включается
И написать, что работает только в случае с прямым DC->IP и воркерами
Из cfproxy убрать, сам я это поддерживать не буду, а кому надо - сами мозгами пораскинут. Или просто воркера сделают.
|
И хотелось бы результаты тестов увидеть после с verbose логами |
|
@Flowseal из дебаг лога взял основное, но если тебе нужен весь - скину весь Config: {... 'dc_ip': ['2:149.154.167.220','4:149.154.167.220'],
'verbose': True, 'cfproxy': True,
'cfproxy_worker_domain': ['x.workers.dev'],
'force_test_dc': False ...}
# --- Test DC2 (auto-detected +10000) -> direct DC -> IP, test WS path ---
DEBUG [c1] handshake ok: DC10002 proto=0xDDDDDDDD
INFO [c1] DC10002 -> wss://kws2.web.telegram.org/apiws_test via 149.154.167.220
INFO [c1] DC10002 WS session closed (normal): ^7.2KB (21 pkts) v20.0KB (35 pkts) in 100.8s
# --- Test DC1 (auto-detected +10000, not in dc_ip) -> CF worker ---
DEBUG [c2] handshake ok: DC10001 proto=0xDDDDDDDD
INFO [c2] DC10001 not in config -> fallback
INFO [c2] DC10001 -> trying CF worker x.workers.dev for 149.154.175.10
INFO [c2] DC10001 WS session closed (normal): ^5.3KB (15 pkts) v225.0KB (97 pkts) in 20.5s |
Flowseal
left a comment
Flowseal
left a comment
There was a problem hiding this comment.
Когда я говорил про raw_dc, это не подразумевало, что нужно везде заменять dc на raw_dc. Замените обратно где поменяли dc на raw_dc. Достаточно просто log.info сделать, что DC заменен с 10000+ в начале.
| test_env = proxy_config.force_test_dc or raw_dc >= 10000 | ||
| dc = raw_dc - 10000 if raw_dc >= 10000 else raw_dc |
There was a problem hiding this comment.
Вы это уже делали в tg_ws_proxy.py, просто передайте переменную какую-нибудь is_test_dc
2 participants
Проблема
Прокси не умеет работать с тестовой средой Telegram: все таблицы IP — продовые, а у тестовых DC нет вебсокет фронта (
kws{dc}.web.telegram.org). Клиент в тестовом режиме уходил на продовый DC и не проходил авторизацию.Решение
Два механизма:
Автоматический: Telegram Desktop помечает тестовые DC сдвигом +10000 (10001-10003). Прокси распознаёт такие DC и ведёт их сразу в fallback на IP тестовых DC (прямой TCP / свой Cloudflare worker), минуя вебсокет и релеи. Работает сценарий
основной + тестовый аккаунт в одном клиенте: продовый трафик идёт обычным маршрутом, тестовый — на тестовые DC соответственно.Принудительный: добавлена опция
force_test_dc(CLI-флаг--force-test-dc). Некоторые клиенты на базе библиотек отправляют в хендшейк номер тестового DC как обычный 1-3, и на стороне прокси он неотличим от продового.Например, Telethon: тестовая среда у него настраивается через
session.set_dc(2, '149.154.167.40', 443), и в байты 60-61 заголовка уходитsession.dc_idкак есть, без сдвига (MTProxyIO.init_header). Для таких клиентов опция будет принудительно направлять весь трафик прокси сразу на тестовые DC. По умолчанию выключена.* Продовые аккаунты через прокси с этой опцией работать не будут.
Изменения
proxy/utils.py— добавлена таблицаDC_TEST_IPSproxy/bridge.py,proxy/tg_ws_proxy.py— маршрутизация: автодетектdc >= 10000, выбор таблицы IP, отключение продовых CF релеев для тестового трафикаproxy/config.py, CLI-флаг--force-test-dcdocs/TestDc.mdПроверка
DC10001 test env -> direct fallback -> TCP fallback to 149.154.175.10:443), продовый работает как раньше