
Комментарии 18
Спасибо, очень годная статья. Надеюсь проработает подольше.
да, кстати, у кого есть ИИ-агент типа opencode - его можно поставить на сервер (или просто сказать "ходи на сервер через ssh user@domain..."), и сказать ему прочитать эту статью (прям ссылку дать), составить план работ, использовать в качестве домена-приманки "домен-провайдера.ru", после настройки протестировать работу существующих виртуальных хостов и домена-приманки через mtproxy, найти в system логах tg-ссылку и поправить в ней порт — и через минуту у вас всё будет работать. Он ещё и сам всё протестирует — вам останется только ссылку скопировать и отправить друзьям
именно так! Использовал https://argv.cloud/blog/2025/ai-remote-ops/
Настроил домашний минисервер на доступ к другим серверам для контроля и администрирования.
да, мой opencode наудивление очень круто выполняет всю работу по администрированию linux серверов — прям идеально. И всё перепроверит, сделает бэкапы на всякий случай — короче прям без нареканий. Главное сначала в режиме планирования всё обсудить на берегу, он задаст уточняющие вопросы, распишет план работ — и погнали.
А кто-нибудь ковырялся с wireshark, насколько хендшейк телеги через такой прокси отличается от обычного захода на сайт?
я навайбил мини скрипт который ловит подключение от браузера и от ТГ-клиента и сравнивает их хендшейк. Разница есть, да.
Waiting on port 20098 for first connection...
Client A from xxx:57588
tls_version: 0x0303
sni: my-site.one
alpn: h2, http/1.1
cipher_suites_count: 16
cipher_suites: 0x5a5a, 0x1301, 0x1302, 0x1303, 0xc02b, 0xc02f, 0xc02c, 0xc030, 0xcca9, 0xcca8, 0xc013, 0xc014, 0x009c, 0x009d, 0x002f, 0x0035
extensions: 0x2a2a, 0xff01, 0x000b, 0xfe0d, 0x000a, 0x0023, 0x002d, 0x000d, 0x0017, 0x44cd, 0x001b, 0x0005, 0x002b, 0x0010, 0x0033, 0x0012, 0x0000, 0x0a0a
Waiting on port 20099 for first connection...
Client B from xxx:57599
tls_version: 0x0303
sni: www.hetzner.com
alpn: h2, http/1.1
cipher_suites_count: 21
cipher_suites: 0x8a8a, 0x1301, 0x1302, 0x1303, 0xc02c, 0xc02b, 0xcca9, 0xc030, 0xc02f, 0xcca8, 0xc00a, 0xc009, 0xc014, 0xc013, 0x009d, 0x009c, 0x0035, 0x002f, 0xc008, 0xc012, 0x000a
extensions: 0xfafa, 0x0000, 0x0017, 0xff01, 0x000a, 0x000b, 0x0010, 0x0005, 0x000d, 0x0012, 0x0033, 0x002d, 0x002b, 0x001b, 0x4a4a, 0x0015
Differences
sni: my-site.one vs www.hetzner.com
cipher_suites: different
only_in_a: 0x5a5a
only_in_b: 0x000a, 0x8a8a, 0xc008, 0xc009, 0xc00a, 0xc012
extensions: different
only_in_a: 0x0023, 0x0a0a, 0x2a2a, 0x44cd, 0xfe0d
only_in_b: 0x0015, 0x4a4a, 0xfafaА не случится так, что РКН, отловив трафик прокси, не заблокирует по IP вообще весь ваш сервер вместе со всеми сайтами?
может и так случиться, но тогда я просто переключу свои сайты на другой хостинг и буду думать что делать дальше.
у меня несколько недель работал socks5 для телеги. На прошлой недели начали блочить трафик телеги через сокс, телега не работает. Честный http-трафик через сокс ходит.
Пришлось поднимать mtproxy.
прошло чуть больше месяца — прокси работает, держит порядка 250 пользователей в сутки, почасовая активность — промерно 50 пользователей в час. На двухядерной виртуалке нагрузка в top от этого прокси - 1% CPU и 2% RAM.
top - 06:01:30 up 31 days, 21:15, 1 user, load average: 0.02, 0.04, 0.05
Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.5 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 1967.6 total, 222.4 free, 1136.3 used, 837.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 831.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
584733 nobody 20 0 274272 43652 14500 S 1.0 2.2 0:04.14 python3
584823 root 20 0 12392 5864 3604 R 1.0 0.3 0:00.04 top Ничего не понятно, Но ужасно интересно.
Есть более устойчивая версия MTProxy к DPI https://github.com/telemt/telemt
судя по описанию — ровно такой же функционал маскировки как у alexbers/mtprotoproxy через длинный secret с префиксом ee. Может я что-то пропустил?
Проблема на самом деле не в проксях, а в телеграм-клиентах, которые отправляют ssl-handshake заметно отличающийся от браузерного. Я уже отправил своим друзьям в команде телеграма этот багрепорт, так что может они исправят.
Возможно конечно версия на rust меньше ресурсов ест, но судя по статистике моего сервера — куда уж меньше. У меня сейчас несколько десятков активных клиентов и на двухядерной виртуалке я вообще этот питон-прокси в топе не вижу.
server {
...
set_real_ip_from 127.0.0.1; # Nginx Stream local IP
real_ip_header proxy_protocol; # proxy_protocol needed
real_ip_recursive on;
...
}Это необходимо дописать к каждому виртуальному серверу чтобы получать реальный IP. Автор, добавьте в статью, пол дня убил чтобы найти как правильно настроить.
официальный mtproxy с исправлениями из merge request
https://github.com/TelegramMessenger/MTProxy/pull/673/files
или с этим
https://github.com/TelegramMessenger/MTProxy/pull/669/files
запустился, все по инструкции из readme
Настройка Telegram MTProxy на 443 порту параллельно с работающим nginx