Publicar sitios ServBay en Internet (Proxy Inverso, Túneles y Reenvío de Puertos)

Además de usarse para desarrollo local, muchos usuarios despliegan ServBay en un servidor permanente (como Mac mini en un datacenter, un PC fijo en oficina o un servidor Windows) para usarlo como servidor original backend, exponiendo el sitio a Internet para prestación de servicios externos. Esto es completamente viable en producción: ya existe una amplia base de usuarios operando de esta forma de manera estable.

Sin embargo, si no se comprenden los comportamientos de red por defecto de ServBay, es fácil toparse con problemas de protocolo, certificados, cabeceras Host o red, lo que provoca errores como “funciona localmente pero falla en acceso público”. Este artículo está dirigido a quienes desean usar ServBay como backend y explica primero el comportamiento de red por defecto, para luego presentar las soluciones completas en el orden "Túneles integrados → Proxy inverso (recomendado) → Reenvío de puertos", terminando con una lista exhaustiva de comprobación para diagnosticar problemas de acceso.

Plataformas compatibles

Este artículo es válido tanto para ServBay en macOS como para ServBay en Windows. Los modos de protocolo web, comportamientos de escucha y patrones de rutas de certificados son idénticos en ambas plataformas; sólo cambia el directorio de instalación predeterminado (macOS: /Applications/ServBay, Windows: C:\ServBay, dependiendo de la ubicación real). El servidor web por defecto difiere: macOS usa Caddy, Windows usa Nginx; ambos pueden intercambiarse por Nginx / Apache / Caddy.

Entendiendo el comportamiento de red por defecto de ServBay

La mayoría de los problemas de acceso remoto tienen origen en malentendidos sobre estos comportamientos predeterminados:

El protocolo por defecto del sitio es HTTP & HTTPS. En este modo, las visitas por HTTP (80) serán redireccionadas permanentemente (301) a HTTPS (443). Esta es una configuración predeterminada moderna intencionada: deberías aprovechar HTTPS y no volver a HTTP en claro.
HTTPS selecciona el sitio y certificado usando SNI. Si tienes varios sitios en el mismo ServBay, la coincidencia ocurre a través de SNI en el handshake TLS (igual al dominio del sitio). Un proxy inverso que conecta por HTTPS debe enviar el SNI correcto, o de lo contrario recibirá el sitio/certificado por defecto.
Por defecto, ServBay escucha en todas las interfaces de red (0.0.0.0), en los puertos HTTP 80 / HTTPS 443, permitiendo accesos externos sin necesidad de cambiar la dirección de enlace.
El certificado HTTPS local es emitido por ServBay CA. ServBay incluye su propia CA local (aparece en llaveros como ServBay User CA - ECC Root) y firma tus sitios con ella. Los navegadores públicos no confiarán por defecto en esta CA, pero haciendo que el proxy inverso confíe en la CA (o saltando la verificación) es suficiente; no es necesario emitir un certificado público adicional para el backend.

Error frecuente: HTTP & HTTPS + sólo reenvío del 80

Si el sitio usa el modo HTTP & HTTPS pero sólo reenvías el puerto 80 y no el 443: el cliente solicita http://dominio → ServBay responde con 301 https://dominio → el cliente intenta el 443 → nadie responde → falla el acceso. Además, el navegador puede cachear ese 301 (HSTS), complicando la solución.

La solución no es volver a HTTP 80, sino asegurar una ruta HTTPS funcional (ver solución de proxy inverso más abajo).

Comparativa de métodos para publicar

Método	Descripción	Mejor para
Túneles integrados (frpc / cloudflared, etc.)	Incluido en ServBay; crea un túnel saliente, sin IP pública ni apertura de puertos	Sin IP pública, red doméstica/NAT, publicar lo más rápido posible
Proxy inverso externo (recomendado)	Nginx/HAProxy/Caddy/Traefik reciben tráfico público, gestionan certificados y hacen backend por HTTPS hacia ServBay	Acceso entrante desde Internet, unificación de entrada, múltiples sitios backend o gestión centralizada de certificados
Reenvío de puertos (NAT)	El gateway reenvía el puerto público al servidor ServBay directo	Un solo backend y usuarios experimentados

Método 1: Túneles integrados (el más sencillo, sin IP pública)

Si no tienes IP pública o no quieres complicarte con proxies y certificados, los túneles internos de ServBay son tu mejor opción. Estos conectan de forma saliente, evitando por naturaleza problemas de NAT, IPv6, reenvío de puertos o confianza de certificados:

Cloudflare Tunnel (cloudflared) — Exposición del sitio local mediante Cloudflare, proporcionando HTTPS público automáticamente, sin necesidad de abrir puertos. Ideal para escenarios con dominio público más CDN / WAF.
frp (frpc) — Conecta a tu propio servidor frps para máximo control.
ngrok / Pinggy — Genera URL públicas temporales fácilmente, útil para demos o integraciones tipo webhook.

Para muchos, un túnel cloudflared es suficiente para “exponer el sitio local”, sin necesidad de considerar proxy inverso o reenvío de puertos.

Método 2: Proxy inverso externo + HTTPS backend (recomendado)

Esta es la opción recomendada para producción: el proxy inverso expone HTTPS público y también comunica con ServBay por HTTPS (con el sitio en modo HTTP & HTTPS), logrando cifrado extremo a extremo.

¿Por qué preferir HTTPS backend en vez de HTTP 80?

La mayoría de guías indica usar backend HTTP entre el proxy y el origin. No lo recomendamos salvo que entiendas bien las implicancias:

Cifrado extremo a extremo: Incluso si proxy y ServBay están en la misma red, todo el tráfico va cifrado, evitando sniffing interno o manipulación.
Protocolos modernos: Mantener HTTPS permite HTTP/2 en frontend, obteniendo ventajas de multiplexación, compresión de cabeceras, etc. Forzar HTTP te condena a paradigmas antiguos.
Evitar problemas de degradación: Al volver a HTTP tendrás que pelear con redirecciones 301 de HTTP & HTTPS, caché HSTS, generación de links https en aplicaciones, etc.
ServBay CA es fácil de confiar: Sólo debes agregar la CA de ServBay al proxy inverso o saltar la verificación, ambos procedimientos duraderos.

El método con HTTP 80 está en Método 3 y sólo lo recomendamos para usuarios experimentados y bien informados de los riesgos.

Puntos clave generales

Estos puntos aplican a los cuatro tipos de proxy; en los ejemplos asumimos dominio público example.com, backend ServBay 192.168.1.115, puerto 443 y modo HTTP & HTTPS.

HTTPS backend: El proxy_pass o upstream debe apuntar a https://192.168.1.115:443.
Enviar SNI correcto: El SNI debe coincidir exactamente con el dominio configurado en ServBay (example.com); de lo contrario, ServBay no seleccionará el certificado correcto.
Confiar en ServBay CA (recomendado) o saltar validación: En la siguiente sección te explicamos cómo obtener el archivo de CA.
Transmitir cabecera Host íntegra: Host: example.com, para que funcione el server_name en ServBay.
Transmitir X-Forwarded-Proto: https: Así las aplicaciones backend saben que la petición original es HTTPS, evitando redirecciones o enlaces mal generados.
Consistencia IPv4 / IPv6: Ver Consistencia IPv4/IPv6.

Obtener el ServBay CA para confiar en backend

El archivo del certificado raíz local está en el directorio de instalación de ServBay:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (ajusta la carpeta según instalación)

Copia este .crt al servidor proxy (ej: /etc/nginx/servbay-ca/) y configúralo como CA válido en la verificación de backend.

Acerca de la cadena de certificados

ServBay usa una estructura de doble CA: raíz + intermedia. Los certificados de los sitios los firma la intermedia. Si la verificación falla sólo confiando en la raíz, fusiona la raíz y la intermedia (ServBay-Private-CA-ECC-Intermediate.crt en el mismo directorio) en un solo bundle para confiar en el proxy; o primero prueba saltando la validación y luego cambia a modo estricto.

Proxy inverso Nginx (backend HTTPS)

nginx

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

    # Certificado público para el exterior (ej: 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;                 # Backend HTTPS

        # —— Clave: SNI y validación ——
        proxy_ssl_server_name on;                             # Usar SNI
        proxy_ssl_name        example.com;                    # SNI = dominio ServBay
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Validar contra ServBay CA
        proxy_ssl_verify_depth 2;                             # Necesita raíz + intermedia
        # Alternativa sencilla (sin CA): proxy_ssl_verify off;

        # —— Clave: Cabeceras Host y 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;
    }
}

# Redirección HTTP → HTTPS centralizada en el proxy
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Proxy inverso HAProxy (backend 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
    # Backend HTTPS: ssl + SNI + validación 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 sencilla: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Proxy inverso Caddy (backend HTTPS)

Caddy solicita y renueva el certificado público automáticamente para example.com, y reverse_proxy de Caddy transmite Host y cabeceras X-Forwarded-* por defecto:

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 rápida: tls_insecure_skip_verify
        }
    }
}

Proxy inverso Traefik (backend HTTPS)

Ejemplo de configuración dinámica con 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                 # Transmitir Host
        servers:
          - url: "https://192.168.1.115:443" # Backend HTTPS
        serversTransport: servbay-tls

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

Método 3: Reenvío de puertos (NAT)

Si sólo tienes un backend, puedes reenviar el puerto público en el gateway/enrutador directo al host ServBay (supón IP interna 192.168.1.115).

Recomendado: Reenviar 443 y mantener HTTPS

En el gateway, redirige: público 443 → 192.168.1.115:443 (además público 80 → 192.168.1.115:80 para que ServBay redirija 80 a 443).
Configura el registro DNS A al IPv4 público.
Mantén el sitio en modo HTTP & HTTPS. Como los visitantes se conectan directo a ServBay, debes configurar un certificado público confiable para ese dominio (ver notas sobre certificados más adelante), o los navegadores mostrarán advertencias.
Verifica la consistencia entre IPv4 e IPv6 (siguiente sección).

Publicar sólo HTTP 80 (sólo para escenarios muy específicos)

Sólo reenviar el 80 y poner el sitio en modo HTTP eliminará todos los beneficios de HTTPS y HTTP/2, y puede causar conflictos con HSTS/cache de navegador. Sólo recomendado en casos extremos y entendiendo los riesgos. Si debes hacerlo, configura explícitamente el sitio en modo HTTP (evita 301 a 443) y reenvía sólo el 80.

Consistencia entre IPv4 / IPv6

Una causa frecuente de acceso inestable: si tu dominio tiene registros A (IPv4) y AAAA (IPv6), los clientes implementan Happy Eyeballs y a veces prefieren IPv6. Si sólo hiciste NAT/proxy para IPv4, los accesos por IPv6 fallarán. Opciones:

Sólo IPv4: Asegúrate que dig AAAA tu-dominio +short no devuelva nada, mantén sólo el registro A.
Soporte dual IPv6: Configura también reenvío para IPv6, haz que el proxy escuche en [::] y asegúrate que el backend sea accesible por IPv6.

Checklist de diagnóstico de fallos de acceso

Si experimentas fallos (sitios inaccesibles, timeouts, errores de certificado o páginas erróneas), sigue este orden (dominio example.com, backend 192.168.1.115):

¿Redirección 301 a un 443 no abierto?
bash
```
curl -I http://example.com
```
1
Si ves 301 y Location: https://..., pero el 443 no está abierto, ahí está el problema. Habilita HTTPS o cambia el modo del sitio a HTTP.

¿IPv6 está causando problemas?

bash

curl -4 -I https://example.com     # Sólo IPv4
curl -6 -I https://example.com     # Sólo IPv6
dig A example.com +short
dig AAAA example.com +short        # Si hay AAAA pero no funciona IPv6, elimina o habilítalo

¿El SNI/certificado backend es correcto? (para backend HTTPS) Solicita directo con SNI:
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Si hay errores de certificado/mismatch, probablemente el SNI está mal o falta confianza en la CA.
¿Las peticiones llegan a ServBay? Comprueba los logs de acceso en el servidor ServBay (ver “Ver archivos de Log” en ServBay). Si tiempo de espera y no aparece el request, el problema está entre red/gateway/proxy.
¿La cabecera Host es correcta? (proxy L7)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Si directo al backend funciona pero no por proxy, el proxy no está transmitiendo correctamente la Host.

Certificados y seguridad

Cadena backend: En conexión proxy → ServBay vía HTTPS, haz que el proxy confíe en ServBay CA (ServBay-Private-CA-ECC-Root.crt, une intermedia si es necesario); esto es confianza local, basta configuration única.
Certificado público: Para accesos desde Internet, se requiere certificado público confiable. En proxy inverso, el proxy los gestiona (Caddy/Traefik pueden emitir y renovar automáticamente); en reenvío directo debes configurar el certificado en ServBay (ver Solicitar certificados por ACME). El CA propio de ServBay sólo es confiable en LAN/local.
No publiques bases de datos: Al exponer el web, no abras puertos de MySQL, Redis, Memcached, etc. simultáneamente. Ver consideraciones en Acceso desde red local.
Firewall: Mantén abiertos sólo los puertos imprescindibles; cierra el resto.

Preguntas frecuentes (FAQ)

P: Funciona local, pero falla público, ¿es problema DNS?
- R: Normalmente no es un “problema de resolución”, sino un 301 a 443 cerrado, o bien SNI/certificado incorrecto, cabecera Host perdida, o inconsistencias IPv4/IPv6. Consulta la checklist anterior.
P: ¿Tengo que bajar a HTTP 80 para usar proxy inverso?
- R: No hace falta ni recomendable. Mantén HTTP & HTTPS, usa HTTPS como backend confiando en ServBay CA (o salta validación) y tendrás cifrado end-to-end más HTTP/2.
P: El proxy reporta errores de certificado/backend incorrecto, ¿por qué?
- R: Asegúrate de enviar SNI correcto (igual al dominio), que el proxy confía en ServBay CA (con cadena intermedia si corresponde). Puedes validar saltando verificación inicialmente.
P: ¿ServBay es estable en producción como backend?
- R: Sí. Muchos usuarios lo usan en Mac mini / Windows en datacenters con gran estabilidad. Lo crítico es alinear protocolo, SNI, cabecera Host, confianza y soporte IPv4/IPv6.
P: ¿Qué hago si no tengo IP pública?
- R: Usa Método 1: Túneles integrados (cloudflared / frpc), no necesitas ni IP pública ni abrir puertos.

Resumen

Publicar ServBay como backend en Internet es totalmente factible. La ruta recomendada es: mantener el modo HTTP & HTTPS, poner un proxy inverso que haga backend por HTTPS enviando el SNI correcto y confiando en ServBay CA, para obtener cifrado extremo a extremo y capacidades modernas como HTTP/2. Si no tienes IP pública, usa los túneles integrados como cloudflared o frpc; el reenvío de puertos queda para quienes entienden bien sus implicancias. En caso de errores, la checklist de este documento acelera el diagnóstico: casi siempre el problema estará en el modo de protocolo, SNI/certificado, cabecera Host o la dualidad IPv4/IPv6.

Publicar sitios ServBay en Internet (Proxy Inverso, Túneles y Reenvío de Puertos) ​

Entendiendo el comportamiento de red por defecto de ServBay ​

Comparativa de métodos para publicar ​

Método 1: Túneles integrados (el más sencillo, sin IP pública) ​

Método 2: Proxy inverso externo + HTTPS backend (recomendado) ​

¿Por qué preferir HTTPS backend en vez de HTTP 80? ​

Puntos clave generales ​

Obtener el ServBay CA para confiar en backend ​

Proxy inverso Nginx (backend HTTPS) ​

Proxy inverso HAProxy (backend HTTPS) ​

Proxy inverso Caddy (backend HTTPS) ​

Proxy inverso Traefik (backend HTTPS) ​

Método 3: Reenvío de puertos (NAT) ​

Consistencia entre IPv4 / IPv6 ​

Checklist de diagnóstico de fallos de acceso ​

Certificados y seguridad ​

Preguntas frecuentes (FAQ) ​

Resumen ​