Прокси‑и‑трансляторы в Termux: настройка и оптимизация SOCKS5/HTTP/HTTPS туннелей с использованием ssh, tinyproxy и ss‑redir

Termux — удобная среда для администрирования и сетевых экспериментов на стороне устройства. Когда требуется гибко управлять исходящими соединениями (например, для тестирования, доступа к внутренним сервисам, маршрутизации через промежуточный узел или изоляции трафика), на практике часто применяют прокси‑сервисы и туннели.

В этой статье рассмотрим безопасные и легальные с точки зрения сетевой инженерии сценарии: построение туннелей через ssh, запуск локального HTTP‑прокси tinyproxy, а также прозрачную маршрутизацию/редирект через ss‑redir. Фокус — на настройке, оптимизации стабильности и удобства, а также на параметрах, которые помогают диагностировать проблемы.

Важно: любые действия должны соответствовать правилам вашей сети и требованиям законодательства РФ. Приведённые примеры ориентированы на управление локальным/внутренним трафиком и лабораторное тестирование. Если вы строите «обход блокировок», вы берёте на себя ответственность за соответствие действующим ограничениям.

Подготовка Termux: обновление системы и установка пакетов

Начнём с обновления базового окружения и установки необходимых инструментов. В Termux обычно достаточно базового набора: openssh (или клиент ssh), утилиты сборки зависимостей, а также компоненты для работы прокси/редиректа.

pkg update -y
pkg upgrade -y
pkg install -y openssh git curl iproute2 netcat-openbsd

Далее установим tinyproxy. В зависимости от актуального репозитория Termux пакет может отсутствовать как готовый — тогда соберём из исходников или используем доступный вариант. Проверяйте наличие пакета командой:

apt-cache search tinyproxy

Если пакет доступен:

pkg install -y tinyproxy

Если нет — можно собрать из исходников. Самый практичный путь: держать версию и зависимости в контроле (для лаборатории это оптимально). Ниже — схема сборки через репозиторий:

pkg install -y build-essential autoconf automake libtool
# Дальше — сборка tinyproxy (примерный сценарий; при необходимости уточните ветку/версию):
git clone https://github.com/tinyproxy/tinyproxy.git
cd tinyproxy
# Конфигурирование и сборка
./autogen.sh || true
./configure --help
make -j$(nproc)
make install

Для ss‑redir ситуация аналогична: обычно используют готовый сборочный рецепт или репозиторий. В рамках статьи приведём установку через источники, но конкретные шаги могут зависеть от выбранного форка. Рекомендуется использовать проверяемые источники и фиксировать версии.

Схемы: как «туннелировать» трафик в Termux

Существует несколько типовых архитектур:

SOCKS/HTTP через ssh туннель — удобный способ вынести маршрутизацию через сервер, где есть нужный сетевой доступ.
Локальный HTTP‑прокси tinyproxy — когда приложениям проще отдавать HTTP proxy (или когда нужен небольшой прокси с контролем параметров).
ss‑redir — прозрачная/полупрозрачная маршрутизация: клиентские приложения продолжают обращаться «как обычно», а редирект перенаправляет соединения в нужный стек.

Дальше разберём каждую технологию по отдельности и затем покажем, как их сочетать для устойчивой работы.

Вариант 1: SOCKS5/HTTP(S) через ssh в Termux

Наиболее универсальный метод — создать туннель на удалённый хост по ssh и поднять локальный прокси, который будет проксировать соединения через удалённую сторону.

Допустим, вы имеете ssh‑доступ к серверу (например, с публичным IP в вашей инфраструктуре или в лабораторной сети). В Termux используйте локальную привязку (например, 127.0.0.1) и порт SOCKS/HTTP.

1) SOCKS5 через ssh (dynamic port forwarding)

Команда создаёт локальный SOCKS5‑прокси, который направляет трафик на сервер по ssh.

ssh -N -D 1080 user@your_server_host

Пояснения:

-N — без интерактивной сессии (только туннель).
-D 1080 — динамический forwarding (SOCKS5) на локальный порт 1080.
Используйте -o ExitOnForwardFailure=yes, чтобы быстрее понимать, что туннель не поднялся.

Рекомендуемый «рабочий» вариант с диагностикой:

ssh -N -o ExitOnForwardFailure=yes -D 1080 user@your_server_host

2) HTTP‑прокси через ssh (локальный forward для HTTP)

SSH из коробки удобнее для SOCKS. Но можно организовать HTTP‑доступ, используя локальный forward на удалённый HTTP‑порт при наличии HTTP‑сервиса на сервере. Для общего «преобразования SOCKS в HTTP» обычно применяют дополнительный прокси/транслатор. Практически проще: поддержка SOCKS5 во многих приложениях. Если приложению нужен именно HTTP, рассмотрите связку tinyproxy + ssh (ниже).

3) Проверка туннеля

Проверьте, что локальный порт прослушивается:

ss -ltnp | grep 1080 || true

Тест SOCKS можно сделать утилитами, которые умеют SOCKS. Например, если у вас установлен curl с SOCKS‑поддержкой:

curl -x socks5h://127.0.0.1:1080 https://example.com -I

Если доменное имя резолвится на стороне прокси (часто важное отличие), используйте socks5h.

Вариант 2: tinyproxy в Termux как локальный HTTP‑прокси

tinyproxy хорош тем, что:

прост в настройке;
даёт контроль доступа (acl);
может быть поставлен рядом с вашим ssh‑туннелем (tinyproxy как «фронт»).

1) Базовый конфиг tinyproxy

Обычно конфигурационный файл располагается в стандартных путях (в Termux путь может отличаться). Найдите его и откройте:

tinyproxy -h || true
# Попробуйте найти конфиг:
find $PREFIX -name 'tinyproxy.conf' 2>/dev/null

В конфиге важны параметры:

Port — порт локального прокси (например 8888);
User/Group — от чьего пользователя запускать;
Listen — адрес прослушивания (часто 127.0.0.1 для локальной безопасности);
Allow/Deny — ACL.

Пример минимально безопасного конфига под локальное использование:

Port 8888
Listen 127.0.0.1
Timeout 600
DefaultErrorFile "/usr/share/tinyproxy/default-error.html"
MaxClients 50
MinSpareServers 5
MaxSpareServers 20
StartServers 10
MaxRequestsPerChild 0
ConnectPort 443
# Ограничение доступа — разрешаем только localhost nAllow 127.0.0.1
# Остальное — запрет
Deny 0.0.0.0/0

Строка Allow/Deny зависит от версии tinyproxy, но идея та же: не открывать прокси наружу.

2) Проброс tinyproxy через ssh‑SOCKS

Частый практический сценарий: tinyproxy принимает HTTP‑запросы локально, а дальше использует upstream‑маршрутизацию через ssh‑SOCKS5 на 127.0.0.1:1080. В зависимости от возможностей tinyproxy для «транспорта» (и версии) конфигурация может отличаться. В некоторых схемах проще оставить tinyproxy как «прокси‑сервер», который принимает HTTP CONNECT, а upstream направлять через отдельный компонент.

Если ваша версия tinyproxy поддерживает настройку upstream через SOCKS/прокси, используйте функциональность Proxy/Upstream (названия директив зависят от сборки). Идея такая:

поднять ssh SOCKS на локальном порту 1080;
настроить tinyproxy так, чтобы исходящие соединения шли через SOCKS upstream.

Командный порядок обычно выглядит так:

# 1) Сначала ssh SOCKS
ssh -N -o ExitOnForwardFailure=yes -D 1080 user@your_server_host

# 2) Затем запускаем tinyproxy
# В зависимости от системы команда запуска может отличаться:
tinyproxy -c /path/to/tinyproxy.conf -d

Опцию -d включайте для отладки в терминале (для лаборатории).

3) Настройка приложений на Termux/Android

Если вы запускаете tinyproxy на 127.0.0.1:8888, то приложения (либо настройки Android) должны указывать HTTP прокси: 127.0.0.1 и порт 8888. Для некоторых приложений важно различать:

HTTP proxy (для открытия соединений/CONNECT);
SOCKS proxy (если приложение умеет SOCKS).

Тест:

curl -x http://127.0.0.1:8888 http://example.com -I

Для HTTPS обычно нужен CONNECT; проверьте так:

curl -x http://127.0.0.1:8888 https://example.com -I

Вариант 3: ss‑redir для прозрачного редиректа трафика

ss‑redir применяют, когда требуется «перехватить» исходящие соединения и перенаправить их в нужный обработчик/порт без настройки прокси в каждом приложении. Это похоже на прозрачные сценарии маршрутизации и часто удобно для тестирования.

Рассмотрим общую логику (конкретные флаги и параметры зависят от реализации ss‑redir и версии). Обычно шаги такие:

Запустить ss‑redir с привязкой к локальному интерфейсу/порту назначения.
Настроить локальную проксирующую сторону (сервер/туннель), куда будут уходить перехваченные соединения.
Проверить, что трафик действительно перенаправляется и не ломает DNS.

1) Установка ss‑redir

Найдите репозиторий/сборку для вашей версии. В Termux обычно:

# примерный шаблон — уточните актуальный источник под вашу задачу
# (не приводится как «единственно правильный»; важно взять проверяемый исходник)
git clone https://example.com/ss-redir.git
cd ss-redir
pkg install -y build-essential
make -j$(nproc)
cp ss-redir $PREFIX/bin/

После установки проверьте:

ss-redir --help

2) Прозрачный перехват: базовый пример запуска

Обычно используется привязка локального порта и указание upstream (куда перенаправлять). Пример носит иллюстративный характер; подставьте реальные параметры вашей сборки:

# Примерная схема (проверьте help конкретной версии ss-redir)
ss-redir -l 1081 -u -s 127.0.0.1 -p 1080
# где:
# -l 1081: локальный слушающий порт/режим перехвата
# -s 127.0.0.1 -p 1080: upstream SOCKS (ssh)
# флаги -u/прочие зависят от реализации

Ключевой момент: DNS. Если редирект «прозрачный», доменные имена должны корректно резолвиться либо на устройстве, либо на стороне upstream. В туннелях через SOCKS часто предпочтительно резолвить на удалённой стороне (аналог socks5h).

3) Проверка

Проверьте соединения через проверочные запросы:

curl https://example.com -I --max-time 10

Если у вас включён прозрачный редирект, приложение не должно знать про прокси — значит результат зависит от корректности перехвата на уровне сетевого стека.

Оптимизация: скорость, стабильность и диагностика

Чтобы туннели работали предсказуемо в мобильной среде, уделите внимание следующим аспектам.

1) keepalive и таймауты ssh

Мобильные сети часто меняют маршрут и могут ронять TCP. Настройте keepalive для ssh:

ssh -N \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -D 1080 user@your_server_host

2) Таймауты tinyproxy

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

Timeout 600
MaxClients 50
MinSpareServers 5
MaxSpareServers 20
StartServers 10

3) Ограничение доступа к локальному прокси

Запускайте tinyproxy только на 127.0.0.1, а не на всех интерфейсах. Это снижает риск непреднамеренного доступа.

4) Логи и «что именно сломалось»

Для ssh используйте подробность логов при диагностике:

ssh -vvv -N -o ExitOnForwardFailure=yes -D 1080 user@your_server_host

Для tinyproxy включайте -d и проверяйте конфиг. Если туннель поднимается, но трафик не идёт — причина часто в DNS, ACL или в том, что приложение использует не тот тип прокси (HTTP vs SOCKS).

5) Экономия ресурсов на устройстве

На слабых устройствах ограничьте параллельность:

уменьшайте MaxClients;
не запускайте избыточные слои прокси без необходимости;
для тестов переключайтесь на прямой ssh‑SOCKS, если приложению подходит.

Безопасность и корректная эксплуатация в локальной сети

Сетевые прокси — это «точка доверия». Основные практики:

Всегда ограничивайте слушающие адреса (предпочитайте Listen 127.0.0.1).
Используйте сильную аутентификацию для ssh и ключи вместо пароля.
Не открывайте прокси на внешние интерфейсы без явной необходимости.
В лабораторной среде изолируйте стендами доступ и маршрутизацию.

Если вы используете VPN, допускается применять его для создания локальной сети и контроля доступа между вашими узлами в инфраструктуре (например, чтобы сервер ssh был достижим только из вашей среды). Не используйте VPN «для обхода блокировок».

Заключение

Termux позволяет гибко строить сетевые сценарии: ssh‑туннели для SOCKS5, локальный HTTP‑прокси tinyproxy и прозрачные перехваты через ss‑redir. Ключ к успеху — правильная архитектура (какой тип прокси нужен приложению), аккуратная настройка таймаутов/keepalive и строгие ограничения доступа к локальным сервисам.

Если вам нужна консультация по выбору схемы, настройке стенда в вашей инфраструктуре, диагностике сетевых проблем или автоматизации конфигураций Termux, обращайтесь в РыбинскЛАБ: мы поможем подобрать безопасное решение под ваши условия и требования.