Всем привет ?
Врываюсь на Хабр с двух ног со своей первой статьей.
Всё чаще меня посещала мысль: а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны? Любознательность и стремление к независимости хранения данных привела меня к идее своего облака, не где-то в далеком ЦОД, а здесь, дома, в гостиной, тихо жужжа в корпусе размером с книгу. Но есть один критически важный нюанс, который отделяет любительскую поделку от полноценной замены коммерческим сервисам — безопасный доступ извне. Зачем нам HTTPS, если для внутренней сети хватило бы и простого HTTP? Ответ выходит далеко за рамки банального «это нужно для шифрования и безопасности».

Нашим полигоном станет Raspberry Pi 5 в компактном корпусе Argon NEO 5 с быстрым M.2 накопителем, на котором будет развернута UmbrelOS. Но для старта нам потребуется не только «железо». Нам нужен собственный зарегистрированный домен. Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов. При планировании работы домашнего сервера, который должен функционировать непрерывно, вопрос стабильного электропитания выходит в приоритете. Внезапное отключение электричества — это не просто несколько минут простоя, это прямой путь к data corruption, поэтому так же рекомендую использовать ИБП.
Смена DNS серверов домена на Cloudflare
Почему Cloudflare?
Во-первых, это бесплатно. Для большинства функций, необходимых домашнему серверу, не требуется платная подписка.
Во-вторых, безопасность «из коробки». Cloudflare предоставляет защиту от ботов, эксплойтов, DDoS, частых запросов API, Web Application Firewall.
В-третьих, простая работа с SSL. Cloudflare полностью интегрирован с протоколом ACME, который используют центры сертификации вроде Let's Encrypt.
Обратная сторона медали: что стоит учитывать:
Наиболее актуальный для пользователей в России минус — это ограничение трафика
Возможна задержка доступа к сайту, со стороны прокси, так как теперь весь трафик проходит через серверы Cloudflare
Конфиденциальность со стороны Cloudflare. Используя Cloudflare, вы по умолчанию доверяете ему весь свой трафик
Итак приступим к первому этапу. Заходим и регистрируемся на Cloudflare. Добавляем домен, и Cloudflare сам нам выдаст адреса двух DNS-серверов. Далее их необходимо ввести на панели управления регистратора домена. Cloudflare автоматически просканирует существующие DNS-записи у вашего текущего хостера и предложит перенести их. Перенос не мгновенный и может занять до 24 часов.

После успешной миграции рекомендую сразу создать A-записи для субдоменов. Мы будем разворачивать не только саму операционную систему UmbrelOS, но и приложения внутри нее, такие как Nextcloud. Best practice — выделить для каждого сервиса свой субдомен, даже с запасом. Все неактивные субдомены можем выделить в "404 Hosts" и при надобности использовать.
Кто такой этот ваш реверс прокси
В UmbrelOS доступно несколько решений для организации обратного прокси — критически важного компонента, который будет направлять трафик с ваших субдоменов на соответствующие приложения внутри сети. Давайте рассмотрим каждого из них.

RP |
Плюсы |
Минусы |
Nginx Proxy Manager |
Встроенная поддержка Let's Encrypt |
Более высокое потребление ресурсов |
Широкие возможности кастомизации |
Избыточность для простых сценариев |
|
Основа основ |
Отсутствие мониторинга |
|
Много документации |
||
Zoraxy |
Минималистичный и легковесный |
Ограниченные возможности SSL |
Простота настройки |
Меньше документации |
|
Наличие мониторинга |
||
OpenResty Manager |
Гибкость конфигурации |
Меньше готовых решений "из коробки" |
Расширенные возможности |
Меньше документации |
|
Наличие мониторинга |
Мой выбор - Nginx Proxy Manager во многом благодаря привычке и отлаженности процесса. Однако при его использовании в UmbrelOS есть важный нюанс, про который не могу не сказать. В целях безопасности и избежания конфликтов, NPM внутри UmbrelOS использует нестандартные порты:
HTTP → порт 40080
HTTPs → порт 40443
Чтобы весь входящий интернет-трафик перенаправлялся в нашу домашнюю сеть на правильные порты Nginx Proxy Manager, нужно настроить на роутере (в нашем случае MikroTik) правила dst-nat.

Не забываем про masquerade. Правило masquerade необходимо для того, чтобы пакеты, возвращающиеся из вашей локальной сети обратно в интернет, помнили свой исходный путь. Без этого правило dst-nat может не работать корректно, так как ответные пакеты от сервера пойдут напрямую клиенту в обход роутера, и соединение не установится.
По горам с NPM и SSL
Теперь, когда инфраструктура готова, пришло время создать первый прокси-хост в Nginx Proxy Manager. Это мост между нашим доменом и локальным сервисом.

Открываем веб-интерфейс Nginx Proxy Manager и переходим в раздел "Proxy Hosts". Нажимаем кнопку добавления нового хоста. В поле "Domain Names" вводим полный адрес, который мы зарезервировали ранее для доступа к самой UmbrelOS. Убеждаемся, что в настройках "Scheme" выбрано http, так как внутри нашей локальной сети нет HTTPS. Поле "Forward Hostname / IP" должно содержать локальный IP-адрес вашего сервера Umbrel в сети. В поле "Forward Port" указываем стандартный порт 80, на котором работает веб-интерфейс UmbrelOS.
После сохранения конфигурации можно проверить ее работоспособность. Попробуйте перейти в браузере по доменному адресу. На этом этапе вы, скорее всего, увидите ошибку "521 — Host error". Эта ошибка означает, что доменное имя корректно резолвится и запрос доходит до вашего сервера, но сам веб-сервис пока недоступен извне. Причина в том не настроили корректную работу с SSL-сертификатами.
Во вкладке SSL для созданного прокси-хоста выбираем опцию «Запросить новый SSL-сертификат». Откроется форма с несколькими важными параметрами, которые необходимо настроить. Активируем чекбокс «Force SSL» — это гарантирует, что все HTTP-соединения будут автоматически перенаправляться на защищенный HTTPS-протокол. Указываем действующий email адрес для уведомлений от Let's Encrypt и принимаем условия обслуживания. Ключевым моментом является использование "DNS Challenge" — метода проверки, при котором не требуется прямой доступ к серверу из интернета. Этот способ идеально подходит для наших условий, так как позволяет провайдеру сертификатов убедиться в нашем контроле над доменом через DNS-записи. Выбираем провайдера Cloudflare из выпадающего списка. Теперь нам потребуется создать API-токен для авторизации. Переходим в личный кабинет Cloudflare:
Открываем раздел управления аккаунтом "Manage Account"
Переходим в подраздел "API Tokens"
Создаем новый токен, используя шаблон "Edit zone DNS"
На этапе настройки прав доступа обязательно указываем наш домен в параметре "Zone Resources"
Копируем полученный токен и вставляем его в поле "Credentials File Content", вместо шаблона ключа
0123456789abcdef0123456789abcdef01234567
Проверяем доступность домена UmbrelOS по HTTPs
А что там с Nextcloud?
После успешного получения SSL-сертификата и проверки доступности Nextcloud по HTTPS, необходимо выполнить финальную корректировку в самой конфигурации Nextcloud. Без этого шага могут возникать проблемы с генерацией корректных URL и предупреждения о небезопасном соединении.
Необходимо изменить config.php. Файл конфигурации Nextcloud обычно находится в директории данных приложения. В UmbrelOS путь может выглядеть так:
*/umbrel/app-data/nextcloud/data/config.php

Нужно найти и отредактировать два критически важных параметра:
<?php
$CONFIG = array (
...
// Добавляем домен в доверенные
'trusted_domains' =>
array (
0 => 'localhost',
1 => 'nextcloud.your-domain.com', // Ваш субдомен для Nextcloud
),
...
// Принудительное использование HTTPS
'overwriteprotocol' => 'https',
...
);
Nextcloud будет отклонять запросы с доменов, не указанных в этом списке. Без добавления вашего субдомена вы можете столкнуться с ошибкой "Доступ запрещен".
Так же рекомендую ввести следующую конфигурацию в "Custom Nginx Configuration", в реверс прокси.
client_max_body_size 10G;
client_body_timeout 3600s;
client_body_buffer_size 512k;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
send_timeout 3600s;
proxy_buffering off;
proxy_request_buffering off;
Поддержка больших файлов до 10 ГБ вместо стандартных 1-2 МБ
Увеличенные таймауты для операций с большими файлами (загрузка/синхронизация)
Отключение буферизации предотвращает двойное копирование данных и уменьшает задержки при работе с файлами
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
Корректное определение реального IP пользователя в логах Nextcloud
Поддержка WebSocket для реального времени
Правильное определение протокола для генерации URL
Сохранение оригинального Host заголовка
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;
add_header X-XSS-Protection "1; mode=block";
HSTS принуждает использовать только HTTPS
Защита от кликджекинга через X-Frame-Options
Предотвращение MIME атак
Блокировка межсайтового скриптинга
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
Снижение трафика на 60-80% за счет сжатия
Ускорение загрузки интерфейса и статических ресурсов
Оптимизированные настройки для веб-приложений
Поддержка современных форматов (WebAssembly, JSON-LD, манифесты)
404 и что с ними будем делать?

Из неплохого варианта - замена стандартной страницы страницы 404 Nginx Proxy Manager на собственную кастомную страницу, для этого можно использовать следующий подход:
Сначала создайте кастомную HTML-страницу в настройках NPM "Default Site".
В настройках прокси-хоста перейдите в раздел "Advanced" и добавьте следующую конфигурацию:
error_page 404 =200 /index.html;
location = /index.html {
root /data/nginx/default_www;
}
Итог
Пройдя все этапы настройки, мы создали полнофункциональный домашний сервер с безопасным доступом из вне. Теперь сервер превратился в полноценную альтернативу коммерческим облачным сервисам, но с полным контролем над данными и конфиденциальностью.
Спасибо что прочитали!
Комментарии (5)
igrblkv
06.10.2025 08:051) А в каком месте почитать про UmbrelOS?
2) Почему не unraid, CasaOS/ZimaOS, cosmos-server или Yunohost?
Или TrueNAS Scale, например?
Да и XPenology разве не подойдёт?requese Автор
06.10.2025 08:05Приветствую.
Был опыт работы ESXI ARM + CasaOS - вполне неплохая и более "открытая", в плане возможностей, ОС. Хотелось пощупать что то другое с более красивым UI. А про UmbrelOS в интернете гайдов не много.
ПС: под "более открытая" имею ввиду деплой приложения напрямую из UI, т.е. нужен только docker compose и все. В UmbrelOS необходимо делать комьюнити маркет на git с docker compose, ссылка тут. Да и к тому же UmbrelOS на ARM не поддерживает внешние накопители, только внутренние диски (например те накопители, в Rasspberry Pi 5, которые подключены через PCIe).
dezinger
"Он станет тем самым постоянным адресом, по которому вы будете находить свой сервер из любой точки мира, не завися от капризов провайдера и сложных запоминаний IP-адресов. "
А с каким IP вы связали домен? Полагаю вы забыли упомянуть что потребуется арендовать у провайдера постоянный IP.
igrblkv
Ну, кстати, обычно рекомендуют VPS/VDS с прокси-менеджером, который имеет доступ к локальным ресурсам и все ходят через белый ИП, выданный не Вашим домашним провайдером, а выданный виртуалке хостинг-провайдером. И при этом совсем не требуется белый ИП-адрес у домашнего провайдера.
dezinger
Да это вариант, через VPN тунель, где VPS это VPN-сервер а локальный сервер VPN-клиент. Почему автор опустил этот довольно важный момент непонятно. Так как это уже некоторые постоянные расходы хоть и небольшие.