FAQ — Часто задаваемые вопросы¶
Вопросы упорядочены от простых к сложным. Последнее обновление: 2026-10-17.
Основы¶
Что такое dix.su?¶
dix.su — платформа для публикации локальных сервисов в интернет без белого IP и
проброса портов. Запустил device_client на своём устройстве — и твой
localhost:3000 мгновенно доступен по адресу slug.dix.su из любой точки мира.
Это бесплатно?¶
Да, базовый тариф SIMPLE бесплатен: 10 ГБ трафика в месяц, без ограничений по времени, плюс 14-дневный пробный период приватного режима. Платные тарифы (VIP/PRO/PERS) добавляют больше трафика, TCP-протоколы, свой домен, аналитику и постоянный приватный режим.
У меня нет белого IP / я за CGNAT — поможет ли dix.su?¶
Именно для этого платформа и создана. CGNAT (carrier-grade NAT) — когда провайдер раздаёт один публичный IP на сотни клиентов — полностью блокирует входящие соединения. device_client устанавливает исходящее WSS-соединение к прокси, через которое и проходит весь трафик. Белый IP не нужен.
Нужны ли технические знания?¶
Для HTTP-туннеля (сайт, API, веб-приложение) — минимальные: скачать бинарник,
запустить одной командой. Для TCP-туннелей (SSH, базы данных) — базовые знания
терминала. Docker-стеки из каталога — вообще sh setup.sh и готово.
Мои данные в безопасности?¶
Трафик HTTP-туннеля проходит через серверы dix.su (TLS между клиентом и прокси, plain-текст между прокси и вашим устройством). Для полной конфиденциальности доступен E2E-режим (приватный туннель): ключ никогда не покидает устройство, прокси передаёт байты вслепую без расшифровки. Подробнее — в разделе «E2E» ниже.
Использование¶
На каком устройстве работает device_client?¶
Поддерживаются: Linux (x86_64, ARM64), macOS (Apple Silicon, Intel), Windows (x86_64). Скачивается как самодостаточный бинарник без зависимостей. Готовые устройства из магазина поставляются с уже настроенным клиентом.
Как не потерять доступ к устройству при обновлении или перезапуске device_client?¶
Если управление устройством идёт через основной туннель, его перезапуск обрывает соединение — и вы теряете доступ до физического вмешательства.
Рекомендуется держать два независимых туннеля:
- Основной (
mydevice) — ваш сервис, порт 80 - Резервный/mgmt (
mydevice-mgmt) — управление устройством, используется для обслуживания и перезапуска основного
Обновление и перезапуск основного туннеля всегда делайте через mgmt-туннель.
Дополнительно: включите автоперезапуск — Restart=always (systemd) или respawn
(OpenRC), чтобы сервис поднимался сам после краша или ребута.
Вариант 1 — браузерный терминал ttyd (все тарифы, включая SIMPLE)¶
ttyd — терминал в браузере поверх HTTP/WebSocket. Работает на Linux, macOS и Windows. Не требует открытого SSH-порта.
Браузерный терминал требует отдельного слага с LOCAL_PORT=7681 (обычно
mydevice-mgmt). Причина: HTML-страница ttyd грузится через HTTP-прокси — modulauth
форвардит запрос на slug.dix.su, dixu_proxy отдаёт ответ от LOCAL_PORT device_client.
Если LOCAL_PORT=80 — откроется веб-сервер, а не ttyd. Совместить на одном слаге
с основным HTTP-сервисом невозможно.
# Установка (Linux)
apt install ttyd # Debian/Ubuntu
pacman -S ttyd # Arch/Manjaro
apk update && apk add ttyd # Alpine Linux
# или скачать бинарь с github.com/tsl0922/ttyd/releases (есть для Windows)
# Запуск ttyd на порту 7681
ttyd --port 7681 --writable login
# Запуск туннеля — основной слаг или отдельный mgmt
device_client mydevice-mgmt <token> 7681 # рекомендуется (независимый)
# ИЛИ
device_client mydevice <token> 7681 # тоже работает
Браузерный терминал доступен в личном кабинете:
Браузер покажет запрос системного логина и пароля устройства.Не путайте с
https://mydevice-mgmt.dix.su— это страница туннеля, не терминал.
На Windows ttyd запускает PowerShell/CMD; команды для установки и запуска те же
(бинарь ttyd.exe из релизов).
Подробные инструкции по установке сервиса (systemd / OpenRC / macOS / Windows) → docs/guides/mgmt-tunnel.md
Вариант 2 — нативный SSH через TCP-туннель (тариф VIP и выше)¶
На тарифах VIP/PRO/PERS доступен SSH-порт 2222. Mgmt-туннель проксирует порт 22 устройства:
Подключение стандартным SSH-клиентом:
ssh -p 2222 -o "ProxyCommand=bash -c '{ echo DIXSU:mydevice-mgmt; cat; } | nc mydevice-mgmt.dix.su 2222'" user@mydevice-mgmt.dix.su
Требует тариф VIP или выше.
Подробная инструкция с готовыми конфигами → docs/guides/mgmt-tunnel.md
Что будет если выключить устройство или компьютер?¶
Туннель сразу становится недоступен — сайт вернёт страницу «устройство офлайн» с контактами владельца. Когда устройство снова выйдет в сеть, туннель восстановится автоматически (device_client переподключается сам).
Что такое заморозка туннеля и как она работает? {#freeze}¶
Заморозка — временная блокировка входящих запросов к слагу без остановки device_client на устройстве. Полезна когда нужно временно скрыть сервис извне, не теряя активное подключение клиента.
Что происходит при заморозке: - Новые HTTP/TCP-запросы к слагу получают ответ 503 «туннель заморожен» - Уже установленные соединения не разрываются - device_client продолжает работать и держит WebSocket-соединение с прокси - Размораживание мгновенно восстанавливает доступ
Управление заморозкой — в личном кабинете на вкладке «Мои туннели» (кнопки «❄ Заморозить» / «▶ Открыть» рядом с каждым слагом).
Для основного слага заморозка сохраняется в базе и переживает рестарт платформы. Для дополнительных (secondary) слагов — только в памяти прокси, сбрасывается при перезапуске контейнера.
Администратор платформы может заморозить туннель независимо от пользователя (например при нарушении правил). В этом случае кнопка размораживания в ЛК недоступна — только администратор может разморозить.
Можно ли использовать свой домен (например mysite.com)?¶
Да, начиная с тарифа VIP. Настрой CNAME mysite.com → slug.dix.su и добавь свой домен в личном
кабинете — платформа получит TLS-сертификат через Let's Encrypt автоматически.
Подробнее — docs/guides/custom-domain.md.
Для чего нужны «готовые устройства» из магазина?¶
Устройство (мини-ПК, смартфон, Raspberry Pi) с предустановленным device_client позволяет держать туннель 24/7 без включённого компьютера. Включил в розетку — туннель поднялся. Ничего настраивать не нужно.
Можно ли запустить через Docker, не устанавливая бинарник?¶
Да. В каталоге GitLab есть готовые стеки (dixsu-test, dixsu-mysql и др.):
git clone https://gitlab.com/dixsu/market/dixsu-test
# заполнить .env: DIXSU_SLUG и DIXSU_TOKEN
sh setup.sh
Через 10–15 секунд сервис доступен по https://slug.dix.su.
Forgejo при первом запуске показывает страницу «Initial configuration» — что заполнять?¶
Это одноразовый мастер настройки. Большинство полей уже заполнены автоматически из переменных окружения стека — трогать их не нужно.
Что реально нужно заполнить:
- Database type → выбрать SQLite3 (стек уже настроен на него)
- Instance title → название твоего сервера (любое, например «Мой Git»)
- Administrator account → логин, email и пароль первого администратора
- Опционально: чекбокс «Only instance administrators can create accounts» — отметь, если хочешь закрыть публичную регистрацию сразу
Нажать Install Forgejo — через несколько секунд откроется страница входа.
Подробная расшифровка каждого поля — в гайде Forgejo: Git, Docker и реестры пакетов → Установщик: начальная конфигурация.
На стеке dixsu-git нужно что-то настраивать, чтобы заработал Docker-реестр?¶
Нет. Package Registry в Forgejo включён по умолчанию, а TLS и проксирование берёт на себя
dix.su-туннель — сертификат для *.dix.su валидный, поэтому insecure-registries в
daemon.json не нужен и свой nginx перед Forgejo поднимать не нужно. Достаточно:
Проверить, что реестр отвечает: curl -I https://ваш-слаг.dix.su/v2/ — должен вернуться
заголовок docker-distribution-api-version: registry/2.0. Подробнее — в гайде
Forgejo: Git, Docker и реестры пакетов → Docker / OCI реестр.
Архитектура туннелей¶
Можно ли запустить два device_client на одном слаге?¶
Нет. Слаг — это одно активное WebSocket-соединение с прокси. Если запустить второй
device_client с тем же слагом, он вытеснит первый.
Но два device_client не нужны: один клиент обслуживает HTTP-запросы (порт 80) и TCP relay (SSH :22, ttyd :7681) одновременно.
Почему SSH и ttyd работают на том же слаге, что и HTTP на 80?¶
HTTP-прокси и TCP relay — разные механизмы, которые device_client обрабатывает независимо:
- HTTP-прокси — входящие HTTP-запросы к
slug.dix.suфорвардируются на один настроенный локальный порт (тот, что указан при запуске, например:80). - TCP relay — когда прокси получает TCP-соединение на специальных портах
(2222→SSH:22, 3389→RDP:3389, 4432→PostgreSQL:5432 и т.д.), он посылает device_client
событие
tcp_connectс указанием целевого порта. Клиент открывает TCP к этому порту независимо от HTTP-конфига.
Поэтому один device_client на слаге eskimos с LOCAL_PORT=80 одновременно:
eskimos:80 ← HTTP-запросы к eskimos.dix.su (HTTP-прокси)
eskimos:22 ← SSH через dix.su:2222 (тариф VIP+) (TCP relay)
Браузерный терминал (ttyd) на том же слаге НЕ работает. HTML-страница ttyd
грузится через HTTP-прокси — форвардится на LOCAL_PORT (80). Получите веб-сервер, не ttyd.
Для ttyd нужен отдельный слаг с LOCAL_PORT=7681:
Можно ли через браузерный терминал прокинуть SSH (порт 22)?¶
Нет. Каждый вход на dix.su жёстко привязан к порту на устройстве:
| Вход на dix.su | → устройство |
|---|---|
/auth/terminal/{slug} (браузерный терминал) |
:7681 (ttyd) |
| порт 2222 | :22 (SSH) |
| порт 3389 | :3389 (RDP) |
| порт 4900 | :5900 (VNC) |
| порт 4432 | :5432 (PostgreSQL) |
| порт 4306 | :3306 (MySQL) |
| порт 4379 | :6379 (Redis) |
| порт 4017 | :27017 (MongoDB) |
Маппинг нельзя изменить. Браузерный терминал всегда открывает соединение к порту 7681 устройства — ttyd должен слушать именно на этом порту.
Что такое браузерный терминал ttyd и кто может им пользоваться?¶
ttyd — open-source сервер, который отдаёт полноценный терминал (bash/sh/login) через браузер поверх WebSocket.
- Запускается на устройстве на порту 7681, слушает только
localhost. - Доступен через dix.su по URL
https://dix.su/auth/terminal/{slug}— только для залогиненного владельца аккаунта. Публично не доступен. - Поддерживает все тарифы, включая SIMPLE (SSH-порт не нужен).
- Аутентификация: стандартный системный логин/пароль устройства (через ttyd).
- На Windows ttyd может запускать
cmdили PowerShell вместо bash.
Можно ли подключиться по SSH к устройству за NAT без запущенного device_client?¶
Нет. Устройство за NAT не имеет входящих соединений — до него нельзя достучаться напрямую.
device_client устанавливает исходящее WebSocket-соединение к прокси, которое пробивает
NAT. Именно через это соединение прокси реализует TCP-relay для SSH: получает входящее
TCP-соединение на порту 2222 и пересылает байты через WebSocket к device_client, а тот
открывает TCP-соединение к localhost:22 на устройстве.
Без запущенного device_client у прокси нет канала до устройства — SSH-соединение установить невозможно.
Что можно делать на платформе¶
Для каких сервисов подходит dix.su?¶
Хорошо работает: - Личные сайты, блоги, портфолио - Медиасерверы: Jellyfin, Plex, Navidrome - Файловые хранилища: Nextcloud, Seafile - Умный дом: Home Assistant, openHAB - Git-серверы: Gitea, Forgejo - Базы данных: PostgreSQL, MySQL, Redis, MongoDB (TCP-туннель, тариф PERS) - Панели мониторинга, дашборды - Менеджеры паролей (Vaultwarden и т.п.) - Среды разработки и тестирования
Можно ли дать другому человеку доступ к моему туннелю?¶
Обычный туннель (slug.dix.su) — публично доступен, любой со ссылкой зайдёт.
Если нужно ограничить доступ — включи приватный режим: туннель требует
авторизации через dix.su-аккаунт, посторонние видят заглушку.
- На SIMPLE приватный режим доступен 14 дней пробно, дальше нужен VIP или выше — иначе туннель замораживается.
- Пригласить других пользователей dix.su: PRO — до 10, PERS — до 100.
Ограничения и совместимость¶
Подходит ли для игровых серверов (Minecraft и т.д.)?¶
Нет — и вот почему:
- Minecraft Bedrock Edition (порт 19132) использует UDP. dix.su работает поверх WebSocket → TCP; UDP не поддерживается в принципе.
- Minecraft Java Edition (порт 25565) использует plain TCP без TLS. Маршрутизация на платформе основана на TLS SNI: прокси узнаёт к какому устройству направить трафик, читая поле SNI из TLS ClientHello. Minecraft не говорит TLS → прокси не может определить назначение → соединение отклоняется.
Это архитектурное ограничение, не временный баг — для его снятия потребуется другой механизм маршрутизации (например, уникальный порт на каждого пользователя).
Что работает для игр: веб-панели управления сервером (Pterodactyl, AMP и аналоги) отлично работают через обычный HTTP-туннель.
Поддерживается ли UDP?¶
Нет. WebSocket-relay работает поверх TCP; UDP-дейтаграммы не передаются. Затронуто: игровые серверы с UDP, VoIP/SIP, STUN/TURN, QUIC, Wireguard.
Какие TCP-протоколы поддерживает туннель?¶
Семь фиксированных протоколов, требующих TLS от клиента:
| Протокол | Внешний порт | Минимальный тариф |
|---|---|---|
| SSH | 2222 | VIP |
| RDP | 3389 | PRO |
| VNC | 4900 | PRO |
| PostgreSQL | 4432 | PERS |
| MySQL | 4306 | PERS |
| Redis | 4379 | PERS |
| MongoDB | 4017 | PERS |
Для каждого нужен TLS на стороне клиента (sslmode=require, --ssl-mode=REQUIRED,
--tls --sni slug.dix.su и т.п.). Подробные команды — docs/guides/tcp-tunnel-clients.md.
Почему TCP-туннель требует SSL/TLS от клиента?¶
Все TCP-соединения приходят на один публичный IP. Чтобы понять, к какому
именно устройству нужно направить соединение, прокси читает поле SNI (Server
Name Indication) из TLS ClientHello — там содержится slug.dix.su, по которому
однозначно определяется туннель. Без TLS от клиента SNI отсутствует → маршрутизация
невозможна.
Работает ли туннель через корпоративный прокси / VPN?¶
HTTP-туннель — как правило да (WSS — это HTTPS, обычно разрешён). TCP-туннели зависят от того, открыты ли нестандартные порты (2222, 3389, 4432 и т.д.) на вашем корпоративном файрволе. Если нет — TCP-туннели недоступны.
Тарифы и оплата¶
Какие тарифы доступны?¶
| SIMPLE | VIP | PRO | PERS | |
|---|---|---|---|---|
| Цена за 30 дней | 0 ₽ | 299 ₽ | 499 ₽ | 799 ₽ |
| Публичный трафик | 10 ГБ/мес | 50 ГБ/мес | 200 ГБ/мес | без лимита |
| E2E-трафик (приватный режим) | 2 ГБ/мес | 5 ГБ/мес | 20 ГБ/мес | 100 ГБ/мес |
| HTTP-туннель, визитка, ссылки, каталог, ttyd | ✓ | ✓ | ✓ | ✓ |
| Приватный режим (+E2E) | пробно 14 дней | ✓ | ✓ | ✓ |
| SSH / SCP / SFTP (:2222) | — | ✓ | ✓ | ✓ |
| Свой домен + SSL | — | ✓ | ✓ | ✓ |
| Логи атак + email-уведомления | — | ✓ | ✓ | ✓ |
| RDP (:3389), VNC (:4900) | — | — | ✓ | ✓ |
| Аналитика посещений | — | — | ✓ | ✓ |
| Доп. слаги | — | — | до 2 | ∞ |
| Приглашённые в приватный туннель | — | — | до 10 | до 100 |
| PostgreSQL, MySQL, Redis, MongoDB | — | — | — | ✓ |
Каждый следующий тариф включает всё из предыдущих. Оплата — Т-Банк (Россия) или картой (международная, через Lemon Squeezy).
Можно ли иметь несколько туннелей (разные адреса) на одном аккаунте?¶
Да, на тарифах PRO и PERS. Это называется дополнительные слаги: вы создаёте
несколько адресов вида yourslug-git.dix.su, yourslug-dev.dix.su и т.д. —
каждый со своим токеном и независимым device_client.
Лимиты: PRO — до 2 дополнительных слагов, PERS — без ограничений.
Подробнее — docs/guides/multi-slug.
Что будет если кончится трафик?¶
Лимит публичного трафика — на SIMPLE/VIP/PRO, на PERS его нет; E2E-трафик лимитирован на всех тарифах (см. таблицу выше). При исчерпании туннель перестаёт принимать запросы до 1-го числа следующего месяца, когда квота сбрасывается. На 80% лимита приходит предупреждение на email. Можно перейти на более высокий тариф — доступ восстановится сразу с новым лимитом.
Безопасность и приватность¶
Что разрешено и что запрещено?¶
Разрешено: личные сервисы, разработка, тестирование, бизнес-инфраструктура, медиа, умный дом, хранилища данных — полный список в Политике допустимого использования.
Запрещено (удаление без предупреждения): - Материалы сексуального насилия над несовершеннолетними - Контент террористических и экстремистских организаций - Продажа наркотиков, оружия, поддельных документов - Фишинг, мошеннические схемы - Распространение вирусов, C2-серверы - DDoS-атаки, сканирование чужих сетей
Жалобы: abuse@dix.su (критические нарушения — реакция в течение 24 часов, прочие — в течение 72 часов).
Что такое E2E-режим и чем он отличается от обычного туннеля?¶
В обычном туннеле TLS терминируется на прокси-сервере dix.su: сервер видит расшифрованный трафик. В E2E-режиме (часть приватного режима, любой тариф; на SIMPLE — в пробный период) сертификат Let's Encrypt выдаётся непосредственно на устройство: TLS-handshake происходит между браузером клиента и вашим устройством напрямую, прокси передаёт зашифрованные байты вслепую. Приватный ключ никогда не покидает устройство.
Логирует ли платформа содержимое трафика?¶
Платформа логирует метаданные (когда, откуда, сколько байт) для целей биллинга и защиты от злоупотреблений. Содержимое HTTP-трафика через прокси технически расшифровывается при TLS-терминации, но не сохраняется. Для полной конфиденциальности используйте E2E-режим.
Не нашли ответ?¶
Напишите на support@dix.su или в Telegram-чат поддержки.