Комментарии 32
Спасибо за проделаннуб работу, возникло 2 вопроса
- с помощью синей изоленты нет возможности скрестить бота с официальной mtproxy
- не могу понять отчего http проксирование работает быстрее VPN решения которое умеет сжимать трафик
все-таки бот и клиент телеграма – это разные вещи, я сомневаюсь что клиент работает http-запросами на api, скорее всего у него свой бинарный протокол и другие сервера. так что боту socks/mtproxy не нужны, достаточно обычного http reverse proxy, что автор и проделал…
другое дело что решение какое-то однобокое. если бот не должен получать сообщения или сообщения вытягиваются поллингом – вопросов нет, а иначе как будет вебхук работать – там же сам телеграм инициирует отправку нотификаций на адрес бота. нужен либо ещё один реверс от телеграма к боту, либо может проще бота развернуть где-то отдельно от основного сервиса? тогда и проксировать ничего не придётся… а данные можно боту скармливать уже с основного сервиса по http...
Правда лично я его не тестил при подключении в качестве бота — только как обычного пользователя.
proxy_pass https://api.telegram.org/;А резолвинг-то, наверное, все еще идет только при старте или релоаде nginx'а? Т.е. если вдруг поменяется IP, то все встанет?
nginx.org/ru/docs/http/ngx_http_core_module.html#resolver
location / {
…
resolver 8.8.8.8;
set $url «api.telegram.org»;
proxy_pass https://$url;
…
}
Более лучшеВыберите уж что-то одно. И… спасибо за конфиг :)
На стороне приложения пишем в /etc/hosts:
ip.of.my.proxy api.telegram.orgДля Nginx на проксе пишем:
stream {
# Конфигурация апстрима
upstream tgapi {
server api.telegram.org:443;
}
# Вот этот блок ради того, чтобы можно было один сервер использовать как прокси для нескольких имен
map $ssl_preread_server_name $upstream {
hostnames;
default tgapi;
api.telegram.org tgapi;
}
server {
listen 443;
ssl_preread on;
proxy_pass $upstream;
}
}Кстати, в большинстве дистрибутивов nginx собран без stream, но оно есть в nginx-full в официальной репе самого nginx.
Тогда бизнес может оказаться без канала связи.
Я думаю, надо найти другие боты для связи с клиентами, для надежности.
В целом, у вас задача стоит «просто отфорвардить запросы через разблокированное место». Есть вариант с nginx + stream, который я выше написал, есть haproxy, который может просто запроксить не трогая содержимое. Наконец, есть всякие другие подобные штуки которые делают то же самое. Все они позволяют 2 основных вещи:
1. Сохранить оригинальное шифрование.
2. Обеспечить доступ через разблоченный узел.
Схема «свой домен + сертификат + апстрим» конечно имеет право на жизнь, но она сложнее, требует выписки (и поддержки) своего сертификата, требует изменения в конфигурации приложения (имя домена) при том, что совершенно не дает профита.
resolvers default
nameserver default 4.2.2.2:53
frontend localhost
bind *:443
option tcplog
mode tcp
default_backend nodes
backend nodes
mode tcp
balance roundrobin
option ssl-hello-chk
server api api.telegram.org:443 check resolvers default
socat TCP4-LISTEN:443,reuseaddr,fork,bind=serverip TCP4:api.telegram.org:443
После чего все запросы на 443 порт вашего сервера будут проксироваться на api.telegram.org.
const TelegramBot = require('node-telegram-bot-api')
if (config.proxy) {
options.request = {
proxy: config.proxy
}
}
const bot = new TelegramBot(config.token, options)
Или я что то не так понял?
можно и так, но – сквида с авторизацией поднимать дольше и сложнее чем реверс на nginx сделать…
лично я бы просто поднял tcp-тоннель с помощью socat, а на сервере прописал адрес тоннеля в /etc/hosts для api.telegram.org, тогда и с сертификатами не пришлось бы ничего городить. а уж научить systemd поднимать socat на автозапуске – вообще ничего не стоит…
Роскомнадзор и Телеграм боты через прокси