CDN:Performance optimization troubleshooting guide

Los problemas de rendimiento dependen de muchos factores. Antes de solucionarlos, compruebe que la solicitud realmente pase por CDN y establezca grupos de control para acotar la causa raíz.

Recopile el efecto de acceso

Una solución de problemas reproducible debe registrar como mínimo la siguiente información:

• Hora UTC, región e ISP del cliente, IP del cliente ofuscada <CLIENT_IP>, LocalDNS;

• URL de solicitud, método de solicitud, código de estado, cadena de redirecciones;

• Resultado de DNS, IP del nodo conectado realmente;

• X-Cache, X-Swift-CacheTime, Age (si está presente), Via;

• Cache-Control, Pragma, Expires, ETag, Last-Modified, Vary;

• Content-Type, Content-Length, Content-Encoding, Accept-Ranges, Content-Range;

• Duración de DNS, TCP, TLS, TTFB, descarga y total;

• Resultados de comparación de la misma solicitud para el primer GET por CDN, GET repetido, GET a nodo específico y GET directo al origen.

curl -sS -D /tmp/cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntime_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\nsize_download=%{size_download}\n' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<CDN_NODE_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<ORIGIN_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' \
  "https://<CDN_DOMAIN>/<LARGE_RESOURCE_PATH>"

curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"
curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

Calidad de red deficiente entre el cliente y el nodo o anomalía de programación

Síntoma: El ping al dominio acelerado muestra alta latencia o pérdida de paquetes; los usuarios de una región o ISP específico presentan lentitud; los usuarios se programan hacia nodos lejanos.

Posibles causas y solución de problemas:

• Configuración incorrecta de la región de aceleración: Cuando la región de aceleración se establece en "Mainland China only", los usuarios internacionales se programan hacia nodos de China continental; cuando se establece en "Global (excluding Mainland China)", los usuarios de China continental se programan hacia nodos internacionales. Establezca la región de aceleración con el alcance correcto según la distribución de usuarios (por ejemplo, "Global").

• El dominio no completó el registro ICP: Los dominios sin registro solo pueden seleccionar "Global (excluding Mainland China)". Cuando los usuarios de China continental acceden a través de nodos internacionales, el enlace es más largo y la velocidad puede ser insatisfactoria. Para ofrecer aceleración a los usuarios de China continental, complete primero el registro ICP; si no es posible registrarlo, considere usar Edge Security Acceleration (ESA) para reducir la latencia de los usuarios de China continental que acceden a sitios internacionales.

• Configuración DNS incorrecta del cliente: Por ejemplo, un usuario en Tokio que usa un DNS de EE. UU. podría programarse hacia un nodo estadounidense en lugar de uno cercano. Indique al usuario que cambie a un DNS correspondiente a su ubicación e ISP.

• Fluctuación de red del ISP regional: Cuando la región de aceleración y el DNS son correctos, pero el acceso sigue siendo lento, recopile información de traceroute y MTR para confirmar el segmento de enlace específico donde ocurre la latencia. Pruebe vinculando la IP del nodo al que llega la solicitud del usuario para confirmar si el nodo responde con normalidad y luego combine el estado de acierto de caché y el tamaño del recurso para un análisis más detallado.

Proporción de aciertos de caché baja o recuperación de origen frecuente que causa acceso lento

Síntoma: El encabezado de respuesta X-Cache es MISS, X-Swift-CacheTime es 0; alta presión de origen y alto tráfico de origen; el primer acceso es más lento que acceder directamente al origen.

Causas comunes y soluciones de optimización:

• El primer acceso no tiene caché: El nodo debe recuperar datos del origen en la primera respuesta. Se recomienda usar la función de captación previa de URL para traer proactivamente el contenido de origen a los nodos CDN; consulte Purge and prefetch resources.

• Tráfico bajo y popularidad insuficiente del archivo: La caché del nodo elimina los elementos menos populares según su popularidad; los recursos con poco tráfico se eliminan antes. En escenarios de tráfico bajo, extienda adecuadamente el tiempo de caché o use la captación previa para mantener la popularidad.

• Configuración de caché inadecuada:

  • Cuando no se configura ninguna regla de caché y los archivos estáticos no devuelven los encabezados de respuesta ETag y Last-Modified, el archivo no se almacena en caché. Agregue estos dos encabezados de respuesta en el origen o configure reglas de caché en CDN; consulte Configure CDN cache expiration.

  • Cuando no se configura ninguna regla de caché, se usa la política de caché predeterminada, con un tiempo máximo de caché que no supera los 3600 segundos, lo que provoca fácilmente expiraciones frecuentes y recuperaciones de origen. Establezca un tiempo de caché razonable según su negocio.

  • Cuando el encabezado de respuesta del origen contiene s-maxage=0, max-age=0, no-cache, no-store, private o Pragma: no-cache, el contenido no se almacenará en caché aunque haya reglas configuradas. Modifique el encabezado de respuesta del origen a un valor almacenable (como public) o habilite Ignore Origin No-Cache Header en la regla de caché de CDN.

• La URL lleva parámetros variables: Cuando URL con distintos parámetros acceden al mismo archivo, CDN las trata como recursos diferentes y recupera cada una desde el origen por separado. Habilite la función de ignorar parámetros; consulte Ignore parameters.

• Los archivos grandes tardan en recuperarse del origen: Para escenarios de archivos grandes, se recomienda habilitar la recuperación de origen por Range para optimizar la eficiencia; consulte Configure range origin fetch.

• Actualización frecuente de caché: Actualizar frecuentemente la caché de URL o directorios hace que la caché del nodo permanezca inválida y reduce la proporción de aciertos. Actualice únicamente los recursos afectados cuando se modifique el contenido.

Método de verificación: Vincule el dominio del usuario en hosts a la IP de origen y acceda directamente. Luego compare el tiempo de carga con el acceso por CDN para verificar el efecto de aceleración y confirmar si el cuello de botella está en la recuperación de origen o en el enlace de distribución. Para más estrategias de optimización de la proporción de aciertos, consulte Cache troubleshooting.

Solicitudes dinámicas lentas

Síntoma: El contenido dinámico, como las interfaces API, es lento; los recursos estáticos son rápidos, pero la página general carga lentamente.

Causa: CDN no almacena en caché contenido dinámico que cambia en tiempo real. Las solicitudes dinámicas se reenvían al servidor de origen cada vez, por lo que la aceleración por caché de CDN no tiene efecto sobre ellas. Si el origen es lento, las solicitudes dinámicas también lo serán.

Solución:

• Separe el contenido estático y dinámico en el origen: use un dominio acelerado por CDN para los recursos estáticos y un dominio que resuelva directamente al origen para las solicitudes dinámicas.

• Use Edge Security Acceleration (ESA) para acelerar las solicitudes dinámicas mediante optimización de ruta, optimización de transporte y otras tecnologías que acortan la cadena de origen. Tenga en cuenta que la aceleración dinámica es una optimización de enlace; si el servidor de origen es lento, aún deberá optimizarlo.

La recuperación de origen entre países o transfronteriza es lenta

Síntoma: Cuando el origen y los usuarios principales están en distintos países o regiones, la calidad de la recuperación de origen fluctúa, esta es lenta y la tasa de fallos es alta, lo que afecta la caché y la distribución de contenido.

Causa: La recuperación de origen transfronteriza depende de la capacidad de los cables submarinos y de la congestión de la red pública entre países.

Solución: Use Global Accelerator (GA) para proporcionar aceleración específica al origen en el país correspondiente y configure políticas de recuperación de origen por región en CDN para mejorar la calidad cuando hay fallos de caché. GA admite tipos de origen como ECS, ALB y OSS, y ofrece soluciones como Accelerate back-to-origin with GA and CDN.

La página principal del sitio web carga lentamente

Síntoma: La solicitud de la página principal permanece en estado Pending mucho tiempo en Network; después de que la página principal responde, los recursos estáticos cargan rápido.

Causa: La página principal suele ser un recurso dinámico o estar configurada como no almacenable en caché, por lo que cada visita regresa al origen. Cuando la respuesta del origen es lenta, la solicitud de la página principal se bloquea y los recursos posteriores, como imágenes, JS y CSS referenciados en el HTML, no pueden comenzar a cargar.

Solución: Primero confirme mediante los encabezados de respuesta si la página principal acierta en caché; si falla, solucione la configuración de caché según Proporción de aciertos de caché baja o recuperación de origen frecuente que causa acceso lento; si la respuesta del origen es lenta, optimice su rendimiento o adopte la separación de contenido estático y dinámico.

Los recursos grandes cargan lentamente

Síntoma: Content Download representa una gran proporción de Timing; los recursos de la página tienen un tamaño total grande.

Solución: Habilite las funciones de optimización de rendimiento (compresión inteligente, optimización de página, etc.) para reducir el tamaño de los archivos y mejorar la velocidad de carga; consulte Performance optimization. La compresión inteligente admite los siguientes formatos: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, text/javascript, image/tiff, image/svg+xml, application/json, application/xml.

La compresión Gzip no funciona después de la recuperación de origen

Síntoma: El origen (como Nginx) tiene habilitada la compresión Gzip y el encabezado de respuesta devuelve Content-Encoding: gzip cuando el cliente accede directamente al origen. Al acceder por CDN con el encabezado de solicitud que incluye Accept-Encoding: gzip, deflate, el encabezado de respuesta solo devuelve Content-Length y el contenido no está comprimido.

Causa: Las solicitudes de recuperación de origen de CDN incluyen el encabezado Via para indicar que provienen de un servidor proxy. El módulo ngx_http_gzip_module de Nginx usa la configuración gzip_proxied para controlar si se habilita la compresión en solicitudes de proxy. El valor predeterminado de esta configuración es off, por lo que las solicitudes de recuperación de origen de CDN no devuelven contenido comprimido.

Solución:

1. Establezca gzip_proxied any en el archivo de configuración de Nginx (bloque http, server o location, según corresponda) para que todas las solicitudes provenientes de servidores proxy se compriman.

2. Ejecute nginx -t para confirmar que la configuración es correcta y luego ejecute nginx -s reload para recargarla.

3. Acceda por CDN y confirme que el encabezado de respuesta contiene Content-Encoding: gzip.

Método de verificación: Use curl para probar directamente contra el origen. Cuando no se envía el encabezado Via, devuelve Content-Encoding: gzip; después de agregar -H 'Via:xxx' para simular una solicitud de proxy, solo devuelve Content-Length. Esto confirma que el problema se debe a la configuración de gzip_proxied.

Nota: El enfoque de solución de problemas es el mismo cuando la compresión Brotli no funciona. Confirme si el origen rechaza devolver contenido comprimido para solicitudes de proxy debido al encabezado de solicitud Via o a una configuración similar a gzip_proxied, y sustituya la configuración relacionada con Gzip por la configuración de Brotli correspondiente.

Compensación con la optimización de página: Si también habilita la optimización de página, tenga en cuenta que la compresión de origen y la optimización de página son mutuamente excluyentes; CDN no aplica la optimización de página después de que el origen devuelve contenido comprimido. Elija entre la compresión de origen (que ahorra ancho de banda de origen) y la optimización de página (que reduce el tamaño del HTML) según la prioridad de su negocio.

La optimización de página no funciona cuando están habilitadas tanto la optimización de página como la compresión Gzip

Síntoma: La optimización de página está habilitada. Cuando se envía curl sin el encabezado de solicitud Accept-Encoding, el HTML devuelto está optimizado; pero al acceder desde un navegador (que envía Accept-Encoding: gzip de forma predeterminada), el contenido devuelto no tiene optimización de página.

Causa:

• El origen devuelve contenido comprimido con Gzip: Los navegadores incluyen el encabezado de solicitud Accept-Encoding: gzip de forma predeterminada, y CDN reenvía este encabezado al recuperar del origen. Cuando el origen tiene Gzip habilitado, devuelve contenido comprimido. Los nodos CDN no descomprimen el contenido ya comprimido por el origen antes de aplicar la optimización de página, por lo que esta no surte efecto cuando el origen devuelve contenido comprimido.

• La compresión inteligente de CDN no bloquea la optimización de página: La compresión inteligente de CDN se ejecuta después de la optimización de página; ambas no entran en conflicto. Este síntoma solo aparece cuando el origen ya devolvió contenido comprimido. La precompresión del origen impide que CDN aplique la optimización de página y no guarda relación con la compresión inteligente del lado de CDN.

Solución:

• Opción 1: Asegúrese de que el origen no devuelva contenido comprimido con Gzip para las solicitudes de recuperación de origen de CDN. Para orígenes Nginx, modifique el parámetro gzip_proxied para que las solicitudes de servidores proxy no devuelvan contenido comprimido.

• Opción 2: En la configuración de CDN, elimine Accept-Encoding del encabezado de solicitud HTTP de origen para que el origen devuelva contenido sin comprimir y CDN aplique la optimización de página.

Nota: Después de que el origen deje de devolver contenido comprimido, CDN podrá comprimir la respuesta al cliente mediante la función de compresión inteligente, con lo que logrará tanto la optimización de página como la compresión de transmisión.

Anomalías de negocio tras habilitar ignorar parámetros

Síntoma: Después de habilitar ignorar parámetros, la autenticación falla, los datos de usuario se mezclan, se devuelve contenido en caché incorrecto o el procesamiento de imágenes deja de funcionar.

Causa: Una vez habilitada esta función, CDN trata las solicitudes con distintos parámetros como el mismo recurso para la caché. Los siguientes tipos de parámetros de URL no deben ignorarse de forma global:

• Identificadores de identidad de usuario (como UID, token, Session ID): ignorarlos provoca fallos de autenticación o mezcla de datos de usuario.

• Diferenciación de contenido dinámico (como versión ?v=1, número de página ?page=2): ignorarlos devuelve contenido en caché incorrecto.

• Directivas de procesamiento de origen (como el parámetro de procesamiento de imágenes de OSS x-oss-process): ignorarlo invalida el parámetro de procesamiento y devuelve el recurso original sin procesar.

Solución de problemas y solución:

1. Elimine o deshabilite la configuración de ignorar parámetros.

2. Actualice la caché (actualización de URL o de directorio) para borrar la caché obsoleta en los nodos perimetrales.

3. Si necesita conservar algunos parámetros, use el modo de retener parámetros especificados y establezca los parámetros clave (como x-oss-process, token) como retenidos. Para obtener detalles sobre la función de ignorar parámetros, consulte Ignore parameters.

La configuración de ignorar parámetros no surte efecto después de modificarla

Síntoma: Después de modificar la configuración de ignorar parámetros, el acceso sigue siendo anómalo o el tráfico de origen no disminuyó.

Causa: Tras modificar la configuración, los archivos ya almacenados en caché en los nodos perimetrales no se actualizan automáticamente; la caché antigua sigue respondiendo según la política anterior.

Pasos para solucionar el problema:

1. Confirme que la configuración se guardó: Inicie sesión en la consola de CDN, vuelva a abrir la página de configuración de ignorar parámetros y confirme que la configuración actual coincide con el estado esperado.

2. Compruebe si hay conflicto con Cache Key personalizado: Cache Key personalizado anula la configuración de ignorar parámetros. Si Cache Key personalizado está habilitado, la configuración de ignorar parámetros no tendrá efecto. Confirme que ambas opciones no estén habilitadas al mismo tiempo.

3. Actualice la caché: En la página Purge and prefetch resources, ejecute una actualización de URL o de directorio. La nueva configuración solo surtirá efecto completo después de borrar la caché antigua.

4. Verifique el efecto de la configuración: Ejecute curl -I "full URL" y revise el encabezado de respuesta X-Cache para confirmar que el estado de acierto de caché cumple con lo esperado.

Contenido incorrecto en el procesamiento de imágenes de OSS o la captura de fotogramas de video

Síntoma: Al usar el procesamiento de imágenes de OSS (como x-oss-process=image/resize,w_200) o la captura de fotogramas de video, el acceso devuelve la imagen o el video original sin procesar, o bien las solicitudes con distintos parámetros de procesamiento devuelven el mismo contenido.

Causa: Después de habilitar ignorar parámetros para el dominio CDN, el enlace de la imagen original y el enlace con parámetros de procesamiento se almacenan en caché como el mismo recurso, lo que genera contenido incorrecto.

Solución: En la configuración de ignorar parámetros de la consola de CDN, establezca el parámetro x-oss-process en el modo de retener parámetros especificados, para que las URL con parámetros de procesamiento de imágenes se almacenen en caché por separado y no entren en conflicto con la caché de la imagen original. Después de modificar la configuración, actualice la caché (consulte La configuración de ignorar parámetros no surte efecto después de modificarla).

Estado de acierto de caché inconsistente tras habilitar ignorar parámetros

Síntoma: Ignorar parámetros está habilitado, pero el estado de acierto de caché es inconsistente entre clientes; algunas solicitudes muestran X-Cache MISS.

Posibles causas:

1. La URL lleva parámetros de autenticación dinámicos no ignorados: Por ejemplo, la URL tiene auth_key y otros parámetros de autenticación configurados como retenidos. Cada solicitud tiene un valor de autenticación distinto, por lo que CDN las reconoce como recursos diferentes.

2. El primer acceso no tiene caché en el nodo: El recurso aún no se ha almacenado en caché en ese nodo perimetral, por lo que el primer acceso inevitablemente mostrará MISS.

3. Diferencias en los encabezados de solicitud del cliente: Por ejemplo, un Accept-Encoding distinto puede activar el almacenamiento de múltiples copias (las versiones Gzip y no Gzip se almacenan por separado). Si el origen devuelve Vary: User-Agent, las solicitudes de distintos UA también se almacenarán por separado.

4. Conflicto con Cache Key personalizado: Cache Key personalizado anula la configuración de ignorar parámetros; cuando ambas están habilitadas, ignorar parámetros no surte efecto.

Método de solución de problemas: En el cliente, ejecute curl -I "full URL" y compare los encabezados de respuesta X-Cache y X-Swift-CacheTime para confirmar el estado de caché. Solución: Confirme que la configuración de ignorar parámetros es correcta (habilitada y con los parámetros clave retenidos), asegúrese de que la estrategia de encabezados de solicitud del cliente sea consistente y compruebe que Cache Key personalizado no esté habilitado al mismo tiempo.