Вопросы и ответы

Что такое dix.su?

dix.su — платформа с набором инструментов для работы в интернете без сервера с белым IP:

Прокси-туннель — публикует локальный сервис по адресу slug.dix.su
Личная визитка — страница-визитка с вашими ссылками и соцсетями
Короткие ссылки — с доказанным авторством и статистикой
Отзовик — отзывы от верифицированных пользователей
Каталог — публичный каталог сервисов пользователей

Все базовые функции бесплатны. Платные тарифы открывают прямые TCP-подключения (SSH, RDP, базы данных), аналитику и приватный E2E-режим.

→ Документация платформы

Это бесплатно?

Да. Тариф SIMPLE бесплатен без ограничения по времени: HTTP-туннель, 10 ГБ/мес, визитка, короткие ссылки, каталог и 14-дневный пробный период приватного режима.

Платные тарифы (VIP/PRO/PERS) добавляют больше трафика, прямые TCP-подключения (SSH, RDP, VNC, базы данных), аналитику посещений и полноценный приватный E2E-режим.

У меня нет белого IP / я за CGNAT — поможет ли dix.su?

Именно для этого платформа и создана. CGNAT (carrier-grade NAT) — когда провайдер раздаёт один публичный IP на сотни клиентов — полностью блокирует входящие соединения извне.

device_client устанавливает исходящее зашифрованное WebSocket-соединение к прокси-серверу, через которое и проходит весь трафик. Белый IP, проброс портов, изменение настроек роутера — ничего этого не нужно.

Нужны ли технические знания?

Для HTTP-туннеля (сайт, веб-приложение, API) — минимальные: скачать бинарник, запустить одной командой в терминале. Для TCP-туннелей (SSH, базы данных) — базовые знания командной строки.

Если устанавливать ничего не хочется — возьмите готовое устройство из магазина: включаете в розетку, туннель поднимается автоматически без вашего участия.

Мои данные в безопасности?

Трафик всегда зашифрован между браузером посетителя и нашим прокси (TLS). В стандартном режиме TLS терминируется на прокси — сервер технически может видеть расшифрованный трафик, но не сохраняет его содержимое.

Для полной конфиденциальности в приватном режиме доступен E2E (любой тариф; на SIMPLE — в рамках 14-дневного пробного периода): сертификат Let's Encrypt выдаётся напрямую на ваше устройство, прокси передаёт зашифрованные байты не расшифровывая. Приватный ключ никогда не покидает ваше устройство.

На каком устройстве работает device_client?

Поддерживаются: Linux (x86_64, ARM64 — включая Raspberry Pi), macOS (Apple Silicon и Intel), Windows (x86_64). Бинарник самодостаточен — встроен Erlang-рантайм, ничего дополнительно устанавливать не нужно.

Готовые устройства из магазина поставляются с уже настроенным и автозапускающимся клиентом.

Что будет, если устройство выключится или потеряет интернет?

Туннель немедленно становится недоступен — посетители видят страницу «устройство офлайн» с вашими контактами.

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

Как настроить автозапуск туннеля при старте системы?

Через systemd (Linux): создайте файл /etc/systemd/system/dixsu.service:

[Unit]
Description=dix.su tunnel
After=network-online.target

[Service]
ExecStart=/usr/local/bin/device_client ваш-слаг ваш-токен 8080
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Затем: systemctl enable --now dixsu

Через Docker Compose: добавьте restart: unless-stopped в service-блок device_client.

→ Подробнее в документации

Можно ли запустить через 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. Бесплатно, без триала.

Если ваш сервис слушает только 127.0.0.1 внутри Docker — device_client не сможет к нему подключиться. В docker-compose.yml используйте ports: ["127.0.0.1:8080:8080"], а в команде device_client указывайте хост контейнера сервиса, а не localhost.

Можно ли использовать свой домен вместо slug.dix.su?

Да, начиная с тарифа VIP. Платформа автоматически выпускает TLS-сертификат через Let's Encrypt. Алгоритм подключения:

В DNS своего домена добавьте CNAME на ваш-слаг.dix.su и TXT для верификации владения
В личном кабинете (раздел «Туннель → Свой домен») введите домен и нажмите «Подключить»
После проверки DNS и атрибуции сертификат будет выдан автоматически (обычно 1–5 минут)
Посетители сразу видят ваш домен и «зелёный замок»

Поддерживаются APEX-домены (example.com) и субдомены (shop.example.com).

→ Полное руководство по настройке своего домена

Какие DNS-записи нужно добавить у регистратора?

Нужны две записи:

Тип	Хост	Значение
`CNAME`	`@` (или пустой)	`ваш-слаг.dix.su`
`TXT`	`_dixsu`	`dixsu-verify=<токен из кабинета>`

Нюанс хоста TXT: большинство регистраторов (Namecheap, GoDaddy, reg.ru) принимают относительный хост — введите просто _dixsu и регистратор автоматически добавит домен. Cloudflare и некоторые другие требуют полное имя: _dixsu.mysite.com. Если ввести FQDN у обычного регистратора, получится _dixsu.mysite.com.mysite.com — это ошибка, запись не пройдёт верификацию.

DNS-изменения распространяются от 5 минут до 48 часов (обычно 5–30 минут).

→ Шаг 2: DNS-записи — подробнее в документации

Что такое «атрибуция» и зачем нужна ссылка на dix.su?

Перед выдачей SSL-сертификата платформа автоматически проверяет, что ваш сайт содержит ссылку на https://dix.su или https://www.dix.su в HTML. Это небольшое требование атрибуции за использование бесплатного туннеля.

Проверка происходит через стандартный адрес ваш-слаг.dix.su, а не через ваш домен — SSL-сертификат для кастомного домена ещё не выдан на этом этапе.

Если атрибуция уже есть на вашем сайте — этот шаг пройдёт автоматически без каких-либо действий с вашей стороны.

Сколько кастомных доменов и как часто их можно менять?

Каждый аккаунт может подключить один кастомный домен. Ограничения на смену:

Ограничение	Значение
Смен домена в месяц	не более 2
Пауза между сменами	14 дней
Отключить/включить тот же домен	без ограничений

Ограничения защищают от злоупотреблений с выпуском сертификатов Let's Encrypt, у которого есть суточные лимиты по доменам.

Верификация прошла, но сайт не открывается по своему домену — что делать?

Проверьте по шагам:

CNAME ещё не распространился — проверьте командой dig CNAME mysite.com +short. Должен вернуть ваш-слаг.dix.su. Если пустой — подождите.
SSL-сертификат ещё выдаётся — агент обрабатывает очередь раз в 60 секунд. Зайдите в личный кабинет: статус домена должен показать «активен». Если «pending» — немного подождите.
Устройство офлайн — убедитесь, что device_client запущен и туннель активен по адресу ваш-слаг.dix.su.
Ошибка сертификата в браузере — попробуйте в режиме инкогнито или очистите кеш SSL. Иногда браузер кешует старый (самоподписанный) сертификат.

Если статус в кабинете «активен», но домен не открывается более 10 минут — напишите нам, приложив результат dig CNAME mysite.com и dig TXT _dixsu.mysite.com.

→ Раздел диагностики в документации

Как подключиться к устройству по SSH через туннель?

SSH-туннель доступен с тарифа VIP. Особенность: SNI-маршрутизация требует, чтобы slug был передан до начала SSH-переговоров. Команда подключения через nc:

ssh -o ProxyCommand='{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222' пользователь@localhost

Для удобства добавьте в ~/.ssh/config:

Host мой-сервер
    HostName localhost
    User ubuntu
    Port 2222
    ProxyCommand { echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222

После этого достаточно писать ssh мой-сервер. Также работают SCP, SFTP и проброс портов через SSH (-L, -R).

→ Полное руководство по TCP-подключениям

Как подключиться по SSH с Windows?

На Windows 10 и 11 встроен OpenSSH — отдельно ничего устанавливать не нужно. Конфиг хранится в %USERPROFILE%\.ssh\config (например C:\Users\Иван\.ssh\config).

Проблема: команда nc на Windows по умолчанию не установлена. Для ProxyCommand нужен один из вариантов:

Вариант 1 — WSL (рекомендуется): если установлен WSL 2 с Ubuntu, ProxyCommand работает через него:

# %USERPROFILE%\.ssh\config
Host ваш-слаг.dix.su
    Port 2222
    ProxyCommand wsl.exe bash -c "{ echo DIXSU:%h | sed 's/.dix.su//'; cat; } | nc %h %p"

Либо упрощённо — прописав слаг явно:

Host ваш-слаг.dix.su
    Port 2222
    ProxyCommand wsl.exe bash -c "{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222"

Вариант 2 — Git for Windows: Git Bash включает bash.exe и nc. В config укажите путь явно:

Host ваш-слаг.dix.su
    Port 2222
    ProxyCommand "C:/Program Files/Git/usr/bin/bash.exe" -c "{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222"

Вариант 3 — PuTTY: в настройках соединения → Connection → Proxy → Proxy type: Local, Proxy hostname и port оставить пустыми, в поле «Telnet command / Local proxy command» ввести:

cmd /c "echo DIXSU:ваш-слаг & type - | nc ваш-слаг.dix.su 2222"

После настройки конфига ssh user@ваш-слаг.dix.su работает из PowerShell, Windows Terminal и Git Bash одинаково.

Как передавать файлы через SFTP (FileZilla, WinSCP, командная строка)?

SFTP — подсистема SSH, работает через тот же туннельный порт 2222. Тариф VIP+.

Командная строка (Linux / macOS / Windows с WSL):

sftp -P 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'" \
  user@ваш-слаг.dix.su

Если в ~/.ssh/config уже прописан блок Host ваш-слаг.dix.su — достаточно просто sftp user@ваш-слаг.dix.su.

FileZilla (Linux / macOS / Windows):

Протокол: SFTP
Сервер: ваш-слаг.dix.su
Порт: 2222
Аутентификация: пароль или ключ (через Edit → Settings → Connection → SFTP укажите ключ)

FileZilla не поддерживает ProxyCommand напрямую. Если хост не подключается — убедитесь, что в ~/.ssh/config прописан блок Host ваш-слаг.dix.su с ProxyCommand, и FileZilla использует Native OpenSSH (Edit → Settings → Connection → SFTP → Use external ssh-agent).

WinSCP (Windows):

Протокол: SFTP
Хост: ваш-слаг.dix.su, Порт: 2222
Advanced → Connection → Proxy → Proxy type: Local
Proxy command: wsl.exe bash -c "{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222"

Krusader / Dolphin (Linux KDE): добавьте блок в ~/.ssh/config (см. вопрос про SSH), затем в адресной строке Krusader введите sftp://user@ваш-слаг.dix.su/.

Как смонтировать файловую систему устройства как локальную папку?

Технология называется SSHFS: монтирует папки с удалённого устройства через SSH-туннель как обычный диск или директорию. Тариф VIP+, отдельных портов не нужно.

Linux (Debian / Ubuntu / Raspberry Pi OS):

sudo apt install sshfs
mkdir -p ~/mnt/dixsu
sshfs user@ваш-слаг.dix.su:/home/user ~/mnt/dixsu \
  -p 2222 \
  -o ProxyCommand="bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'" \
  -o reconnect,ServerAliveInterval=15

# Размонтировать:
fusermount -u ~/mnt/dixsu

macOS:

# Требуется macFUSE + sshfs через Homebrew:
brew install --cask macfuse
brew install sshfs

sshfs user@ваш-слаг.dix.su:/home/user ~/mnt/dixsu \
  -p 2222 \
  -o ProxyCommand="bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'"

# Размонтировать:
umount ~/mnt/dixsu

Windows — SSHFS-Win (WinFsp):

Установите WinFsp и SSHFS-Win
В проводнике: ПКМ «Этот компьютер» → «Подключить сетевой диск»
Папка: \\sshfs.r\user@ваш-слаг.dix.su!2222

Или командной строкой:

net use X: \\sshfs.r\user@ваш-слаг.dix.su!2222

SSHFS-Win на Windows использует системный OpenSSH и читает %USERPROFILE%\.ssh\config — если там прописан ProxyCommand для вашего хоста, монтирование пройдёт без дополнительных параметров.

Можно ли получить доступ к файлам устройства с Android?

Да, без root — есть родное Android-приложение с dix.su-туннелем внутри, Termux и ручная настройка SSH не нужны. Подробности и пошаговая настройка — в разделе «Android-приложения» ниже.

Для доступа к файлам не нужен тариф PERS или E2E-режим. SSH шифрует трафик самостоятельно: прокси-сервер выступает слепым TCP-ретранслятором и физически не может видеть содержимое файлов или команд — у него нет SSH-ключа устройства. Достаточно тарифа VIP.

Можно ли подключиться к Samba / сетевой папке через туннель?

Прямого TCP-порта для SMB нет — протокол не несёт TLS-заголовка, по которому прокси определяет устройство. Но SMB отлично работает через SSH-туннель с проброской порта (-L). Тариф VIP+.

Шаг 1 — создать туннель (держать открытым в отдельном терминале):

ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'" \
  -L 127.0.0.1:1445:127.0.0.1:445 -N user@ваш-слаг.dix.su

После этого SMB устройства доступен локально на localhost:1445.

Linux — монтирование:

sudo apt install cifs-utils
mkdir -p ~/mnt/smb
sudo mount -t cifs //127.0.0.1/share ~/mnt/smb \
  -o port=1445,username=samba-user,password=samba-pass

# Отмонтировать:
sudo umount ~/mnt/smb

Или через браузер файлов без монтирования:

smbclient //127.0.0.1/share -p 1445 -U samba-user

macOS — Finder: Перейти → Подключиться к серверу → smb://127.0.0.1:1445/share. Ввести логин/пароль Samba.

Windows — через WSL:

# SSH-туннель в WSL (шаг 1), затем монтирование:
sudo mkdir -p /mnt/smb
sudo mount -t cifs //127.0.0.1/share /mnt/smb \
  -o port=1445,username=samba-user,password=samba-pass,vers=3.0

Windows не поддерживает нестандартный порт SMB в стандартном UNC-пути \\server\share — клиент всегда использует порт 445. Монтирование через WSL обходит это ограничение: файлы видны в Проводнике по адресу \\wsl$\Ubuntu\mnt\smb.

Как и SFTP/SSHFS, трафик Samba полностью скрыт от прокси-сервера — SSH шифрует его end-to-end. Тариф PERS не нужен.

Как подключиться к удалённому рабочему столу по RDP?

RDP работает через прямой TCP-порт 3389 с TLS-маршрутизацией по SNI — тариф PRO+. ProxyCommand не нужен: клиент подключается напрямую к ваш-слаг.dix.su:3389.

На устройстве: стандартный xrdp (Linux) или включённый Remote Desktop (Windows) без дополнительной настройки TLS — прокси берёт шифрование на себя.

Windows (встроенный mstsc):

# Выполните в строке запуска (Win+R) или в PowerShell:
mstsc /v:ваш-слаг.dix.su:3389

Или: «Подключение к удалённому рабочему столу» → Компьютер: ваш-слаг.dix.su:3389.

Linux (Remmina): Протокол RDP, сервер ваш-слаг.dix.su, порт 3389, безопасность TLS или Negotiate. При первом подключении примите самоподписанный сертификат xrdp.

macOS (Microsoft Remote Desktop): «Add PC» → PC name: ваш-слаг.dix.su:3389.

Через SSH-туннель (если нет PRO, но есть VIP):

# Шаг 1 — в отдельном терминале (держать открытым):
ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'" \
  -L 13389:localhost:3389 -N user@ваш-слаг.dix.su

# Шаг 2 — в другом терминале / другой программе:
mstsc /v:localhost:13389           # Windows
xfreerdp /v:localhost:13389 /u:user  # Linux

Как подключиться к удалённому рабочему столу через VNC?

VNC работает через порт 4900 — тариф PRO+. В отличие от RDP, здесь TLS на устройстве обязателен: запустите x11vnc с флагом --ssl.

# На устройстве — генерируем ключ и запускаем с SSL:
mkdir -p ~/.vnc/ssl
openssl req -new -x509 -days 365 -nodes \
  -out ~/.vnc/ssl/vnc.crt -keyout ~/.vnc/ssl/vnc.key -subj "/CN=vnc-tunnel"
x11vnc -display :0 -forever -nopw \
  -ssl ~/.vnc/ssl/vnc.key,~/.vnc/ssl/vnc.crt -rfbport 5900

Linux (TigerVNC / vncviewer):

vncviewer ваш-слаг.dix.su:4900

Linux (Remmina): протокол VNC, сервер ваш-слаг.dix.su, порт 4900, включить SSL/TLS.

Windows: RealVNC Viewer, TigerVNC Viewer или UltraVNC — сервер ваш-слаг.dix.su::4900 (двойное двоеточие для нестандартного порта), включить шифрование.

macOS: Finder → Перейти → Подключиться к серверу → vnc://ваш-слаг.dix.su:4900, или приложение RealVNC Viewer.

Альтернатива через SSH-туннель (без x11vnc --ssl, тариф VIP):

# Шаг 1 — в отдельном терминале:
ssh -p 2222 \
  -o "ProxyCommand=bash -c '{ echo DIXSU:ваш-слаг; cat; } | nc ваш-слаг.dix.su 2222'" \
  -L 15900:localhost:5900 -N user@ваш-слаг.dix.su

# Шаг 2 — подключаем VNC-клиент к локальному порту:
vncviewer localhost:15900   # Linux
# Windows / macOS: укажите адрес localhost:15900 в любом VNC-клиенте

Почему для VNC нужен TLS на устройстве, а для RDP — нет?

Прокси маршрутизирует соединения по SNI в первом пакете TLS. Для этого TLS должен инициироваться клиентом до того, как начнётся протокол прикладного уровня.

RDP сам добавляет CredSSP/TLS поверх своего первого пакета, то есть TLS-рукопожатие с SNI происходит автоматически.

VNC (протокол RFB) начинается с серверного приветствия без TLS. Прокси получает первые байты и не видит SNI → не может маршрутизировать. Решение: запустить x11vnc с флагом --ssl, тогда TLS инициируется сервером при первом байте соединения и SNI приходит к прокси корректно.

→ Настройка VNC с TLS

Что такое браузерный терминал и как он защищён?

Браузерный терминал — это ttyd, лёгкий HTTP/WebSocket-сервис, открывающий терминал устройства прямо в браузере. Работает на любом тарифе, включая SIMPLE — SSH-порт открывать не нужно.

Доступен по адресу https://dix.su/auth/terminal/ваш-слаг — только для авторизованных пользователей dix.su с доступом к этому слагу.

Почему терминал сразу открывается без пароля?
По умолчанию ttyd запускается от пользователя root и открывает шелл напрямую (/bin/sh или bash), не вызывая login. Авторизация происходит на уровне dix.su — посторонние не смогут открыть ваш терминал. Если root не имеет пароля (типично для Alpine Linux), то даже с login запроса пароля не будет.

Как добавить дополнительный пароль (необязательно):

Вариант А — установить пароль root на устройстве:

passwd root

И запустить ttyd с командой login вместо шелла:

ttyd --port 7681 --writable login

Вариант Б — HTTP Basic Auth встроенный в ttyd (отдельный пароль только для терминала):

ttyd --port 7681 --credential пользователь:пароль --writable login

Для браузерного терминала нужен отдельный слаг с LOCAL_PORT=7681 — ttyd должен слушать на порту 7681. Совместить с основным веб-сервисом (порт 80) на одном слаге не получится.

Рекомендация по безопасности: держите mgmt-туннель замороженным в обычное время и размораживайте только когда нужен терминал. Даже при защите на уровне dix.su открытый терминал — это постоянно доступный шелл устройства. Разморозить можно за секунду прямо в личном кабинете → «Мои туннели».

→ Настройка браузерного терминала (mgmt-туннель)

Как запустить device_client на Windows и не потерять туннель после перезагрузки?

На Windows клиент запускается через PowerShell. Главная особенность: если имя пользователя Windows содержит кириллицу (например «Александр»), клиент упадёт сразу — Erlang-рантайм внутри бинарника не может работать с такими путями.

Обязательно перед запуском:

Создать папку C:\dixsu\ — путь без кириллицы
Скачать бинарник в неё: https://dix.su/downloads/device_client_windows_x86_64
Задать переменную окружения DEVICE_CLIENT_INSTALL_DIR:

$env:DEVICE_CLIENT_INSTALL_DIR="C:\dixsu\install"
$env:SERVER_HOST="proxy.dix.su"; $env:SERVER_PORT="443"
C:\dixsu\device_client_windows_x86_64.exe мой-слаг мой-токен 8080

Почему DEVICE_CLIENT_INSTALL_DIR?
Клиент упакован через Burrito и при первом запуске распаковывает Erlang-рантайм в %LOCALAPPDATA%\.burrito\. Если %LOCALAPPDATA% содержит кириллицу (путь C:\Users\Александр\...) — распаковка завершается ошибкой «Failed to open arguments file». Переменная перенаправляет кэш в C:\dixsu\install\ — ASCII-путь, гарантированно без проблем.

Автозапуск после перезагрузки — два способа:

Вариант А — Планировщик задач (запускается после входа пользователя):

# Создать скрипт C:\dixsu\start-tunnel.ps1
$env:DEVICE_CLIENT_INSTALL_DIR="C:\dixsu\install"
$env:SERVER_HOST="proxy.dix.su"; $env:SERVER_PORT="443"
C:\dixsu\device_client_windows_x86_64.exe мой-слаг мой-токен 8080

# Зарегистрировать задачу (PowerShell от администратора)
$action = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument "-NonInteractive -File C:\dixsu\start-tunnel.ps1" `
  -WorkingDirectory "C:\dixsu"
$trigger = New-ScheduledTaskTrigger -AtLogOn
$trigger.Delay = "PT1M"
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit 0 `
  -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
Register-ScheduledTask -TaskName "dixsu-tunnel" `
  -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest -Force

Вариант Б — NSSM (настоящий Windows-сервис, запускается до входа пользователя):

winget install nssm
nssm install dixsu-tunnel "C:\dixsu\device_client_windows_x86_64.exe" "мой-слаг мой-токен 8080"
nssm set dixsu-tunnel AppEnvironmentExtra "DEVICE_CLIENT_INSTALL_DIR=C:\dixsu\install" "SERVER_HOST=proxy.dix.su" "SERVER_PORT=443"
nssm set dixsu-tunnel AppRestartDelay 5000
nssm set dixsu-tunnel Start SERVICE_AUTO_START
nssm start dixsu-tunnel

NSSM предпочтительнее для серверного сценария (ПК без монитора, автовход не нужен). Планировщик задач проще и достаточен для рабочей станции.

→ Подробный гайд: Windows как устройство dix.su

Как установить браузерный терминал (ttyd) на Windows?

ttyd — веб-терминал, открывает cmd.exe или PowerShell в браузере на порту 7681. Через mgmt-туннель dix.su это даёт удалённый доступ к Windows-машине без SSH-клиента.

Установка:

winget install tsl0922.ttyd

Winget устанавливает бинарник в профиль пользователя. Из-за возможной кириллицы в пути — скопировать в C:\dixsu\:

Copy-Item (where.exe ttyd) C:\dixsu\ttyd.exe

Запустить вручную для проверки:

C:\dixsu\ttyd.exe --port 7681 --writable cmd

Затем открыть http://localhost:7681 — должна появиться командная строка.

Автозапуск через NSSM:

nssm install ttyd "C:\dixsu\ttyd.exe" "--port 7681 --writable cmd"
nssm set ttyd Start SERVICE_AUTO_START
nssm start ttyd

Типичная ошибка при установке: Unexpected status SERVICE_STOPPED — значит NSSM не смог запустить процесс. Проверьте путь к бинарнику:

nssm edit ttyd   # откроет GUI с настройками сервиса

Что видит пользователь в браузере: терминал открывается без пароля — авторизация происходит на уровне dix.su, посторонние не видят ваш терминал. Чтобы добавить пароль на сам терминал:

nssm set ttyd Application "C:\dixsu\ttyd.exe"
nssm set ttyd AppParameters "--port 7681 --credential user:password --writable cmd"

Рекомендация по безопасности: держите mgmt-туннель замороженным в обычное время и размораживайте только когда нужен терминал.

Как настроить автоматический вход в Windows (Autologon)?

Docker Desktop стартует только после входа пользователя. Если Windows используется как сервер (без монитора, headless), нужен автовход — иначе после перезагрузки Docker и контейнеры не поднимутся, пока кто-то физически не залогинится.

Настройка через Sysinternals Autologon (пароль хранится зашифрованным в реестре):

Invoke-WebRequest https://live.sysinternals.com/Autologon.exe -OutFile C:\dixsu\Autologon.exe
C:\dixsu\Autologon.exe

В открывшемся окне: введи имя пользователя и пароль → Enable → OK.

NSSM-сервисы (dixsu-tunnel, ttyd) поднимаются до входа пользователя — они работают даже без Autologon. Autologon нужен только для Docker Desktop и контейнеров.

Что поднимается автоматически после перезагрузки Windows?

Компонент	Когда	Условие
NSSM-сервисы (`dixsu-tunnel`, `ttyd`)	До входа пользователя	`SERVICE_AUTO_START`
Docker Desktop	После входа пользователя	«Start when you sign in» + Autologon
Docker-контейнеры (`restart: unless-stopped`)	Вместе с Docker Desktop	Autologon

Типичная проблема: nginx или другой контейнер в состоянии Exited (127) после перезагрузки. Причина — Docker Desktop не успел инициализировать bind-mount файла при старте контейнера. Признак: в docker inspect <контейнер> ошибка mount ... not a directory. Решение: монтировать директорию вместо отдельного файла в docker-compose.yml:

# Неправильно (bind-mount файла — нестабильно при старте):
- ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro

# Правильно (bind-mount директории):
- ./nginx:/etc/nginx/conf.d:ro

Если контейнер уже завис в Exited — поднять вручную:

docker compose up -d

Вторая типичная проблема: все контейнеры в состоянии running, но сайт не отвечает — nginx работает с дефолтным конфигом (без проксирования). Причина — Docker Desktop иногда монтирует директорию ./nginx/ пустой при рестарте контейнера. Диагностика:

docker exec <nginx-container> ls /etc/nginx/conf.d/
# если пусто — это оно

Решение — принудительно пересоздать nginx:

docker compose up -d --force-recreate nginx

Для автоматического исправления при каждой перезагрузке — добавить в crontab WSL (crontab -e):

@reboot /home/<user>/django_shop/scripts/fix-nginx-mount.sh >> /tmp/fix-nginx.log 2>&1

В ttyd на Windows: как получить PowerShell от администратора и войти в WSL?

ttyd, запущенный через NSSM, работает от учётной записи SYSTEM — уровень выше обычного администратора, UAC не нужен.

PowerShell от администратора — в открывшемся cmd.exe просто набери:

powershell

Получишь PowerShell с полными правами SYSTEM.

Консоль WSL/Ubuntu:

wsl -d Ubuntu

WSL 2 привязан к пользовательской сессии — команда wsl работает только если пользователь залогинен в Windows. Если настроен Autologon — wsl в ttyd работает нормально. Без Autologon — только после ручного входа.

Что такое заморозка туннеля и как ею пользоваться?

Заморозка — это способ временно закрыть доступ к туннелю извне, не останавливая device_client на устройстве. Прокси-сервер перестаёт пропускать входящие запросы к слагу и отдаёт страницу «туннель заморожен» вместо вашего сервиса.

Что происходит на каждом уровне:

Для посетителей — они видят страницу 503 «туннель заморожен», ваш сервис недоступен
Для device_client — ничего не меняется: клиент продолжает работать, WebSocket-соединение с прокси остаётся активным
Уже открытые соединения — не разрываются мгновенно, только новые запросы блокируются
Размораживание — мгновенное, доступ восстанавливается сразу после нажатия кнопки

Как управлять заморозкой:
Личный кабинет → вкладка «Мои туннели» → кнопка «❄ Заморозить» или «▶ Открыть» рядом с нужным слагом.

Когда это полезно:

Временно скрыть сервис на техническое обслуживание
Закрыть доступ к mgmt-туннелю (браузерный терминал) когда он не нужен
Быстро отключить туннель при подозрительной активности — без остановки клиента

Основной слаг: состояние заморозки хранится в базе данных и переживает перезапуск платформы.
Дополнительные слаги (secondary): состояние хранится только в памяти прокси и сбрасывается при перезапуске контейнера — после рестарта слаг будет разморожен.

Заморозка администратором — это отдельный механизм. Администратор платформы может заморозить ваш туннель независимо от вас (например при нарушении правил). В этом случае кнопка «▶ Открыть» в личном кабинете недоступна и разморозить самостоятельно нельзя — только через обращение на admin@dix.su. Причина будет указана в письме или в личном кабинете.

Можно ли дать кому-то доступ к моему туннелю?

Обычный туннель (slug.dix.su) публично доступен — просто поделитесь ссылкой.

Если нужно ограничить доступ для определённых людей — включите приватный режим: туннель потребует входа через аккаунт dix.su, посторонние увидят заглушку. Пригласить других пользователей можно на тарифе PRO (до 10 человек) и PERS (до 100).

Тариф SIMPLE включает 14-дневный пробный период приватного режима — можно попробовать бесплатно. После него для приватного режима нужен тариф VIP или выше, иначе туннель замораживается.

Что означает ошибка «no tunnel connected» и что с ней делать?

Прокси получил соединение, но device_client с вашим слагом сейчас не подключён. Чек-лист:

Запущен ли device_client на устройстве? Проверьте через ps aux | grep device_client
Правильный ли слаг и токен указаны в команде запуска?
Есть ли у вашего устройства выход в интернет?
Для TCP-протоколов: включён ли нужный порт в личном кабинете (раздел «Прямые подключения»)?
Соответствует ли тариф запрашиваемому протоколу?

После нескольких неудачных попыток подключения прокси вводит временный rate-limit (~60 секунд). Дождитесь, затем повторите — не зацикливайтесь в мгновенных ретраях.

Работает ли туннель через корпоративный прокси или VPN?

HTTP-туннель — как правило да. Соединение клиента к серверу идёт по WSS (WebSocket Secure) — это HTTPS-трафик на 443 порту, который разрешён в подавляющем большинстве корпоративных сетей.

TCP-туннели (SSH, RDP, базы данных) используют нестандартные порты (2222, 3389, 4432 и т.д.). Если они заблокированы корпоративным файрволом — TCP-туннели будут недоступны.

Может ли администратор отключить мой туннель? Что при этом происходит?

Да. При нарушении Правил использования администратор может заморозить туннель.

Заморозка работает так: прокси-сервер перестаёт пускать посетителей на ваш slug — вместо содержимого они видят страницу «туннель заморожен». Ваше устройство при этом остаётся подключённым, но трафик через него не проходит. Разморозить самостоятельно нельзя — нужно обратиться в поддержку на admin@dix.su.

Состояние заморозки сохраняется при перезапуске серверов — это не временный кэш, а запись в базе данных.

→ Как устроено управление туннелями изнутри

Что такое личная визитка на dix.su?

Личная визитка — публичная страница вашего профиля по адресу dix.su/p/ваш-слаг. Аналог Linktree, но на домене dix.su, бесплатно и с верификацией личности.

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

Доступна бесплатно для всех пользователей. Редактирование — прямо на странице, без перезагрузок.

Какие социальные сети можно добавить на визитку?

На визитке можно разместить иконки: Telegram, GitHub, VK, Instagram, YouTube, LinkedIn, WhatsApp и другие. Добавляются в один клик из настроек профиля.

Помимо иконок соцсетей можно добавить произвольное количество кнопок-ссылок с любым текстом — на любые URL. Порядок кнопок настраивается перетаскиванием.

Как узнать, сколько раз кликали на мои ссылки на визитке?

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

Чем короткие ссылки dix.su отличаются от bit.ly и аналогов?

Главное отличие — доказанное авторство. Каждая ссылка вида dix.su/abc1234 привязана к конкретному аккаунту dix.su. Любой человек может проверить кто создал ссылку через link.dix.su.

Это решает проблему доверия: получая ссылку, вы можете убедиться, что она создана реальным человеком с верифицированным профилем, а не анонимом.

Дополнительно: ссылки бессрочные, количество неограниченно, коллизий нет (7-значный код генерируется уникальным).

Как проверить кто создал ссылку dix.su?

Перейдите на link.dix.su и вставьте ссылку. Для ссылок dix.su вы увидите: имя и аватар создателя, дату создания, количество кликов и итоговый URL назначения.

Для внешних ссылок (других сервисов сокращения) — сервис показывает полную цепочку HTTP-редиректов до финального адреса. Если ссылка анонимная — так прямо и указывается.

Есть ли лимит на количество коротких ссылок?

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

Что такое проверка ресурса на dix.su?

Сервис проверки на странице /clarity позволяет узнать кто стоит за ссылкой или туннелем до того, как вы перейдёте по ней.

Ссылки — вставьте dix.su/abc1234 или любой другой URL, чтобы узнать автора и конечный адрес
Туннели — введите адрес (eskimos.dix.su) или только слаг, чтобы узнать владельца и его уровень верификации

Принцип «Доверяй, но проверяй»: прежде чем открыть незнакомую ссылку или туннель, убедитесь, что за ним стоит реальный человек с верифицированным аккаунтом.

Что значит «верифицированный» аккаунт?

При проверке туннеля или ссылки отображается, сколько и какие социальные платформы (GitHub, VK, Telegram, Яндекс и др.) привязаны к аккаунту владельца.

Больше верифицированных платформ = выше объективный уровень доверия. Аккаунт с GitHub, VK и Telegram сложнее создать анонимно, чем аккаунт только с email.

Что такое Отзовик на dix.su?

Отзовик — платформа отзывов о любых интернет-ресурсах: туннелях dix.su, сайтах, SaaS-сервисах, интернет-магазинах, мобильных приложениях. Отзывы оставляют только верифицированные пользователи dix.su — анонимов нет.

Можно оставить оценку в звёздах, плюсы и минусы ресурса. Отзыв всегда привязан к конкретному аккаунту — вы всегда видите кто его написал и насколько этот человек верифицирован.

Почему здесь нельзя накрутить или купить отзывы?

Каждый отзыв жёстко привязан к аккаунту dix.su. Чтобы оставить отзыв, нужно зарегистрироваться и верифицировать хотя бы одну социальную платформу (GitHub, VK, Telegram и т.д.).

Создание пачки фейковых аккаунтов с реальными соцсетями технически нетривиально — у каждого аккаунта своя соцсеть, которую видно при проверке. Отзывы от аккаунтов с высоким уровнем верификации весомее.

Как оставить отзыв о ресурсе?

Создайте аккаунт dix.su и привяжите хотя бы одну социальную платформу
Перейдите в Отзовик и найдите нужный ресурс или добавьте его сами
Оставьте честный отзыв с оценкой, плюсами и минусами

Что такое каталог сервисов и зачем в него добавляться?

Каталог — публичный справочник активных туннелей dix.su, открытых для внешних посещений. Добавление в каталог бесплатно и помогает привлечь аудиторию среди пользователей платформы.

Чтобы добавить проект: в личном кабинете откройте «Туннель → Каталог» и заполните описание и категорию. В каталоге можно сортировать по рейтингу (оценки из Отзовика).

Какие сервисы можно публиковать через dix.su?

Всё, что запускается на вашем устройстве и принимает сетевые соединения:

Личные сайты, блоги, портфолио (Nginx, WordPress, Ghost, Hugo)
Медиасерверы: Jellyfin, Plex, Navidrome
Файловые хранилища: Nextcloud, Seafile
Умный дом: Home Assistant, openHAB, Zigbee2MQTT, Frigate
Git-серверы: Gitea, Forgejo
Мессенджеры: Matrix/Element, Mattermost
Мониторинг: Grafana, Uptime Kuma
Менеджеры паролей: Vaultwarden
Базы данных: PostgreSQL, MySQL, Redis, MongoDB (через TCP-туннель, PERS)
Среды разработки, CI-агенты, демо-стенды для клиентов

Полный список разрешённых сценариев — в Правилах допустимого использования.

Можно ли использовать как сервер для игр — Minecraft и похожие?

Нет — ни Minecraft Java Edition, ни Bedrock Edition не поддерживаются. Объясняем почему.

Bedrock Edition (порт 19132) использует UDP. dix.su работает поверх WebSocket → TCP; UDP-датаграммы не передаются в принципе.

Java Edition (порт 25565) использует plain TCP без TLS. Маршрутизация на платформе работает через TLS SNI: прокси узнаёт к какому устройству направить соединение, читая поле SNI из TLS ClientHello. Minecraft-клиент не говорит TLS → прокси не может определить назначение → соединение отклоняется.

Это архитектурное ограничение, не временный баг.

Что работает для игр: веб-панели управления сервером (Pterodactyl, AMP и аналоги) отлично работают через обычный HTTP-туннель.

Поддерживается ли UDP?

Нет. Relay-механизм платформы работает поверх TCP; UDP-датаграммы не передаются.

Затронуто: игровые серверы с UDP, VoIP/SIP, STUN/TURN, QUIC, WireGuard, некоторые P2P-протоколы.

Какие TCP-протоколы поддерживает туннель?

Семь протоколов с фиксированными портами:

Протокол	Порт	Мин. тариф	Примечание
SSH / SCP / SFTP	2222	VIP	Требует ProxyCommand
RDP	3389	PRO	xrdp или Windows RDP
VNC	4900	PRO	Требует x11vnc --ssl
PostgreSQL	4432	PERS	sslmode=require
MySQL / MariaDB	4306	PERS	--ssl-mode=REQUIRED
Redis	4379	PERS	--tls --sni флаги
MongoDB	4017	PERS	tls=true в строке подключения

→ Точные команды для каждого клиента

Почему при подключении к базе данных требуется SSL?

Все TCP-соединения приходят на один публичный IP-адрес. Чтобы определить, к какому конкретному устройству направить соединение, прокси читает поле SNI (Server Name Indication) из TLS ClientHello — там содержится slug.dix.su, по которому однозначно находится нужный туннель.

Без TLS от клиента SNI отсутствует → маршрутизация невозможна. Поэтому sslmode=require для PostgreSQL, --ssl-mode=REQUIRED для MySQL, --tls для Redis — это не опция, а обязательное условие работы соединения.

Что включают разные тарифы?

Тариф	Цена	Публичный трафик	E2E трафик	Дополнительно
SIMPLE	0 ₽	10 ГБ/мес	2 ГБ/мес	HTTP-туннель, визитка, ссылки, каталог, пробный приватный режим 14 дн.
VIP	299 ₽ / 30 дней	50 ГБ/мес	5 ГБ/мес	SSH / SCP / SFTP `:2222`, собственный домен + SSL, логи атак + email-уведомления
PRO	499 ₽ / 30 дней	200 ГБ/мес	20 ГБ/мес	+ RDP `:3389`, VNC `:4900`, аналитика посещений (трафик, UTM, гео), до 2 доп. слагов, до 10 приглашённых
PERS	799 ₽ / 30 дней	без лимита	100 ГБ/мес	+ PostgreSQL `:4432`, MySQL `:4306`, Redis `:4379`, MongoDB `:4017`, без ограничения доп. слагов, до 100 приглашённых

Каждый следующий тариф включает все возможности предыдущих. Оплата через Т-Банк (Россия) или международной картой.

→ Подробнее о тарифах в документации

Можно ли купить несколько тарифов одновременно?

Да — и в этом суть «умного биллинга» dix.su.

Все купленные тарифы хранятся в личном пуле. Один из них активен (работает прямо сейчас), остальные заморожены (дни не тратятся). Переключаться между ними можно мгновенно и без ограничений.

Пример: у вас есть VIP (20 дней, активен) и PRO (30 дней, заморожен). Нужны базы данных на выходные — переключились на PRO. Вернулись к VIP в понедельник — у PRO осталось 28 дней, у VIP — 20. Ничего не потеряно.

Что происходит с оплаченными днями при переключении тарифа?

Переключение мгновенное: текущий активный тариф «замораживается» (его дни перестают тратиться), а выбранный замороженный становится активным. Оплаченные дни замороженного тарифа сохраняются в точности — без округлений и потерь.

Переключиться можно в любой момент — хоть несколько раз в день.

Сколько дней спишется, если я переключусь несколько раз в день?

Максимум 1 день с каждого тарифа за сутки — независимо от количества переключений. Система запоминает дату последнего списания и повторно не списывает в тот же день.

Пример: вы 5 раз переключились между VIP и PRO за один день. Итого спишется: 1 день с VIP + 1 день с PRO = ровно 2 дня суммарно.

Что произойдёт, когда активный тариф закончится?

Система автоматически активирует следующий замороженный тариф из вашего пула без вашего участия. Вы получите email-уведомление о переключении.

Если замороженных тарифов нет — аккаунт переходит на бесплатный SIMPLE: туннель продолжает работать, но TCP-доступы и аналитика становятся недоступны до следующей оплаты.

Итог: сервис не падает в ночь истечения тарифа, если у вас есть запасные оплаченные тарифы в пуле.

Пропадают ли оплаченные дни, если туннель заморожен из-за исчерпания квоты?

Нет — пока туннель заморожен, дни ни с одного тарифа не списываются.

Если вы исчерпали месячную квоту трафика, система замораживает туннель до 1-го числа следующего месяца. В период заморозки счётчик оплаченных дней не идёт — вы не теряете то, за что заплатили.

1-го числа квота сбрасывается, туннель автоматически размораживается, и биллинг возобновляется с того дня, где остановился.

Как продлить тариф? Добавляются ли дни к оставшимся?

Да — при повторной покупке того же тарифа 30 дней прибавляются к уже имеющимся. Счётчик не сбрасывается, дни не сгорают, нет давления «не успел — потерял».

Пример: осталось 5 дней PRO. Купили ещё 30 дней PRO — теперь 35 дней. Можно продлевать заблаговременно без риска потерять дни.

Что будет, если закончится трафик?

Месячный лимит публичного трафика — 10 / 50 / 200 ГБ на SIMPLE / VIP / PRO, на PERS лимита нет (E2E-трафик лимитирован отдельно на всех тарифах). При исчерпании туннель перестаёт принимать запросы до 1-го числа следующего месяца — квота сбрасывается ежемесячно. На 80% лимита приходит предупреждение на email. Перейти на более высокий тариф можно в любой момент — доступ восстановится сразу с новым лимитом.

Что разрешено и что запрещено на платформе?

Разрешено: личные сервисы, разработка, тестирование, бизнес-инфраструктура, медиа, умный дом, файловые хранилища, системы резервного копирования — любые законные сценарии.

Запрещено (немедленное удаление аккаунта):

Материалы сексуального насилия над несовершеннолетними
Контент террористических и экстремистских организаций
Продажа наркотиков, оружия, поддельных документов
Фишинг и мошеннические схемы
Распространение вирусов и вредоносного ПО, C2-серверы
DDoS-атаки, сканирование чужих сетей без письменного разрешения

Полный текст — в Правилах допустимого использования. Жалобы: abuse@dix.su.

Чем E2E-режим отличается от обычного туннеля?

В стандартном туннеле TLS-соединение заканчивается на прокси dix.su: сервер видит расшифрованный трафик, хотя и не сохраняет его.

В режиме E2E (часть приватного режима, доступен на любом тарифе) сертификат Let's Encrypt выдаётся непосредственно на ваше устройство через механизм DNS-01. TLS-рукопожатие происходит напрямую между браузером посетителя и вашим оборудованием; прокси-сервер передаёт зашифрованные байты не расшифровывая. Приватный ключ никогда не покидает ваше устройство.

→ Модель безопасности платформы

Логирует ли платформа содержимое трафика?

Платформа собирает метаданные: время, IP-адрес, объём трафика — для биллинга и защиты от злоупотреблений. Содержимое трафика не сохраняется.

В режиме E2E содержимое технически недоступно даже нам — трафик расшифровывается только на вашем устройстве.

Что делать, если мой аккаунт или устройство скомпрометированы?

Немедленно напишите на abuse@dix.su с описанием ситуации. Администратор временно заблокирует туннель до выяснения обстоятельств.

Параллельно: остановите device_client на устройстве, смените токен доступа в личном кабинете и проверьте, не изменились ли настройки вашего сервиса.

За что могут заблокировать профиль или ссылки?

Модерация применяется при нарушении Правил допустимого использования. Возможные меры:

Блокировка туннеля — соединение через device_client прекращается. Применяется при превышении трафикового лимита, злоупотреблении пропускной способностью или нарушениях AUP.
Блокировка профиля — визитка slug.dix.su становится недоступна для всех посетителей. Применяется при размещении запрещённого контента на странице профиля.
Блокировка коротких ссылок — все ссылки вида dix.su/xxx перестают работать (возвращают 410 Gone). Применяется при распространении ссылок на вредоносные ресурсы.
Удаление аккаунта — при грубых нарушениях (фишинг, малвар, CSAM, терроризм) аккаунт удаляется немедленно без предупреждения.

Все меры, кроме удаления, обратимы: после устранения нарушения напишите на abuse@dix.su.

Как платформа проверяет короткие ссылки?

При создании каждой короткой ссылки адрес назначения автоматически проверяется через Google Safe Browsing API — ту же базу угроз, которую использует Chrome и Firefox для предупреждений о вредоносных сайтах.

Проверяются четыре категории угроз:

Malware — сайты, распространяющие вирусы и вредоносное ПО
Social Engineering (Phishing) — фишинговые страницы и мошеннические сайты
Unwanted Software — сайты с нежелательным или вводящим в заблуждение ПО
Potentially Harmful Application — приложения с вредоносным поведением

Если URL найден в базе — ссылка не создаётся, а возможность создавать новые ссылки автоматически блокируется до разбирательства. Для снятия блокировки напишите на abuse@dix.su.

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

Что видит пользователь, если мой профиль или ссылка заблокированы?

Заблокированный профиль — страница slug.dix.su показывает сообщение «Профиль недоступен» со ссылкой на AUP. Личные данные не раскрываются.
Заблокированная ссылка — при переходе по dix.su/xxx возвращается HTTP 410 Gone. Адрес назначения не раскрывается.
Замороженный туннель — визитка и другие ресурсы, которые хостятся на вашем устройстве, становятся недоступны (502 / таймаут). Профиль и ссылки при этом продолжают работать.

Могу ли я обжаловать блокировку?

Да. Напишите на abuse@dix.su, укажите:

Email аккаунта
Описание ситуации — почему вы считаете блокировку ошибочной
Если речь о конкретной ссылке — её код (dix.su/xxx)

Автоматические блокировки (Safe Browsing) рассматриваются в течение 1–2 рабочих дней. Ручные — в течение 3–5 дней.

Если блокировка подтверждена нарушением AUP, для снятия потребуется удалить нарушающий контент.

Как удалить аккаунт?

Откройте личный кабинет → вкладку «Аккаунт» и нажмите «Удалить аккаунт». Для подтверждения потребуется ввести ваш email.

После подтверждения аккаунт помечается к удалению: профиль, визитка, короткие ссылки и туннель сразу скрываются от других пользователей. Физического удаления в этот момент не происходит — у вас есть 30 дней, чтобы передумать.

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

Что происходит с данными сразу после запроса на удаление?

Немедленно скрываются:

Публичный профиль и визитка
Все короткие ссылки (dix.su/xxx)
Токен туннеля — соединение через device_client прерывается
Запись в каталоге, если была
Привязанные OAuth-аккаунты (Google, GitHub, VK и др.)

Email-уведомления отключаются автоматически. Войти в аккаунт в этот период нельзя, но восстановить его — можно.

Физическое удаление всех записей из базы данных происходит ровно через 30 дней.

Как восстановить аккаунт в течение 30 дней?

Три способа:

Из прощального письма — нажмите кнопку «Восстановить аккаунт». Откроется страница восстановления с вашим email.
Напрямую — перейдите на dix.su/account/restore, введите email и следуйте инструкции.
Через OAuth (Google, GitHub, VK и др.) — просто войдите через любую привязанную соцсеть. Аккаунт восстановится автоматически.

После восстановления все данные возвращаются в прежнем виде: профиль, ссылки, настройки туннеля. Вам придёт письмо-подтверждение. Email-уведомления включаются обратно автоматически.

Кто является оператором сервиса dix.su?

Сервис принадлежит и управляется ИП Сахно Роман Александрович (ИНН 614104707933, ОГРНИП 323237500434312). Деятельность — предоставление услуг компьютерных сетей, MCC 4816 (аналогично ngrok, Cloudflare Tunnel). Лицензия оператора связи не требуется.

По всем вопросам: admin@dix.su

→ Полные реквизиты и правовые документы

Какие документы регулируют использование сервиса?

Три документа, которые образуют единое соглашение:

Пользовательское соглашение — основной документ, права и обязанности сторон
Политика конфиденциальности — как собираются и хранятся ваши данные
Правила допустимого использования — что разрешено и что запрещено

Все три доступны на русском и английском языках. Регулирующее право — Российская Федерация (152-ФЗ, 149-ФЗ, 436-ФЗ).

Несёт ли dix.su ответственность за содержимое туннелей?

Нет. dix.su — технический посредник: платформа предоставляет сетевую инфраструктуру, но не имеет доступа к содержимому ресурсов, которые вы публикуете. Вся ответственность за контент лежит на пользователе (п. 3.2 Пользовательского соглашения).

Это аналогично позиции хостинг-провайдера или CDN — мы не контролируем и не проверяем публикуемый контент, но реагируем на обоснованные жалобы.

Какова ответственность платформы при платном тарифе?

На бесплатном тарифе SIMPLE ответственность оператора — 0 ₽: сервис предоставляется «как есть» без SLA.

На платных тарифах (VIP, PRO, PERS, GLAVA) максимальная ответственность оператора не превышает суммы, уплаченной за текущий расчётный период (30 дней).

→ Политика возвратов и лимиты ответственности

Возможен ли возврат средств?

Добровольный отказ от тарифа в середине периода — возврат не производится, доступ сохраняется до конца оплаченного срока.

Если произошёл технический сбой по вине платформы продолжительностью более 24 часов — напишите на admin@dix.su: рассмотрим пропорциональное продление тарифа.

При полном закрытии сервиса — возврат за неиспользованную часть в течение 30 дней с момента уведомления.

Как платформа обрабатывает персональные данные?

Собираем минимально необходимое: email, имя и аватар (при регистрации через соцсети), IP-адреса и метаданные туннеля. Содержимое трафика не сохраняется.

Данные хранятся на серверах в РФ. Срок хранения журналов туннеля — 30 дней с автоудалением. Данные аккаунта — до удаления профиля или 3 лет неактивности.

Удалить аккаунт и все данные: dix.su/data-deletion. Вопросы по данным: dixsu@itdid.ru.

→ Политика конфиденциальности

Соответствует ли сервис GDPR?

Для пользователей из EU/EEA реализованы базовые требования GDPR: баннер согласия на cookies, англоязычные версии всех правовых документов, право на доступ и удаление данных, уведомление по email о значимых изменениях политики.

Основной регулятор — российское законодательство (152-ФЗ). Жалобы в надзорный орган: Роскомнадзор.

Можно ли перепродавать или сдавать в аренду доступ к туннелю?

Нет. Перепродажа, субаренда и коммерческая передача доступа к инфраструктуре dix.su третьим лицам без письменного согласия Оператора запрещена (AUP §4.2).

Если вам нужна B2B-интеграция или white-label решение — напишите на admin@dix.su, обсудим условия.

На каких тарифах доступна аналитика посещений?

Аналитика доступна на тарифах PRO, PERS и GLAVA. На тарифах SIMPLE и VIP раздел аналитики закрыт — видна только квота трафика.

Если вы только перешли на PRO — данные появятся начиная с момента оплаты: за прошлые дни ретроспективы нет.

→ Техническая документация по аналитике

Что именно показывает аналитика?

В личном кабинете на вкладке «Аналитика» отображаются данные по вашему туннелю за выбранный день:

Трафик — входящий и исходящий объём в байтах, количество запросов, число уникальных посетителей
Топ страниц — какие пути (URL) вашего туннельного сайта посещались чаще всего
Источники трафика — UTM-метки (utm_source, utm_medium, utm_campaign, utm_content, utm_term, ref) и домен-реферер (откуда пришли посетители)
География — страны и города посетителей по IP-адресу

Также доступна сводка за текущий месяц — суммарный трафик без детализации по дням.

Как считаются уникальные посетители?

Уникальность определяется по отпечатку IP + User-Agent — без хранения «сырого» IP в базе данных. Отпечаток хэшируется с суточной солью: каждый новый день соль меняется, поэтому пересчитать «кто это был вчера» по базе невозможно. Такой же подход использует Plausible Analytics.

Это приблизительная метрика: люди за одним NAT (корпоративная сеть, мобильный оператор) могут считаться как один посетитель.

Учитываются ли в статистике боты и поисковые роботы?

Частично. Трафик (байты, количество запросов) считается полностью — включая ботов, поскольку они создают реальную нагрузку и влияют на расход месячной квоты. Посещения страниц, уникальные посетители и география — фильтруются: известные боты и сканеры (Googlebot, YandexBot, Facebook External Hit и подобные) в эти метрики не попадают.

Статические ресурсы (CSS, JS, картинки, шрифты) тоже не учитываются в посещениях страниц — только реальные переходы.

Как работают UTM-метки и откуда данные по источникам?

Если посетитель перешёл на ваш туннель по ссылке с UTM-параметрами — они автоматически попадут в статистику. Поддерживаемые параметры: utm_source, utm_medium, utm_campaign, utm_content, utm_term, ref.

Дополнительно фиксируется домен-реферер из заголовка Referer — это позволяет видеть органические переходы из поисковиков или соцсетей, даже без UTM-меток.

Как долго хранятся данные аналитики?

Данные за конкретный день хранятся 90 дней. После этого они удаляются автоматически. Если нужно сохранить историю дольше — воспользуйтесь экспортом в Excel.

Можно ли выгрузить данные аналитики?

Да. В разделе «Аналитика» доступна кнопка «Экспорт в Excel». Можно выбрать произвольный диапазон дат (до 365 дней назад). Файл содержит все метрики: трафик, топ страниц, UTM-параметры и географию.

Есть ли статистика самого сайта dix.su?

Нет. Аналитика посещений страниц самого dix.su (лендинг, FAQ, документация) не ведётся. Только трафик туннельных сайтов (slug.dix.su) собирается в базу данных.

Хранится ли содержимое трафика, который идёт через туннель?

Нет. Собираются только метаданные: объём трафика, IP-адрес (для уникальных посетителей — только хэш), запрошенные пути, UTM-параметры. Содержимое запросов и ответов не сохраняется.

В режиме E2E (приватный туннель) содержимое технически недоступно даже серверу — трафик расшифровывается только на вашем устройстве.

Есть ли приложение для Android?

Да — в разделе Android личного кабинета доступен CIFS Documents Provider (dix.su). Это менеджер файлов с поддержкой SFTP/SMB/FTP, доработанный для работы через dix.su-туннель нативно: не нужен Termux, отдельный SSH-клиент или ручная настройка ProxyCommand. После подключения файлы вашего устройства появляются прямо в системном пикере Android — их видят все приложения. Полная документация: dix.su/docs/guides/android-app.

Как подключиться по SFTP через dix.su на Android?

Установите APK из раздела Android в личном кабинете. После установки:

Нажмите + → выберите протокол SSH FTP (Apache Commons)
Включите переключатель «dixsu tunnel»
В появившемся поле Slug укажите ваш slug — хост и порт (ваш-slug.dix.su:2222) подставятся автоматически и заблокируются
Введите логин/пароль (или SSH-ключ) SSH-пользователя на вашем устройстве и нажмите Save

Файлы устройства станут доступны системному пикеру Android — их увидят все приложения (Фото, Видео, документы).

Как настроить автоматический бэкап фото с телефона?

Проще всего — встроенным бэкапом, без сторонних приложений: в форме SFTP-соединения есть секция «Backup», где выбирается локальная папка. Дальше либо жмёте «Sync now» вручную (надёжно, но пока открыт экран приложения), либо включаете чекбокс «Auto backup» — раз в ~15 минут (минимальный интервал, который вообще разрешает Android для фоновых задач) приложение само проверяет папку на новые файлы и грузит их, даже когда приложение закрыто.

Если нужна более тонкая настройка — двусторонняя синхронизация, фильтры по типу файла, мгновенный старт сразу по появлению файла — есть второй вариант: секция «Local SFTP proxy» в той же форме соединения. Чекбокс «Keep proxy running» поднимает локальный порт 127.0.0.1:<port>, к которому напрямую по SFTP подключается стороннее приложение синхронизации (например, FolderSync или Autosync) — с теми же логином/паролем, что и в самом соединении. Пока чекбокс включён, приложение само переподнимает прокси при каждом своём запуске, если тот успел упасть.

В обоих случаях не забудьте кнопку «Disable battery optimization» в той же форме — без неё Android может убить фоновый процесс, и синхронизация будет обрываться или срабатывать нерегулярно.

Полная пошаговая инструкция для обоих вариантов (в т.ч. настройка Account/Folderpair в FolderSync): dix.su/docs/guides/android-app.

Почему APK нужно разрешать установку вручную?

APK подписан production-ключом dix.su (не debug) — устанавливается как обычное приложение. Разрешение на установку «из неизвестных источников» Android запрашивает при первой установке любого APK не из официального стора — это не специфично для нашего приложения. Перед установкой разрешите его в настройках безопасности (Настройки → Безопасность → Установка неизвестных приложений). Публикация в RuStore и F-Droid — в процессе.

Какие письма отправляет dix.su?

Все письма делятся на два типа:

Транзакционные — отключить нельзя, они обеспечивают безопасность и работу аккаунта:

Одноразовый пароль для входа
Код подтверждения при смене email
Уведомление о привязке нового способа входа (OAuth)
Уведомление о пометке аккаунта к удалению и о восстановлении
Данные для подключения device_client
Чек НПД при оплате
Смена адреса туннеля (slug)

Уведомления — опциональные, можно отключить по категориям:

Статус туннеля — туннель стал недоступен или веб-сервер не отвечает
Подозрительная активность — атака на туннель обнаружена и заблокирована (тариф VIP+)
Лимиты трафика — использовано 80% месячной квоты или туннель заморожен
Каталог и профиль — заявка в каталог одобрена/отклонена, жалоба на профиль

Как отключить уведомления?

Есть два способа:

1. В личном кабинете → вкладка «Уведомления» — включите или выключите нужные категории переключателем и нажмите «Сохранить». Настройки применяются сразу.

2. Одним кликом из письма — каждое уведомительное письмо содержит ссылку «Отписаться от уведомлений» в нижней части. Клик мгновенно отключает соответствующую категорию без необходимости входа в аккаунт.

После отписки вы попадёте на страницу подтверждения, где также можно восстановить подписку.

С какой частотой приходят уведомления об офлайне и атаках?

Повторные уведомления об одном и том же событии отправляются не чаще одного раза в 30 минут. Это предотвращает лавинообразную рассылку при нестабильном соединении устройства.

Уведомление об использовании трафика (80%+) отправляется не чаще одного раза в сутки.

Почему я получаю письмо, хотя отписался?

Транзакционные письма (вход, смена email, безопасность аккаунта) не зависят от настроек уведомлений и отключить их нельзя — они нужны для работы аккаунта.

Если вы получаете уведомительное письмо после отписки, проверьте: отписались ли от правильной категории? На странице «Уведомления» видны текущие настройки. Если проблема сохраняется — напишите на support@dix.su.

Что такое стеки контейнеров?

Стеки контейнеров — это готовые сборки Docker Compose, которые разворачиваются на вашем устройстве и сразу выходят в интернет через dix.su-туннель. Никакого белого IP, VPN и настройки nginx не нужно — всё включено.

Доступные стеки:

🦊 dixsu-git — Git-хостинг + Docker/OCI, PyPI, Maven, npm (на базе Forgejo)
🐘 dixsu-postgres — PostgreSQL 16 с TCP-туннелем
🐬 dixsu-mysql — MySQL 8.0 с TCP-туннелем
🟥 dixsu-redis — Redis 7 с TCP-туннелем
🍃 dixsu-mongodb — MongoDB 7 с TCP-туннелем

Каждый стек генерирует готовый .env с вашим токеном и slug прямо в личном кабинете — вкладка «Мои контейнеры».

→ Руководство по dixsu-git

Как запустить стек? Что делать с .env?

Три шага:

В личном кабинете → «Мои контейнеры» → выберите стек → скопируйте или скачайте сгенерированный .env
Скачайте docker-compose.yml по ссылке рядом, положите его вместе с .env в одну папку
В этой папке выполните: docker compose up -d

Через несколько секунд сервис будет доступен по адресу https://ваш-слаг.dix.su.

В .env уже прописаны ваш DIXSU_SLUG и DIXSU_TOKEN — device_client в контейнере сам подключится к туннелю, больше ничего настраивать не нужно.

Как работать с Git-репозиториями в Forgejo?

Туннель dix.su работает поверх HTTP/WebSocket, поэтому SSH-доступ к Git не поддерживается — используйте только HTTPS.

Шаг 1 — создайте Access Token в Forgejo:
Settings → Applications → Generate New Token, scope: write:repository + read:repository.

Шаг 2 — настройте credential helper (один раз на машину):

git config --global credential.helper store

Шаг 3 — клонируйте или задайте remote:

# Клонировать
git clone https://git.dix.su/myuser/myrepo.git

# Первый раз git спросит логин и пароль:
# Username: myuser       ← логин в Forgejo
# Password: ВАШ_ТОКЕН   ← Access Token (не пароль аккаунта!)
# После этого git запомнит токен — больше не спрашивает

Первый пуш нового проекта:

git init
git add .
git commit -m "Initial commit"
git remote add origin https://git.dix.su/myuser/myrepo.git
git push -u origin main

Если remote уже был настроен на SSH — переключите на HTTPS:

git remote set-url origin https://git.dix.su/myuser/myrepo.git

Токен сохраняется в ~/.git-credentials (файл доступен только вашему пользователю). При смене токена удалите строку из этого файла или выполните git credential reject.

→ Полное руководство по Forgejo

Как пользоваться Docker-реестром (push / pull образов)?

Реестр работает сразу после запуска стека dixsu-git — дополнительной настройки не нужно.

Создайте токен в Forgejo: Settings → Applications → Generate New Token, scope: write:package + read:package. Затем:

docker login git.dix.su
# Username: ваш логин в Forgejo
# Password: токен из шага выше

docker tag myimage:latest git.dix.su/myuser/myimage:latest
docker push git.dix.su/myuser/myimage:latest
docker pull git.dix.su/myuser/myimage:latest

Репозиторий пакетов создаётся автоматически при первом push — заранее ничего заводить не нужно.

insecure-registries в daemon.json прописывать не нужно — TLS-сертификат *.dix.su валидный, HTTPS работает из коробки.

→ Полное руководство по реестрам

Как использовать Forgejo как PyPI, Maven или npm реестр?

Все реестры пакетов включены в Forgejo по умолчанию — дополнительных сервисов не нужно. Для работы нужен один Access Token (тот же, что для git и Docker).

Экосистема	Базовый URL реестра
PyPI (Python)	`https://git.dix.su/api/packages/myuser/pypi/`
Maven (Java/Kotlin)	`https://git.dix.su/api/packages/myuser/maven`
npm (Node.js)	`https://git.dix.su/api/packages/myuser/npm/`
NuGet (.NET)	`https://git.dix.su/api/packages/myuser/nuget/`
Cargo (Rust)	`https://git.dix.su/api/packages/myuser/cargo/`
Generic (файлы)	`https://git.dix.su/api/packages/myuser/generic/`

Замените git.dix.su на адрес вашего Forgejo и myuser на ваш логин.

→ Полные примеры конфигурации

Как создать первого пользователя в Forgejo?

Самый простой способ — при первом открытии https://ваш-слаг.dix.su Forgejo покажет форму первоначальной настройки. После её заполнения зарегистрируйтесь через веб-интерфейс — первый зарегистрировавшийся пользователь автоматически становится администратором.

Если регистрация через форму закрыта (DISABLE_REGISTRATION=true в .env), создайте пользователя через CLI:

docker exec -it dixsu-forgejo-1 \
  forgejo admin user create \
    --username admin \
    --password "ВашПароль" \
    --email admin@example.com \
    --admin

Имя контейнера уточните через docker ps | grep forgejo.

Стеки работают на Raspberry Pi / Android / слабом железе?

Да. Forgejo (стек dixsu-git) написан на Go и работает даже при 256 МБ RAM — это один из самых лёгких Git-серверов. Образ поддерживает amd64, arm64 и armv7.

Базы данных (PostgreSQL, MySQL, MongoDB) потребляют больше ресурсов, но комфортно работают на Raspberry Pi 4 (4 ГБ RAM).

device_client (туннельный клиент в контейнере) работает на любой архитектуре, где есть Docker.

Вопросы и ответы

Не нашли ответ?