От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси

[d1vetrov]

прочитал половину, я фундаментально не понимаю, при наличии влесс заворачивать туда мтпрото? или у вас на телефоне ютуба нет?

мтпрото мертвый продукт, на него сегодня не стоит даже время тратить

вы описали внутренний стек андроид, когда телега идет через внутренний сокс, но есть звонки, жемини и прочая чепуха)

[gloobus]

Автор, интересно было почитать, особенно когда нечто подобное уже сам делал недавно. У меня ранее все прекрасно работало в связке telemt+MTPROTO_FIX, до того момента пока не стали блокировать доступ по айпи к DC телеграма.
Есть ещё один ру-сервер, который отлично работает и подключается к DC по ipv6, но при этом не пашет по ipv4, но такая фишка с этим не прошла, пинг проходит по ipv6, но доступа к DC нет.
Есть третий заграничный сервер для использования vless xhttp, на ру-сервере я создал подключение к нему через xray-core (как клиента), сделал локальный inbound на socks5 и уже в upstream telemt цеплялся к заграничному серверу через socks5. Работоспособность вернулась, проблем нет, ру-сервер за 75 рублей в месяц справляется, при этом как по мне выступает прослойкой что бы не палить заграничный сервер.
Кстати у тебя на ру-сервере “listen”: “0.0.0.0”, возможно конечно там файрволом отсекается, но думаю стоит лучше использовать 127.0.0.1 если конечно он тебе не нужен вне локального использования.
Четвертый сервер сейчас гоняю, ради эксперимента чисто, там решил сделать маааааксимально всё по феншую с маскировкой - зарегал домен нормальный (ну почти, в зоне xyz), взял сервер в DE, попросил нейросеть написать сайт на немецком якобы немца оказывающего услуги с отзывами и т.п. не придраться, развернул там nginx с этим сайтом, поставил hy2 с маскировкой под свой же сайт (выдача по hhtp/3), редирект на https и так же выдача по 443/tcp с заголовком что "в следующий раз иди по http/3". SSH на альтернативном порту, остальное закрыто файрволом. Хочу посмотреть, сколько он проработает.

[bbasil]

Зачем это вот "фсьио" ?))

В то время как нормальный правильно настроенный туннель обеспечивает тоже самое и плюсом кучу всего другого ?

[falkenberg]

кажется насчет xtls-rprx-vision написана какая-то дичь. Приведу лишь выдержку Gemini: Итог:Автор столкнулся с реальным падением туннеля, но сделал дилетантский вывод («Vision предназначен только для обычного веба, а на сырых байтах всегда ломается»). В реальности Vision штатно переносит сырые не-TLS байты, а проблема возникла из-за попытки натянуть Fake-TLS на анализатор внутреннего TLS либо из-за конфликта конфигов.