Опублікувати сайт ServBay у публічній мережі (реверс-проксі, тунелі та переадресація портів)

Окрім локальної розробки, багато користувачів розгортають ServBay на постійних серверах (орендований Mac mini у дата-центрі, офісний комп’ютер, Windows-сервер тощо) як бекенд-оригінал (origin server) і вже потім публікують сайт у зовнішній мережі. Це повністю життєздатний сценарій – багато користувачів уже стабільно працюють саме так.

Однак незнання стандартних мережевих налаштувань ServBay часто призводить до помилок у протоколах, сертифікатах, Host-заголовках тощо — у результаті сайт працює локально, а із зовнішнього світу доступ не працює. Ця стаття роз’яснює ці налаштування та покроково описує підходи у такому порядку: Вбудовані тунелі → Реверс-проксі (рекомендовано) → Переадресація портів, а також надає чек-лист для діагностики основних проблем доступу.

Підтримувані платформи

Матеріал стосується ServBay для macOS і ServBay для Windows. Протоколи, поведінка слухання портів і структура сертифікатів ідентичні — різниться лише папка встановлення (macOS: /Applications/ServBay, Windows: C:\ServBay, залежно від місця встановлення). Також за замовчуванням у macOS використовується Caddy, а у Windows – Nginx. У обох випадках можна переключити вебсервер на Nginx / Apache / Caddy.

Розуміння стандартної мережевої поведінки ServBay

Переважна більшість проблем із зовнішнім доступом виникає через нерозуміння наступних нюансів:

За замовчуванням сайт працює у режимі HTTP & HTTPS. При цьому всі HTTP-запити (порт 80) завжди перенаправляються на HTTPS (порт 443) через 301. Це сучасна і безпечна поведінка – раджу залишати HTTPS, а не примусово відмовлятися від нього на користь лише HTTP.
Вибір сайту та сертифіката у HTTPS здійснюється по SNI. Якщо на одному ServBay кілька сайтів, потрібне правильне SNI (домен сайту) у TLS-рукопотисканні. Реверс-проксі має передавати коректний SNI — в іншому випадку отримаєте стандартний сайт або не той сертифікат.
Слухання на всіх мережевих інтерфейсах (0.0.0.0), порти – HTTP 80 / HTTPS 443. Зовнішній доступ дозволений без додаткового налаштування прив’язки.
Локальні HTTPS-сертифікати підписані ServBay CA. Вбудований локальний CA (ServBay User CA - ECC Root) використовується для підпису сертифікатів сайтів. Браузери відвідувачів за замовчуванням не довіряють йому, але ви можете додати ServBay CA у довірені на стороні реверс-проксі (або вимкнути перевірку). Для ланцюжка між проксі та бекендом не потрібно окремий загальнодоступний сертифікат.

Типова помилка: HTTP & HTTPS + тільки переадресація 80

Якщо сайт у режимі HTTP & HTTPS, але ви відкрили лише 80 і не перенаправили 443: запит користувача на http://домен перенаправляється на https://домен, клієнт намагається з’єднатись із портом 443 — відповіді немає — доступ відсутній. Браузери й HSTS кешують такий 301 і ускладнюють пошук проблеми.

Рішення – не відмовлятися від HTTPS, а реалізувати коректний HTTPS-зворотній потік (див. наступний розділ).

Вибір способу публікації

Спосіб	Опис	Застосування
Вбудовані тунелі (frpc / cloudflared та ін.)	ServBay самостійно встановлює зовнішній тунель. Не потрібна зовнішня IP-адреса або відкриті порти.	Відсутня публічна IP, домашня/NAT-мережа, найпростіший спосіб.
Передній реверс-проксі (рекомендовано)	Nginx/HAProxy/Caddy/Traefik приймає зовнішній трафік і керує сертифікатами, зворотній потік через HTTPS на ServBay	Є зовнішня точка входу, централізоване управління, кілька бекендів або сертифікатів
Переадресація портів (NAT)	Граничний шлюз напряму перенаправляє порт до хоста з ServBay	Тільки один бекенд і повне розуміння мережевої схеми

Спосіб 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). Це забезпечить шифрування міжворітне (end-to-end protection).

Чому варто використовувати HTTPS-зворотній потік, а не повертатись до HTTP 80

Більшість інструкцій у мережі застарілі й пропонують запускати бекенд через HTTP і проксувати у відкритому вигляді. Ми НЕ радимо так чинити, якщо лише ви глибоко не розумієте всі ризики:

End-to-end шифрування: навіть якщо реверс-проксі й ServBay у тій же мережі, трафік повністю зашифрований — ніхто зі співробітників не зможе його прослухати чи підмінити.
Сучасні можливості протоколу: лише з HTTPS передній веб можна безпроблемно включити HTTP/2 (h2) і використати всі вигоди мультиплексування, компресії заголовків, повторного використання з’єднань. Примусовий HTTP обмежує вас старими стандартами.
Уникнення типових проблем зі зниженням версії: відкотившись на HTTP отримаєте ланцюжок 301/ HSTS/ генерацію http-посилань у вашому ПЗ і складні проблеми.
Немає складності з довірою до ServBay CA: треба лише додати ServBay CA до довірених на проксі або відключити перевірку для з’єднання – один раз і надовго.

Сценарій з HTTP 80 докладно описаний у способі 3. Радимо лише тим, хто розуміє всі ризики.

Ключові моменти

Нижче наведені універсальні пункти, актуальні для всіх зазначених проксі-серверів. Хай буде домен example.com, бекенд – 192.168.1.115, порт 443, режим HTTP & HTTPS.

HTTPS-зворотній потік: Вкажіть у proxy_pass/upstream адресу https://192.168.1.115:443.
Обов’язково вказуйте коректний SNI: SNI має відповідати налаштуванням домену на ServBay (тобто example.com), інакше буде отримано невірний сайт/сертифікат.
Довіряйте ServBay CA (рекомендовано) або ігноруйте перевірку: Подробиці у секції нижче.
Прозоро передавайте Host-заголовок: Host: example.com для співпадіння з server_name на ServBay.
Передавайте X-Forwarded-Proto: https: Це покаже додатку реальний протокол клієнта, допоможе уникнути генерації http-посилань чи петель 301.
IPv4/IPv6: Деталі нижче у IPv4/IPv6 однаковість.

Отримання ServBay CA для довіри проксі до бекенду

Файл кореневого сертифіката знаходитиметься за адресою:

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 для бекенд-з’єднання.

Про ланцюжок сертифікатів

ServBay використовує модель "кореневий CA + проміжний CA", де сертифікати сайтів видає проміжний центр. Якщо вказати довіреним лише root CA, часто не вистачає ланцюжка для успішної перевірки. Об'єднайте root CA і проміжний CA (ServBay-Private-CA-ECC-Intermediate.crt) в один bundle, або для перевірки використайте "ігнорувати сертифікат", а потім перемкніть на сувору перевірку.

Nginx: реверс-проксі з HTTPS-зворотнім потоком

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 та перевірки —
        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 + проміжний
        # Простий спосіб (без CA): proxy_ssl_verify off;

        # — Передача Host і протоколу —
        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-зворотнім потоком

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-зворотнім потоком

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-зворотнім потоком

Динамічна конфігурація 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-зворотній потік
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Простий спосіб: insecureSkipVerify: true

Спосіб 3: Переадресація портів (NAT)

Якщо у вас лише один бекенд, можна на маршрутизаторі чи шлюзі зробити переадресацію портів на внутрішню IP ServBay (192.168.1.115).

Рекомендація: переадресовувати 443, залишити HTTPS

На шлюзі: "Зовнішній 443" → "192.168.1.115:443" (та "зовнішній 80" → "192.168.1.115:80" для HTTP→HTTPS).
Вказати A-запис на зовнішню IPv4.
Сайт у режимі HTTP & HTTPS. Тепер відвідувачі під’єднуються напряму – треба зовнішній валідний сертифікат (див. нижче). На ServBay CA браузери не реагуватимуть.
Переконайтесь у відповідності IPv4/IPv6 (див. нижче).

Чистий HTTP 80 (для виключних випадків)

Якщо ви відкриєте тільки порт 80 і перемкните сайт у режим HTTP, ви втратите всі переваги HTTPS/HTTP2 й потрапите у пастки з кешем HSTS. Використовуйте лише якщо це єдиноможливий та усвідомлений сценарій. У такому разі явно виберіть режим HTTP й призначте лише порт 80.

IPv4/IPv6 однаковість

Причина нестабільного зовнішнього доступу – за замовчуванням, якщо у домена є обидва записи: A (IPv4) та AAAA (IPv6), у частини клієнтів запити йдуть по IPv6 (Happy Eyeballs). Якщо ви закрили налаштування лише для IPv4, трафік по IPv6 не дійде. Оберіть один варіант:

Використовуйте тільки IPv4: Переконайтесь, що за dig AAAA ваш_домен +short результат порожній, залишається лише A.
Працюйте з обома: Налаштуйте переадресацію/проксування через IPv6, додайте [::] у налаштуваннях і перевірте, чи сервер доступний через IPv6.

Чек-лист для усунення помилок

Якщо сайт не відкривається через Інтернет (помилки, час очікування, сертифікат, не той сайт) перевіряйте наступне (домен – example.com, бекенд – 192.168.1.115):

301 на закритий 443?
bash
```
curl -I http://example.com
```
1
Якщо повертає 301 і Location: https://..., а порт 443 не відкрито – причина тут. Прокладіть 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/сертифікат бекенду правильний? (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? Перевірте доступ по логах на серваку (у ServBay – "Перегляд Log файл"). Якщо в логах нічого – проблема у мережі/маршрутизації/проксі.
Host-заголовок прозоро? (L7 reverse proxy)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Якщо напряму працює, а через проксі ні – проверьте конфігурацію передачі Host.

Сертифікати та безпека

Зворотній потік через проксі: реверс-проксі → ServBay проходить по HTTPS. Проксі має довіряти ServBay CA (ServBay-Private-CA-ECC-Root.crt, можна додати проміжний), це внутрішня довіра і достатньо налаштувати один раз.
Зовнішній сертифікат: усім відвідувачам потрібен загальнодоступний сертифікат. При реверс-проксі його веде проксі (Caddy/Traefik – автоматично), при NAT-переадресації – треба додати у налаштування сайтів ServBay вручну (Довідка з ACME). Сертифікат ServBay User CA застосовується лише у локальній/внутрішній мережі, зовнішні браузери йому не довіряють.
Не відкривайте інші сервіси! Не виводьте у публічний доступ MySQL, Redis, Memcached. Дивіться поради щодо захисту у Доступ з локальної мережі.
Фаєрвол: Відкривайте лише потрібні порти, все інше — блокуйте.

Поширені питання (FAQ)

Q: Локально працює, зовні – ні, проблема у DNS?
- A: Зазвичай ні – причина у тому, що 301 переспрямовує на закритий 443, або проблеми із SNI/сертифікатом, Host-заголовком чи IPv4/IPv6. Використовуйте чек-лист.
Q: Треба переключатись на HTTP 80 для роботи з проксі?
- A: Ні і не раджу. Тримайте режим HTTP & HTTPS, використовуйте проксі що ходить по HTTPS і довіряє ServBay CA (або ігнорує перевірку) — отримаєте end-to-end захист і HTTP/2.
Q: Проксі повертає помилку сертифікату/сайту?
- A: Перевірте що SNI збігається із доменом, проксі довіряє ServBay CA (додавайте проміжний сертифікат якщо треба). На першому етапі можна тимчасово відключити перевірку.
Q: ServBay стабільний для живого бекенда у продакшн?
- A: Так, багато користувачів розгортають ServBay на Mac mini/Windows у дата-центрах з успіхом. Важливо коректно налаштувати протоколи, SNI, Host, CA та IPv4/IPv6.
Q: Що робити без публічної IP?
- A: Використовуйте Спосіб 1: Вбудований тунель (cloudflared/frpc), не потрібно відкритих портів чи IP.

Висновок

Публікація ServBay як бекенд-оригінал у зовнішній мережі повністю реальна. Рекомендований шлях: залишайте режим HTTP & HTTPS, використовуйте передній проксі з HTTPS-зворотнім потоком, передавайте правильний SNI і довіряйте ServBay CA — так ви отримуєте захист end-to-end та всі можливості HTTP/2. Якщо немає зовнішньої IP, найзручніше — cloudflared/frpc тунель. Переадресація портів — для досвідчених. Якщо виникають проблеми із доступом, використовуйте наведений чек-лист — у 99% випадків причина у налаштуваннях протоколу, SNI/сертифікату, Host або IPv4/IPv6.

Опублікувати сайт ServBay у публічній мережі (реверс-проксі, тунелі та переадресація портів) ​

Розуміння стандартної мережевої поведінки ServBay ​

Вибір способу публікації ​

Спосіб 1: Вбудовані тунелі (найпростіше, не потрібна зовнішня IP) ​

Спосіб 2: Передній реверс-проксі + HTTPS-зворотній потік (рекомендовано) ​

Чому варто використовувати HTTPS-зворотній потік, а не повертатись до HTTP 80 ​

Ключові моменти ​

Отримання ServBay CA для довіри проксі до бекенду ​

Nginx: реверс-проксі з HTTPS-зворотнім потоком ​

HAProxy: реверс-проксі з HTTPS-зворотнім потоком ​

Caddy: реверс-проксі з HTTPS-зворотнім потоком ​

Traefik: реверс-проксі з HTTPS-зворотнім потоком ​

Спосіб 3: Переадресація портів (NAT) ​

IPv4/IPv6 однаковість ​

Чек-лист для усунення помилок ​

Сертифікати та безпека ​

Поширені питання (FAQ) ​

Висновок ​