Перейти к основному содержимому

Исходящие запросы

Вкладка Исходящие запросы окна Настройки Qubix, в группе Защита. Здесь выбирают, каким путём запросы сервера выходят в интернет: напрямую с адреса сервера, через ваш прокси SOCKS или через Tor. С прокси или Tor службы, к которым обращается сервер, видят адрес прокси или выхода Tor, а не адрес самого сервера.

Кто видит вкладку

Эта вкладка видна только администратору.

Пути наружу​

В поле Как сервер ходит в интернет три пути:

  • Напрямую, с адреса сервера — сервер выходит в интернет со своего адреса. Так сервер работает, пока администратор не выбрал другой путь.
  • Через свой прокси SOCKS — запросы идут через прокси SOCKS5, адрес которого вы вписываете.
  • Через Tor — запросы идут через сеть Tor. Tor работает на сервере в отдельном контейнере: сервер поднимает его, когда вы выбираете Tor, и снимает, когда выбираете другой путь.

Выбранным путём идут не все запросы: Facebook, Cloudflare, Namecheap, сервер лицензий и ещё несколько видов запросов ходят мимо него — полный перечень в разделе Что идёт мимо выбранного пути.

Если выбранный прокси или Tor перестал отвечать, запросы, которые идут этим путём, получают отказ: на свой адрес сервер не переходит. Как только путь ответит, запросы снова пойдут; отказанный тем временем запрос путь сам не повторяет. То, что идёт мимо пути, всё это время работает как обычно.

Как перейти на свой прокси​

  1. Откройте Настройки Qubix → Исходящие запросы.
  2. В поле Как сервер ходит в интернет выберите Через свой прокси SOCKS. Появится поле Адрес прокси SOCKS.
  3. Впишите адрес прокси: socks5://host:port или socks5://login:password@host:port, если прокси просит вход. Схема socks5h:// тоже принимается, а адрес без схемы читается как socks5://.
  4. Нажмите Сохранить. Перед сохранением сервер отправляет через прокси запрос и узнаёт, какой адрес виден снаружи. Если адрес — не адрес SOCKS5 или прокси не ответил, ничего не сохраняется, а причина видна рядом с кнопкой: неотвечающий прокси остановил бы все запросы, которые идут этим путём.

Под описанием поля показан сохранённый прокси — его адрес и порт, а если у него есть вход, слова «с входом»; сами логин и пароль не показываются. Сохранённый адрес остаётся, когда вы переходите на другой путь. Чтобы вернуться к нему, снова выберите Через свой прокси SOCKS и сохраните, оставив поле пустым: сервер проверит сохранённый прокси и возьмёт его. Новый адрес вписывайте, только чтобы заменить сохранённый.

В этом режиме сервер сам разрешает имена своих запросов через обычный DNS-сервер, проверяет, что адрес не из внутренней сети, и отдаёт прокси проверенный адрес, а не имя — при любой из двух схем. Поэтому прокси в вашей собственной сети нельзя использовать, чтобы попасть внутрь этой сети.

Как перейти на Tor​

  1. Откройте Настройки Qubix → Исходящие запросы.
  2. В поле Как сервер ходит в интернет выберите Через Tor.
  3. Нажмите Сохранить. В отличие от прокси, Tor сохраняется без проверки: путь вступает в силу сразу, а сервер в фоне скачивает образ Tor и поднимает контейнер.
  4. Нажмите Проверить в группе Путь наружу и дождитесь, когда появится адрес, который виден снаружи. Пока контейнер не поднят, запросы, которые идут этим путём, получают отказ.

Группа Путь наружу показывает состояние контейнера Tor; его читают при открытии вкладки и при каждой проверке:

  • Контейнер Tor работает.
  • Контейнера Tor ещё нет: он поднимается, когда выбран Tor.
  • Контейнер Tor остановлен.
  • Сервер не достаёт до Docker, поэтому контейнер Tor не проверить.

Пока выбран Tor, сервер каждые пять минут проверяет контейнер и поднимает его заново, если тот пропал или остановлен. При каждом запуске сервера — например, после обновления Qubix — контейнер приводится к той версии Tor, которую несёт установленный выпуск.

Проверка пути наружу​

Когда сохранён прокси или Tor, под выбором пути появляется группа Путь наружу. Пока сервер ходит напрямую, проверять нечего, и группы нет.

Нажмите Проверить: сервер отправит запрос через действующий путь и покажет ответ:

  • «Снаружи виден адрес …» — путь работает, и именно этот адрес видят службы, к которым обращается сервер. Если адрес принадлежит выходу Tor, строка говорит и об этом: сервер узнаёт это у проверки самого Tor Project. Если она не ответила, а ответила другая служба, называющая адрес, строка будет без этой пометки — даже в режиме Tor.
  • Строка о том, что путь не отвечает, и под ней подробности. Останавливаются только запросы, которые идут этим путём: они получают отказ, пока путь не ответит, а то, что идёт мимо пути, работает.

Что идёт мимо выбранного пути​

Эти запросы не идут путём, выбранным на вкладке, каким бы он ни был:

  • Facebook. Запросы к Facebook идут, как и прежде, через прокси браузерного профиля, а если у профиля его нет — напрямую. Напрямую уходят конверсии в Facebook (Conversions API), проверка пикселя, проверка прокси профиля и скачивание картинок и роликов объявлений.
  • Cloudflare и Namecheap — напрямую: их ключи привязаны к адресу сервера. Напрямую идёт и проверка домена через сеть Cloudflare, и определение собственного адреса сервера: через Tor сервер узнал бы адрес выхода Tor вместо своего.
  • Наш сервер лицензий — напрямую: проверка лицензии и то, что сервер с него скачивает, например обновления баз гео и клоака.
  • Проверка портов и DNS-проверки доменов — напрямую, по самому их смыслу: проверка порта обязана прийти с адреса самого сервера, а DNS-запросы прокси SOCKS не переносит.
  • Запрос со своим прокси. Вызов fetch, который называет свой прокси, — поле proxy у ctx.fetch в скриптах — идёт до этого прокси напрямую с сервера; см. Написание скрипта.
  • Узлы вашей внутренней сети:
    • запрос fetch скрипта, правила Britva или обработчика страниц сайта к адресу внутренней сети, который разрешает Список хостов, идёт напрямую. Через ваш прокси и Tor fetch не достанет внутренний узел, заданный именем, — задавайте его адресом;
    • постбэки к узлам перечня Внутренние сети для прокси, почты и постбэков (Службы и задачи) идут напрямую;
    • базы данных скриптов во внутренней сети из перечня Узлы баз данных для скриптов подключаются напрямую (Свои базы данных).
  • Проверка новой версии Qubix — напрямую: сервер спрашивает реестр образов Qubix, не вышла ли новая версия.
  • Другие контейнеры Qubix ходят в интернет сами, напрямую: помощник на подписке Claude и контейнер сертификатов, который получает для доменов сертификаты Let's Encrypt.
  • Docker сам скачивает образы контейнеров, напрямую с адреса сервера: обновления Qubix, образ Tor (при каждом запуске сервера и при каждом сохранении этой вкладки, пока выбран Tor) и образы других частей сервера, например моделей, которые работают на самом сервере.
  • Разрешение имён (DNS). В режиме своего прокси имена своих запросов разрешает сам сервер (см. выше). В режиме Tor имена запросов, которые идут через Tor, разрешает Tor, но DNS-сервер, которым пользуется сервер Qubix, по-прежнему видит имена запросов, которые идут мимо пути напрямую, имена из DNS-проверок доменов, имена, которые сервер проверяет перед запросом, — например, хосты баз данных скриптов, — и имена постбэков, когда перечень Внутренние сети для прокси, почты и постбэков не пуст.

Соединения без шифрования​

Шифрование

Через прокси или Tor соединение без шифрования может прочитать и изменить тот, кто его несёт. Адрес http:// в запросе скрипта или в постбэке идёт открытым до прокси или выхода Tor — по возможности берите адреса https://. Выход Tor — чужой сервер: поэтому база данных скрипта в интернете подключается через Tor, только если соединение проверяет сервер базы, — настройки в разделе Свои базы данных.

Что дальше​