Apuntar tu propio dominio a un servidor de etiquetado: el CNAME, el certificado y el error 1014 de Cloudflare

Dos razones, y son distintas. Para un bloqueador de anuncios, una solicitud es de terceros si su nombre de host está en una lista, y signalhost.io hoy no está en ninguna pero podría estarlo mañana; tusitio.com nunca lo estará. Para un navegador, una cookie colocada por una respuesta de metrics.tusitio.com es una cookie de primera parte para tusitio.com, mientras que una de otro dominio es de terceros, y Safari la rechaza sin más. Esa es la cookie que conserva un clic en un anuncio para Google Ads, Meta y TikTok hasta la compra. Lo que no consigue es una vida más larga: Safari sigue limitando a siete días las cookies de un servidor que está en una dirección distinta. El servidor de etiquetado es el mismo en ambos casos. El nombre de host es lo que cambia cómo se le trata.

¿Montas un servidor de etiquetado desde cero? Cómo configurar Google Tag Manager del lado del servidor, paso a paso.

Un CNAME, en tu proveedor de DNS, que apunte el subdominio que elegiste a nuestro punto de entrada solo DNS:

metrics.yoursite.com.   CNAME   tenants.signalhost.io.

No a tu nombre de host aleatorio de inquilino, y no a un comodín. tenants.signalhost.io es un nombre que publicamos específicamente para esto, y la razón por la que tiene que ser ese nombre es la siguiente sección.

Si tu propio dominio está en Cloudflare, crea el registro con el proxy APAGADO: la nube gris, «solo DNS». Un registro con proxy enrutaría las solicitudes de tus visitantes a través de tu cuenta de Cloudflare hasta nosotros, y el paso del certificado de abajo no puede completarse a través de él.

Nuestros propios nombres de host están detrás de Cloudflare. Si un cliente apunta su CNAME a uno de nuestros nombres con proxy —el comodín, o un nombre de host de inquilino—, su tráfico llega a Cloudflare para un nombre de host que pertenece a una cuenta de Cloudflare distinta de la nuestra. Cloudflare lo rechaza con el error 1014, «CNAME Cross-User Banned». La página que lo muestra es de Cloudflare, no menciona a ninguno de los dos, y nada en tu DNS, tu sitio o tu navegador lo explica.

tenants.signalhost.io está sin proxy a propósito: resuelve directamente a nuestros servidores, así que un CNAME hacia él simplemente funciona. La comprobación de DNS del panel reconoce el caso del destino con proxy por su nombre y dice qué cambiar, pero es más rápido no llegar a hacerlo.

En cuanto el registro resuelve, solicitamos un certificado de Let's Encrypt para tu nombre de host. La validación es HTTP-01: Let's Encrypt recupera una ruta concreta por HTTP sin cifrar en el puerto 80 desde el nombre, y nosotros la respondemos. HTTP sin cifrar porque todavía no hay certificado —eso es lo que se está obteniendo—, y esta es la única ruta sin cifrar que nuestro borde responde en absoluto. Es una comparación de nonce; nada más es accesible por ese camino.

Cuenta con unos minutos. El panel muestra tres pasos en orden: el CNAME resuelve, se emite el certificado, el nombre de host está sirviendo. Un paso atascado en el certificado con el CNAME en verde casi siempre significa un registro con proxy de tu lado: Cloudflare responde a la solicitud de validación con su propio certificado y su propia página, y Let's Encrypt ve lo que no debe.

La etiqueta de Google de tu contenedor web lleva la URL del contenedor de servidor. Cuando el nombre de host empieza a servir, la reescribimos a tu dominio personalizado y republicamos el contenedor, y la devolvemos al nombre de host de inquilino si quitas el dominio. Desde ese momento, tus hits van a tu propio dominio.

Te queda una cosa por hacer: el fragmento de tu sitio sigue cargando Tag Manager desde tu dirección de signalhost.io. Sigue funcionando, pero es la única solicitud que una lista de filtros aún podría reconocer, así que sustitúyelo. La página del contenedor muestra el fragmento nuevo en cuanto el dominio está sirviendo, y te lo enviamos por correo electrónico en ese mismo momento. Sustitúyelo en lugar de añadir un segundo: dos fragmentos cargan el contenedor dos veces.

Quitar un dominio es lo mismo a la inversa. Quítalo en el panel, vuelve a poner en tu sitio el fragmento que muestre entonces la página del contenedor —carga de nuevo desde tu dirección de signalhost.io— y borra el registro DNS al final. Si borras primero el registro, hasta que el panel se dé cuenta, tu sitio carga sus etiquetas desde un nombre que ya no resuelve.

• Error 1014 en el navegador: el CNAME apunta a un nombre nuestro con proxy. Cambia el destino a tenants.signalhost.io.
• CNAME en verde, certificado pendiente durante más de quince minutos: tu registro tiene proxy. Pon la nube en gris en tu proveedor de DNS.
• El CNAME nunca se pone en verde: busca un registro A o AAAA en conflicto con el mismo nombre —un CNAME no puede coexistir con ellos— y dale a la propagación hasta una hora.
• Sirviendo, pero la página del contenedor no muestra tráfico del nombre nuevo: el contenedor web todavía no se ha republicado. Ocurre a los pocos minutos de que el nombre de host esté activo; la página del contenedor muestra a qué nombre de host apunta la etiqueta ahora mismo.
• Sirviendo, pero tu sitio sigue cargando Tag Manager desde signalhost.io: el fragmento antiguo sigue en la página. Sustitúyelo por el de la página del contenedor.