Publicando sites ServBay em rede pública (Proxy Reverso, Túnel e Encaminhamento de Porta)

Além do desenvolvimento local, muitos usuários optam por implantar o ServBay em um servidor fixo (Mac mini hospedado em datacenter, workstation de escritório, servidor Windows, etc.) como servidor de origem backend e, a partir daí, publicar o site para acesso externo pela internet. Isso é perfeitamente viável em produção — muitos usuários já rodam assim de modo estável.

No entanto, se você não entender o comportamento padrão de rede do ServBay, é fácil enfrentar problemas em relação ao protocolo, certificado, cabeçalho Host, rede etc., resultando em situações do tipo "tudo funciona localmente, mas o acesso externo falha". Este guia é para quem deseja usar o ServBay como backend, explicando primeiro esses comportamentos padrão. Em seguida, apresenta soluções completas na ordem "Túnel interno → Proxy reverso (recomendado) → Encaminhamento de porta", finalizando com um checklist para resolução de problemas comuns de acesso.

Plataformas suportadas

Este artigo se aplica tanto ao ServBay para macOS quanto ao ServBay para Windows. A configuração dos modos de protocolo, comportamento de escuta e caminhos de certificado são idênticos em ambas as plataformas, mudando apenas a pasta de instalação (macOS usa /Applications/ServBay, Windows geralmente C:\ServBay, conforme instalado). O servidor web padrão difere: macOS usa Caddy, Windows usa Nginx — ambos podem ser trocados entre Nginx / Apache / Caddy.

Entenda o comportamento de rede padrão do ServBay

A maioria dos problemas de acesso externo decorre da má compreensão dos seguintes comportamentos padrão:

O protocolo padrão do site é HTTP & HTTPS. Neste modo, acessos HTTP (porta 80) são redirecionados 301 obrigatoriamente para HTTPS (porta 443). Isso é uma configuração moderna proposital — recomenda-se seguir pelo HTTPS e não insistir no 80 sem criptografia.
O ServBay utiliza SNI para selecionar site e certificado em HTTPS. Em um ServBay com vários sites, a seleção é feita via SNI (domínio) durante o handshake TLS. Seu proxy reverso deve enviar o SNI correto ao acessar via HTTPS, ou irá receber apenas o site/certificado padrão.
Por padrão, escuta em todas as interfaces de rede (0.0.0.0), portas HTTP 80 / HTTPS 443, permitindo acesso externo sem precisar alterar o endereço de ligação.
Os certificados HTTPS locais são assinados pela CA do ServBay. O ServBay possui uma CA interna (aparece como ServBay User CA - ECC Root no Keychain) que assina os certificados dos seus sites. Navegadores de visitantes externos não confiam por padrão, mas basta configurar a confiança dessa CA em seu proxy reverso (ou ignorar a checagem) — não há necessidade de certificados públicos para o upstream.

Erro comum: HTTP & HTTPS + Encaminhar apenas a porta 80

Se o site está em HTTP & HTTPS (padrão), mas você encaminha apenas a 80, sem tratar a 443: o cliente acessa http://domínio → ServBay responde 301 https://domínio → cliente tenta a 443 → sem resposta → acesso falha. O navegador ainda pode cachear esse 301, dificultando o diagnóstico.

O correto não é voltar ao HTTP 80, mas garantir o funcionamento do HTTPS (veja a solução de proxy reverso abaixo).

Comparativo das três formas de publicação

Método	Descrição	Indicação
Túnel interno (frpc / cloudflared, etc)	Embutido no ServBay, o túnel é aberto ativamente, sem precisar de IP público ou liberar portas	Sem IP público, em rede doméstica/NAT, deseja publicar rápido
Proxy reverso frontal (recomendado)	Nginx/HAProxy/Caddy/Traefik recebe o tráfego externo, gerencia certificados, depois faz upstream via HTTPS ao ServBay	Tem entrada pública, precisa de múltiplos backends/certificados centralizados
Encaminhamento de portas (NAT)	O gateway encaminha portas diretamente ao ServBay	Só há um backend, administrador experiente

Opção 1: Túnel interno (a mais simples, sem IP público)

Caso você não tenha IP público ou queira evitar complexidades de proxy reverso e certificados, os serviços de túnel internos do ServBay são a escolha mais fácil. Eles estabelecem conexões saindo do ServBay, contornando NAT, IPv6, regras de encaminhamento de porta e problemas de confiança em certificados:

Cloudflare Tunnel (cloudflared) — expõe seu site local via rede global da Cloudflare, fornecendo HTTPS público confiável automaticamente, sem abrir portas. Ideal para quem precisa de domínio público + CDN/WAF.
frp (frpc) — conecta-se a um servidor frps privado, totalmente sob seu controle.
ngrok / Pinggy — gera URLs públicos temporários rapidamente, útil para demonstrações ou testes de webhook.

Para muitos usuários, criar um túnel com cloudflared é o suficiente para "publicar o site local na internet", não sendo necessário ler as seções de proxy reverso ou encaminhamento de porta.

Opção 2: Proxy reverso frontal + HTTPS upstream (recomendado)

Esta é a solução recomendada para produção: você tem um proxy reverso com HTTPS público, usa upstream via HTTPS para o ServBay (mantendo o site em modo HTTP & HTTPS) e garante criptografia ponta a ponta.

Por que usar HTTPS para upstream em vez de HTTP 80

A maioria dos tutoriais ainda recomenda "backend em HTTP, proxy faz upstream em texto claro". Não indicamos esse método, exceto em casos muito específicos e entendendo os riscos:

Criptografia ponta a ponta: Mesmo que o proxy e o ServBay estejam em rede interna, o tráfego fica criptografado, protegendo contra sniffing e manipulação.
Protocolos modernos: Apenas mantendo o HTTPS o proxy pode ativar HTTP/2 (h2) no frontend, aproveitando multiplexação, compressão de cabeçalhos, etc.; usando HTTP fica limitado a padrões antigos.
Evita problemas causados por downgrade: Reverter ao HTTP traz múltiplos desafios como lidar com redirecionamentos 301, cache HSTS, geração de links em https na camada de aplicação, entre outros.
Confiar na CA do ServBay é simples: O uso de CA própria não é um problema — basta configurar o proxy para confiar na CA ou pular a checagem do upstream, configuração única e duradoura.

Para upstream em HTTP 80, consulte Opção 3. Indicado apenas para casos muito especiais, ciente dos impactos.

Pontos-chave para qualquer proxy reverso

Esses pontos se aplicam aos quatro proxies abaixo. Exemplificação: domínio example.com, backend ServBay em 192.168.1.115, porta HTTPS 443, site ServBay no modo HTTP & HTTPS.

Upstream em HTTPS: defina proxy_pass ou upstream para https://192.168.1.115:443.
Envie o SNI correto: o SNI deve ser igual ao domínio configurado no ServBay (example.com), do contrário, o ServBay não entregará o site/certificado certo.
Confie na CA do ServBay (recomendado) ou ignore a checagem (simples): veja como obter o arquivo CA abaixo.
Transmita o cabeçalho Host: Host: example.com, necessário para correspondência do server_name.
Envie X-Forwarded-Proto: https: informa ao backend que o acesso original foi via https, evitando geração de links http ou loops de redirecionamento.
Consistência IPv4/IPv6: veja Consistência IPv4/IPv6.

Obtendo a CA do ServBay (para confiar no certificado upstream)

O arquivo do certificado raiz da CA local do ServBay está no diretório de instalação:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (dependendo de onde foi instalado)

Copie esse arquivo .crt para o servidor do proxy reverso (por exemplo, /etc/nginx/servbay-ca/) e utilize na configuração do proxy como CA confiável para upstream.

Sobre a cadeia de certificados

O ServBay adota uma estrutura "CA raiz + CA intermediária". O certificado do site é assinado pela intermediária. Se seu proxy não confiar apenas na raiz e falhar na validação, combine o certificado raiz com o da intermediária (ServBay-Private-CA-ECC-Intermediate.crt no mesmo diretório) em um único bundle para confiabilidade total; ou use temporariamente a opção de "ignorar validação" e depois ative a validação estrita.

Proxy reverso Nginx (HTTPS upstream)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Para ativar suporte a IPv6
    server_name example.com;

    # Certificado público confiável (ex: 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;                 # Upstream em HTTPS

        # —— Fundamental: SNI e validação do upstream ——
        proxy_ssl_server_name on;                             # Envia SNI
        proxy_ssl_name        example.com;                    # SNI = domínio do ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Ativa validação após CA ser confiada
        proxy_ssl_verify_depth 2;                             # Raiz + intermediária = 2 níveis
        # Opcional: proxy_ssl_verify off;

        # —— Fundamental: transmitir Host e protocolo ——
        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;
    }
}

# Redirecionamento HTTP → HTTPS (feito pelo proxy)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Proxy reverso HAProxy (HTTPS upstream)

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
    # Upstream HTTPS: ssl + envia SNI + valida 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
    # Alternativa: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Proxy reverso Caddy (HTTPS upstream)

O Caddy obtém e renova automaticamente certificados para example.com, e o reverse_proxy já transmite Host e X-Forwarded-* por padrão:

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
            # Alternativa: tls_insecure_skip_verify
        }
    }
}

Proxy reverso Traefik (HTTPS upstream)

Exemplo de configuração dinâmica via 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                 # Transmite Host
        servers:
          - url: "https://192.168.1.115:443" # Upstream HTTPS
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Alternativa: insecureSkipVerify: true

Opção 3: Encaminhamento de portas (NAT)

Se você tem apenas um backend, pode, no gateway/roteador, redirecionar portas públicas para o ServBay (ex: IP interno 192.168.1.115).

Recomendado: encaminhe a 443, mantenha o HTTPS

No gateway, encaminhe: porta pública 443 → 192.168.1.115:443 (e porta pública 80 → 192.168.1.115:80 para o ServBay redirecionar para 443).
Configure o DNS para apontar o registro A ao IPv4 público.
O site deve permanecer em HTTP & HTTPS. Visitantes externos vão se conectar direto ao ServBay, então o domínio deve ter certificado público confiável (veja as instruções sobre certificados abaixo) — caso contrário, navegadores exibirão aviso.
Confirme a consistência IPv4/IPv6 (próxima seção).

HTTP 80 puro (apenas em casos especiais)

Encaminhar apenas a 80 e mudar o site para o modo HTTP elimina todos os benefícios do HTTPS/HTTP/2, além de gerar conflitos com HSTS/cache de navegador. Só faça isso em situações muito específicas e sabendo os riscos. Caso faça: configure o site em modo HTTP explicitamente (para evitar 301 para a 443 não encaminhada) e encaminhe apenas a 80.

Consistência IPv4/IPv6

Esse é um motivo comum para instabilidade no acesso público. Se o domínio tiver registros A (IPv4) e AAAA (IPv6), os clientes podem priorizar IPv6 (Happy Eyeballs). Se você só configurar proxy ou encaminhamento para IPv4, acessos via IPv6 falharão. Resolva de uma das formas:

Use apenas IPv4: Garanta que dig AAAA seu-dominio +short não retorna nada, mantendo só o registro A.
Suporte a IPv6 também: Configure proxy/encaminhamento para IPv6, garanta que o backend aceita conexões IPv6.

Checklist de resolução de problemas de acesso

Se o acesso externo falhar (site não abre, timeout, erro de certificado, site incorreto, etc), siga (domínio example.com, backend 192.168.1.115):

Está recebendo 301 para porta 443 não encaminhada?
bash
```
curl -I http://example.com
```
1
Recebe 301 e Location: https://..., mas não processou a 443 → problema identificado. Resolva o HTTPS ou coloque o site em modo HTTP.

IPv6 está causando problemas?

bash

curl -4 -I https://example.com     # Usa apenas IPv4
curl -6 -I https://example.com     # Usa apenas IPv6
dig A example.com +short
dig AAAA example.com +short        # Tem AAAA mas IPv6 inoperante → remova ou habilite IPv6

SNI/certificado do upstream estão corretos? (no cenário HTTPS upstream) Faça uma requisição com SNI ao backend:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Se relatar erro de certificado ou domínio, provavelmente SNI está incorreto ou a CA não foi confiada.
A requisição chega ao ServBay? No host ServBay, confira o log de acessos do site correspondente (opção Ver arquivo de Log no ServBay). Se o acesso com timeout não aparecer no log, o problema está na rede/gateway/proxy.
Cabeçalho Host correto? (proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Se acesso direto ao backend funciona e via proxy não → o proxy não está transmitindo o Host.

Certificados e segurança

Upstream: O trajeto proxy → ServBay via HTTPS requer que o proxy confie na CA do ServBay (ServBay-Private-CA-ECC-Root.crt, combine com intermediária se necessário); isso é só para confiança interna, configuração única e permanente.
Certificado público: Visitantes externos devem receber um certificado confiável publicamente. No método proxy reverso, é o proxy que gerencia (Caddy/Traefik renovam automaticamente); com encaminhamento de porta, configure o domínio no ServBay com certificado público (veja Solicitando certificado via ACME). O certificado ServBay User CA só serve para uso local/LAN — visitantes externos não confiam.
Não exponha bancos de dados: Ao publicar o seu web, nunca abra portas do MySQL, Redis, Memcached, etc. Veja Acesso via LAN para segurança.
Firewall: Só deixe abertas as portas necessárias, bloqueie o restante.

Perguntas Frequentes (FAQ)

P: Funciona localmente, mas não externamente — é problema de DNS?
- R: Normalmente não é "não resolve", e sim 301 do HTTP & HTTPS para porta 443 não encaminhada, SNI/certificado errado, Host não transmitido ou inconsistência de IPv4/IPv6. Cheque ponto a ponto no checklist.
P: Preciso mudar para HTTP 80 para o proxy funcionar?
- R: Não é necessário e nem recomendado. Deixe em HTTP & HTTPS, use upstream via HTTPS confiando na CA do ServBay (ou ignore checagem), assim garante criptografia ponta a ponta e HTTP/2.
P: Proxy relata erro de certificado/destino incorreto?
- R: Confira se está enviando o SNI correto (domínio do site), se o proxy confia na CA do ServBay (inclua certificado intermediário se for o caso). Para validar rapidamente, ignore a checagem primeiro, depois ative validação estrita.
P: ServBay é estável em servidor de produção?
- R: Sim. Muitos rodam ServBay em Mac mini/servidor Windows hospedados em IDC, com serviços estáveis abertos. Os pontos-chave são alinhar protocolo/SNI/cabeçalho Host/confiança em certificado e IPv4/IPv6.
P: Não tenho IP público, e agora?
- R: Use Opção 1: Túnel interno (cloudflared/frpc), sem precisar de IP público nem encaminhamento de portas.

Resumo

É totalmente viável publicar o ServBay como backend na internet. A rota recomendada é: mantenha o site em modo HTTP & HTTPS, utilize proxy reverso frontal com upstream via HTTPS, envie o SNI correto e confie na CA do ServBay, garantindo criptografia ponta a ponta e HTTP/2. Se não tiver IP público, utilize os túneis internos cloudflared/frpc. O encaminhamento de portas é viável para admins experientes. Em caso de problemas, use o checklist deste guia — quase sempre a causa estará no modo de protocolo, SNI/certificado, Host ou inconsistência IPv4/IPv6.

Publicando sites ServBay em rede pública (Proxy Reverso, Túnel e Encaminhamento de Porta) ​

Entenda o comportamento de rede padrão do ServBay ​

Comparativo das três formas de publicação ​

Opção 1: Túnel interno (a mais simples, sem IP público) ​

Opção 2: Proxy reverso frontal + HTTPS upstream (recomendado) ​

Por que usar HTTPS para upstream em vez de HTTP 80 ​

Pontos-chave para qualquer proxy reverso ​

Obtendo a CA do ServBay (para confiar no certificado upstream) ​

Proxy reverso Nginx (HTTPS upstream) ​

Proxy reverso HAProxy (HTTPS upstream) ​

Proxy reverso Caddy (HTTPS upstream) ​

Proxy reverso Traefik (HTTPS upstream) ​

Opção 3: Encaminhamento de portas (NAT) ​

Consistência IPv4/IPv6 ​

Checklist de resolução de problemas de acesso ​

Certificados e segurança ​

Perguntas Frequentes (FAQ) ​

Resumo ​