Отсутствие поддержки DD и mtbuddy install --help

[ikey-ru]

Сценарий: сервер, где провайдер режет прямой доступ к Telegram (и DC, и middle-proxy, наружу только обычный веб), трафик до Telegram я заворачивал на внешний выходной узел.

1. Middle-proxy refresh не уважает upstream. Это самое болезненное. При type=socks5 начальный fetch getProxyConfig/getProxySecret уходит мимо прокси, напрямую, и на сети без прямого Telegram падает в NetworkUnreachable → откат на bundled-defaults, middle-proxy толком не поднимается. При этом сам DC-релей через этот же SOCKS работает, и тот же getProxyConfig руками через socks (curl) отдаёт 200. То есть обновление метаданных тоже надо пускать через upstream. Как перевёл егресс на WireGuard (маршрут на уровне ОС), refresh сразу прошёл, Middle-proxy cache updated, всё ожило.

2. Нет DD (secure) для клиентов. В constants.zig secure = 0xdddddddd лежит, а наружу отдаётся только ee/FakeTLS-ссылка. dd-режим (без TLS, padded) выдать нельзя, ни флагом, ни в линках. Для совместимости и разнообразия профилей dd нужен.

3. mtbuddy install --help реально ставит. Вместо справки запускает установку с дефолтным доменом (wb.ru). Неожиданно и деструктивно: потерял время, выясняя, откуда взялся левый конфиг.

4. --secret молча игнорируется при повторной установке. Конфиг уже есть, и берётся ранее сгенерённый секрет. Хотя бы предупреждение бы.

5. flood_guard / rate_limit недружелюбны к NAT. Дефолты (20 хендшейков/30с на IP, rate_limit_per_subnet=30) валят легитимных клиентов за общим NAT. У меня весь трафик шёл с одного carrier-NAT-IP, защита банила его на 120с, и пошли постоянные дисконнекты, пока не выключил. Стоит задокументировать.

6. На сломанной сети движок молчит. На старте не проверяет связность с DC, пишет «Waiting for connections», и что релея нет, понимаешь только когда клиент не подключается. Стартовый self-test (или чтобы config doctor реально пинговал DC/upstream) сильно упростил бы диагностику.

[sleep3r]

Спасибо, заберу это и поправлю к релизу 1.0.0