Публикация сайтов ServBay в интернет (обратный прокси, туннели и проброс портов)

Помимо локальной разработки, многие пользователи размещают ServBay на постоянно работающем сервере (Mac mini в дата-центре, офисный ПК, Windows-сервер и др.) в роли backend origin-сервера, а сам сайт делают доступным в публичной сети. Это абсолютно рабочая практика в промышленной эксплуатации — множество пользователей стабильно используют такой подход.

Однако незнание сетевых особенностей ServBay по умолчанию может привести к ошибкам с протоколами, сертификатами, заголовками Host и другими нюансами — в итоге «локально всё работает, а снаружи — проблемы». Эта статья посвящена тем, кто хочет использовать ServBay как backend origin-сервер: сначала разбираем сетевое поведение по умолчанию, затем — пошаговые решения в порядке «встроенные туннели → обратный прокси (рекомендуется) → проброс портов», и в завершение — универсальный чек-лист для диагностики проблем.

Поддерживаемые платформы

Материал актуален как для ServBay для macOS, так и для ServBay для Windows. На обоих платформах реализованы идентичные режимы работы сайтов, правила прослушивания портов и пути к сертификатам; отличается лишь корневая папка установки (macOS — /Applications/ServBay, Windows — обычно C:\ServBay, ориентируйтесь по своему пути). Веб-сервер по умолчанию разный: macOS — Caddy, Windows — Nginx; в обоих случаях можно переключить на Nginx / Apache / Caddy.

Как работает сеть ServBay по умолчанию

Большинство проблем при внешнем доступе связаны с неправильным пониманием следующих особенностей:

Режим сайта по умолчанию — HTTP & HTTPS. В этом режиме весь входящий HTTP-трафик (80 порт) безусловно перенаправляется (301) на HTTPS (443). Таково современное безопасное значение по умолчанию — стройте схему на HTTPS, не откатывайтесь на открытый 80 порт.
Выбор сайта и сертификата в HTTPS зависит от SNI. На одном экземпляре ServBay может быть несколько сайтов — выбор сайта и сертификата в процессе TLS сочетается по SNI (домену сайта). Обратный прокси при проксировании по HTTPS ОБЯЗАН передавать корректный SNI — иначе получите дефолтный сайт и сертификат.
Слушает все интерфейсы (0.0.0.0). По умолчанию ServBay принимает соединения со всех сетевых интерфейсов на стандартных портах HTTP 80 / HTTPS 443; менять адрес привязки, как правило, не нужно.
Локальный HTTPS-сертификат подписан внутренним ServBay CA. В комплекте ServBay есть собственный локальный центр сертификации (CA, обычно в Keychain как ServBay User CA - ECC Root), который выпускает сертификаты для ваших сайтов. Браузеры «из внешки» по умолчанию ему не доверяют — но обратному прокси можно доверять этому CA (или отключить валидацию для обратного потока), отдельный публичный сертификат для такого обратного соединения не требуется.

Типичная ошибка: HTTP & HTTPS + только прокидка 80 порта

Если оставили режим сайта HTTP & HTTPS, а в наружу прокинули только порт 80, без 443: клиент идёт по http://домен → ServBay отдаёт 301 https://домен → клиент пытается достучаться до 443 → никто не слушает → ошибка доступа. Браузеры и HSTS кэшируют 301, что дополнительно осложняет поиск проблемы.

Решение — не откатываться на HTTP, а полноценно прокинуть HTTPS (см. рекомендации для обратного прокси далее).

Как выбрать подходящий способ публикации

Метод	Описание	Кому подходит
Встроенные туннели (frpc / cloudflared и др.)	ServBay сам устанавливает туннель наружу, не нужен публичный IP и не требуется открывать порты	Нет «белого» IP, домашние/NAT-сети, быстрый запуск
Обратный прокси (рекомендуется)	Nginx/HAProxy/Caddy/Traefik принимает трафик снаружи, сам управляет сертификатами, а далее идёт HTTPS проксирование на ServBay	Есть внешний вход, нужна точка единого управления/нагрузки или централизованные сертификаты
Проброс портов (NAT)	Роутер напрямую переадресует входящий порт на ServBay-хост	Один backend, точное понимание рисков и ограничений

Вариант 1: Встроенные туннели (самый простой, не нужен публичный IP)

Если у вас нет белого IP или нет желания настраивать прокси и сертификаты — встроенные туннели ServBay — самый быстрый и удобный вариант. Система устанавливает исходящее соединение, автоматически обходя NAT, IPv6, проброс портов и доверие к сертификатам:

Cloudflare Tunnel (cloudflared) — публикует сайт через мировую сеть Cloudflare, сразу выдаёт надёжный публичный HTTPS, не открывает портов. Отлично для постоянного домена, CDN/WAF и стабильного доступа.
frp (frpc) — подключение к вашему серверу frps, полный контроль.
ngrok / Pinggy — быстрые временные публичные URL для демо, webhook и отладки.

Для большинства пользователей такого туннеля через cloudflared уже достаточно для публикации сайта во внешний интернет — дальнейшие разделы (обратный прокси и проброс портов) можете пропустить.

Вариант 2: Обратный прокси + HTTPS проксирование (рекомендуется)

В промышленной эксплуатации оптимально использовать обратный прокси, который принимает внешние HTTPS-подключения, а далее проксирует через HTTPS обратно в ServBay (сохраняя режим сайта HTTP & HTTPS). Получаем сквозное шифрование до локального backend-сервера.

Почему рекомендуем HTTPS-проксирование, а не открытый HTTP 80

Многие гайды всё ещё чаще используют схему «backend на HTTP, прокси в виде чистого 80 порта». Мы НЕ рекомендуем такой подход, исключая особые случаи, где взвешены все риски:

Сквозное шифрование. Даже если прокси и ServBay в одной подсети или дата-центре, весь трафик в шифре — никакого прослушивания или атак типа MITM.
Современные возможности протоколов. Работа через HTTPS позволяет по максимуму использовать HTTP/2 (h2): мультиплексирование, сжатие заголовков, ускорение подключений; у HTTP 80 этих возможностей нет вовсе.
Уход от ловушек деградации. Назад в HTTP — значит, придётся разгребать проблемы с 301 на HTTPS, HSTS и кэшами, а также некорректной генерацией https-ссылок в приложениях.
Доверие к ServBay CA настраивается разово. Не проблема, что ServBay генерирует внутренний сертификат — просто настройте доверие к CA на прокси или отключите валидацию, и всё будет работать на годы.

Если вам действительно нужен HTTP 80 — читайте Вариант 3 (только для вполне понимающих риски).

Общие требования для любой проксирующей схемы

Далее разбираем четыре популярных прокси-сервера. Примеры используются для домена example.com, backend ServBay — 192.168.1.115, HTTPS-порт — 443, режим сайта HTTP & HTTPS:

Проксируем через HTTPS. proxy_pass или upstream должен идти на https://192.168.1.115:443.
Передаём правильный SNI. В SNI указывайте ровно тот домен, что прописан в ServBay (например, example.com), иначе не получите правильный сертификат.
Доверие к ServBay CA (рекомендовано) или временно отключить верификацию. Способ получения CA — ниже.
Точный пасс Host заголовка. (Host: example.com) — чтобы ServBay выбрал нужный vhost/server_name.
X-Forwarded-Proto: https. Сообщает backend, что изначально был HTTPS, чтобы приложение не ломало редиректы и ссылки.
Consistency для IPv4/IPv6. Подробнее — поддержка IPv6.

Как получить CA ServBay (для доверия сертификатам на backend)

Файл корневого CA-сертификата находится в папке установки ServBay:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (путь уточняйте по месту инсталляции)

Файл .crt скопируйте на сервер с обратным прокси (например, /etc/nginx/servbay-ca/) и используйте в настройках как доверенное CA для backend-а.

О цепочке сертификатов

У ServBay двухуровневая схема: root CA + промежуточный CA. Непрохождение проверки может быть связано с тем, что прокси доверяет только root — объедините root и промежуточный (ServBay-Private-CA-ECC-Intermediate.crt в той же папке) в один CA bundle для trust chain, или используйте временно «отключить верификацию», а потом настройте строгую.

Nginx обратный прокси (HTTPS back-to-back)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # При необходимости поддержки IPv6
    server_name example.com;

    # Внешний публичный сертификат (например, Let’s Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # HTTPS проксирование

        # —— Ключевое: SNI и backend trust ——
        proxy_ssl_server_name on;                             # Передавать SNI
        proxy_ssl_name        example.com;                    # SNI = домен ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Включить верификацию после доверия CA
        proxy_ssl_verify_depth 2;                             # Root + intermediate, два уровня
        # Лёгкая схема (без CA): proxy_ssl_verify off;

        # —— Ключевое: Host и proto passthrough ——
        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;
    }
}

# Перенаправление HTTP на HTTPS (настраивается на уровне прокси)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy обратный прокси (HTTPS back-to-back)

haproxy

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # HTTPS проксирование: ssl + SNI + доверие ServBay CA
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Упрощённый вариант: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy обратный прокси (HTTPS back-to-back)

Caddy сам выпишет и обновит публичный сертификат для example.com, reverse_proxy по умолчанию сохраняет Host и X-Forwarded-*:

caddy

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # Упрощённо: tls_insecure_skip_verify
        }
    }
}

Traefik обратный прокси (HTTPS back-to-back)

Пример динамического файла file provider:

yaml

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Пассуем Host
        servers:
          - url: "https://192.168.1.115:443" # HTTPS backend
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Легко: insecureSkipVerify: true

Вариант 3: Проброс портов (NAT)

Если backend всего один, можно на роутере или шлюзе напрямую прокинуть внешний порт на хост с ServBay (например, 192.168.1.115).

Рекомендуемый сценарий: прокидываем 443, сохраняем HTTPS

На роутере осуществляется проброс: внешний 443 → 192.168.1.115:443 (и внешний 80 → 192.168.1.115:80 — ServBay сам перекинет 80 на 443).
В DNS добавьте запись A (IPv4) — на внешний адрес.
Сайт работает в режиме HTTP & HTTPS. Так как трафик идёт прямо в ServBay, для домена необходим надёжный публичный сертификат — иначе у внешних пользователей будут предупреждения о недоверии (см. раздел про сертификаты ниже).
Проверьте соответствие схемы IPv4/IPv6 (см. след. раздел).

Проксирование только HTTP 80 (только для особых случаев)

Публикация только 80 порта и переключение сайта в режим HTTP лишает вас плюсов HTTPS и HTTP/2, и плохо работает с HSTS/кэшами. Только для максимально осознанных кейсов. Если всё же надо — настройте явный режим сайта на HTTP (так не будет вредной 301), и пробрасывайте только 80 порт.

IPv4 / IPv6 — как избежать ошибок

Одна из частых причин нестабильности. Если у домена в DNS есть и A (IPv4), и AAAA (IPv6), — многие клиенты через Happy Eyeballs будут сначала пробовать IPv6; если проброшен или настроен только IPv4-интерфейс, — часть запросов не дойдёт. Как правильно:

Только IPv4: Проверьте, что dig AAAA ваш_домен +short ничего не возвращает и осталась только A-запись.
Двойная поддержка IPv6: Прокиньте и разрешите IPv6, убедитесь, что backend можно достичь по обоим протоколам.

Чек-лист диагностики проблем с внешним доступом

Если сайт недоступен снаружи (страница не грузится, таймауты, ошибки сертификата, не тот сайт), проверьте последовательно (пример: домен example.com, backend — 192.168.1.115):

301 на неоткрытый 443 порт?
bash
```
curl -I http://example.com
```
1
Если в ответе 301 и Location уходит на https, а 443 не открыт/не прокинут — дело в этом. Или прокиньте HTTPS (рекомендовано), или режим сайта переводите из HTTP & HTTPS в чистый HTTP.

Не балуется ли IPv6?

bash

curl -4 -I https://example.com     # Принудительно через IPv4
curl -6 -I https://example.com     # Принудительно через IPv6
dig A example.com +short
dig AAAA example.com +short        # Если AAAA присутствует, но IPv6 не работает — уберите или настройте

SNI/сертификаты backend-а корректные? (при HTTPS-проксировании)
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Если сайт или сертификат не подходят — скорее всего, SNI не передаётся или CA не доверяется.
Доходит ли запрос до ServBay? Смотрите webserver-логи нужного сайта на хосте с ServBay (через «Просмотр Log файла» в панели). Нет обращений — застряли на уровне сети/прокси/роутера.
Корректный Host-заголовок? (L7-проксирование)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Если прямое подключение к backend работает, а через прокси — нет, прокси скорее всего не передаёт Host.

Сертификаты и безопасность

Проксирование до ServBay: Для HTTPS-проксирования настройте обратный прокси на доверие к ServBay CA (ServBay-Private-CA-ECC-Root.crt, при необходимости объединить с промежуточным CA). Это разовая настройка во внутреннем периметре.
Внешний сертификат: Для внешних соединений используйте только публичные сертификаты. При обратном проксировании ими управляет сам прокси (Caddy/Traefik могут выдавать автоматически); в случае прямого проброса портов — установите на сайт ServBay публичный сертификат для домена (см. получение SSL-сертификата через ACME). Самоподписанный ServBay CA годится только для локали или локальной сети, внешние пользователи ему не доверяют.
Не открывайте базы в интернет: При публикации веба в сеть ни в коем случае не оставляйте открытыми MySQL, Redis, Memcached и другие сервисные порты. Меры защиты рассмотрены в доступ из локальной сети.
Firewall: Открывайте только нужные порты, остальные блокируйте.

Часто задаваемые вопросы (FAQ)

В: Локальный доступ нормальный, снаружи — проблемы. Это DNS?
- О: В 90% случаев нет. Часто дело в 301 с HTTP & HTTPS на неоткрытый 443, ошибках в SNI/сертификатах, не переданном Host или проблеме c IPv6. Проверьте по чек-листу.
В: Необходимо обязательно уходить на HTTP 80 для работы через прокси?
- О: Нет, и не стоит. Смело сохраняйте HTTP & HTTPS, проксируйте через HTTPS с доверием к ServBay CA или даже без проверки, и используйте все плюсы HTTP/2.
В: Прокси ругается на сертификат или не тот сайт?
- О: Проверьте, что SNI отправляется правильно (домен сайта), а proxy доверяет ServBay CA (или отключите временно валидацию).
В: Можно ли использовать ServBay как production-backend?
- О: Да, множество пользователей используют mac mini/Windows-серверы на ServBay в IDC для обслуживания внешних клиентов. Важно грамотно настроить режим сайта, SNI, Host, доверие к сертификатам и обе схемы IP.
В: Что делать, если нет публичного IP?
- О: Используйте Вариант 1: Встроенные туннели — через cloudflared/frpc всё работает!

Резюме

Публикация сайта ServBay в интернет в роли origin-сервера — полностью рабочая и стабильная схема. Рекомендуемый путь: сохраняйте режим работы сайта HTTP & HTTPS, используйте обратный прокси с HTTPS-проксированием и передачей верного SNI с доверием к ServBay CA — получите сквозное шифрование и преимущества HTTP/2. Нет публичного IP? — Встроенные туннели cloudflared/frpc решают вопрос. Проброс портов — исключительно для тех, кто чётко осознаёт риски. Любые проблемы с внешним доступом легко отлавливаются по чек-листу — почти всегда причина в протоколе, SNI/сертификатах, Host или IP-конфигурации.

Публикация сайтов ServBay в интернет (обратный прокси, туннели и проброс портов) ​

Как работает сеть ServBay по умолчанию ​

Как выбрать подходящий способ публикации ​

Вариант 1: Встроенные туннели (самый простой, не нужен публичный IP) ​

Вариант 2: Обратный прокси + HTTPS проксирование (рекомендуется) ​

Почему рекомендуем HTTPS-проксирование, а не открытый HTTP 80 ​

Общие требования для любой проксирующей схемы ​

Как получить CA ServBay (для доверия сертификатам на backend) ​

Nginx обратный прокси (HTTPS back-to-back) ​

HAProxy обратный прокси (HTTPS back-to-back) ​

Caddy обратный прокси (HTTPS back-to-back) ​

Traefik обратный прокси (HTTPS back-to-back) ​

Вариант 3: Проброс портов (NAT) ​

IPv4 / IPv6 — как избежать ошибок ​

Чек-лист диагностики проблем с внешним доступом ​

Сертификаты и безопасность ​

Часто задаваемые вопросы (FAQ) ​

Резюме ​