NaiveProxy на Ubuntu 24.04 через Caddy: установка

MAATRIX

Активная DPI-проба не просто смотрит на сигнатуру пакета — она подключается к вашему серверу сама и проверяет, ведёт ли он себя как настоящий HTTPS-сайт. Большинство обфускаций это не проходят, потому что честно эмулируют TLS-хендшейк вручную и рано или поздно ошибаются в деталях. NaiveProxy заходит с другой стороны: он использует сетевой стек самого Chromium, поэтому TLS-отпечаток, поведение при ошибках и структура HTTP/2-трафика — это не имитация, а код настоящего браузера. Ниже — установка NaiveProxy на Ubuntu 24.04 через Caddy: сборка сервера с плагином forwardproxy, сайт-прикрытие на том же домене и подключение клиентов.

Как работает маскировка NaiveProxy

Классическая связка «прокси поверх TLS» видна DPI по мелочам: нестандартный ALPN, отсутствие настоящего сертификата у домена, странный порядок расширений в ClientHello. NaiveProxy убирает эти отличия, потому что клиент — это модифицированная сборка Chromium net stack, а не самописный TLS-клиент. Он открывает обычное HTTP/2-соединение к вашему серверу, аутентифицируется Basic Auth внутри CONNECT-запроса и туннелирует трафик через него. Со стороны наблюдателя это выглядит как браузер Chrome, который открыл сайт и держит с ним keep-alive соединение.

Второй слой маскировки — сайт-прикрытие. Сервер поднимается на Caddy, и один и тот же домен одновременно отдаёт обычный сайт (статику или реверс-прокси на реальное приложение) и обслуживает forward-proxy запросы с валидным логином и паролем. Если кто-то зайдёт на ваш домен браузером без пароля, он увидит обычную страницу, а не отказ в соединении или подозрительную заглушку. Это принципиально отличает NaiveProxy от протоколов вроде Shadowsocks или VLESS Reality, где маскировка достигается имитацией чужого TLS handshake, — здесь достаточно один раз сравнить с Shadowsocks и VLESS, чтобы увидеть разницу в подходе.

Подготовка сервера и домена

Понадобится чистый VPS с Ubuntu 24.04, root-доступом и доменом, у которого A-запись уже указывает на IP сервера, — без домена Caddy не сможет выпустить сертификат, а без сертификата маскировка не работает в принципе. Ресурсы под сам NaiveProxy скромные: 1 ядро и 1 ГБ RAM спокойно тянут десятки одновременных клиентов, запас нужен только под сайт-прикрытие, если он тяжелее статической страницы.

Обновите систему и проверьте синхронизацию времени — от неё зависит выпуск сертификата по ACME:

apt update && apt upgrade -y
timedatectl status

Откройте в фаерволе только нужные порты — SSH и веб, forward-proxy трафик пойдёт через тот же 443:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Локацию сервера выбирайте по тому, откуда будут подключаться клиенты: RU-площадка даёт меньший пинг для российских пользователей, US и UK — для доступа к зарубежным сервисам. У MAATRIX все три локации оплачиваются из России картой, СБП или криптой, поэтому для проекта на NaiveProxy подойдёт любая без иностранной карты.

Установка Caddy с плагином forwardproxy

Официальный пакет Caddy плагин forwardproxy не включает — его нужно вкомпилировать через xcaddy. Сначала поставьте сам Caddy из официального репозитория, как описано в пошаговой установке Caddy с авто-SSL — это даст готовый systemd-юнит, каталоги и права, которые дальше не придётся создавать вручную:

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install caddy -y
systemctl stop caddy

Теперь поставьте Go и соберите свой бинарник Caddy с форком forwardproxy, который умеет протокол naive:

apt install -y golang-go git
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
export PATH=$PATH:$(go env GOPATH)/bin
xcaddy build --with github.com/caddyserver/forwardproxy@caddy2=github.com/klzgrad/forwardproxy@naive

Сборка займёт несколько минут — xcaddy скачивает исходники Caddy и плагина и линкует их в один бинарник caddy в текущей папке. Замените им системный бинарник, сохранив права и владельца:

cp /usr/bin/caddy /usr/bin/caddy.bak
mv caddy /usr/bin/caddy
chown root:root /usr/bin/caddy
chmod 755 /usr/bin/caddy

Убедитесь, что модуль подключён — в списке должен быть http.handlers.forward_proxy:

caddy list-modules | grep forward_proxy

Если строка есть — можно запускать сервис заново, теперь уже с поддержкой NaiveProxy:

systemctl start caddy

Caddyfile: сайт-прикрытие и forward proxy на одном домене

Прежде чем писать конфиг, сгенерируйте хеш пароля — plaintext-пароль в Caddyfile не хранится:

caddy hash-password --plaintext 'замените-на-свой-пароль'

Отредактируйте /etc/caddy/Caddyfile, разместив реальный сайт и forward proxy на одном домене:

example.com {
    route {
        forward_proxy {
            basic_auth ваш_логин ХЕШ_ПАРОЛЯ
            hide_ip
            hide_via
            probe_resistance
        }
        file_server {
            root /var/www/example
        }
    }
    encode gzip
}

Директива forward_proxy перехватывает только запросы с корректным CONNECT и заголовком авторизации, всё остальное проваливается дальше по route — на обычную отдачу файлов. hide_ip и hide_via убирают заголовки, которые выдали бы в трафике факт проксирования, а probe_resistance заставляет сервер при неудачной аутентификации отвечать так же, как ответил бы обычный веб-сервер, а не отказом в духе «это прокси, но пароль неверный». В /var/www/example положите настоящий контент — лендинг, блог, что угодно правдоподобное: если кто-то зайдёт на домен без учётных данных NaiveProxy, он должен увидеть сайт, а не пустую страницу или ошибку.

Примените конфиг мягкой перезагрузкой:

systemctl reload caddy

Клиент NaiveProxy: config.json и запуск

Для Linux, Windows и macOS есть отдельный клиентский бинарник naive, тоже основанный на сетевом стеке Chromium, — его публикуют в релизах проекта klzgrad/naiveproxy на GitHub отдельно для каждой платформы. Скачайте архив под свою систему, распакуйте и создайте config.json рядом с бинарником:

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "https://ваш_логин:ваш_пароль@example.com"
}

Запустите клиент:

./naive config.json

Клиент поднимет локальный SOCKS5-прокси на 127.0.0.1:1080, через который можно направить браузер или системный трафик — например, прописать этот адрес в настройках прокси Firefox или завернуть через него весь трафик системы отдельной утилитой.

Держать под рукой сырой бинарник неудобно на телефоне и не всегда удобно на десктопе, поэтому чаще NaiveProxy используют через готовые клиенты с GUI, которые давно добавили поддержку протокола: NekoBox — на Android и как кроссплатформенное приложение, v2rayN — на Windows (там NaiveProxy идёт как отдельное ядро), Shadowrocket — на iOS через профиль вида naive+https://логин:пароль@example.com. Во всех них достаточно вставить логин, пароль и домен сервера — те же значения, что в config.json.

Проверка работы и эксплуатация

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

curl -x socks5h://127.0.0.1:1080 https://ifconfig.me

Команда должна вернуть IP вашего VPS, а не домашний. Затем проверьте маскировку с другой стороны — откройте https://example.com обычным браузером без учётных данных прокси: должен загрузиться сайт-прикрытие, а не ошибка или пустая страница. Если это так, для стороннего наблюдателя ваш сервер выглядит как рядовой веб-сайт вне зависимости от того, идёт через него проксируемый трафик или нет.

Логи Caddy — обычное место для диагностики проблем с подключением:

journalctl -u caddy --no-pager | tail -n 50

По эксплуатации: пароль для basic_auth стоит менять не реже раза в несколько месяцев и не переиспользовать его нигде больше, потому что фактически это единственный секрет, защищающий вход в прокси. При частых неудачных попытках авторизации имеет смысл добавить fail2ban с фильтром по логам Caddy, чтобы автоматически банить IP, которые перебирают пароль. Обновлять сам Caddy с плагином придётся вручную пересборкой через xcaddy — apt upgrade перезапишет бинарник версией без forwardproxy, поэтому после системных обновлений полезно на всякий случай перепроверить caddy list-modules.

Частые вопросы