Развёртывание серверных сервисов в Termux: NGINX, Node.js, Django, PostgreSQL с TLS и reverse proxy

Termux давно перестал быть «просто эмулятором терминала» — это удобная среда для развёртывания локальных серверных сервисов. В этой статье мы рассмотрим практический сценарий: развёртывание PostgreSQL, Node.js и Django в Termux, установку и настройку NGINX в качестве reverse proxy, а также включение TLS-шифрования для защищённого доступа. Материал ориентирован на законное использование в локальной сети/на собственных ресурсах и не предполагает обход ограничений.

Схема будет такой: NGINX принимает HTTPS-запросы, терминирует TLS и проксирует трафик к приложениям: Node.js и Django. PostgreSQL используется как единое хранилище данных (например, для Django и/или Node.js).

Подготовка Termux и окружения

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

pkg update && pkg upgrade -y

pkg install -y nginx nodejs python python-pip postgresql-libs openssl nano git

Далее полезно проверить, что серверные компоненты стартуют/доступны:

nginx -v

node -v

python --version

Если вы планируете использовать Django, создайте отдельную директорию проекта и виртуальное окружение.

mkdir -p ~/lab-server && cd ~/lab-server

Создадим виртуальное окружение для Django:

python -m venv .venv

source .venv/bin/activate

pip install --upgrade pip

pip install django gunicorn psycopg2-binary

TLS-сертификаты: локальный контур и безопасная практика

Для TLS в Termux есть два подхода: использовать сертифицированный сертификат (если вы реально размещаете сервис под доменом) либо создать локальный сертификат для тестовой/домашней сети. В рамках статьи мы сделаем корректную TLS-настройку для локального доступа.

Сгенерируем самоподписанный сертификат. Он будет работать в пределах вашей локальной сети, а браузер/клиент потребуется доверие (добавление сертификата в trust store) — это нормальная практика для тестов и внутреннего контура.

Создадим сертификаты в удобной папке:

mkdir -p ~/lab-server/certs

Сгенерируем ключ и сертификат (измените CN/Subject под вашу цель):

openssl req -x509 -newkey rsa:4096 -keyout ~/lab-server/certs/server.key -out ~/lab-server/certs/server.crt -days 365 -nodes -subj "/CN=termux-lab"

Проверьте наличие файлов:

ls -lah ~/lab-server/certs

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

Настройка PostgreSQL в Termux

PostgreSQL в Termux чаще разворачивается как встроенная подсистема/библиотеки, а для полноценной работы используют запуск сервера в нужном режиме и с правильными каталогами данных. Ниже — практический, «рабочий» шаблон: инициализация кластера, настройка пароля и запуск. В конкретных версиях Termux могут различаться пути, поэтому ориентируйтесь на вывод команд.

Создадим папку данных:

mkdir -p ~/lab-server/pgdata

Инициализируем кластер:

initdb -D ~/lab-server/pgdata

Запустим PostgreSQL (в тестовой локальной конфигурации). Для удобства можно задать порт 5432 и слушание на localhost или на адрес в вашей локальной сети. На старте ограничим доступ localhost, затем при необходимости расширим правила.

postgres -D ~/lab-server/pgdata -p 5432 -h 127.0.0.1

Если нужно выполнить операции в фоне/подсказками — используйте отдельные терминальные сессии и проверяйте логи.

Создадим пользователя и БД. Откройте второй терминал и подключитесь:

psql -h 127.0.0.1 -p 5432 -U postgres

Дальше:

CREATE USER labuser WITH PASSWORD 'strong_password_here';

CREATE DATABASE labdb OWNER labuser;

GRANT ALL PRIVILEGES ON DATABASE labdb TO labuser;

Выйдите:

Для Django потребуется строка подключения. Пример:

postgresql://labuser:strong_password_here@127.0.0.1:5432/labdb

Развёртывание Django за Gunicorn

Перейдите в директорию проекта и создайте Django-приложение (если ещё нет):

cd ~/lab-server

django-admin startproject labsite .

Создадим простое приложение:

python manage.py startapp api

Настроим подключение к PostgreSQL в settings.py. Откройте файл:

nano labsite/settings.py

Найдите блок DATABASES и задайте:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'labdb',
        'USER': 'labuser',
        'PASSWORD': 'strong_password_here',
        'HOST': '127.0.0.1',
        'PORT': '5432',
    }
}

Применим миграции:

python manage.py makemigrations

python manage.py migrate

Добавьте Gunicorn в проект как сервер приложений.

Проверим запуск локально на отдельном порту, например 8000. Соберите статические файлы при необходимости (не обязательно для демо):

gunicorn labsite.wsgi:application --bind 127.0.0.1:8000 --workers 2 --timeout 60

На этом шаге Django доступен локально; дальше NGINX будет проксировать запросы на него.

Развёртывание Node.js сервиса для reverse proxy

Создадим отдельный Node.js сервис, который будет отвечать по HTTP, например на 3000 или 3001. Внутри Termux это удобно держать отдельно от Django.

mkdir -p ~/lab-server/nodeapp && cd ~/lab-server/nodeapp

npm init -y

Установим минимальные зависимости (для простого HTTP-сервера можно без фреймворка):

npm install express

Создадим server.js:

nano server.js

Пример содержимого:

const express = require('express');
const app = express();

app.get('/health', (req, res) => {
  res.json({ status: 'ok', service: 'node' });
});

app.get('/hello', (req, res) => {
  res.send('Hello from Node.js in Termux');
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, '127.0.0.1', () => {
  console.log(Node service listening on 127.0.0.1:${PORT});
});

Добавьте запуск:

node server.js

Проверьте в браузере/через curl на уровне localhost:

curl http://127.0.0.1:3000/health

NGINX как reverse proxy с HTTPS

Теперь настроим NGINX так, чтобы он обслуживал HTTPS и проксировал маршруты на внутренние сервисы. В Termux конфигурация NGINX может отличаться по путям, однако общий принцип одинаковый: правим nginx.conf или добавляем server блок в доступную конфигурацию.

Обычно удобно создать конфиг в рабочей директории и запускать nginx с нужным файлом. Попробуйте найти конфиг:

nginx -t

Если требуется отредактировать основной конфиг, найдите файл:

ls -lah /data/data/com.termux/files/usr/etc/nginx

Для примера создадим свой конфиг поверх стандартных:

mkdir -p ~/lab-server/nginx

nano ~/lab-server/nginx/termux-lab.conf

Пример server конфигурации для TLS и проксирования:

server {
    listen 443 ssl http2;
    server_name termux-lab;

    ssl_certificate     ~/lab-server/certs/server.crt;
    ssl_certificate_key ~/lab-server/certs/server.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    # Логи (можно упростить/убрать при необходимости)
    access_log /data/data/com.termux/files/home/lab-server/nginx/access.log;
    error_log  /data/data/com.termux/files/home/lab-server/nginx/error.log;

    # Django (пример: /api -> Django)
    location /api/ {
        proxy_pass http://127.0.0.1:8000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;

        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }

    # Node.js (пример: /node/ -> Node)
    location /node/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    # Общая страница/health для удобства
    location = /health {
        return 200 "ok
";
        add_header Content-Type text/plain;
    }
}

Теперь нужно включить этот конфиг в NGINX. Простой вариант: использовать include в основном конфиге. Откройте стандартный nginx.conf:

nano /data/data/com.termux/files/usr/etc/nginx/nginx.conf

Найдите секцию http и добавьте строку:

include /data/data/com.termux/files/home/lab-server/nginx/*.conf;

Сохраните и проверьте конфигурацию:

nginx -t

Запуск NGINX:

nginx

Проверьте, что NGINX слушает порт 443 (в Termux это обычно локально, и доступ зависит от сети/маршрутизации):

ss -lntp | grep -E ':443|:80'

Тест со стороны клиента (если вы доверяете сертификату):

curl -k https://termux-lab/api/

Примечание: для curl используйте -k на время теста, но в реальных сценариях клиент должен доверять сертификату. Для браузера добавьте сертификат в доверенные, если это локальная сеть.

Маршруты и CORS/headers: типичные нюансы

Если ваш Django возвращает API для фронтенда, и фронтенд запрашивает данные через HTTPS (а Django за reverse proxy получает заголовки X-Forwarded-Proto), корректно настроьте Django, чтобы он корректно понимал схему https. Обычно помогает настройка SECURE_PROXY_SSL_HEADER и включение проксируемых заголовков.

В settings.py добавьте (при необходимости):

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

Также убедитесь, что Django не перенаправляет в HTTP обратно. Это особенно важно при использовании DEBUG=False.

Запуск сервисов: практичная организация

Для удобства поддерживайте сервисы отдельно:

PostgreSQL: запущен на 127.0.0.1:5432
Django (Gunicorn): на 127.0.0.1:8000
Node.js: на 127.0.0.1:3000
NGINX: принимает 443 и проксирует наружу

Рекомендуемая дисциплина: внутренние сервисы держать привязанными к localhost (127.0.0.1) и открывать внешний доступ только на NGINX, чтобы снизить поверхность атаки.

Чтобы проверить, что NGINX проксирует, используйте:

curl -k https://термux-host/node/hello

И проверьте Django маршрут (пример зависит от ваших URL):

curl -k https://термux-host/api/

Защита: сетевые границы и минимизация рисков

Даже в локальной среде действуют общие принципы безопасности:

Не слушайте PostgreSQL напрямую на публичных интерфейсах; используйте 127.0.0.1 и доступ только через proxy/локальные приложения.
Порт 443 открывайте только для NGINX.
Используйте сильные пароли к базе данных (никогда не храните их в репозитории).
Обновляйте пакеты (pkg upgrade) и зависимости приложений.
Логируйте ошибки NGINX в отдельный файл для диагностики.

Если вам нужно подключиться к сервисам из другого устройства в локальной сети, используйте доступные варианты сетевой связности. В некоторых сценариях удобно создать локальную сеть через VPN исключительно для построения локального контура, а не для обхода ограничений. При этом сохраняйте привязку внутренних сервисов к 127.0.0.1 и выставляйте доступ только через NGINX.

Заключение

Мы показали связку для развёртывания в Termux: PostgreSQL как хранилище, Django и Node.js как отдельные приложения, и NGINX как единый вход с TLS-шифрованием и reverse proxy. Такой подход даёт понятную архитектуру: приложения живут за локальными портами, а безопасность и маршрутизация — на стороне NGINX.

Если вы хотите, чтобы мы адаптировали конфигурации под ваш сценарий (адресация в сети, доменные имена, автообновление сертификатов, система запуска сервисов, схема БД и деплой Django/Node), обращайтесь за консультацией в РыбинскЛАБ. Мы поможем собрать надёжный и аккуратно поддерживаемый стенд именно под ваши условия.