Настройка обратного прокси на Synology DSM в 2026 году: пошаговое руководство

Встроенный обратный прокси в Synology DSM решает задачу публикации нескольких внутренних веб-сервисов через один внешний IP-адрес. Вы настраиваете правило, которое принимает HTTPS-запросы на поддомен и бесшумно перенаправляет их на нужный порт вашего NAS, где работает Nextcloud, Docker-контейнер или любое другое приложение. Эта инструкция проверена на DSM 7.2 и более новых версиях 2026 года. Она проведет вас от проверки сетевых предпосылок до устранения ошибки 502 Bad Gateway.

В основе механизма лежит nginx, но Synology полностью упаковала его в графический интерфейс. Вам не придется писать конфигурационные файлы вручную. Достаточно заполнить поля «Источник» и «Назначение», привязать SSL-сертификат и при необходимости включить перенаправление заголовка Host. Если вы ранее использовали внешний Nginx или Traefik, встроенный прокси DSM закроет 80% типовых сценариев без дополнительных контейнеров и сложной оркестрации. Для более глубокого понимания архитектуры обратного прокси и его роли в современных окружениях изучите наш материал по возможностям и ограничениям прокси-решений.

Что такое обратный прокси в DSM и зачем он нужен

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

В контексте Synology NAS эта схема дает три ключевых преимущества. Первое: единая точка входа для десятка приложений. Вы можете держать открытыми только порты 80 и 443, а все внутренние сервисы - Photo Station, Drive, веб-интерфейсы Docker-контейнеров, кастомные приложения - будут доступны по своим поддоменам. Второе: терминация SSL. Сертификат настраивается один раз на прокси, внутренние сервисы могут работать по HTTP без шифрования. Третье: сокрытие внутренней инфраструктуры. Номера портов, на которых висят приложения, никогда не светятся наружу.

Когда встроенного прокси достаточно, а когда стоит смотреть в сторону внешних решений? Если ваши сценарии ограничиваются пробросом HTTP/HTTPS-трафика к веб-интерфейсам и вы не планируете сложную балансировку нагрузки или кастомные правила кеширования, встроенный механизм DSM полностью покрывает потребности. Для продвинутых случаев - например, rate limiting, health checks, интеграция с CrowdSec - лучше развернуть отдельный Nginx Proxy Manager в Docker. Он дает более тонкий контроль над заголовками и политиками безопасности.

Подготовка DSM к настройке обратного прокси

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

Проверка версии DSM и прав доступа

Обратный прокси доступен в DSM начиная с версии 6.0, но интерфейс и расположение настроек могут отличаться. Эта инструкция ориентирована на DSM 7.2 и новее, актуальные на август 2026 года. Чтобы проверить версию, откройте «Центр обновлений» в Панели управления. В верхней части окна отображается текущая версия DSM. Если доступно обновление, установите его до начала настройки - это исключит баги, исправленные в последних релизах.

Для работы с обратным прокси требуется учетная запись из группы administrators. Учетки с правами обычного пользователя не видят раздел «Портал входа». Проверьте свою роль: Панель управления → Пользователи и группы → найдите свою учетную запись → вкладка «Группы». Если группы administrators нет в списке, войдите под администратором и добавьте.

Сетевые предпосылки: порты, DNS и файрвол

Обратный прокси работает на уровне приложений внутри DSM, но чтобы запросы из интернета дошли до него, нужна правильная сетевая обвязка. На роутере должны быть проброшены порты 80 (HTTP) и 443 (HTTPS) на внутренний IP-адрес вашего Synology NAS. Проверьте, что IP-адрес NAS статический - либо задан вручную в настройках сетевого интерфейса, либо зарезервирован по MAC-адресу в DHCP-сервере роутера.

Если провайдер выдает динамический внешний IP, настройте DDNS. В DSM это делается через Панель управления → Внешний доступ → DDNS. Synology предоставляет собственный сервис synology.me, но поддерживаются и сторонние провайдеры. После активации DDNS ваш NAS будет доступен по постоянному доменному имени, даже когда внешний IP меняется.

DNS-записи - следующий обязательный шаг. Каждый поддомен, который вы планируете использовать для проксирования (например, cloud.example.com для Nextcloud или app.example.com для Docker-контейнера), должен быть прописан в DNS-зоне вашего домена. Создайте A-запись, указывающую на внешний IP-адрес, или CNAME-запись, ссылающуюся на ваш DDNS-хост. Без этого Let's Encrypt не сможет выпустить сертификат, а браузер не найдет ваш сервер.

Последний штрих - брандмауэр DSM. Откройте Панель управления → Безопасность → Брандмауэр. Если брандмауэр активен, создайте правило, разрешающее входящие соединения на порты 80 и 443 с любых внешних адресов. Без этого правила пакеты будут отброшены еще до того, как их увидит обратный прокси.

Пошаговая настройка обратного прокси в интерфейсе DSM

Все манипуляции выполняются в разделе «Портал входа». Перейдите: Панель управления → Портал входа → вкладка «Дополнительно» → кнопка «Обратный прокси». Откроется список существующих правил. Если вы здесь впервые, список пуст.

Создание правила прокси: поля Источник и Назначение

Нажмите «Создать». Откроется форма с двумя блоками: «Источник» и «Назначение». Источник описывает, как клиенты будут обращаться к сервису извне. Назначение указывает, куда прокси должен перенаправить запрос внутри вашей сети.

Разберем типовой сценарий: у вас на NAS работает веб-интерфейс Docker-контейнера на порту 9000, и вы хотите открыть к нему доступ по HTTPS через поддомен app.example.com. Заполняем поля:

Протокол источника: HTTPS. Вы будете принимать зашифрованные соединения из интернета.
Имя хоста источника: app.example.com. Именно этот поддомен клиенты будут вводить в браузере.
Порт источника: 443. Стандартный порт для HTTPS.
Протокол назначения: HTTP. Внутренний сервис слушает без шифрования - прокси сам расшифрует трафик.
Имя хоста назначения: localhost. Приложение работает на том же NAS, где и прокси.
Порт назначения: 9000. Порт, на котором висит ваш контейнер.

Когда указывать localhost, а когда IP-адрес? Если сервис запущен непосредственно на Synology NAS (пакет из Центра пакетов, Docker-контейнер в сетевом режиме bridge с пробросом портов на хост), используйте localhost или 127.0.0.1. Если сервис работает на другом физическом устройстве в локальной сети - например, на отдельном сервере с IP 192.168.1.100 - указывайте этот IP в поле «Имя хоста назначения». Для Docker-контейнеров в режиме host указывайте localhost, так как они разделяют сетевой стек с хостом.

Если вы хотите принимать и HTTP-запросы, создайте отдельное правило с протоколом источника HTTP и портом 80. В этом правиле можно включить HSTS или настроить редирект на HTTPS, но проще создать второе правило, которое будет перенаправлять HTTP на HTTPS. Для этого в блоке «Источник» укажите HTTP и порт 80, а в блоке «Назначение» - HTTPS и порт 443 того же хоста.

Настройка заголовков для корректной работы приложений

Многие веб-приложения чувствительны к заголовку Host. Когда клиент отправляет запрос на app.example.com, заголовок Host содержит app.example.com. Прокси передает запрос на localhost:9000, и если заголовок Host не изменить, приложение увидит localhost:9000. Это ломает генерацию абсолютных URL, редиректы после логина и загрузку статических ресурсов.

Симптомы проблемы: после входа в Nextcloud вас перебрасывает на http://localhost:8080/login, или страница загружается без стилей, потому что CSS-файлы запрашиваются с неправильного хоста. Решение - включить опцию «Перенаправлять заголовок Host» в правиле прокси. Она находится в форме создания/редактирования правила, под полями «Назначения». При активации этой опции прокси подставляет в заголовок Host то значение, которое указано в поле «Имя хоста источника». Приложение получает app.example.com и корректно формирует все ссылки.

Для Nextcloud этого недостаточно - нужно дополнительно прописать доверенные домены в конфигурационном файле config.php. Подробнее об этом в разделе практических сценариев.

Настройка HTTPS и SSL-сертификатов для обратного прокси

Без HTTPS современные браузеры помечают сайт как небезопасный, а некоторые веб-приложения отказываются работать через незашифрованное соединение. Встроенный обратный прокси DSM использует сертификаты, управляемые через Панель управления → Безопасность → Сертификат.

Выпуск и установка сертификата Let's Encrypt

Let's Encrypt предоставляет бесплатные доверенные сертификаты с автоматическим продлением. Для выпуска сертификата через DSM выполните условия:

Домен или поддомен, для которого выпускается сертификат, должен резолвиться во внешний IP-адрес вашего NAS. Проверьте командой nslookup app.example.com с внешнего хоста.
Порт 80 должен быть открыт и доступен из интернета - Let's Encrypt использует HTTP-валидацию.
Если вы выпускаете wildcard-сертификат (*.example.com), потребуется DNS-валидация. DSM поддерживает её для ограниченного списка провайдеров.

Процесс выпуска: Панель управления → Безопасность → Сертификат → Добавить → Получить сертификат от Let's Encrypt. Введите доменное имя (например, app.example.com или *.example.com для wildcard), укажите email для уведомлений об истечении срока. Нажмите «Готово». DSM свяжется с серверами Let's Encrypt, проведет валидацию и установит сертификат.

Распространенная ошибка - превышение лимита запросов. Let's Encrypt разрешает выпускать не более 5 сертификатов на один домен в неделю. Если вы экспериментируете и несколько раз перевыпускаете сертификат, можно упереться в лимит. Решение - подождать или использовать staging-окружение Let's Encrypt для тестов, но DSM не предоставляет такой опции в GUI.

Привязка сертификата к правилу обратного прокси

После выпуска сертификата его нужно привязать к правилу прокси. Откройте список правил обратного прокси, выберите нужное правило, нажмите «Настроить». В открывшемся окне найдите выпадающий список «Сертификат» и выберите сертификат, который только что выпустили. Сохраните изменения.

Если вы используете один wildcard-сертификат для всех поддоменов, достаточно привязать его один раз к каждому правилу. DSM автоматически подхватывает обновленный сертификат при продлении - ручного вмешательства не требуется. Проверьте работу HTTPS: откройте браузер, перейдите по адресу https://app.example.com. В адресной строке должен отображаться закрытый замок без предупреждений.

Для проектов, где требуется повышенная безопасность, например при интеграции хранилища с корпоративным доменом, обратите внимание на наш материал по настройке SSL/TLS для серверных соединений. Принципы работы с сертификатами, описанные там, применимы и к окружению Synology.

Практические сценарии: Nextcloud, Docker-контейнеры и другие приложения

Теория становится понятной на конкретных примерах. Ниже - три проверенных сценария с точными параметрами, которые можно скопировать и адаптировать под свою среду.

Проксирование Nextcloud

Nextcloud, установленный через Центр пакетов Synology, по умолчанию слушает на портах 80 и 443 через веб-сервер Apache, встроенный в пакет. Если эти порты уже заняты обратным прокси, возникает конфликт. Решение - переназначить порты Nextcloud на нестандартные и пустить трафик через прокси.

Параметры правила для Nextcloud, который после перенастройки слушает HTTP на порту 8080:

Источник: HTTPS, cloud.example.com, порт 443
Назначение: HTTP, localhost, порт 8080
Перенаправлять заголовок Host: включено

Обязательный дополнительный шаг - настройка доверенных доменов в config.php Nextcloud. Подключитесь к NAS по SSH и выполните:

sudo -u httpd php /volume1/web/nextcloud/occ config:system:set trusted_domains 1 --value=cloud.example.com

Путь к occ может отличаться в зависимости от версии пакета и места установки. Без этой команды Nextcloud будет отвечать ошибкой «Доступ через недоверенный домен».

Проксирование Docker-контейнеров

Вы запустили контейнер с веб-интерфейсом, например Portainer или Homepage, командой:

docker run -d -p 9000:9000 portainer/portainer-ce

Контейнер слушает на порту 9000 на хосте. Правило прокси:

Источник: HTTPS, portainer.example.com, порт 443
Назначение: HTTP, localhost, порт 9000
Перенаправлять заголовок Host: включено

Если контейнер запущен в сетевом режиме bridge с пробросом портов, localhost работает. Если вы используете macvlan-сеть и контейнер получил собственный IP-адрес (например, 192.168.1.200), укажите этот IP в поле «Имя хоста назначения». Режим host не требует изменений - контейнер делит сетевой стек с хостом, и localhost по-прежнему корректен.

Проксирование приложений с WebSocket

Home Assistant, Code-server, VS Code Server и многие современные веб-приложения используют WebSocket для двусторонней связи между клиентом и сервером. Если прокси не поддерживает WebSocket, приложение теряет соединение, интерфейс зависает или не обновляется в реальном времени.

Встроенный обратный прокси DSM поддерживает WebSocket из коробки. Никаких дополнительных настроек включать не нужно. Создайте правило как обычно, с теми же параметрами источника и назначения. Для проверки откройте консоль разработчика в браузере (F12), перейдите на вкладку Network, отфильтруйте по WS. Вы должны увидеть установленное WebSocket-соединение с кодом 101 Switching Protocols. Если соединение падает с ошибкой, проверьте, что приложение не требует обязательного HTTPS на стороне назначения - в поле «Протокол назначения» можно указать HTTPS и соответствующий порт.

Если вы выбираете NAS для домашней инфраструктуры или небольшого офиса, где подобные сценарии будут основными, рекомендуем ознакомиться с нашим сравнением Synology, QNAP и TrueNAS. Оно поможет оценить, насколько встроенные возможности DSM соответствуют вашим задачам.

Типовые ошибки и их решение

Даже при точном следовании инструкции что-то может пойти не так. Ниже - три самые частые проблемы, их симптомы и способы исправления.

Ошибка 502 Bad Gateway

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

Сервис не запущен. Проверьте, работает ли приложение: выполните на NAS curl http://localhost:9000 (подставьте свой порт). Если curl возвращает ошибку соединения, приложение упало или не стартовало.
Неверный порт назначения в правиле прокси. Сверьте порт, который вы указали в поле «Порт назначения», с фактическим портом приложения. Для Docker-контейнеров проверьте командой docker ps - в колонке PORTS отображается маппинг.
Брандмауэр DSM блокирует соединение на внутренний порт. Даже если порт открыт для внешних подключений, локальные соединения между компонентами DSM могут фильтроваться. Временно отключите брандмауэр для диагностики. Если проблема исчезла, добавьте правило, разрешающее трафик с localhost на нужный порт.

Проблемы с заголовком Host и редиректами

Симптом: после успешного входа в приложение URL в адресной строке браузера меняется на http://localhost:8080 или http://192.168.1.10:9000. Приложение редиректит на внутренний адрес, потому что не знает свой внешний домен.

Решение - включить «Перенаправлять заголовок Host» в правиле прокси. Если опция уже включена, но проблема сохраняется, приложение может игнорировать заголовок Host и использовать собственную переменную для формирования URL. В этом случае настройте base URL в конфигурации самого приложения. Для Nextcloud это параметр overwrite.cli.url в config.php. Для других приложений ищите в документации параметры вроде «External URL», «Base URL» или «Server URL».

Ошибки SSL и сертификатов

NET::ERR_CERT_COMMON_NAME_INVALID - браузер сообщает, что имя в сертификате не совпадает с доменом в адресной строке. Причины:

Сертификат выпущен на другой домен. Проверьте, что в правиле прокси выбран именно тот сертификат, который покрывает ваш поддомен. Если у вас несколько сертификатов, легко перепутать.
Сертификат привязан не к тому правилу. Откройте правило, нажмите «Настроить» и проверьте выбранный сертификат.
Истек срок действия. Let's Encrypt выпускает сертификаты на 90 дней. DSM должен продлевать их автоматически, но если автообновление отключено или порт 80 был недоступен в момент продления, сертификат истекает. Проверьте статус в Панель управления → Безопасность → Сертификат.

Для принудительного обновления выберите сертификат в списке и нажмите «Продлить». Если продление завершается ошибкой, временно отключите брандмауэр и повторите попытку.