OxidProxy — руководство пользователя

Версия документа: 1.15
Версия программы: 2.6.2
Сайт: https://oxidproxy.com/ru/
Поддержка: support@oxidproxy.com · Telegram

Содержание

1. 1. Описание продукта
2. 2. Системные требования
3. 3. Установка
   - 3.1 3.1. Автоматическая установка (рекомендуется)
   - 3.2 3.2. Ручная установка
   - 3.3 3.3. Что создаётся при установке
   - 3.4 3.4. Обновление и удаление
4. 4. Первоначальная настройка
5. 5. Конфигурация (config.yaml)
   - 5.1 5.1. Лицензия
   - 5.2 5.2. Сетевые параметры
   - 5.3 5.3. Маскировка ОС (OS Fingerprinting)
   - 5.4 5.4. IPv6 подсети и ротация
   - 5.5 5.5. API и управление пользователями
   - 5.6 5.6. DNS-резолвер
   - 5.7 5.7. Ограничение скорости (Traffic Shaping)
   - 5.8 5.8. Тайм-ауты
   - 5.9 5.9. Сервисный аккаунт
   - 5.10 5.10. Чёрный список (Blacklist)
   - 5.11 5.11. Логирование
   - 5.12 5.12. MITM-режим (mitm_listeners)
   - 5.13 5.13. Брендирование панели
6. 6. HTTP API
7. 7. Web-Дашборд
8. 8. Управление службой
9. 9. Логирование и мониторинг
10. 10. Командная строка (CLI)
11. 11. Диагностика и устранение неполадок
12. 12. FAQ
13. 13. История изменений

1. Описание продукта

OxidProxy — высокопроизводительный SOCKS5(h) / HTTP CONNECT IPv6 прокси-сервер, написанный на Rust. Предназначен для развёртывания на собственном выделенном или виртуальном сервере (VPS) и выступает в роли шлюза: принимает входящие подключения по IPv4, авторизует их и маршрутизирует трафик через настроенные IPv6 подсети.

Ключевые возможности

Как это работает

   Ваше ПО            OxidProxy Server           IPv6 подсети         Интернет
  (SOCKS5h/HTTP)  →   Auth • DNS • Shaping   →  Subnet A (w:100)  →  Target
                                                 Subnet B (w:50)

2. Системные требования

3. Установка

3.1. Автоматическая установка (рекомендуется)

Запустите от имени root. Если на сервере нет curl (на минимальном образе Debian 13 его нет), сначала поставьте его:

apt-get update && apt-get install -y curl

Проверка сервера перед установкой (необязательно). Скрипт проверки смотрит, подходит ли сервер: систему, ядро, загрузчик, сеть IPv6, свободные порты и то, доходит ли ваша подсеть до сервера. Он ничего не ставит и настроек не меняет. В конце пишет итог — готов, готов с замечаниями или не готов — и что исправить.

Если подсеть IPv6 у вас уже есть, впишите её вместо примера; если подсетей несколько — по --subnet на каждую:

curl -fsSL -o v6check.sh https://oxidproxy.com/downloads/v6check.sh
bash v6check.sh --ru --subnet 2a01:1234::/48

Если подсети пока нет, запустите без неё: bash v6check.sh --ru. Результат будет неполным: главное — доходит ли подсеть до сервера — останется непроверенным, и итог будет не лучше «готов, есть замечания». Когда подсеть появится, проверьте ещё раз.

Затем запустите установщик:

curl -fsSL https://oxidproxy.com/downloads/install.sh | bash

Скрипт автоматически:
1. Проверит, что запущен от root на Debian 12 или 13 для x86_64, и обновит списки пакетов
2. Скачает и установит кастомное ядро Linux с патчем p0f — подходящее для вашей версии Debian, — предварительно проверив, что Secure Boot выключен. Ядро, которое на сервере уже есть, повторно не скачивается
3. Настроит загрузчик GRUB на загрузку нового ядра по умолчанию и предупредит, если вместо него загрузится другое
4. Установит logrotate и nftables, затем пакет OxidProxy. Пакет создаёт системного пользователя oxidproxy и systemd-службу — она включена в автозапуск, но пока не запущена
5. Спросит, ставить ли баннер при входе. При каждом входе по SSH под root он показывает состояние службы, ядро, сети и адрес панели; стандартное приветствие Debian при этом отключается, оригинал сохраняется в /etc/motd.debian-backup
6. Предложит перезагрузить сервер, если это нужно: после установки ядра или если работает другое ядро

Без терминала (из скрипта или у агента по SSH) скрипт сам отвечает «нет» на оба вопроса. Чтобы ответить заранее, задайте OXID_MOTD (баннер) и OXID_REBOOT (перезагрузка) со значением y или n:

curl -fsSL https://oxidproxy.com/downloads/install.sh | OXID_MOTD=y OXID_REBOOT=n bash

3.2. Ручная установка

1. Скачайте .deb-пакет со страницы загрузки
2. Установите пакет вместе с зависимостями — logrotate и nftables, на минимальных образах их может не быть:

apt-get update
apt-get install -y logrotate nftables
dpkg -i oxidproxy_*.deb
# При ошибках зависимостей:
apt-get install -f -y

3. (Опционально) Установите кастомное ядро для p0f. Команды ниже — для Debian 12; на Debian 13 ядро ставьте автоматическим установщиком (раздел 3.1): он ставит 6.12.111-oxidproxy-p0f и держит его в GRUB первым, впереди собственных ядер Debian.

dpkg -i linux-image-6.1.187-oxidproxy-p0f_6.1.187-oxidproxy-p0f-1_amd64.deb
update-grub

3.3. Что создаётся при установке

3.4. Обновление и удаление

Обновление. Запустите установщик ещё раз — той же командой, что в разделе 3.1. Он заменит пакет, а ядро скачает, только если в выпуске есть ядро, которого на сервере ещё нет. Вопрос про баннер прозвучит снова; ответ «нет» уже установленный баннер не убирает. Обновить вручную — поставить новый пакет поверх старого:

dpkg --force-confold -i oxidproxy_*.deb
# При ошибках зависимостей:
apt-get install -f -y

• Ваш config.yaml остаётся как есть. Если шаблон в новой версии другой, dpkg кладёт его рядом под именем config.yaml.dpkg-dist. Чтобы увидеть настройки новой версии, создайте свежий пример командой oxidproxy -g (раздел 10); oxidproxy -t покажет предупреждения по вашему конфигу.
• Логины, пароли и CA сервера не меняются.
• Работающая служба перезапускается один раз, в конце; остановленная остаётся остановленной. Автозапуск остаётся таким, каким вы его оставили.
• Перезагрузка нужна, только если установилось новое ядро; установщик тогда скажет об этом и предложит перезагрузить сервер.

Удаление.

apt remove oxidproxy

останавливает службу, убирает её из автозапуска и удаляет программу. Конфигурация, файлы аккаунтов, CA и логи остаются: повторная установка пакета подхватит их, логины и пароли будут прежними. Если служба была в автозапуске, она туда вернётся; запустите её командой systemctl start oxidproxy.

apt purge oxidproxy

удаляет и остальное: /etc/oxidproxy (конфиг с лицензионным ключом и токенами, списки), /var/lib/oxidproxy (файлы аккаунтов, CA), /var/log/oxidproxy, файлы /etc/sysctl.d/90-oxidproxy.conf и 89-oxidproxy-ra.conf, а также задержки профилей (latency_base_ms) на сетевых интерфейсах. Файлы аккаунтов и логи, которые конфиг складывал в другие места (accounts_file, log.dir), не трогаются.

Даже purge не удаляет:

• кастомное ядро: оно остаётся установленным и по-прежнему загружается по умолчанию (на Debian 13 — вместе с /etc/default/grub.d/99-oxidproxy-p0f.cfg);
• системного пользователя oxidproxy;
• строку маршрута подсети в /etc/rc.local (блок # --- oxidproxy-ipv6-setup ---): purge о ней напомнит; закомментируйте её, если эта подсеть на сервере больше ни для чего не нужна;
• баннер при входе, если вы его ставили: /etc/profile.d/99-oxidproxy-status.sh, /usr/local/sbin/oxidproxy-status и /usr/local/sbin/dashboard-url.

4. Первоначальная настройка

Сразу после установки служба ещё не работает. Она включена в автозапуск и сама поднимется после перезагрузки на шаге 4, поэтому сначала выполните шаги 1–3:

Эти значения сервер проверяет при запуске. Если в license_key, master_token или public_ip остались значения из шаблона, служба назовёт нужное поле и не стартует: наполовину настроенный сервер в работу не уходит.

Шаг 1. Отредактируйте конфигурацию

nano /etc/oxidproxy/config.yaml

Обязательно заполните:
- license_key — ваш лицензионный ключ (получить в Telegram)
- public_ip — внешний IPv4 адрес вашего сервера
- ipv6_subnets — ваши IPv6 подсети
- master_token — секретный токен для API (замените на свой!)

Шаг 2. Настройте маршрутизацию IPv6

Отредактируйте файл /etc/rc.local и раскомментируйте строку маршрута:

nano /etc/rc.local

Замените шаблон на вашу реальную подсеть:

ip -6 route add local 2a01:xxxx::/32 dev lo

Шаг 3. Проверьте конфигурацию

oxidproxy -t /etc/oxidproxy/config.yaml

Должно вывести ✅ Syntax OK. с перечислением основных параметров.

Шаг 4. Перезагрузите сервер

reboot

Это необходимо для применения кастомного ядра и правил маршрутизации.

Шаг 5. Проверьте службу

После перезагрузки служба уже работает. Проверьте:

systemctl status oxidproxy

В статусе должно быть active (running). Если вы не перезагружали сервер (например, кастомное ядро уже работало), запустите службу сами: systemctl start oxidproxy.

5. Конфигурация (config.yaml)

Все настройки находятся в файле /etc/oxidproxy/config.yaml. Для применения изменений необходимо перезапустить службу.

5.1. Лицензия

license_key: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# license_servers: не обязателен — см. пояснение ниже

license_servers:
  - "адрес.выданный.поддержкой:8000"

5.2. Сетевые параметры

listen_ip: "0.0.0.0"
public_ip: "123.45.67.89"
# ext_iface: "eth0"  # Опционально

5.3. Маскировка ОС (OS Fingerprinting)

Секция listeners позволяет создать несколько портов, каждый с собственным профилем маскировки TCP/IP отпечатка. Антифрод-системы, анализирующие трафик утилитами типа p0f, увидят характерные для указанной ОС параметры.

Используйте порты 1024 и выше. Служба из пакета работает от пользователя oxidproxy и не может открыть порт ниже 1024: такой порт останется закрытым, а oxidproxy -t предупредит об этом. Это касается и mitm_listeners, api_port, api_port_https.

Каждый listener поддерживает поле mode, определяющее протокол:

listeners:
  - port: 1080
    os_preset: "linux"
    # mode: "socks"  # По умолчанию, можно не указывать

  - port: 1081
    os_preset: "android"
    mode: "hybrid"    # Принимает и SOCKS5, и HTTP CONNECT

  - port: 1082
    os_preset: "windows"
    mode: "http"

  - port: 1083
    os_preset: "ios"
    mode: "socks"

  - port: 1084
    os_preset: "macos"
    mode: "http"

Доступные профили:

Тонкая настройка (только для опытных пользователей):

Каждый профиль задаёт эти значения сам, поэтому в шаблоне конфигурации у портов только порт, профиль ОС и режим. Чтобы изменить значение, добавьте ключ под портом; без ключа действует значение профиля.

  - port: 1081
    os_preset: "android"
    mode: "hybrid"
    tos: [0, 32, 40]      # свой набор вместо auto

Прежние значения шаблона tos: 10 (android) и tos: 8 (ios, macos) работают как auto. Любое другое одно число, кроме 0, ставит один и тот же класс на все соединения порта. У настоящих устройств так не бывает, поэтому oxidproxy -t об этом предупреждает. Пустой список (tos: []) — ошибка. Два младших бита значения в TCP-соединениях не передаются: ими управляет ядро. UDP маркируется, только когда задано одно число.

5.4. IPv6 подсети и ротация

ipv6_subnets:
  - cidr: "2a01:xxxx::/32"
    weight: 427
  - cidr: "2a02:yyyy:yyyy:yyyy::/64"
    weight: 16

rotation_interval: 10

Как работает ротация:
- IP-адрес привязан к паре логин/пароль (Sticky Session)
- При каждой авторизации проверяется, не истёк ли rotation_interval
- Если истёк — генерируется новый IPv6 из подсети (с учётом весов)
- Активные соединения НЕ разрываются — смена IP происходит только при новом подключении
- При простое сессии более 5 минут (настраиваемо через timeouts.idle) она закрывается

5.5. API и управление пользователями

api_port: 8080
api_port_https: 8443  # опционально — HTTPS API

master_token: "my-secret-token"

max_accounts: 100000

accounts_file: "/var/lib/oxidproxy/accounts_[os]_[mode]_[port].txt"

account_seed: 8312921461266748753  # задал установщик

5.6. DNS-резолвер

Имена разрешает сам сервер. Кэш общий для всех листенеров: имя, найденное для одного клиента, следующему достаётся уже готовым. Серверы с weight делят нагрузку между собой, серверы без веса включаются только тогда, когда взвешенные не отвечают. Резолвер следит за поведением каждого сервера и перестаёт слать запросы тому, кто замолчал, возвращаясь к нему позже. Если основной сервер не ответил за 300 мс, запрос параллельно уходит резервному (серверу без weight), и побеждает первый ответ, поэтому один медленный сервер не задерживает клиента. Держите хотя бы один резервный сервер: если все серверы со взвешиванием, переключаться некуда.

timeout — это время, которое даётся одному серверу на ответ, а не время ожидания клиента: благодаря параллельному запросу клиент обычно получает ответ раньше. Задача этого значения — решать, как быстро замолчавший сервер будет выведен из ротации, поэтому оно короткое. Поставьте 2, если из ротации выводятся исправные серверы. Что происходит с каждым сервером сейчас, видно в /stats, раздел 6.2.

dns:
  timeout: 1
  cache_size: 8000
  suppress_aaaa_not_found: true

  servers:
    # Основные (с балансировкой)
    - address: "[2606:4700:4700::1111]:53"
      weight: 53
    - address: "1.1.1.1:53"
      weight: 7

    # Резервные (failover)
    - address: "[2620:fe::fe]:53"
    - address: "9.9.9.9:53"

Логика работы:
1. Запрос отправляется на один из основных серверов с весом (выбирается по weight — чем больше вес, тем чаще сервер используется). Основных серверов может быть несколько.
2. Если основной сервер не ответил (таймаут/ошибка) — запрос идёт в резервный пул. Резервных серверов также может быть несколько (указываются без параметра weight).
3. Если домен существует, но не имеет AAAA-записи — это не ошибка соединения, бэкап не используется

5.7. Ограничение скорости (Traffic Shaping)

shaping:
  rate: 12500000   # 100 Мбит/с
  burst: 25000000  # 200 Мбит/с (burst)

Шпаргалка:

5.8. Тайм-ауты

timeouts:
  shutdown: 10    # Ожидание завершения сессий при остановке (сек)
  idle: 300       # Максимальное бездействие сессии (сек)

5.9. Сервисный аккаунт

service_account:
  enabled: true
  login: "checker"
  password: "strong_password"
  allowed_domain: "ifconfig.me"

Сервисный аккаунт предназначен для мониторинга и проверки работоспособности прокси. Особенности:
- Статический логин/пароль (не генерируется, не ротируется)
- Имеет доступ только к одному домену (allowed_domain)
- Не расходует лимиты ротации
- Не сменяет IP

Секция обязательна со всеми четырьмя ключами, даже если учётка вам не нужна: чтобы выключить её, поставьте enabled: false. Без секции или без одного из ключей сервер не запустится.

5.10. Чёрный список (Blacklist)

blocked_file: "/etc/oxidproxy/blacklist.txt"

В файле перечисляются заблокированные домены (вместе с поддоменами), IP-адреса и сети IPv4 или IPv6 в записи CIDR, по одному на строку. Комментарии начинаются с #. Список действует во всех режимах, включая браузерный.

Ключ blocked_file обязателен. Если самого файла нет, сервер запускается без чёрного списка и пишет об этом в журнал.

# Блокировка рекламных доменов
doubleclick.net
ads.google.com

# Блокировка приватных IPv6 сетей
fc00::/7
fe80::/10

5.11. Логирование

По умолчанию сервер пишет журнал только в systemd-journald, читать его — journalctl -u oxidproxy. В шаблоне строка dir закомментирована:

log:
  # dir: "/var/log/oxidproxy"
  level: "info"

Раскомментируйте dir, чтобы писать ещё и в файлы. Создаются два файла:
- oxidproxy.log — полный лог (уровень задаётся параметром level)
- error.log — только ошибки (всегда)

Пакет ротирует файлы только в /var/log/oxidproxy: logrotate, который ставится вместе с пакетом, делает это раз в час и хранит три последних. Файлы в любом другом каталоге не ротируются и растут без ограничений; oxidproxy -t и служба при запуске об этом предупреждают. Оставьте dir: "/var/log/oxidproxy" или настройте logrotate для своего каталога сами.

Проверить, куда идёт журнал: oxidproxy -t покажет Log Dir: not set, logging to journal only или используемый каталог.

5.12. MITM-режим (mitm_listeners)

В MITM-режиме OxidProxy терминирует TLS-соединение клиента собственным удостоверяющим центром (CA) и пересобирает запрос к целевому серверу с сетевым отпечатком настоящего браузера: JA4 (со всеми составляющими), HTTP/2 и Akamai. Профиль выбирается автоматически по User-Agent клиента, поэтому один порт обслуживает все ОС и браузеры — Chrome, Firefox и Safari на Windows, macOS, Linux, Android и iOS.

MITM-листенеры описываются в отдельной секции mitm_listeners и работают параллельно с обычными listeners:

mitm_listeners:
  - port: 9443
    mode: "hybrid"             # socks (по умолчанию) / http / hybrid
    profiles:
      - "windows-chrome"
      - "windows-firefox"
      - "macos-safari"
      - "android-chrome"
      - "ios-safari"
    default: "windows-chrome"  # если для ОС клиента в списке нет профиля
    # strict: false            # true — отказывать, ничего не подставляя
    # allow_unknown_ua: false  # true — пускать и клиентов без браузерного UA

Профили именуются по схеме <ос>-<браузер>. Доступные варианты:

Поля листенера:

5.13. Брендирование панели

Веб-панель может нести ваш знак вместо нашего. Сделано для перепродажи: панель клиента не обязана рекламировать поставщика.

brand:
  name:   "Acme"
  accent: "Proxy"
  url:    "https://acme.example"

Настройка меняет не только шапку. Она же переименовывает заголовок вкладки браузера, подпись темы в списке и имя файла сертификата, который панель предлагает скачать. Полное имя (name + accent) получают и сертификаты, которые сервер создаёт с этого момента: новый MITM-CA с примером выше называется AcmeProxy MITM Root CA, сертификат HTTPS API получает то же имя. Уже созданные сертификаты имя не меняют: переименованный CA — это новый CA, и всем клиентам пришлось бы ставить его заново.

6. HTTP API

API доступен по адресу http://YOUR_IP:PORT или https://YOUR_IP:PORT, где PORT задаётся параметрами api_port и api_port_https в конфигурации (в шаблоне 8080 и 8443). Без api_port_https HTTPS API нет.

Для аутентификации используется параметр token (значение из master_token).

Каждый метод отвечает стандартным кодом HTTP: 200 при успехе, 401, если токен не передан или неверен, 400, если запрос невыполним как написан, например запрошен режим, которого нет у листенера, или правка белого списка отклонена (раздел 6.6), и 500, если сервер не смог выполнить верный запрос, например не удалось сохранить правку белого списка. 403 означает, что адреса вызывающего нет в белом списке IP (раздел 7.4): он охраняет и API, и панель. /ca отвечает 404, когда на сервере нет ни MITM-порта, ни HTTPS API и CA поэтому не создан (с api_port_https из шаблона CA есть); /list отвечает 404 в случаях из раздела 6.5; правки белого списка могут получить 409 (раздел 6.6), а /health отвечает 503, пока лицензия не подтверждена. Пояснение приходит в теле, но ветвиться в скрипте следует по коду.

6.1. Получение нового прокси — GET /allocate

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

curl "http://YOUR_IP:8080/allocate?token=YOUR_TOKEN&port=1080&mode=socks5"

Ответ:

socks5://user_AbCdEfGh:KlMnOpQrSt@YOUR_IP:1080

Параметры запроса:

Порт указывает листенер однозначно. os выбирает его по профилю; если листенеров с таким профилем несколько, вернётся первый по конфигурации. Вызов без port и без os берёт первый листенер linux, а если такого нет — первый листенер в конфигурации. Порт или профиль, которых нет в конфигурации, получают ответ 400 со списком настроенных.

Примеры:

# Реквизиты для листенера на порту 1081
curl "http://YOUR_IP:8080/allocate?token=YOUR_TOKEN&port=1081&mode=socks5"
# Ответ: socks5://user_xxx:pass_xxx@YOUR_IP:1081

# Тот же листенер, HTTP-прокси (листенер в режиме http или hybrid)
curl "http://YOUR_IP:8080/allocate?token=YOUR_TOKEN&port=1081&mode=http"
# Ответ: http://user_xxx:pass_xxx@YOUR_IP:1081

# По профилю ОС
curl "http://YOUR_IP:8080/allocate?token=YOUR_TOKEN&os=android"

6.2. Статистика — GET /stats

Возвращает полную статистику сервера в JSON.

curl "http://YOUR_IP:8080/stats?token=YOUR_TOKEN"

Пример ответа (сокращённо — поля listeners/mitm_listeners опущены, это эхо соответствующих секций конфига; список DNS-серверов сокращён до двух, массивы hourly и daily — до одной точки):

{
  "version": "2.6.2",
  "uptime_seconds": 9980,
  "active_connections": { "tcp": 56, "udp": 4 },
  "mitm": { "active": 3, "total": 512 },
  "traffic": {
    "ingress_bytes": 264074969,
    "egress_bytes": 35524983
  },
  "dns": {
    "total_queries": 18905,
    "cache_hits": 17106,
    "cache_stale_served": 12,
    "cache_misses": 1799,
    "cache_entries": 1420,
    "inflight_joined": 63,
    "hedge_fired": 208,
    "hedge_won_by_backup": 41,
    "all_failed": 3,
    "bad_names": 0,
    "all_down_queries": 0,
    "servers": [
      {
        "address": "[2606:4700:4700::1111]:53",
        "weight": 58, "state": "healthy",
        "queries": 1502, "failures": 7,
        "timeouts": 6, "servfails": 1, "net_errors": 0,
        "consecutive_failures": 0,
        "last_failure_ago_s": 1840, "last_error": "Timeout"
      },
      {
        "address": "9.9.9.9:53",
        "weight": null, "state": "healthy",
        "queries": 36, "failures": 0,
        "timeouts": 0, "servfails": 0, "net_errors": 0,
        "consecutive_failures": 0,
        "last_failure_ago_s": null, "last_error": null
      }
    ]
  },
  "events": {
    "total_connections": 18963,
    "connection_errors": 12,
    "access_denied": 0,
    "blocked_domains": 0,
    "dns_no_ipv6": 4,
    "firewall_blocks": 0
  },
  "license": {
    "expires_at_unix": 1770484105,
    "days_left": 29,
    "seconds_left": 2530000,
    "is_active": true,
    "servers": { "node-1": "online", "node-2": "online", "node-3": "online" }
  },
  "telemetry": {
    "cpu_cores": 2,
    "total_mem_mb": 2048,
    "latest_cpu_usage": 4.8,
    "latest_mem_mb": 96,
    "open_fds": 412,
    "max_fds": 1000000,
    "hourly": [ { "ts": 1770480000, "rx": 1843200, "tx": 245760 } ],
    "daily": [ { "ts": 1770393660, "rx": 1650000, "tx": 231000 } ]
  },
  "kernel_p0f": true,
  "whitelist_fallback": null,
  "server_ip": "1.2.3.4",
  "shaper": {
    "enabled": false,
    "rate_bytes": 0,
    "burst_bytes": 0,
    "up_throttled": 0, "down_throttled": 0,
    "up_wait_ms": 0, "down_wait_ms": 0,
    "up_oversize": 0, "down_oversize": 0
  }
}

Основные поля:

6.3. Состояние и версия — GET /health, GET /version

Оба отвечают без токена; белый список IP действует и здесь. /health отдаёт 200, пока лицензия подтверждена, и 503, когда нет, — удобно для внешнего мониторинга. /version отдаёт версию простым текстом.

curl "http://YOUR_IP:8080/health"
{"status":"ok","license_active":true,"uptime_seconds":9980,"version":"2.6.2"}

curl "http://YOUR_IP:8080/version"
2.6.2

6.4. Метрики — GET /metrics

Большая часть счётчиков из /stats в текстовом формате Prometheus: по строке имя значение, строки с # — HELP и TYPE. Читается любым Prometheus-совместимым сборщиком. Нужен токен, кроме запросов с самой машины.

curl "http://YOUR_IP:8080/metrics?token=YOUR_TOKEN"

Имена начинаются с oxidproxy_: например, oxidproxy_active_tcp, oxidproxy_bytes_egress_total, oxidproxy_license_active, oxidproxy_kernel_p0f_active, oxidproxy_dns_queries_total. Запросы к API, отклонённые из-за неверного или отсутствующего токена (401), считает oxidproxy_api_unauthorized_total. Запросы и соединения, отклонённые белым списком IP, сюда не выводятся: их считают events.firewall_blocks в /stats и панель Recent Blocks в дашборде.

6.5. Файлы аккаунтов — GET /list

Скачивает файл аккаунтов порта для одного протокола — тот же, что кнопки TXT в панели (раздел 7.8). mode — socks5 или http. Ответ 404 — для порта, которого нет в конфигурации, и пока файл не выгружен; без port или с любым другим mode — 400.

curl -OJ "http://YOUR_IP:8080/list?token=YOUR_TOKEN&port=1081&mode=socks5"

6.6. Белый список IP — GET /whitelist

Тот же список, которым управляет панель (раздел 7.4), меняется на ходу, без перезапуска. Только адреса и подсети IPv4. GET возвращает записи, итоги и последние блокировки в JSON; добавление и удаление отвечают OK: ….

curl "http://YOUR_IP:8080/whitelist?token=YOUR_TOKEN"
curl -X POST "http://YOUR_IP:8080/whitelist/add?token=YOUR_TOKEN&cidr=203.0.113.0/24"
curl -X DELETE "http://YOUR_IP:8080/whitelist/remove?token=YOUR_TOKEN&cidr=203.0.113.0/24"

Если правка невозможна по самому запросу, сервер отвечает 400 и пишет причину в теле: не передан cidr, адрес неверный или IPv6, такая запись уже есть, удаляемой записи нет в списке, запись защищена (замок в панели), запись последняя, удаление закрыло бы доступ вашему же адресу (каким его видит сервер) или в списке уже 1000 записей.

Файл whitelist.txt служба читает при запуске. Если его изменили мимо службы — вручную, скриптом или скопировав поверх другой файл — после того как служба его прочитала, правка действует после перезапуска (systemctl restart oxidproxy). До перезапуска добавление и удаление отвечают 409 и файл не трогают, чтобы не перезаписать вашу правку; после перезапуска повторите запрос. 500 означает, что правку не удалось сохранить: файл не удалось записать либо его не удалось прочитать при запуске службы (whitelist_fallback, раздел 6.2).

7. Web-Дашборд

Встроенный дашборд доступен по адресу:

http://YOUR_IP:8080/dashboard?token=YOUR_TOKEN

7.1. Мониторинг в реальном времени

Дашборд доступен по адресу http://YOUR_IP:PORT/dashboard?token=YOUR_TOKEN, где PORT задаётся параметром api_port в конфигурации. Поддерживается также HTTPS-режим через api_port_https.

Дашборд обновляется каждые 10 секунд и отображает:
- Hardware Health — загрузка CPU (с числом ядер), использование RAM и Open Sockets: открытые файловые дескрипторы, в основном сокеты, против лимита службы. Эта полоса желтеет выше 70% и окрашивается в тревожный цвет темы выше 90%: нагруженный прокси упирается в сокеты задолго до того, как кончится CPU
- Network Traffic — суммарный принятый и отправленный трафик (Rx / Tx), всего соединений с момента запуска, активные TCP и UDP соединения, MITM Sessions (активные сейчас и всего с момента запуска), Traffic Shaper — Disabled или скорость в Мбит/с и burst в МБ (раздел 5.7) — и Shaper Throttle: сколько раз лимит придержал трафик от клиента (↑) и к клиенту (↓)
- Recent Blocks — раздел 7.5
- License & Status — статус (таблица ниже), Days Left (осталось дней), Expires (дата окончания) и состояние каждого сервера лицензирования: online, offline или checking... сразу после запуска. Пока сервер лицензий не ответил, в Days Left и Expires стоит —; в последние сутки Days Left показывает < 1 жёлтым
- DNS Resolver — доля попаданий в кэш (при наведении — сами числа), строка на каждый сервер с весом: вес и состояние (healthy, probing — пробный запрос после сбоев — или down), одна строка Backup Pool — сколько резервных серверов исправны, Hedged Requests — сколько раз резервному серверу уходил параллельный запрос и сколько раз он ответил первым — и Stale / Failed: ответы из устаревших записей кэша и запросы, на которые не ответил ни один сервер (раздел 5.6)
- Версия и аптайм — в шапке дашборда

Заголовок и значок вкладки браузера меняются вместе со статусом.

Красный знак ! предупреждает об одном из двух режимов, в которых сервер работает не полностью; причина и что делать — в подсказке (наведите курсор или перейдите на знак клавишей Tab):
- у заголовка AUTO-ROTATION API LINKS, вместо «(p0f Profiled)», — сервер работает не на ядре OxidProxy, и соединения уходят с собственным TCP-отпечатком сервера, а не профиля (kernel_p0f, раздел 6.2). В выводе uname -r должно быть oxidproxy-p0f; если это ядро установлено, но не загружено, журнал при запуске подскажет, как поправить загрузку
- у заголовка панели IP Whitelist — whitelist.txt не удалось прочитать, поэтому пускаются все адреса, и на прокси-порты, и в дашборд, а правка списка выключена. В подсказке указана причина; файл должен читаться пользователем oxidproxy. Исправьте это и выполните systemctl restart oxidproxy

7.2. Графики трафика

Два графика скорости (Rx/Tx в Мбит/с) с подписями средних значений:
- Почасовой — последние 60 минут с шагом 1 минута
- Суточный — последние 24 часа с шагом 1 минута

7.3. Connection Analytics

Круговая диаграмма показывает разбивку всех соединений по категориям:

7.4. Управление IP Whitelist

Панель «IP Whitelist» позволяет управлять списком разрешённых IP-адресов и подсетей прямо из браузера, без перезапуска сервиса:
- Просмотр — отображает все записи с индикатором защищённости (🔒 — системная запись, недоступная для удаления)
- Добавление — поле ввода принимает отдельный адрес IPv4 или подсеть IPv4 в CIDR-нотации (например, 192.168.1.0/24); IPv6 в белом списке не поддерживается. Нажмите + Add Entry или Enter
- Удаление — кнопка «✕» напротив каждой записи. Удаление 0.0.0.0/0 требует подтверждения во избежание случайной блокировки доступа. Последнюю запись удалить нельзя — её кнопка неактивна: пустой список закрыл бы доступ всем, и дашборду тоже; нельзя удалить и запись, без которой ваш адрес (каким его видит сервер) перестал бы пускаться, — дашборд покажет причину
- Импорт из файла — кнопка «📁 Import» позволяет загрузить .txt-файл с перечнем IP/CIDR (по одному на строку, поддерживаются комментарии через #)

Список автоматически обновляется каждые 10 секунд — изменения, внесённые через панель с другого устройства или через API, отразятся без перезагрузки страницы. Хранится он в файле из параметра whitelist_file, по умолчанию /etc/oxidproxy/whitelist.txt. Ручная правка этого файла при работающей службе действует после перезапуска (systemctl restart oxidproxy); до него панель не сохраняет свои изменения списка, чтобы не перезаписать вашу правку, и подсказывает перезапустить службу.

В списке может быть до 1000 записей. Пока whitelist.txt не прочитан, пускаются все адреса, у заголовка панели горит красный ! (раздел 7.1), а правка списка выключена: исправьте файл и выполните systemctl restart oxidproxy.

7.5. Recent Blocks

Панель «🚨 Recent Blocks» отображает последние заблокированные соединения (до 10 записей) с IP-адресом и временем блокировки. Счётчик Total показывает суммарное число блокировок с момента последнего запуска сервиса.

7.6. AUTO-ROTATION API LINKS

В верхней части дашборда для каждого порта листенера автоматически создаётся карточка с подписью его профиля ОС. Кнопки API SOCKS5 и API HTTP неактивны, если порт не обслуживает этот протокол.

При нажатии на кнопку в буфер обмена копируется ссылка для получения нового прокси (запрос GET /allocate?port=...&mode=...), а в нижнем правом углу появляется уведомление.

Под кнопками API-ссылок для каждого профиля расположены кнопки TXT SOCKS5 и TXT HTTP для прямого скачивания файла со списком аккаунтов соответствующего профиля и режима. Кнопка неактивна, если порт не обслуживает этот режим; если файл ещё не выгружен, панель об этом скажет.

Каждый MITM-листенер получает свою карточку MITM, первой в ряду: в ней те же кнопки и ещё Download CA certificate — клиент скачивает CA сервера и один раз добавляет его в доверенные, после чего весь HTTPS-трафик идёт через выбранный профиль браузера. Без mitm_listeners карточка MITM приглушена, с надписью not configured.

7.7. Темы оформления

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

7.8. Загрузка файлов аккаунтов

Кнопки TXT на карточке каждого порта скачивают его файлы аккаунтов. С путём accounts_file из шаблона они называются так:

Каждый файл содержит строки формата protocol://login:password@IP:PORT, готовые для импорта в любое ПО.

8. Управление службой

OxidProxy устанавливается как systemd-сервис и запускается от пользователя oxidproxy.

# Запуск
systemctl start oxidproxy

# Остановка (graceful — ждёт завершения активных сессий)
systemctl stop oxidproxy

# Перезапуск
systemctl restart oxidproxy

# Статус
systemctl status oxidproxy

# Включить автозапуск
systemctl enable oxidproxy

# Просмотр логов в реальном времени
journalctl -u oxidproxy -f

9. Логирование и мониторинг

Файлы логов

По умолчанию сервер пишет журнал только в systemd-journald: journalctl -u oxidproxy. Файлы появляются, когда задан log.dir (раздел 5.11):

Ротация логов

Файлы журнала в /var/log/oxidproxy ротирует logrotate раз в час, он ставится вместе с пакетом; запускает его собственный таймер пакета oxidproxy-logrotate.timer. Хранятся три последних файла, старые сжимаются gzip. Файлы в другом каталоге, заданном в log.dir, не ротируются, и oxidproxy -t об этом предупреждает.

Системная телеметрия

Каждые 10 секунд в лог выводится строка [SYS_STATS]:

[SYS_STATS] System Mem: 524/2048 MB | App Mem: 85 MB | CPU: 12.3% | Conns: 42 / 4096

10. Командная строка (CLI)

oxidproxy [OPTIONS]

Опции:
  -c, --config <PATH>      Путь к файлу конфигурации (по умолчанию: /etc/oxidproxy/config.yaml)
  -t, --test [<PATH>]      Проверить синтаксис конфигурации
  -g, --generate           Сгенерировать пример config.yaml.example
  -b, --blacklist          Сгенерировать пример blacklist.txt.example
  -H, --hwid               Показать HWID сервера
  -p, --ping <HOST:PORT>   Проверить доступность лицензионного сервера
  -V, --version            Показать версию
  -h, --help               Показать справку

oxidproxy -t без пути проверяет установленную конфигурацию, печатает те же предупреждения, что сервер пишет в журнал при запуске, и завершается с кодом 1 при любой ошибке конфигурации.

Без ключей -t, -g, -b, -H, -p, -V и -h команда oxidproxy запускает сам прокси — с конфигом из -c или с конфигом по умолчанию. На установленном сервере это работа службы (раздел 8): systemd запускает oxidproxy -c /etc/oxidproxy/config.yaml от пользователя oxidproxy и с теми сетевыми правами, которые нужны прокси. Не запускайте прокси из командной строки. Команды oxidproxy ниже (-t, -g, -p, -H) прокси не запускают, их можно выполнять от root.

Примеры:

# Запуск прокси — через systemd, не вручную
systemctl start oxidproxy

# Проверка конфига перед деплоем
oxidproxy -t /etc/oxidproxy/config.yaml

# Свежий пример конфигурации: config.yaml.example в текущем каталоге
oxidproxy -g

# Проверка доступности сервера лицензий
oxidproxy --ping адрес.выданный.поддержкой:8000

# Получение HWID
oxidproxy -H

11. Диагностика и устранение неполадок

Сервис не запускается

1. Проверьте конфигурацию:
   oxidproxy -t /etc/oxidproxy/config.yaml

2. Проверьте логи:
   journalctl -u oxidproxy --no-pager -n 50

3. Проверьте лицензионный сервер:
   oxidproxy --ping <HOST:PORT>
   Используйте адрес, который дала поддержка. Штатные адреса встроены в сервер, проверять их вручную не нужно.

Нет подключения через прокси

1. Убедитесь, что клиент использует правильный протокол — SOCKS5, SOCKS5h или HTTP CONNECT (все поддерживаются). Для максимальной анонимности рекомендуется SOCKS5h (DNS-запросы разрешаются на стороне сервера).
2. Проверьте маршрутизацию IPv6 — осмотрите содержимое файла /etc/rc.local и вывод команды:
   ip -6 route show
3. Проверьте, что порт доступен извне:
   ss -tlnp | grep oxidproxy
4. Проверьте файрвол (iptables/nftables)

Не открываются некоторые сайты

OxidProxy работает только через IPv6. Если целевой сайт не имеет AAAA-записи (IPv6), подключение невозможно.

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

dig AAAA example.com

IP не меняется

OxidProxy использует Sticky Sessions. IP привязан к паре логин/пароль. Для смены IP:
- Запросите нового пользователя через GET /allocate
- Или дождитесь истечения rotation_interval и переподключитесь

Загрузилось не то ядро

При старте в журнале есть строка Native kernel mimicking DISABLED, а uname -r не заканчивается на -oxidproxy-p0f: сервер загрузил другое ядро, и маскировка ОС не работает.

1. Посмотрите, какое ядро работает и какие установлены:
   uname -r
ls /boot/vmlinuz-*
2. Проверьте, что в /etc/default/grub стоит GRUB_DEFAULT=0. На Debian 12 этого достаточно: наше ядро по номеру старше ядер Debian и идёт первым — если только рядом не стоит более новое ядро, например из backports.
3. На Debian 13 собственные ядра Debian идут по номерам upstream и после обновления могут оказаться старше нашего, поэтому установщик держит наше первым с помощью файла /etc/default/grub.d/99-oxidproxy-p0f.cfg. Если файла нет, запустите установщик ещё раз (раздел 3.1) — он запишет файл заново.
4. Примените изменения и перезагрузитесь:
   update-grub
reboot

12. FAQ

В: Что такое SOCKS5h и чем отличается от SOCKS5?

О: В режиме SOCKS5h DNS-запросы выполняются на стороне прокси-сервера (Remote DNS). В обычном SOCKS5 DNS разрешается на стороне клиента — это может привести к DNS-утечкам и раскрыть реальный IP. Всегда используйте SOCKS5h.

В: Меняются ли логины и пароли после перезапуска или обновления?

О: Нет. Они выводятся из account_seed, который установщик задаёт один раз, своё значение у каждого сервера. Смена account_seed переиздаёт все учётки; копируя конфигурацию на другой сервер, задайте ему своё значение.

В: Можно ли использовать несколько IPv6 подсетей?

О: Да, добавьте их в секцию ipv6_subnets с разными весами. Трафик будет распределяться пропорционально весам.

В: Как узнать HWID моего сервера?

О: Выполните oxidproxy -H. HWID нужен для привязки лицензии к серверу.

В: Сколько ресурсов потребляет OxidProxy?

О: При 100 000 аккаунтов и ~50 активных соединениях — около 80–120 МБ RAM и ~5% CPU на 1 ядре. Сервер написан на Rust — это обеспечивает высокую производительность и предсказуемое потребление памяти.

В: Безопасен ли API?

О: При включённом api_port_https API работает через HTTPS. Сертификат подписан собственным CA сервера — тем же, что отдаётся по /ca; пока этот CA не установлен, cURL нужен флаг -k (или --cacert с файлом из /ca). Доступ защищён master_token: из методов API без него отвечают только /health, /version и /ca (сертификат CA — в нём нет секретов), а /stats и /metrics — только самой машине. При включённом белом списке IP API и панель отвечают только адресам из него.

В: Что такое HTTP CONNECT режим?

О: HTTP CONNECT — стандартный метод проксирования HTTPS-трафика. Клиент отправляет CONNECT host:443 HTTP/1.1 с заголовком Proxy-Authorization: Basic, после чего устанавливается зашифрованный туннель. Поддерживается всеми браузерами, curl, системными настройками прокси и большинством ПО.

Пример использования через curl:

curl -x http://user_xxx:pass_xxx@YOUR_IP:1081 https://ifconfig.me

В: Чем hybrid отличается от отдельных socks/http портов?

О: В режиме hybrid сервер принимает оба протокола на одном порту. Протокол определяется автоматически по первому байту соединения: 0x05 — SOCKS5, первая буква метода HTTP (CONNECT, GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS) — HTTP, всё остальное сбрасывается. Это удобнее — не нужно открывать дополнительные порты. Все фишки (p0f, shaping, DNS, лимиты) работают одинаково для обоих протоколов.

В: Что делает переменная [mode] в accounts_file?

О: При экспорте аккаунтов [mode] заменяется на протокол (socks5 или http). Для hybrid-листенеров создаются два файла — один с socks5:// ссылками, другой с http://. Пример: accounts_android_socks5_1081.txt и accounts_android_http_1081.txt.

В: Браузер показывает ошибку сертификата при работе через MITM-порт.

О: MITM-порт терминирует TLS собственным удостоверяющим центром (CA), поэтому клиентское устройство должно один раз добавить сертификат CA сервера в доверенные — иначе браузер будет считать соединение небезопасным. Сертификат доступен для скачивания с сервера (эндпоинт /ca) или кнопкой «Download CA certificate» на карточке MITM в дашборде (раздел 7.6).

В: Что произойдёт, если User-Agent клиента не входит ни в один из профилей mitm_listeners?

О: Зависит от клиента. Распознанный браузер, которого нет в profiles, получает другой профиль той же ОС из списка, а если такой ОС в списке нет — профиль default; при strict: true ему отказывают. Клиенту вовсе без браузерного User-Agent — curl, скрипту — отказывают со страницей-объяснением; allow_unknown_ua: true пускает его с профилем default.

13. История изменений

v2.6.2 — октябрь 2026

• Ограничение скорости экономнее — когда клиенты пытаются передать больше лимита (shaping), сервер тратит на это в разы меньше процессора, и нагрузка больше не растёт с числом таких соединений.

v2.6.1 — октябрь 2026

• Надёжный запуск после перезагрузки — служба дожидается, пока сеть сервера поднимется, и лицензия активируется с первого раза.
• Белый список через API — отказ в правке по смыслу запроса (неверный или повторный адрес, нет такой записи, защищённая или последняя запись, удаление закрыло бы ваш собственный адрес, лимит в 1000 записей) отвечает кодом 400, а не 500; текст ответа прежний.
• DNS-резолвер — ожидание ответа сервера по умолчанию 1 секунда (dns.timeout), как в шаблоне конфигурации.
• oxidproxy -t предупреждает, если файлы журнала пишутся не в /var/log/oxidproxy: в другом каталоге пакет их не ротирует.
• Документация — руководство, README пакета и инструкция для ИИ-агента уточнены и дополнены: обновление и удаление, требования к серверу, обязательные ключи конфигурации, коды ответов API, описание панели.
• Валидатор и конструктор конфигурации на сайте проверяют адреса, порты и пустые значения так же, как сервер, и предупреждают о том же, о чём предупреждает oxidproxy -t.

v2.6.0 — октябрь 2026

• Профили ОС — скорректированы сетевые параметры.
• Проще шаблон конфигурации — у портов только порт, профиль ОС и режим; остальные ключи работают как раньше, их список и значения по умолчанию — в руководстве и в README.txt пакета.
• Поддержка Debian 13 (Trixie) — наравне с Debian 12, пакет тот же; установщик сам выбирает подходящее ядро (6.12.111 на Debian 13, 6.1.187 на Debian 12) и проверяет, что выключен Secure Boot, как того требует ядро.
• Предсказуемое удаление и обновление — apt remove останавливает службу и сохраняет данные; apt purge удаляет всё, включая конфигурацию и задержки профилей; обновление не включает автозапуск, если вы его выключили.
• Браузерный режим ближе к настоящим браузерам — повышена точность для актуальных версий Chrome, Edge и Firefox.
• Браузерный режим совместимее и стабильнее — расширена совместимость с клиентами, которые строго проверяют сертификаты, например Python 3.13+, и с HTTPS-сайтами по IPv6-адресу; при скачивании виден размер файла, поддерживается долгая отправка файлов, снижено потребление памяти при долгой работе.
• Сертификаты — сертификат HTTPS API создаётся при первом запуске и сохраняется между перезапусками в /var/lib/oxidproxy/api-tls/; новый CA сервера носит имя из brand, а уже созданный CA не меняется.
• Чёрный список — понимает международные доменные имена и записи вида *.example.com и .example.com (домен вместе с поддоменами); oxidproxy -t показывает, что загружено.
• oxidproxy -t заранее предупреждает о настройках, которые не заработают, и подсказывает решение — порты ниже 1024, отсутствие маршрута IPv6 по умолчанию, файлы журнала, принадлежащие другому пользователю; IPv6-адрес в listen_ip отвергается и при проверке, и при запуске.
• Понятнее ошибки в конфигурации — если config.yaml записан с ошибкой, oxidproxy -t показывает номер строки, а при неверном значении — и имя ключа.
• Панель — правка белого списка сохраняет комментарии и не даёт закрыть доступ самому себе; понятнее сообщения об отказе в доступе и статус лицензии; красный значок с причиной и решением, когда сервер работает не на ядре OxidProxy или не прочитан белый список.
• Белый список — если whitelist.txt изменили вручную или скриптом при работающей службе, панель не перезапишет эти правки и подскажет перезапустить службу.
• HTTP-режим — уточнена обработка запросов, расширена совместимость с запросами на IPv6-адреса.
• DNS-резолвер — устойчивее проверка состояния серверов; большие ответы получаются целиком по TCP; сайт с несколькими IPv6-адресами доступен, даже если один из них не отвечает.
• UDP-режим — расширена совместимость, когда у сервера прокси несколько IPv4-адресов; снижено потребление ресурсов при долгой работе; Connection Analytics считает UDP по сессиям.
• Надёжная установка и запуск — расширена совместимость с серверами, получающими IPv6 по SLAAC; служба надёжно стартует после перезагрузки на серверах с netplan, NetworkManager или медленным DHCP; если порт прокси не открылся при запуске, служба пробует снова, пока он не откроется.
• Журналы и API — файловые журналы (log.dir) ротируются каждый час; меньше повторяющихся строк, все отказы видны в /metrics (новый счётчик oxidproxy_api_unauthorized_total).

v2.5.1 — сентябрь 2026

• Отпечатки ОС ближе к реальным устройствам — параметры соединений различаются от адреса к адресу, как у настоящих устройств в разных сетях; улучшен профиль macOS. Полная точность — с ядром 6.1.187, установщик ставит его сам.
• Класс трафика подбирается автоматически — tos: auto; число или список, как и раньше, задают своё значение.
• Новый шаблон конфигурации — под каждым портом показаны умолчания его профиля: чтобы изменить значение, достаточно раскомментировать строку.
• Строгая проверка профилей — порт с неизвестным os_preset не открывается, остальные работают, oxidproxy -t указывает на ошибку.
• Снижено потребление памяти — неактивные соединения занимают примерно в десять раз меньше памяти.
• Повышена устойчивость — ошибки в обработке одного соединения не затрагивают остальные.
• Чёрный список — поддерживает подсети IPv4 и IPv6, уточнены правила проверки.
• Браузерный режим — уточнены правила проверки, неактивные подключения закрываются по таймауту.
• DNS-резолвер — сбой отдельного домена не влияет на остальные запросы, при недоступности всех серверов резолвер продолжает попытки; новые счётчики в /stats и /metrics.
• Белый список — уточнены правила обработки, его состояние видно в /stats.
• Журналы — новые установки пишут журнал в systemd-journald; запись в файлы включается параметром log.dir, ротацию обеспечивает logrotate.
• oxidproxy -t показывает те же предупреждения, что сервер при запуске.
• Обновлены библиотеки TLS.

При обновлении:

• Перезагрузите сервер: ядро 6.1.187 начинает работать после перезагрузки.
• Проверьте os_preset у всех портов: порт с ошибкой в имени профиля после обновления не откроется. Проверка — oxidproxy -t.
• Ваша конфигурация и журналы при обновлении не меняются.

v2.4.1 — сентябрь 2026

• Проверка конфигурации без указания пути — oxidproxy -t проверяет установленную конфигурацию /etc/oxidproxy/config.yaml, путь указывать не нужно.

v2.4.0 — сентябрь 2026

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

v2.3.7 — сентябрь 2026

• Выбор листенера по порту в /allocate — параметр port указывает листенер точно, что важно, когда на одном профиле работает несколько листенеров с разными настройками. Параметр os продолжает работать.
• Контроль параметров /allocate — порт или профиль, которых нет в конфигурации, получают ответ 400 со списком настроенных.

v2.3.6 — сентябрь 2026

• Новый DNS-резолвер — общий кэш на все листенеры, отслеживание доступности серверов и параллельный запрос к резервному. Резолвинг стал быстрее и устойчивее, расширен набор поддерживаемых имён.
• Подробная статистика DNS в /stats — по каждому серверу видно состояние, вес и характер отказов, это удобно для диагностики.
• UDP-режим оптимизирован — повышены надёжность сессий и совместимость с сетями.
• SOCKS5: точные коды ответов — клиент получает конкретную причину, по которой соединение не состоялось.
• HTTP-режим оптимизирован — повышены устойчивость под нагрузкой и совместимость с клиентами.
• Профили iOS приведены в соответствие с реальными устройствами.
• Браузерный режим улучшен — повышены точность работы и совместимость с сайтами, крупные загрузки обрабатываются экономнее по памяти.
• Проверка конфигурации при запуске — служба сразу указывает на незаполненные обязательные поля и не стартует, пока license_key, master_token или public_ip содержат шаблонные значения.
• Стандартные коды ответов API — /allocate, /stats и /dashboard возвращают 401 при неверном токене и 400 при некорректном запросе.
• Панель: улучшена читаемость тёмной темы.

v2.2.0 — сентябрь 2026

• Задержки профилей снижены — мобильные профили (android, ios) добавляют 30 мс, настольные (windows, macos) — 10 мс, linux не добавляет ничего. Прежние значения были завышены и стоили лишних десятков миллисекунд на каждом запросе. Заданное явно в config.yaml имеет приоритет: умолчания действуют только там, где ключ не указан.
• jitter_ms больше не применяется — ключ по-прежнему принимается, конфигурации с ним остаются рабочими, но при запуске служба пишет о нём предупреждение в журнал.
• Снято ограничение пропускной способности, проявлявшееся при высокой нагрузке.

v2.1.2 — август 2026

• MITM-порт отказывает небраузерным клиентам — curl, скрипты и всё, что не присылает браузерный User-Agent, получают короткую страницу с объяснением вместо выхода наружу под чужим профилем. Чтобы вернуть прежнее поведение, добавьте в листенер allow_unknown_ua: true. Браузеров изменение не касается.
• Баннер при входе по SSH — необязательный, предлагается при установке. Показывает состояние службы, загруженное ядро, настроенные подсети и адрес панели, а также предупреждает, если master_token остался из шаблона. Токен в баннер намеренно не попадает; полную ссылку выдаёт команда dashboard-url.
• Версия браузера согласована с рукопожатием — для трафика без браузерного User-Agent сервер заявляет ту версию, чьё TLS-рукопожатие эмуляция действительно воспроизводит.

v2.1.0 — август 2026

• Новое кастомное ядро — 6.1.177-oxidproxy-p0f взамен 6.1.170, вместе с подходящим пакетом linux-headers на странице загрузки.
• Адреса лицензирования вшиты в сервер — license_servers больше не обязательный ключ. Поле называется Дополнительные серверы лицензий и обычно не заполняется вовсе; впишите адрес, только если его выдала поддержка.
• Журнал вместо файлов — оставьте log.dir пустым, и сервер будет писать только в журнал systemd. Удобно там, где логи собираются централизованно.
• Брендирование панели — секция brand заменяет надпись над панелью и адрес, куда ведёт глобус: панель можно отдавать своим клиентам под собственным именем.
• Разнообразнее отпечаток TCP — MSS больше не одно значение на все соединения. Оно берётся из правдоподобного распределения и остаётся постоянным для конкретного исходящего адреса, поэтому профиль перестал выделяться одинаковой величиной повсюду.
• Понятные ошибки каталога логов — недоступный для записи каталог сообщается при запуске, а не роняет службу.
• Честный статус p0f — если ядро не может выдать отпечаток, сервер говорит об этом прямо, а не переключается на запасной путь молча.

v2.0.0 — июнь 2026

• MITM-режим — новый режим работы: сервер терминирует TLS собственным CA и пересобирает трафик к целевому серверу с сетевым отпечатком настоящего браузера (Chrome, Firefox, Safari) по всем слоям — JA4 (со всеми составляющими), HTTP/2 и Akamai. Профиль выбирается автоматически по User-Agent клиента, поэтому один порт обслуживает все ОС.
• Секция mitm_listeners — отдельные MITM-порты рядом с обычными listeners, с выбором разрешённых профилей по схеме <ос>-<браузер> и профилем по умолчанию.
• Карточка MITM в дашборде — ссылка для подключения и кнопка скачивания сертификата CA для добавления в доверенные на стороне клиента.

v1.8.1 — май 2026

• QUIC по стандарту RFC — масштабная переработка реализации UDP/QUIC: устранены отклонения от спецификации, улучшена совместимость с клиентами, снижены потери пакетов на высоких нагрузках.
• Новое кастомное ядро 6.1.170-oxidproxy-p0f — обновлённое ядро с кардинально улучшенной совместимостью оборудования. Теперь оно загружается на любых гипервизорах и конфигурациях железа так же стабильно, как стандартное ядро Debian 12 (в предыдущей версии ряд конфигураций не загружался после установки ядра).
• Скачивание файлов аккаунтов из дашборда — в блоке AUTO-ROTATION API LINKS появились кнопки TXT SOCKS5 и TXT HTTP для прямой загрузки файлов со списком прокси-аккаунтов, сгруппированных по профилю ОС и режиму.

v1.7.1 — апрель 2026

• Web-Дашборд — IP Whitelist — полноценное управление белым списком прямо из браузера: добавление, удаление, импорт из файла. Изменения вступают в силу немедленно, без перезапуска сервиса.
• Автообновление дашборда — данные IP Whitelist и Recent Blocks теперь обновляются автоматически каждые 10 секунд вместе с остальной статистикой.
• Connection Analytics — новая круговая диаграмма с разбивкой соединений по категориям (успешные, заблокированные, ошибки, IPv4-only домены).
• Recent Blocks — панель последних заблокированных соединений с отметками времени и суммарным счётчиком.
• Темы оформления — добавлены пять визуальных тем дашборда с сохранением выбора в браузере.
• Поддержка HTTP CONNECT — полноценный HTTP-прокси режим с авторизацией Proxy-Authorization: Basic, корректной обработкой всех вариантов заголовка.
• Улучшена устойчивость сервиса — порт API-дашборда больше не вызывает бесшумное падение при занятом порту; ошибка явно указывается в журнале.
• Исправлен макет дашборда — устранена проблема несовпадения границ колонок между виджетами при различных разрешениях экрана.

v1.7.0 — март 2026

• Hybrid Mode — автоматическое определение протокола (SOCKS5 / HTTP CONNECT) на одном порту по первому байту соединения.
• HTTP прокси — добавлена поддержка режима http в секции listeners.
• Поле [mode] в accounts_file — для hybrid-листенеров экспортируются два файла аккаунтов: с SOCKS5 и HTTP ссылками.

v1.6.0 — январь 2026

• HTTPS API — опциональный порт api_port_https с самоподписным сертификатом.
• Smart DNS Failover — резервный пул DNS-серверов с автопереключением при недоступности основного.
• Сервисный аккаунт — статическая учётная запись с ограничением доступа одним доменом для чекеров и мониторинга.