Dominio Personalizado y HTTPS

Dominio Personalizado y HTTPS

Una instalación nueva responde en http://localhost. Esta guía la mueve a tu propio dominio a través de HTTPS — por ejemplo https://consent.example.com.

Haz esto antes de agregar sitios. Cada script de consentimiento que genera Conzent tiene tu dominio incorporado. Cambiar el dominio más tarde funciona, pero debes regenerar los scripts (paso 5) y actualizar el fragmento de inserción en cada sitio web que ya los esté utilizando (paso 6).

1. Apunta DNS a tu servidor

Crea un registro A para el nombre de host que deseas, apuntando a la IP pública de tu servidor:

consent.example.com.   A   203.0.113.10

Confirma que se resuelve con dig +short consent.example.com antes de continuar. Un subdominio de un dominio que ya posees — consent., cmp., privacy. — es la elección habitual.

2. Establecer APP_URL

APP_URL es la única fuente de verdad para cada URL absoluta que produce Conzent: puntos finales de scripts de consentimiento, el fragmento de inserción mostrado en el panel, enlaces de restablecimiento de contraseña y callbacks de OAuth.

Edita .env en tu directorio de instalación:

APP_URL=https://consent.example.com

Utiliza la URL pública exacta, con el esquema y sin barra final. Si estás terminando TLS — y deberías — eso significa https://, aunque el contenedor en sí aún hable HTTP simple internamente. Establecer https:// también cambia la cookie de "recordarme" a Secure, por lo que nunca se envía a través de HTTP simple.

Las nuevas instalaciones pueden hacer los pasos 1 y 2 de una vez:

curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

3. Terminar TLS

El contenedor de nginx incluido sirve HTTP simple en ${APP_PORT:-80}. No obtiene ni sirve certificados.

Opción A — Caddy al frente. Caddy obtiene y renueva automáticamente los certificados de Let's Encrypt. Libera el puerto 80 estableciendo APP_PORT=8080 en .env, luego crea docker-compose.override.yml:

services:
  caddy:
    image: caddy:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./docker/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config
    depends_on:
      - nginx
    restart: unless-stopped

volumes:
  caddy-data:
  caddy-config:

Con docker/caddy/Caddyfile:

consent.example.com {
    reverse_proxy nginx:80
}

Ejecuta docker compose up -d. Caddy emite el certificado en la primera solicitud.

Opción B — un nginx o Apache existente. Establece APP_PORT=8080 en .env, luego haz proxy a él:

server {
    listen 443 ssl http2;
    server_name consent.example.com;

    ssl_certificate     /etc/letsencrypt/live/consent.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/consent.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

X-Forwarded-For es importante más allá de la limpieza: Conzent registra la IP del visitante en cada entrada de registro de consentimiento y la utiliza para la geo-segmentación. Sin el encabezado, cada consentimiento se atribuye a tu proxy.

Opción C — Cloudflare. Haz proxy del registro y establece el modo SSL/TLS en Completo. Mantén TLS de origen activado; "Flexible" deja la conexión entre Cloudflare y tu servidor sin cifrar. Establece CLOUDFLARE_ZONE_ID y CLOUDFLARE_API_TOKEN en .env para que Conzent purgue automáticamente la caché de borde cuando los scripts cambien.

Pon los cambios de pila en docker-compose.override.yml, nunca en docker-compose.yml — las actualizaciones restablecen los archivos rastreados, y el archivo de anulación se deja intacto.

4. Reiniciar y confirmar

docker compose up -d
docker compose exec app php bin/oci health

Carga https://consent.example.com. Deberías obtener la página de inicio de sesión a través de un certificado válido.

5. Regenerar los scripts de consentimiento

Este es el paso que es fácil de pasar por alto y produce los síntomas más extraños si lo haces.

El script de cada sitio vive en public/sites_data/{site_key}/script.js y contiene URLs absolutas construidas a partir de APP_URL en el momento de la generación — el punto final de la API al que publica el consentimiento, el CSS que carga, las rutas del logo. Cambiar APP_URL no reescribe los scripts que ya existen. Hasta que regeneres, los banners en los sitios de tus clientes seguirán llamando al antiguo host: el consentimiento se registra contra el origen incorrecto, o falla por completo una vez que la antigua dirección deja de responder.

docker compose exec app php bin/oci scripts:regenerate

6. Actualiza el fragmento de inserción en tus sitios web

El fragmento mostrado en el panel ahora apunta al nuevo dominio:

<script async src="https://consent.example.com/c/consent.js" data-key="YOUR_SITE_KEY"></script>

Si estás moviendo una instalación en vivo, mantén el antiguo nombre de host resolviendo y haciendo proxy al nuevo hasta que hayas cambiado cada inserción. El cargador es el punto de entrada para todo el banner — un src roto significa que no hay banner de consentimiento en absoluto.

7. Verifica de extremo a extremo

curl -sSI https://consent.example.com/c/consent.js | head -1
curl -s https://consent.example.com/sites_data/YOUR_SITE_KEY/version.json

Luego carga una página que inserte el banner, acepta el consentimiento y confirma que la entrada aparece bajo Registros de Consentimiento. Ese único viaje de ida y vuelta ejerce DNS, TLS, el cargador, el script generado y la ruta de la API juntos.

Resolución de problemas

La referencia completa vive con el código: docs/custom-domain.md en GitHub.