Naive Server

1. Naive Server

Naive Server — это высокопроизводительная и безопасная реализация прокси-сервера (exit node), специально разработанная для работы в связке с клиентом Haonixao/naiveproxy.

Сервер представляет собой полноценный узел выхода, обеспечивающий одновременную поддержку протоколов HTTPS (HTTP/2) и QUIC (HTTP/3). В отличие от универсальных решений, данный сервер сфокусирован исключительно на задачах скрытности и обхода систем глубокого анализа трафика (DPI), предоставляя пользователю максимальный контроль над сетевым поведением без необходимости сложной настройки.

2. Почему Naive Server?

Традиционным способом развертывания NaiveProxy является связка веб-сервера Caddy и плагина forwardproxy. Несмотря на надежность, этот подход имеет ряд недостатков:

Сложность сборки: Для работы с NaiveProxy вам необходимо использовать xcaddy для ручной компиляции Caddy с внешним плагином.
Избыточность конфигурации: Даже простая настройка требует написания Caddyfile, управления путями и сертификатами.
Naive Server предлагает концепцию Zero Config: сервер управляется минимальным набором флагов запуска и поставляется в виде одного готового бинарного файла.

Ключевые отличия и преимущества:

Прозрачность для Chromium-стека: Сервер спроектирован так, чтобы максимально соответствовать ожиданиям сетевого стека Chromium, на котором базируется NaiveProxy. Он не вносит искажений в логику обработки соединений, что критично для предотвращения детекции по отпечаткам (fingerprinting).
Расширенная маскировка (Reality-like): В то время как стандартный forwardproxy просто выдает ответ или перенаправляет запрос, Naive Server реализует механизм, подобный протоколу Reality. Это позволяет серверу «красть личность» любого крупного легитимного сервиса (например, go.dev), превращаясь в его прозрачное зеркало для всех неавторизованных пользователей — как по TCP, так и по UDP (QUIC).
Отсутствие инфраструктурных затрат: В stealth-режиме вам не нужно покупать домен, настраивать получение SSL-сертификатов. Для неавторизованных подключений сервер отдает TLS-слой целевого SNI; для авторизованных — самоподписанный сертификат, который принимает форк клиента без проверки.

3. Key Features

Гибридный транспорт: Одновременная работа на одном порту как через классический HTTPS (TCP), так и через современный QUIC (UDP). Клиент может переключаться между ними «на лету» без перенастройки сервера.
Native Padding: Полная поддержка протокола набивки пакетов NaiveProxy для защиты от анализа трафика по размеру и таймингам. Сервер и форк Haonixao/naiveproxy поддерживают два режима:
- Variant1 (-padding 1, по умолчанию): паддинг применяется только к первым 8 операциям чтения/записи в каждом CONNECT-потоке — как в официальном клиенте klzgrad/naiveproxy и плагине Caddy forwardproxy.
- Variant2 (-padding 2): паддинг применяется на всём протоколе, на каждой операции чтения/записи. Даёт более сильную защиту от length-based анализа, но с большим оверхедом. Требует форк на клиенте; со стандартным naiveproxy несовместим.
Два режима работы:
- Stealth Mode: Режим максимальной скрытности. Использует самоподписанные сертификаты и мимикрию под SNI. Поддерживает HTTPS (TCP) и QUIC (UDP) на порту 443. Идеален для работы без собственного домена.
- Official Mode: Режим для работы с реальными доменами и валидными сертификатами (например, Let's Encrypt). В этом режиме сервер показывает страницу decoy.html (можно вставить в файл свой код) для всех сторонних запросов.
Reality-подобный механизм активации:
- Авторизация через TLS SessionID: Активация IP-адреса происходит незаметно внутри TLS-рукопожатия по TCP. Клиент отправляет специальный криптографический токен в поле SessionID, который сервер проверяет еще до завершения Handshake.
- Прозрачная фильтрация: Для TCP фильтрация происходит в кастомном листенере (ipFilterListener) на уровне Accept(). Для QUIC — в UDP-фронтенде (quicFrontend), который маршрутизирует пакеты по тому же белому списку IP. Авторизованные сессии попадают на внутренний Naive-бэкенд, неавторизованные — прозрачно проксируются на реальный SNI.

4. TLS SessionID Activation

Механизм активации IP — это первый эшелон защиты, работающий внутри первого пакета TLS (Client Hello).

Принцип работы: Чтобы сервер начал воспринимать входящие соединения как запросы от NaiveProxy, клиент должен один раз выполнить "регистрационный" запрос по TCP. В поле SessionID передается 32-байтный токен: [5 байт Random] + [3 байта MinutesSinceYearStart] + [24 байта HMAC-SHA256(Key, Random + Minutes + SNI)].
Скрытность: Если входящее соединение не содержит валидного токена в SessionID, сервер прозрачно проксирует трафик на реальный хост указанного SNI. Для TCP это зеркалирование на sni:443 (TCP), для QUIC — форвардинг UDP-пакетов на sni:443 (UDP). Для внешнего сканера или DPI сервер выглядит как зеркало легитимного ресурса — при условии, что выбранный SNI действительно отвечает на соответствующем транспорте.
Авторизация: После успешной проверки токена IP-адрес клиента заносится в оперативную память сервера (Allowed List). Все последующие соединения с этого IP — и по TCP, и по UDP — обрабатываются как легитимные.
Защита от Replay: В токене используются минуты с начала текущего года (UTC). Сервер допускает отклонение не более 2 минут 30 секунд, что затрудняет повторное использование перехваченного пакета.

5. Встроенная активация

Механизм активации IP-адреса полностью интегрирован в форк клиент Haonixao/naiveproxy.

Порядок действий:

Запустите сервер и скопируйте AUTH KEY (HEX) из логов.
Укажите этот ключ и параметры сервера в config.json клиента (см. раздел "Настройка клиента").
При запуске клиент автоматически выполнит активацию перед установкой основного соединения.

Активация выполняется прозрачно по TCP, после чего сервер авторизует ваш IP для всех последующих сессий (TCP и UDP).

6. Operational Modes

Сервер поддерживает два кардинально разных сценария использования, переключаемых флагом -mode. В обоих режимах на порту 443 одновременно работают HTTPS (TCP) и QUIC (UDP).

Stealth Mode (По умолчанию)

Режим максимальной мимикрии для работы без официального домена.

Сертификаты (на стороне сервера): При первом запуске сервер автоматически генерирует полную цепочку: rootCA.crt, rootCA.key и сертификат для выбранного SNI (например, go.dev.crt / go.dev.key). Файлы остаются на сервере — переносить или импортировать их на клиент не нужно.
Клиент: Используйте форк Haonixao/naiveproxy. В нём отключена проверка сертификатов для TCP/TLS и QUIC/UDP, поэтому самоподписанный сертификат stealth-режима принимается без настройки ОС. Стандартный klzgrad/naiveproxy не принимает самоподписанные сертификаты.
Мимикрия (Reality-like SNI Proxying):
- TCP: Неавторизованные TLS-соединения прозрачно проксируются на реальный sni:443 (TCP). Сканер видит валидный сертификат и ответ целевого домена.
- QUIC: На UDP :443 работает quicFrontend. Неавторизованные QUIC-пакеты форвардятся на реальный sni:443 (UDP). Авторизованные — на внутренний HTTP/3 бэкенд (127.0.0.1:8443), который отдает самоподписанный сертификат Naive Server.
Транспорт: Клиент из форка может использовать https:// и quic:// с одним и тем же SNI и host-resolver-rules. Переключение транспорта не требует перенастройки сервера.
Выбор SNI для маскировки: Для корректной QUIC-маскировки SNI должен поддерживать HTTP/3 на UDP 443. Например, go.dev и dns.google отвечают и по TCP, и по QUIC; docker.com — только по TCP. Если fallback-домен не говорит по QUIC, неавторизованные UDP-подключения завершатся таймаутом (в логах: [quicFrontend] fallback proxy timeout), хотя TCP-маскировка при этом будет работать.

Official Mode

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

Подготовка: Требует наличия зарегистрированного домена (или DDNS вроде DuckDNS) и валидных TLS-сертификатов (например, от Certbot/Let's Encrypt). Сертификаты должны быть названы по схеме ваш.домен.crt и ваш.домен.key.
Транспорт: HTTPS (TCP) и QUIC (UDP) слушают напрямую на :443 с вашими сертификатами. UDP-фронтенд (quicFrontend) в этом режиме не используется.
Decoy Page: Вместо прозрачного проксирования на сторонний SNI сервер позволяет любому пользователю завершить TLS-handshake, но выдает страницу decoy.html. Это выглядит естественно для зондирующих систем: они видят валидный сертификат и стандартный ответ веб-сервера.

7. UDP Support (SOCKS5 UDP Associate)

Этот раздел про проброс произвольного UDP-трафика приложений (игры, VoIP) через SOCKS5. Это отдельная задача от QUIC-транспорта Naive (quic://), который описан выше.

По умолчанию naiveproxy не поддерживает метод UDP ASSOCIATE в своем SOCKS5-интерфейсе. Для решения этой проблемы и обеспечения полноценной работы UDP-трафика (игры, звонки и т.д.) рекомендуется использовать связку с gost.

Схема работы цепочки

Для проброса UDP используется два инстанса gost (на стороне клиента и на стороне сервера), которые упаковывают UDP-пакеты в TCP-туннель NaiveProxy.

1. На стороне сервера (Exit Node): Запустите gost рядом с naive_server, чтобы он принимал локальные SOCKS5-запросы:

nohup ./gost -L socks5://127.0.0.1:8080 > gost.log 2>&1 &

2. На стороне клиента: Создайте цепочку, которая принимает SOCKS5 (с поддержкой UDP) и перенаправляет трафик через Naive и удаленный Gost:

./gost -L socks5://127.0.0.1:1081 -F socks5://127.0.0.1:1080 -F socks5://127.0.0.1:8080?uod=1

Где:

127.0.0.1:1081 — новый локальный SOCKS5-порт с поддержкой UDP.
127.0.0.1:1080 — локальный порт запущенного naive.exe.
127.0.0.1:8080 — адрес gost на удаленном сервере (доступный через туннель).
?uod=1 — критический флаг (UDP over DNS/TCP), заставляющий Gost упаковывать UDP в TCP-стрим.

3. Интеграция с туннелями (Mihomo/Clash): При использовании систем прозрачного проксирования или TUN-интерфейсов (например, Mihomo/Clash), необходимо убедиться, что UDP-трафик направляется на порт локального gost (127.0.0.1:1081). В правилах маршрутизации (Rules) следует явно указать пересылку UDP на этот порт, чтобы обеспечить корректную работу игр и голосовых чатов через созданный туннель.

Эта связка позволяет обойти ограничения NaiveProxy, сохраняя при этом все преимущества его маскировки для основного транспортного уровня.

8. Configuration & CLI Flags

Сервер максимально упрощен в настройке. По умолчанию слушает на всех интерфейсах (0.0.0.0) на порту 443 (TCP для HTTPS и UDP для QUIC).

Флаг	Описание	Значение по умолчанию
`-mode`	Режим работы: `stealth` или `official`	`stealth`
`-sni`	SNI домена для мимикрии (stealth) или имя вашего домена (official)	`go.dev`
`-padding`	Режим padding: `1` (Variant1, первые 8 ops) или `2` (Variant2, всегда)	`1`

-padding — как работает:

При CONNECT-запросе с заголовком Padding сервер отвечает Padding-Type-Reply со значением 1 или 2. Клиент и сервер далее применяют согласованный режим в dualStream (stream.go):

1 (Variant1): переменная NumFirstPaddings = 8 — паддинг только на первых 8 read/write. Совместим с официальным NaiveProxy и Caddy forwardproxy.
2 (Variant2): NumFirstPaddings = -1 — паддинг на каждой read/write без ограничения. Доступен только в связке с форком Haonixao/naiveproxy (клиент объявляет поддержку kVariant2 и согласует тип через заголовки).

Примечание: При запуске сервер генерирует уникальный AUTH KEY (HEX) и выводит его в лог. Этот ключ необходим клиенту для выполнения автоматической активации.

9. Usage & Client Configuration

Запуск сервера

Stealth Mode (рекомендуется):

./naive_server -mode stealth -sni go.dev
# или с постоянным паддингом (Variant2, требует форк на клиенте):
./naive_server -mode stealth -padding 2 -sni go.dev

На клиенте используйте Haonixao/naiveproxy — стандартный клиент несовместим. Выбирайте SNI, который поддерживает HTTP/3, если планируете QUIC-маскировку для неавторизованных подключений.

Official Mode:

./naive_server -mode official -sni your-domain.com

Требует наличия your-domain.com.crt и your-domain.com.key в рабочей директории.

Настройка клиента (config.json)

Соберите и используйте клиент из Haonixao/naiveproxy. Проверка TLS-сертификатов в нём отключена — импорт rootCA.crt на клиенте не требуется. Для сборки в Docker см. каталог naiveproxy_in_docker/.

Важное требование (MAP) для stealth: Необходима директива "host-resolver-rules": "MAP <sni-host> <vps-ip>". Это принудительно сопоставляет донорский домен с IP вашего сервера, чтобы отправлять Client Hello с нужным SNI без правки hosts.

Пример:

{
  "host-resolver-rules": "MAP go.dev <ВАШ_IP>",
  "listen": ["socks://127.0.0.1:1080"],
  "proxy": "https://go.dev:443",
  "server_ip": "<ВАШ_IP>",
  "activation-sni": "go.dev",
  "activation-key": "<AUTH_KEY_HEX>",
  "log": ""
}

Описание новых полей:

server_ip: IP-адрес вашего сервера (используется для предварительного TCP-соединения активации).
activation-sni: SNI домена, который будет использован в пакете активации (должен совпадать с -sni сервера).
activation-key: Тот самый AUTH KEY (HEX), который сервер выводит при запуске.

Docker: сборка и запуск клиента (`naiveproxy_in_docker`)

В каталоге naiveproxy_in_docker/ лежат скрипты и конфиги для сборки и запуска форка Haonixao/naiveproxy в Docker-контейнере. Это удобная альтернатива ручной сборке клиента на хосте: все зависимости (clang, ninja, ccache и т.д.) поднимаются внутри образа.

Файл	Назначение
`Dockerfile`	Образ на базе Ubuntu 22.04, клонирует форк в `/naiveproxy`
`docker-compose.yml`	Сборка и запуск контейнера `naive`, проброс порта `1080`, монтирование `config.json`
`config.json`	Пример конфигурации клиента (отредактируйте IP и SNI под свой сервер)
`commands.txt`	Шпаргалка команд: сборка образа, компиляция `naive` внутри контейнера, запуск и логи

1. Подготовка config.json

Отредактируйте naiveproxy_in_docker/config.json: укажите IP вашего naive_server, SNI и транспорт (https:// или quic://). SNI должен совпадать с -sni сервера.

{
  "host-resolver-rules": "MAP go.dev <ВАШ_IP>",
  "listen": ["socks://127.0.0.1:1080"],
  "proxy": "https://go.dev:443",
  "server_ip": "<ВАШ_IP>",
  "activation-sni": "go.dev",
  "activation-key": "<AUTH_KEY_HEX>",
  "log": ""
}

2. Сборка и запуск контейнера (на хосте):

cd naiveproxy_in_docker
docker compose build --no-cache && docker compose up

3. Сборка и запуск naive (внутри контейнера):

cd /naiveproxy/src
./get-clang.sh
ccache -z && ./build.sh && ccache -s

cd /naiveproxy
nohup ./src/out/Release/naive > naive.log 2>&1 &
tail -20 naive.log

Клиент будет доступен на хосте по socks5://127.0.0.1:1080. Полный список команд (остановка, проверка процесса) — в commands.txt.

Интеграция с Tunnel (Mihomo/Sing-box)

Для полноценной работы системы (включая UDP) рекомендуется использовать туннелировщик с разделением трафика на два порта:

TCP трафик — направлять на порт 1080 (Naive Proxy).
UDP трафик — направлять на порт 1081 (Gost цепочка).

Это обеспечит максимальную производительность TCP через Naive и корректную инкапсуляцию UDP через Gost.

Disclaimer:

Данное решение находится в стадии MVP и предназначено для обеспечения приватности и обхода необоснованных сетевых ограничений.
Рекомендуется использовать дополнительно с Haonixao/mini_decoy

Name		Name	Last commit message	Last commit date
Latest commit History 19 Commits
naiveproxy_in_docker		naiveproxy_in_docker
README.md		README.md
decoy.html		decoy.html
gen_cert.go		gen_cert.go
go.mod		go.mod
go.sum		go.sum
handlers.go		handlers.go
listener.go		listener.go
main.go		main.go
stream.go		stream.go
utils.go		utils.go

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

Naive Server

1. Naive Server

2. Почему Naive Server?

3. Key Features

4. TLS SessionID Activation

5. Встроенная активация

6. Operational Modes

Stealth Mode (По умолчанию)

Official Mode

7. UDP Support (SOCKS5 UDP Associate)

Схема работы цепочки

8. Configuration & CLI Flags

9. Usage & Client Configuration

Запуск сервера

Настройка клиента (config.json)

Docker: сборка и запуск клиента (`naiveproxy_in_docker`)

Интеграция с Tunnel (Mihomo/Sing-box)

About

Uh oh!

Releases

Packages

Uh oh!

Contributors

Uh oh!

Languages

Folders and files

Latest commit

History

Repository files navigation

Naive Server

1. Naive Server

2. Почему Naive Server?

3. Key Features

4. TLS SessionID Activation

5. Встроенная активация

6. Operational Modes

Stealth Mode (По умолчанию)

Official Mode

7. UDP Support (SOCKS5 UDP Associate)

Схема работы цепочки

8. Configuration & CLI Flags

9. Usage & Client Configuration

Запуск сервера

Настройка клиента (config.json)

Docker: сборка и запуск клиента (naiveproxy_in_docker)

Интеграция с Tunnel (Mihomo/Sing-box)

About

Topics

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Docker: сборка и запуск клиента (`naiveproxy_in_docker`)

Packages