VPN conectado pero el contenido mixto sigue bloqueado: qué corregir

Media página se renderiza, una hoja de estilos aparece en gris en el panel Red, y el cliente VPN sigue informando de un túnel sano. Las tres observaciones son ciertas a la vez, porque el navegador juzgó una petición que hizo la página y el túnel no tenía voto en ese juicio. Lo que cierra el caso es una decisión y no un ajuste: reparar la referencia, escalarla a quien posee el host, o abandonar la dependencia. Cada una de esas opciones tiene una prueba barata, y elegir la equivocada consume un ciclo de soporte.

Por qué el túnel no puede cubrir un subrecurso

El contenido mixto empieza con un documento HTTPS que pide un subrecurso por HTTP simple. Cada URL se juzga según su propio esquema, así que la protección del documento padre nunca se extiende a una petición hija. El cifrado añadido por debajo del navegador cambia lo que viaja por el cable, no el http:// que pidió el marcado.

Los navegadores actuales clasifican estas peticiones en dos grupos y las tratan de forma distinta. Los scripts, las hojas de estilo, los iframes y las llamadas con fetch, XMLHttpRequest o WebSocket se rechazan de plano, sin intento previo de actualización. Las imágenes, el audio y el vídeo se reescriben a https:// y se vuelven a pedir, y la carga se abandona cuando falla esa obtención segura. Una URL de subrecurso cuyo host es una dirección IP desnuda queda exenta de la actualización, así que una imagen HTTP en un host IP sigue bloqueada en lugar de repararse en silencio. La división, incluida esa excepción en el lado actualizable, está documentada en la guía de Mozilla sobre contenido mixto. Chrome aplica un rechazo similar a las descargas no seguras iniciadas desde una página segura, y por eso un enlace PDF puede morir mientras la página que lo rodea parece intacta.

La fila en gris es, por tanto, la prueba de que el control funciona, no la prueba de que el túnel haya filtrado texto en claro. Trata la fila como un hallazgo que apunta a una sola referencia y no a la página entera.

Decidir a quién pertenece la referencia no segura

Clasifica la URL infractora según dónde se produce antes de tocar nada. Esa respuesta decide si puedes publicar una corrección hoy, si un proveedor tiene que publicar una, o si la dependencia debe salir de la página. Léela en la columna Iniciador del panel Red, porque el marcado en pantalla suele montarse en tiempo de ejecución.

Cuando el host ya responde en el 443 y solo la referencia dice http, la reparación es local: cambia la referencia, vacía la caché de la página y confirma que la fila pasa a https. Un host que solo escucha en el puerto 80 no se puede poner en regla editándolo, así que el recurso se muda, se pone detrás de algo que controles, o desaparece. Una URL inyectada por un gestor de etiquetas sigue apareciendo aunque tu propia plantilla esté limpia, y ese caso pertenece a un ticket con la URL exacta y la línea de consola adjuntas. Decirle al personal que permita contenido no seguro no es ninguna de estas opciones, porque desactiva la comprobación para cada sitio que visita ese perfil de navegador.

Reparar la referencia en lugar del ajuste del navegador

Recarga el flujo que falla conservando el registro de red y filtra el panel por el host que sospechas. La consola nombra la URL y la directiva, lo que resuelve si una petición fue rechazada o actualizada antes de que toques una plantilla.

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

Dos controles de apoyo merecen conocerse, y ninguno sustituye a la reparación. Una cabecera Content-Security-Policy con upgrade-insecure-requests hace que el navegador reescriba las URL de subrecurso http antes de que salgan de la página, lo que atrapa referencias antiguas que aún no has encontrado. La petición reescrita sigue fallando cuando el host de destino no sirve HTTPS, así que la cabecera solo cambia qué URL intenta el navegador. HSTS se aplica por host, lo que significa que una política en tu propio dominio no hace nada por un CDN de terceros que nunca envió la cabecera. Tras un cambio de plantilla vacía la caché de la página y busca el nombre de host antiguo en el HTML renderizado, porque la misma URL también puede llegar por un parcial, una cadena de traducción o un campo de base de datos.

Sigue también las redirecciones, porque una cadena que empieza en https:// puede aterrizar en una ubicación http:// y el navegador juzga el último salto. La -L forma del segundo comando de arriba imprime esa URL efectiva por ti. Si el último salto es http puro, la referencia sigue mal aunque el enlace que editaste pareciera correcto.

Confirmar la página con la consola y el panel Red

Recarga con la caché desactivada y recorre el flujo otra vez, incluidos los botones que cargan contenido a demanda. Una primera carga de página esconde widgets perezosos, teselas de mapa y scripts de reproductor que solo aparecen tras un clic. La consola no debería contener entradas de contenido mixto y cada fila que hayas tocado debería mostrar https. Captura la consola y la fila de petición antes de cerrar el ticket, porque ese estado es difícil de reconstruir tras el siguiente despliegue.

Cuando el recurso es de otra persona, envía cuatro cosas: la URL exacta, el tipo de petición, el texto de la consola y la página donde aparece. Oculta los identificadores de sesión en todo lo que pegues en un ticket. Un informe que solo dice que las imágenes están rotas no da nada que buscar al propietario.

El túnel sigue haciendo su propio trabajo mientras la corrección vive en la referencia que produjo la petición. Busca una vez más el nombre de host en la plantilla y en el paquete del proveedor tras el despliegue, y cierra el caso solo cuando no quede ninguna entrada de contenido mixto bloqueada en la consola.