> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryprofound.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Verificar y solucionar problemas
> Confirma que Dynamic Bot Rendering enruta correctamente, interpreta los encabezados de diagnóstico x-concierge-* y resuelve los fallos de configuración más comunes.
## Prueba tu configuración
Cada una de las comprobaciones siguientes envía una solicitud `GET`. El contrato de Profound solo cubre `GET`, así que usa `curl -sD - -o /dev/null` en lugar de `curl -I`, que envía `HEAD`. Una respuesta `HEAD` puede provenir de tu origen o de un controlador que omite el cuerpo, y no te dice nada sobre el enrutamiento.
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing -A 'chatgpt-user'
```
Busca un UUID en `x-concierge-request-id` y `x-concierge-bot-kind: chatgpt-user`. Juntos demuestran que tu CDN enrutó la solicitud a Profound y que Profound reconoció al asistente. No demuestran que se haya servido una página renderizada: un `MISS` con `x-concierge-failopen: 1` significa que Profound devolvió el contenido en vivo de tu origen.
En la página que publicaste durante la [configuración](/es/dynamic-bot-rendering/overview#before-you-start), exige también `x-concierge-cache: HIT` y el HTML renderizado. Guarda el cuerpo para compararlo y deja que curl lo descomprima por si Profound lo sirvió con codificación gzip:
```bash theme={null}
curl -sS --compressed -D /tmp/dbr-headers.txt -o /tmp/dbr-page.html \
https://www.example.com/pricing -A 'chatgpt-user'
```
Si esta solicitud es un `MISS`, revisa los encabezados `x-concierge-policy` como se describe en [Interpretar el resultado](#reading-the-result). Repetir la solicitud no convierte un `MISS` en un `HIT`; solo publicar un renderizado lo hace.
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing \
-A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36'
```
No esperes encabezados `x-concierge-*` y sí el mismo contenido de página que antes. Compara también la latencia y las tasas de aciertos de caché con tu línea base: un Worker o un cambio en una política de caché compartida puede afectarlas incluso cuando el enrutamiento no cambia.
```bash theme={null}
curl -sD - -o /dev/null https://www.example.com/pricing -A 'Googlebot/2.1'
```
Tampoco esperes encabezados `x-concierge-*`. Si esta solicitud se enruta, consulta [Problemas comunes](#common-problems).
En staging, envía métodos distintos de `GET`, solicitudes a `/api/users`, `/graphql`, autenticación, administración, recursos del framework y activos, incluidos endpoints sin extensión. Usa endpoints de prueba inofensivos para los métodos que podrían modificar datos, y valores de prueba no secretos para cookies y encabezados de autorización. Todos ellos deben permanecer en tu ruta actual. En Vercel, prueba también los hosts de vista previa y alternativos.
Usa staging o una configuración aislada, registra la configuración original y restáurala después de cada prueba.
* **Cloudflare:** prueba un upstream inaccesible, un tiempo de espera de encabezados de respuesta y uno de los estados de respaldo configurados. Espera contenido del origen con `x-concierge-cdn-failover: 1`. Las redirecciones, `404` y `429` se transmiten tal cual, y una respuesta que ya ha comenzado a transmitirse no se puede reemplazar.
* **CloudFront:** prueba los tiempos de espera de conexión y de respuesta del origen principal dentro del presupuesto configurado y los criterios de estado seleccionados. Espera el origen de respaldo para los fallos configurados, pero no para `401`. Envía solicitudes no almacenadas en caché y ten en cuenta que las respuestas de respaldo en caché persisten hasta que expire su TTL, incluso después de restaurar el origen principal.
* **Vercel:** no hay conmutación por error a nivel de CDN. Durante una interrupción de Profound o tras un rechazo definitivo, un asistente puede recibir un error. No esperes un respaldo transparente al origen.
Después de restaurar la configuración, espera a que se propague y repite las comprobaciones de enrutamiento y de la página publicada.
## Ejecuta la verificación de la configuración desde el dashboard
El dashboard de Profound puede probar el enrutamiento por ti. Envía una solicitud con cada uno de los nueve valores de `User-Agent` de asistentes compatibles a una URL de tu host registrado, desde fuera de tu red, e informa cuáles enrutó tu CDN a Profound.
Estas sondas no llevan credenciales ni marcador de bucle, por lo que tu CDN las ve como tráfico real de asistentes. Un asistente cuenta como enrutado solo cuando su respuesta incluye un ID de solicitud válido y el tipo de bot correspondiente. Un `MISS`, un dominio en pausa, una redirección o un estado distinto de `200` pueden igualmente confirmar el enrutamiento; el estado de la página se informa por separado. Asegúrate de que la URL que pruebas esté en tu lista de páginas públicas permitidas; de lo contrario, todos los asistentes aparecerán, correctamente, como no enrutados.
La verificación de la configuración es una observación en vivo de una URL en un momento concreto. Confirma que la regla de tu CDN se activa para cada asistente. No verifica la propiedad del dominio y no sustituye la comprobación manual de tu página de prueba publicada.
## Referencia de encabezados de respuesta
| Encabezado | Significado |
| - | - |
| `x-concierge-request-id` | Un UUID que Profound asigna a cada solicitud que gestiona. Su ausencia significa que Profound nunca vio la solicitud: la regla no coincidió, la CDN conmutó por error o un proxy eliminó el encabezado. |
| `x-concierge-cache` | `HIT` cuando se sirvió un renderizado publicado, `MISS` cuando Profound recurrió a tu origen. |
| `x-concierge-bot-kind` | El asistente que Profound reconoció, o `unknown`. |
| `x-concierge-failopen` | `1` cuando se devolvió contenido en vivo del origen en lugar de un renderizado almacenado. |
| `x-concierge-origin-status` | El estado HTTP de tu origen, cuando se consultó tu origen. |
| `x-concierge-policy` | El modo efectivo para esta solicitud: `serve`, `warm` u `off`. Consulta [modos de política](/es/dynamic-bot-rendering/overview#policy-modes). |
| `x-concierge-policy-source` | Qué nivel decidió ese modo: `page` para una regla de página, `domain` para el valor predeterminado del dominio o un dominio en pausa, o `default` cuando no se aplicó ninguna regla. |
| `x-concierge-policy-rule` | El ID de la regla ganadora, cuando la hubo. |
| `x-concierge-auth` | Solo en `401`: `missing-key`, `unknown-key` o `inactive-key`. |
| `x-concierge-cdn-failover` | Lo establece el Cloudflare Worker de estas guías, no Profound, cuando sirvió tu origen tras una llamada fallida al upstream. |
## Interpretar el resultado
| Lo que ves | Lo que significa |
| - | - |
| `cache: HIT` | Se sirvió un renderizado publicado. Revisa también el estado y el cuerpo. |
| `MISS` + `failopen: 1` + `policy: serve` | La política permite servir, pero la URL no tiene una publicación utilizable. Renderiza, revisa y publica un candidato para esta ruta y consulta exactas. |
| `MISS` + `failopen: 1` + `policy: warm` | `warm` sirve contenido del origen incluso cuando existe una publicación. Cambia la regla ganadora a `serve` cuando estés listo. |
| `MISS` + `policy: off` + `policy-source: default` | Ninguna regla cubre esta ruta, así que no está habilitada. Añade un valor predeterminado de dominio o una regla de página. |
| `MISS` + `policy: off` + `policy-source: domain` + sin ID de regla | El dominio está en pausa. Reanúdalo en el dashboard. |
| `MISS` + `policy: off` + un ID de regla | La regla ganadora es `off`, o excluye a este asistente de su lista de permitidos. Con `policy-source: domain`, esa regla es el valor predeterminado del dominio. Revisa su modo y los asistentes permitidos. |
| `bot-kind: unknown` | Tu CDN enrutó un `User-Agent` que Profound no reconoce. La solicitud añadió un viaje de ida y vuelta y recibió contenido del origen. Alinea tu regla con la [lista de compatibles](/es/dynamic-bot-rendering/overview#supported-ai-assistants). |
| Sin encabezados `x-concierge-*` en una solicitud de asistente | Profound nunca vio la solicitud. Revisa las condiciones de coincidencia de la regla y, en Cloudflare y CloudFront, si se activó la conmutación por error de la CDN. |
## Respuestas de error
Profound solo recurre a tu origen después de que una solicitud está autenticada y es válida. Los errores de configuración se rechazan en lugar de redirigirse por proxy. El Worker de Cloudflare enmascara sus estados de rechazo configurados sirviendo tu origen, y CloudFront enmascara `400` y `403`, pero no `401`. Vercel no tiene reintentos. Cuando aparezca una página del origen donde esperabas un rechazo, inspecciona los diagnósticos de tu CDN.
| Estado | Causa | Solución |
| - | - | - |
| `401` + `x-concierge-auth: missing-key` | No llegó ningún encabezado `x-concierge-api-key`. | Confirma que la regla adjunta la clave. Nunca registres ni muestres una clave real mientras diagnosticas. |
| `401` + `unknown-key` | Llegó un valor, pero no coincide con ninguna clave. | Busca truncamientos, espacios en blanco o un `$PROFOUND_CONCIERGE_KEY` literal que nunca se expandió. En Vercel, valida la expansión de variables con un valor de prueba no secreto antes de usar la clave real. |
| `401` + `inactive-key` | La clave fue revocada. | Crea una clave nueva y despliégala. |
| `403` | El host no está registrado o pertenece a otra organización. | Registra el host público exacto en el dashboard. Debe coincidir tras la normalización: en minúsculas, sin punto final y sin puerto. |
| `400` | Un host o ruta mal formados, una URL absoluta donde se esperaba una ruta, un fragmento `#` o un marcador de bucle entrante. | Normalmente, una regla que envía una URL completa en lugar de una ruta, o una condición de protección contra bucles defectuosa. |
| `405` | Un método distinto de `GET` llegó a Profound. | Enruta solo `GET` a Profound y prueba con `curl -sD - -o /dev/null` en lugar de `curl -I`. |
| `502` | Profound no pudo acceder a tu origen y no tenía ninguna publicación que servir, o falló una consulta en el backend. | Comprueba que tu origen sea accesible desde internet público y que no bloquee las solicitudes de Profound. Una CDN también puede generar su propio `502`, así que revisa también sus diagnósticos. |
## Problemas comunes
Tu patrón de `User-Agent` coincide con algo fuera de la lista de tokens compatibles. Compáralo con el patrón de tu guía de configuración y con los [asistentes compatibles](/es/dynamic-bot-rendering/overview#supported-ai-assistants). Los rastreadores de búsqueda como `Googlebot` deben seguir llegando a tu origen.
CloudFront reemplaza el `User-Agent` del visitante por `Amazon CloudFront` en las solicitudes al origen, a menos que una política de solicitudes al origen lo reenvíe. Entonces Profound no tiene nada que clasificar. Usa la política de solicitudes al origen personalizada y restringida de la [guía de CloudFront](/es/dynamic-bot-rendering/cloudfront). Evita **AllViewer**, que también reenvía el `Host` del visitante y puede romper la conexión con Profound. Añade `User-Agent` a la política de solicitudes al origen, no a la clave de caché.
La lista de asistentes permitidos de la regla ganadora lo excluye. La respuesta muestra `x-concierge-policy: off` junto con el ID de la regla. Añade el asistente a la lista, o vacía la lista para que la regla herede el valor predeterminado del dominio.
Alguna capa de caché almacena HTML sin separar las respuestas de asistentes y humanos, o sin separar hosts, rutas y cadenas de consulta.
En CloudFront, incluye `x-concierge-route` en la clave de caché, mantén el TTL mínimo en `0` y revisa las variantes de host y de consulta. En Cloudflare, verifica que la llamada al upstream del Worker omita la caché; usar solo el `User-Agent` como clave no puede separar las identidades de página, porque todas las páginas usan la misma URL de upstream. En Vercel, inspecciona la configuración de caché de reescrituras externas del proyecto. En todos los proveedores, revisa también qué ocurre con las entradas en caché después de publicar un reemplazo, despublicar o pausar: una entrada de la CDN puede sobrevivir al cambio en Profound.
La protección contra bucles está fallando. Tu regla debe dejar que las solicitudes que llevan `x-concierge-request` pasen directamente a tu origen. Profound añade ese encabezado a sus propias solicitudes al origen y rechaza con `400` cualquier solicitud entrante que lo lleve, de modo que una exclusión defectuosa se traduce en una solicitud fallida en lugar de un bucle.
En Vercel, se trata de una condición `missing` sobre `x-concierge-request` con el valor `^1$`, el marcador que añade Profound. Cualquier otra expresión regular desactiva la exclusión sin avisar, porque una condición `missing` con un valor solo excluye las solicitudes cuyo encabezado coincide con él.
Las cadenas de consulta forman parte de la identidad de la página. Si tu CDN las elimina antes de la solicitud al origen, `/product?id=a` y `/product?id=b` se reducen a `/product`, y se renderiza y sirve la variante incorrecta.
En CloudFront, incluye en la política de caché las cadenas de consulta de las que dependen tus páginas, o "All". Una política de solicitudes al origen puede reenviar cadenas de consulta adicionales sin incluirlas en la clave, así que verifica el reenvío y la identidad de caché por separado.
Lee `x-concierge-policy` y `x-concierge-policy-source` en la respuesta. Si no hay ninguna regla coincidente, el modo es `off`, y `warm` sirve contenido en vivo del origen incluso cuando existe una publicación. Establece la regla ganadora en `serve`.
Luego confirma que se revisó y publicó un candidato para esta ruta y consulta exactas. La aprobación por sí sola no lo publica, y las solicitudes repetidas tampoco. Un candidato retenido como pendiente sigue pendiente hasta que alguien lo apruebe, lo rechace o lo publique. Si la página está publicada y la política es `serve`, pero sigues viendo un `MISS`, revisa las cachés de tu CDN y la accesibilidad de tu origen.
Revisa las reglas de WAF, los desafíos de bots, la protección de despliegues y las listas de permitidos del origen, tanto para el tráfico entrante de asistentes como para las solicitudes de Profound al origen. Profound no reenvía las cookies ni los encabezados de autorización del visitante, por lo que las páginas protegidas o dependientes de la sesión deben quedar fuera de esta configuración. El marcador de bucle se puede falsificar y no debe usarse como forma de eludir el firewall o la autenticación. Si tu origen necesita una forma de identificar las solicitudes de Profound, contacta con el soporte de Profound.
## Desactivarlo
Para dejar de servir renderizados sin tocar tu CDN, pausa el dominio en el dashboard de Profound. Todas las solicitudes de asistentes van a tu origen mientras se conservan tus reglas, renderizados y publicaciones, y al reanudarlo se restauran. Una pausa surte efecto en Profound de inmediato, pero las respuestas que tu CDN ya almacenó en caché persisten hasta que expiran. Una pausa no sustituye la conmutación por error a nivel de CDN durante una interrupción, porque la solicitud aún tiene que llegar a Profound.
Para eliminar la integración, restaura la configuración de la CDN que registraste antes de la configuración:
* **Cloudflare:** elimina la ruta del Worker añadida o restaura su vinculación anterior sin eliminar otra lógica del Worker.
* **CloudFront:** restaura la asociación de solicitudes del visitante y las políticas anteriores. Usa **No association** solo cuando antes no había ninguna.
* **Vercel:** elimina solo la ruta añadida de `vercel.json`, conserva el resto del enrutamiento y vuelve a desplegar.
Los cambios de enrutamiento surten efecto tras la propagación de la configuración o del despliegue. Las respuestas de respaldo almacenadas previamente en caché pueden persistir hasta su expiración o hasta tu proceso habitual de invalidación. Verifica el enrutamiento y el contenido originales después de revertir. Los dominios registrados, las claves y las publicaciones permanecen en Profound hasta que los elimines.