Глубокий NPM: редиректы и Access Lists for ComfyUI

В NPM есть полезные фишки, о которых я рассказываю по просьбе читателей: Access Lists — ограничение доступа по IP, Custom Locations — проксирование конкретных путей, Streaming — поддержка WebSocket. Я через NPM настроил доступ к ComfyUI только из домашней сети. Ещё сделал редирект: если зайти на domain.com/grafana — открывается Grafana. Сегодня разберу эти возможности подробнее, потому что именно они делают NPM по-настоящему мощным.

Access Lists: контроль доступа по IP

Access Lists — это списки, которые ограничивают доступ к сервису по IP-адресу. Я использую их для панелей и сервисов, которые не хочу открывать всему миру. В интерфейсе NPM создаю список, добавляю разрешённые адреса и привязываю его к нужному хосту.

Мой главный пример — ComfyUI. Нейросетевая генерация требует много ресурсов, и я не хочу, чтобы кто-то посторонний запускал её на моём сервере. Через Access Lists я ограничил доступ только домашней сетью. Снаружи сервис просто не отвечает.

Настройка Access Lists по шагам

Покажу на примере, как я создавал Access List для ComfyUI. В панели NPM открываю раздел Access Lists, жму создать, задаю имя списка. Потом добавляю разрешённые адреса — у меня это диапазон домашней сети. Сохраняю список и привязываю его к хосту ComfyUI.

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

Почему я ограничиваю доступ

Ограничение доступа к чувствительным сервисам — это вопрос безопасности. ComfyUI не требует авторизации по умолчанию, поэтому любой, кто узнает адрес, сможет гонять мои нейросети за мой счёт. Access Lists закрыли эту проблему полностью.

Я рекомендую закрывать таким образом все сервисы без встроенной авторизации: панели, базы данных, админки. Правило простое: если сервис не требует пароля, пусть хотя бы ограничивается по IP. Это база, о которой многие забывают.

Несколько правил в одном списке

В Access List можно добавлять не только адреса, но и правила. Например, я разрешаю доступ из домашней сети всегда, а для работы разрешаю ещё и свой рабочий IP. Сочетание правил легко поддерживать в одном списке.

Управление списками интуитивное: добавил адрес, сохранил — правило применилось. Я пересоздавал списки несколько раз, пока не выстроил удобную структуру. Теперь у меня отдельные списки для домашних сервисов и для рабочих задач.

Custom Locations: проксирование путей

Custom Locations позволяют направлять конкретные пути домена на разные сервисы. Например, я сделал так, что domain.com/grafana открывает Grafana, а остальные пути ведут на основной сайт. Это удобно, когда не хочется заводить отдельный домен под каждый сервис.

Настройка простая: в разделе хоста добавляю Location, указываю путь и адрес внутреннего сервиса. Прописываю правило для пути /grafana и привязываю к порту Grafana. После сохранения всё работает без перезапуска nginx.

Streaming и WebSocket

Для приложений реального времени нужна поддержка WebSocket. Без неё соединения обрываются, и приложение ведёт себя непредсказуемо. В NPM поддержка включается в настройках хоста, и это решает проблему одним флажком.

Я столкнулся с этим, когда подключал сервис с чатом. Сначала сообщения не приходили в реальном времени, пришлось разбираться. Оказалось, нужно включить поддержку WebSocket в NPM. После этого всё заработало как надо.

Тонкости работы с путями

При настройке Custom Locations важно понимать, как путь передаётся сервису. Некоторые приложения ожидают свой путь без префикса, а другие — с ним. Я настраивал Grafana через /grafana и потратил немного времени, пока понял, куда должны указывать заголовки.

В NPM есть поле для переопределения пути, которое решает эту проблему. Указываешь путь, по которому сервис ждёт запрос, и всё начинает работать. Такие мелочи становятся очевидными только после практики.

Заголовки при проксировании

Для корректной работы многих приложений за прокси нужны правильные заголовки. NPM умеет передавать IP клиента, реальный протокол и другие данные. Я включаю нужные заголовки в настройках хоста, чтобы сервисы видели реальные данные посетителей.

Без правильных заголовков логи и аналитика показывали неправильные данные — все запросы выглядели как идущие с сервера. После настройки всё стало отображаться корректно. Это важно, если вы ведёте статистику посещаемости.

WebSocket и способы применения

Поддержку WebSocket я использовал не только для чатов. У меня есть дашборды, которые обновляются в реальном времени, и без WebSocket они работали бы с задержкой. NPM исправил это одной настройкой.

Если вы разрабатываете или эксплуатируете сервисы с живыми обновлениями, обязательно включайте поддержку WebSocket в NPM. Это маленький флажок, который экономит часы разбирательств с обрывами соединений.

Редиректы: перенаправление запросов

Редиректы в NPM позволяют перенаправлять пользователя с одного адреса на другой. Я пользуюсь ими для того, чтобы упростить доступ к сервисам. Например, домен.com/grafana автоматически открывает панель Grafana без лишних движений.

Настройка занимает минуту: указываю источник и цель, сохраняю. NPM сам обрабатывает перенаправление. Это очень удобно, когда сервисов много и хочется собрать всё под одним доменом с понятными путями.

Как проверять работу настроек

После каждой настройки я проверяю результат с разных адресов. Захожу на сервис из дома, чтобы убедиться, что доступ работает, и пробую извне через мобильную сеть, чтобы проверить ограничения. Такая проверка занимает минуту, но даёт уверенность.

Иногда полезно смотреть логи NPM. Там видно, какие запросы приходили и как они обработаны. Если что-то работает не так, логи подсказывают, в чём дело. Я привык заглядывать в логи при любых странностях.

Частые ошибки при настройке

Самая частая ошибка — указать неверный внутренний адрес сервиса. NPM не сможет достучаться до цели и выдаст ошибку. Я всегда перепроверяю адреса и порты, когда настраиваю новый хост. Лучше лишний раз проверить, чем гадать.

Вторая ошибка — забыть про порт в пути. Если сервис слушает нестандартный порт, его нужно указывать в адресе цели. Иначе запрос уйдёт не туда. С этими двумя вещами связано большинство моих первых неудач.

Почему я выбрал путь в домене

Использование путей вместо поддоменов имеет свои плюсы. Не нужно покупать сертификаты на каждый поддомен, всё работает под одним доменом. Минус — приложения должны уметь работать под путём. Для моих сервисов это оказалось удобным решением.

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

Практический пример: Grafana под путём

Разберу свой пример с Grafana подробнее. У меня Grafana работает в контейнере на внутреннем порту. Я хотел открыть к ней доступ через основной домен, чтобы не плодить поддомены. Для этого добавил Custom Location с путём /grafana.

В настройках указал путь, адрес контейнера с Grafana и нужные заголовки. После сохранения стал заходить на domain.com/grafana и попадать в панель. Все графики и дашборды работают, как будто Grafana стоит на главном домене.

Обновление сертификатов

При использовании путей сертификаты выпускаются для основного домена. Обновление происходит автоматически в NPM. Я ничего не делаю руками — панель сама продлевает сертификат до истечения срока. Это снимает целый класс забот.

Один раз я столкнулся с проблемой, когда сертификат не обновился. Причиной оказался временно недоступный домен. После проверки доступности всё встало на место. Теперь я слежу за тем, чтобы домены всегда указывали на сервер.

Мониторинг работы хостов

В NPM можно включать мониторинг хостов. Панель периодически проверяет, отвечает ли сервис. Если сервис упал, я вижу это по статусу. Это удобная альтернатива ручной проверке каждого приложения.

Я включил мониторинг для всех своих хостов. Теперь достаточно бросить взгляд на панель, чтобы понять состояние инфраструктуры. При этом сам мониторинг лёгкий и не нагружает сервер.

Советы по порядку действий

Если вы впервые пробуете продвинутые настройки, действуйте постепенно. Сначала освойте Access Lists, потом добавьте пару Custom Locations, затем включите поддержку WebSocket. Каждый шаг проверяйте сразу. Такой порядок не даст запутаться.

Я жалею, что в первый раз не пошёл этим путём, а переключал всё сразу. Пришлось откатывать настройки и разбираться. Постепенность сэкономит вам нервы и время, а результат будет тем же самым.

Влияние на работу сервисов

Правильная настройка NPM заметно улучшает стабильность сервисов. У меня после настройки заголовков и WebSocket перестали обрываться соединения, а логи стали правдивыми. Один раз всё настроив, я забыл про проблемы на долгое время.

Практика показывает: время, потраченное на настройку прокси, возвращается с лихвой. Меньше отказов, меньше разбирательств, меньше ночных звонков. Именно поэтому я рекомендую всем серьёзно подойти к настройке реверс-прокси.

Что в планах дальше

В планах — подключить к NPM ещё несколько сервисов и привести все настройки к единому виду. Я хочу, чтобы каждый новый сервис сразу получал правильные заголовки, поддержку WebSocket и нужные ограничения. Это удобно автоматизировать через шаблоны.

NPM продолжает расти вместе с моей инфраструктурой. Каждый новый сервис подключается быстрее предыдущего, потому что я уже знаю все настройки. Инструмент стал незаменимой частью моего сервера.

Проверка изоляции сервисов

Реверс-прокси помогает изолировать сервисы друг от друга. Все приложения доступны только через NPM, а внутренние порты наружу не открыты. Я специально проверяю, что внутренние порты недоступны извне, и это даёт спокойствие.

Такая схема снижает риск, что кто-то полезет напрямую в приложение, минуя защиту. Всё управление доступом сосредоточено в одной точке. Для домашнего сервера это правильный баланс удобства и безопасности.

Опыт эксплуатации NPM

За время эксплуатации NPM у меня не было серьёзных падений. Панель работает стабильно, конфигурации хранятся надёжно. Даже после перезагрузок сервера все настройки сохраняются, потому что данные лежат в отдельном томе.

Обновления проходят безболезненно, настройки не теряются. Единственное, что нужно помнить — делать бэкапы конфигурации перед крупными обновлениями. Я следую этому правилу и не испытываю проблем.

Итог

Продвинутые настройки NPM открывают широкие возможности. Access Lists защищают сервисы, Custom Locations собирают всё под одним доменом, а Streaming делает приложения реального времени стабильными. Всё это настраивается в панели без правки конфигов.

Продвинутые настройки NPM — продолжение темы проксирования сервисов в моей Proxmox-среде. Весь цикл статей — в сводном гайде. Загляните, там много полезного для построения домашнего сервера.