Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Настройка NaiveProxy Caddy: доступ и обновления
Marcus Reid
11 октября 2026 г.· 11 мин чтения
Настройка NaiveProxy Caddy требует совместимого сервера прямого прокси, доверенного сертификата и клиента, через который идут только выбранные приложения. Здесь используются Ubuntu 24.04 LTS x64 на обеих сторонах, официальный клиент NaiveProxy v154.0.8037.49-4 и готовая сборка Naive Caddy v2.11.7-naive. Это версии, к которым относится инструкция, а не проверенное автором окружение.［1］［2］
Ключевые выводы
- Используйте Naive-совместимую сборку проекта: обычного исполняемого файла Caddy недостаточно.
- Храните данные доступа в закрытом файле; SOCKS должен слушать только loopback.
- Отдельно проверяйте разрешённую передачу, неверный пароль и CONNECT без аутентификации.
- Первый выпуск сертификата не доказывает работоспособность продления.
- Сохраняйте рабочую конфигурацию и следите за обновлениями безопасности Chromium и Caddy.
Инструкция подготовлена по официальным источникам ниже; полный сквозной тест не выполнялся. Таблицы содержат методы и ожидаемое поведение, а не наблюдавшиеся результаты. Начните с обязанностей владельца и плана восстановления.
Что требует настройка NaiveProxy Caddy?
Нужен сервер, которым вы вправе управлять, независимо проверенный ключ SSH и доступ к консоли провайдера на случай сетевой ошибки. Включите строгую проверку ключа и отдельный проектный known_hosts, заранее заполненный через другой доверенный канал. При неизвестном, изменённом или отозванном ключе остановитесь. Успешный вход по паролю не заменяет проверку подлинности сервера.
Также нужны собственный домен, работающий DNS и возможность обслуживать TCP 80 и 443. Здесь используется HTTPS поверх TCP, без настройки QUIC. Публично доверенный сертификат должен покрывать proxy.example.com. До запуска замените все примерные имена, адрес электронной почты, имя пользователя и пароль. Публикуйте AAAA только при действительно работающем IPv6-пути сервера.
Определите, нужна ли задаче эксплуатация ОС и клиента на основе Chromium. Если требуется только повседневный выход в интернет, сравните обязанности при использовании VPS и VPN. NaiveProxy реализует прикладной прокси; объяснение роли Xray и V2Ray помогает отличать ядро от полной схемы маршрутизации устройства.
Сохраните исходное состояние
На новом выделенном сервере зафиксируйте ОС, архитектуру, слушающие процессы, правила межсетевого экрана и существующую службу сертификатов. Резервные копии конфигурации и сертификатов должны быть доступны только администраторам. Выполните ss -lntup с достаточными правами и определите владельцев TCP 80 и 443. Если порты заняты, сначала разрешите конфликт; не останавливайте постороннюю службу ради примера.
Сохраните доступ SSH с управляющего адреса. Добавляйте только необходимые TCP-правила в локальном экране и экране провайдера, не отключая их. Проверьте время и пакеты CA на обеих машинах: неверные часы тоже нарушают проверку сертификатов.
Шаг 1: установите официальный сервер и разделите файлы
Скачайте серверный файл Linux amd64 со страницы закреплённого выпуска forwardproxy, а клиентский архив Linux x64 — со страницы NaiveProxy. Используйте официальные страницы, изучите примечания и опубликованные сведения о целостности, распакуйте файлы в закрытых временных каталогах. Не выполняйте скачанный shell-установщик. Этот выпуск клиента рекомендует указанную версию Naive Caddy.［1］［2］
Команды ниже предполагают, что извлечённый сервер называется ./caddy, а системного пользователя naive-caddy ещё нет. Если учётная запись существует, сначала выясните её назначение, не меняя владельцев файлов вслепую.
sudo useradd --system --home-dir /var/lib/naive-caddy --shell /usr/sbin/nologin naive-caddy
sudo install -d -o root -g root -m 0755 /opt/naive-caddy/v2.11.7-naive
sudo install -o root -g root -m 0755 ./caddy /opt/naive-caddy/v2.11.7-naive/caddy
sudo install -d -o root -g naive-caddy -m 0750 /etc/naive-caddy
sudo install -d -o naive-caddy -g naive-caddy -m 0700 /var/lib/naive-caddy
sudo install -d -o root -g root -m 0755 /var/www/naive-site
/opt/naive-caddy/v2.11.7-naive/caddy version
/opt/naive-caddy/v2.11.7-naive/caddy list-modules
Требуйте ожидаемую версию и модуль http.handlers.forward_proxy. Служба может записывать состояние сертификатов, но не заменять принадлежащие root программу и конфигурацию. Для управления сертификатами Caddy нужен постоянный доступный для записи каталог. Не используйте временный домашний каталог и не очищайте состояние при обычном обслуживании.［3］
Шаг 2: аутентификация NaiveProxy и HTTPS
Сгенерируйте отдельные случайные имя и пароль через менеджер паролей или openssl rand -hex 24. Шестнадцатеричный формат устраняет неоднозначность экранирования URL. Сохраните значения конфиденциально, не помещая их в аргументы команд, снимки экрана, обращения в поддержку или общие журналы. Через sudoedit создайте /etc/naive-caddy/Caddyfile:
{
order forward_proxy before file_server
log {
exclude http.log.error
}
}
:443, proxy.example.com {
tls admin@example.com
forward_proxy {
basic_auth REPLACE_USER REPLACE_PASSWORD
hide_ip
hide_via
probe_resistance
}
file_server {
root /var/www/naive-site
}
}
Оставьте :443 первым, как требует пример проекта. probe_resistance меняет обработку неаутентифицированных проб: обычный ответ сайта не доказывает разрешение CONNECT. В веб-каталоге размещайте только намеренно публичную статическую страницу, без секретов и содержимого, которое вы не собирались публиковать.［4］
Перед открытием слушающего порта защитите и проверьте файл:
sudo chown root:naive-caddy /etc/naive-caddy/Caddyfile
sudo chmod 0640 /etc/naive-caddy/Caddyfile
sudo -u naive-caddy /opt/naive-caddy/v2.11.7-naive/caddy validate --config /etc/naive-caddy/Caddyfile --adapter caddyfile
Проверка подтверждает подготовку конфигурации, но не выпуск сертификата и не передачу данных. Ошибка здесь означает остановку. Сначала проверьте сборку, модуль, синтаксис и разрешения чтения.
Шаг 3: запустите службу и локальный клиент
От root создайте /etc/systemd/system/naive-caddy.service. Отдельный unit предоставляет возможность привязки низких портов вместо запуска демона от root. Каталог данных сохраняется после перезапуска. Caddy описывает systemd как способ управления службой.［3］
[Unit]
Description=Naive Caddy proxy
After=network-online.target
Wants=network-online.target
[Service]
User=naive-caddy
Group=naive-caddy
Environment=HOME=/var/lib/naive-caddy
WorkingDirectory=/var/lib/naive-caddy
ExecStart=/opt/naive-caddy/v2.11.7-naive/caddy run --config /etc/naive-caddy/Caddyfile --adapter caddyfile
ExecReload=/opt/naive-caddy/v2.11.7-naive/caddy reload --config /etc/naive-caddy/Caddyfile --adapter caddyfile
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/naive-caddy
Restart=on-failure
RestartSec=5
UMask=0077
[Install]
WantedBy=multi-user.target
Выполните sudo systemctl daemon-reload, затем sudo systemctl enable --now naive-caddy. Посмотрите systemctl status naive-caddy, закрытый административный journal и владельцев портов. При ошибках сертификата исправляйте DNS, доступность портов, права или время. Не добавляйте клиенту обход проверки TLS.
На клиентской Ubuntu установите извлечённый naive в принадлежащий root каталог версии, например /opt/naive-client/v154.0.8037.49-4/naive. Создайте каталог своего пользователя с режимом 0700 и файл config.json с режимом 0600:
{
"listen": "socks://127.0.0.1:1080",
"proxy": "https://REPLACE_USER:REPLACE_PASSWORD@proxy.example.com"
}
Запустите исполняемый файл, передав путь закрытой конфигурации, а не секреты в командной строке. Для первого испытания оставьте процесс на переднем плане. Настройте только тестовое приложение на SOCKS5 127.0.0.1:1080, сохранив прежние настройки. Сравнение TUN и системного прокси объясняет, почему остальные приложения могут вообще не использовать этот вход.
Как проверить передачу данных и отказ в доступе?
Для воспроизводимых проверок используйте небольшой HTTPS-ресурс под вашим управлением. В curl явно выберите SOCKS и исключите обход через NO_PROXY:
curl --fail --show-error --noproxy '' --proxy socks5h://127.0.0.1:1080 https://check.example.net/health
Замените ресурс своей разрешённой целью. socks5h запрашивает разрешение имени через прокси только для этого обращения curl. Поведение DNS остальных программ из него не следует. Проверяйте закрытые журналы, не публикуя данные доступа и посещённые адреса.
Для каждого отрицательного случая с копией клиента остановите прежний испытательный процесс на переднем плане, запустите только изменённую копию на том же локальном порту и проверьте владельца слушающего сокета. Меняйте одно условие за раз; перед следующим случаем восстановите правильный файл и повторите положительный запрос.
| Метод проверки | Ожидаемое поведение | Действие при ошибке |
|---|---|---|
| Правильная закрытая конфигурация клиента | Контрольный ресурс возвращает ожидаемое содержимое | Разделите локальный вход, TLS сервера, аутентификацию и ошибки назначения |
| Копия конфигурации с другим корректным hex-паролем | Проксирование не работает | При успехе проверьте процесс, выбранный файл и обход до публикации службы |
| CONNECT через HTTPS-прокси curl без учётных данных | Разрешённый туннель к контрольной цели не создаётся | Не требуйте именно 407: защита от проб может скрывать отказ |
| Копия с другим собственным доменом, ведущим на сервер, но отсутствующим в сертификате | Проверка имени TLS завершается ошибкой | Верните правильное имя, не отключайте проверку сертификата |
Перезапуск только naive-caddy и новый запрос | Новое разрешённое обращение работает после запуска | Проверьте постоянное состояние, пользователя службы и права |
Для проверки без аутентификации выполните curl --noproxy '' --proxy https://proxy.example.com:443 https://check.example.net/health без пароля. Требуется убедиться, что контрольная цель не достигнута через разрешённый туннель. Доступность публичной страницы прикрытия этого не доказывает.
В настроенном браузере откройте инструмент проверки IP и сравните адрес с ожидаемым выходом сервера. Результат относится только к запросу браузера; он не подтверждает UDP, IPv6, весь DNS или все приложения. После каждого отрицательного случая восстановите правильный файл и повторите положительный запрос.
Как обслуживать продление сертификата NaiveProxy и обновления?
Caddy автоматизирует выпуск и продление, пока работают DNS, доступ для проверок CA, хранилище и сам удостоверяющий центр. Запишите срок действия и отслеживайте ошибки службы. Перезапуск с ещё действительным сертификатом не является проверкой продления.［5］
Разделяйте staging и рабочую среду
Для упражнения с ACME выделите отдельные имя, схему портов службы, учётную запись и хранилище. Укажите staging ACME через параметр Caddy acme_ca. На изолированном клиенте Ubuntu получите сертификаты назначенного тестового CA из официального источника и задайте SSL_CERT_FILE с явным набором доверия только для процесса Naive. Проверка имени остаётся включённой. Не устанавливайте тестовые корни системно и не смешивайте это хранилище с рабочим.［6］［7］
Сначала зафиксируйте первый выпуск staging-сертификата. Для доказательства продления нужен последующий заменяющий сертификат и сведения о соответствующем событии. Если имеется только первый сертификат, продление остаётся непроверенным. Не удаляйте рабочее хранилище и не вызывайте повторный выпуск ради искусственного результата.
Перед обновлением сохраните рабочий бинарный файл, закрытую конфигурацию, unit и состояние сертификатов в резервной копии только для администраторов. Изучите выпуски и сообщения о безопасности обоих проектов: обновления Chromium относятся к обязанности владельца клиента. Поместите новую версию в другой каталог, проверьте конфигурацию, измените путь программы только этого unit и повторите положительные, отрицательные проверки и перезапуск. Откат возвращает прежний путь и совместимую конфигурацию; это временное восстановление, а не основание бесконечно хранить уязвимую версию.
Отзовите доступ и удалите службу
Замените или удалите нужную запись basic_auth, проверьте файл и перезагрузите конфигурацию этого unit. Если требуется прекратить уже установленные туннели, остановите и запустите службу, учитывая прерывание остальных пользователей. Старые данные должны перестать работать в новом соединении, а новые — работать. Для полного выключения восстановите настройки прокси приложения, остановите клиент, отключите и остановите naive-caddy, удалите только его правила межсетевого экрана. Храните закрытые материалы восстановления до окончания потребности в откате, затем безопасно выведите из обращения секреты и ненужные DNS-записи.
Итоги
Разделяйте совместимый сервер, состояние сертификатов и клиентскую конфигурацию как разные границы обслуживания. Принимайте маршрут только после успешной разрешённой передачи, отказов в отрицательных случаях, перезапуска и отзыва. Инструкция предоставляет методы проверки, не заявляя о пройденном авторском развёртывании.
Часто задаваемые вопросы (FAQ)
Подходит ли обычный пакет Caddy для NaiveProxy?
Для этого маршрута используйте готовый Naive-совместимый выпуск. Обычный пакет не подтверждает наличие нужного forward-proxy модуля и совместимость padding.
Доказывает ли TLS-рукопожатие аутентификацию NaiveProxy?
Нет. Проверьте запрос через авторизованный клиент и повторите его с неверными данными, используя собственный ресурс для обнаружения случайного обхода.
Зачем ограничивать клиент Naive адресом loopback?
Открытый другим машинам локальный SOCKS без аутентификации может позволить использовать ваши удалённые данные доступа. Loopback ограничивает сетевую доступность клиентским хостом.
Обязан ли CONNECT без аутентификации возвращать HTTP 407?
Нет. Защита от проб может скрывать границу доступа. Важен отказ в разрешённой передаче через туннель, а не конкретный код ответа.
Можно ли отключить проверку TLS для staging?
Оставьте проверку включённой и явно доверьтесь назначенному тестовому CA только в изолированном процессе клиента. После упражнения удалите тестовое доверие.
Подтверждает ли перезапуск Caddy продление сертификата?
Нет. Он может повторно использовать прежний сертификат. Продление требует подтверждения замены сертификата в ходе жизненного цикла, а не просто успешного запуска.
Прерывает ли смена пароля установленные туннели?
Не предполагайте этого. При немедленном отзыве прекратите существующие соединения, затем проверьте отказ новых соединений со старыми данными доступа.
Источники:
- NaiveProxy client release v154.0.8037.49-4 — https://github.com/klzgrad/naiveproxy/releases/tag/v154.0.8037.49-4
- Naive Caddy release v2.11.7-naive — https://github.com/klzgrad/forwardproxy/releases/tag/v2.11.7-naive
- Caddy: running as a service — https://caddyserver.com/docs/running
- NaiveProxy: server and client configuration — https://github.com/klzgrad/naiveproxy
- Caddy: automatic HTTPS — https://caddyserver.com/docs/automatic-https
- Caddyfile: global options — https://caddyserver.com/docs/caddyfile/options
- Let's Encrypt: staging environment — https://letsencrypt.org/docs/staging-environment/
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
