¿Por qué un sitio web funciona con datos móviles pero no con Wi-Fi?

Si un sitio web funciona con datos móviles pero no con Wi-Fi, el sitio no está inaccesible desde todas las redes. La variable que cambia es la ruta desde su dispositivo a través de la red Wi-Fi, por lo que el fallo más probable está en el DNS local, el router, una VPN o un filtro, el estado del navegador o la ruta del proveedor de banda ancha. Primero, compruebe la URL con el comprobador de disponibilidad web de ClockTools. Luego pruebe la misma URL en el mismo dispositivo a través de Wi-Fi y datos móviles, cambiando solo una variable a la vez.

¿Qué prueba este síntoma?

Demuestra que al menos una ruta de red puede llegar al sitio en ese momento. Eso no demuestra que se pueda acceder a todas las páginas o acciones de cuenta desde cualquier región o red. Los datos móviles y el Wi-Fi doméstico pueden utilizar distintos resolutores DNS, direcciones IP públicas, rutas, filtros de contenido y rutas IPv4/IPv6.

Utilice esta pequeña matriz de evidencia antes de cambiar la configuración:

La frase "misma URL" es importante. Una página de inicio y un panel autenticado pueden viajar a través de diferentes rutas de aplicación. Copie la dirección completa en lugar de escribir solo el dominio.

¿El sitio web realmente está caído?

Compruébelo desde fuera de su red local antes de reiniciar nada. ClockTools realiza una comprobación externa de DNS y HTTP e informa del resultado, la resolución A/AAAA, las redirecciones, la URL final, el estado de la respuesta, determinadas cabeceras y los tiempos. En una comprobación controlada el 2026-08-31, https://example.com devolvió en línea, HTTP 200, DNS resuelto y ninguna redirección desde el nodo MAA. Un nombre de host .invalid deliberadamente inexistente devolvió inaccesible, con DNS sin resolver y sin resultado HTTP.

Estas dos pruebas muestran por qué importa el orden: una consulta DNS fallida y un servidor HTTP accesible requieren soluciones distintas. También muestran el límite de la herramienta. Un único nodo externo aporta evidencia sólida, pero no demuestra la disponibilidad desde todas las ciudades o ISP.

Si se puede acceder al resultado externo pero su Wi-Fi aún falla, continúe localmente. Si no es posible acceder a él externamente y mediante datos móviles, espere o comuníquese con el propietario del sitio antes de cambiar su enrutador.

¿Dónde debe hacer la siguiente prueba?

Siga el árbol de diagnóstico en el diagrama adjunto:

1. Mantenga fijos el dispositivo y la URL exacta; cambie solo entre Wi-Fi y datos móviles.
2. En Wi-Fi, pruebe con una ventana privada o un segundo navegador.
3. Pruebe otro dispositivo en la misma red Wi-Fi.
4. Pause temporalmente una VPN o un proxy solo el tiempo necesario para hacer una comparación y después restáurelo.
5. Compare el comportamiento de DNS antes de reemplazar el solucionador.
6. Reinicie el enrutador solo después de registrar la evidencia que de otro modo borraría.

Una ventana privada puede omitir algunas cookies y extensiones almacenadas en caché, pero no crea una nueva ruta ISP. Un segundo dispositivo en el mismo Wi-Fi es más útil para separar el estado del dispositivo del estado de la red. Para obtener una pista a nivel de ruta, utilice Trazado de ruta; para su identidad de salida, compare ¿Cuál es mi IP? en cada red.

¿Podría DNS ser la diferencia?

Sí. Su enrutador Wi-Fi puede anunciar el solucionador de ISP mientras que los datos móviles utilizan el solucionador del operador. Un solucionador puede tener un registro obsoleto, una política de filtrado o una falla que el otro no tiene.

Comience con la observación, no con el reemplazo permanente. Tenga en cuenta si la verificación externa resuelve registros A o AAAA. En el dispositivo afectado, desconéctese y vuelva a conectarse a Wi-Fi, luego vuelva a intentarlo. Si su sistema operativo proporciona un vaciado de caché DNS, utilice su método documentado. Sólo entonces compárelo con un solucionador alternativo de buena reputación. Cloudflare documenta su interfaz JSON de DNS sobre HTTPS para comparar explícitamente los resolutores.

No interprete "DNS funciona" como "la página debe renderizarse". DNS solo asigna el nombre. TLS, el enrutamiento, la política del servidor y la aplicación aún deben tener éxito.

¿Podría el enrutador, VPN o ISP estar bloqueando la ruta?

Cada uno puede crear exactamente esta división:

• Un enrutador puede conservar un mal estado, aplicar controles parentales, preferir una ruta IPv6 rota o bloquear una categoría.
• Una VPN, un proxy, la protección web de un antivirus o un perfil empresarial pueden alterar el DNS y el enrutamiento.
• Un ISP puede tener un incidente de enrutamiento o resolución que afecte a un destino.
• Un sitio puede limitar o bloquear la IP pública de la red Wi-Fi mientras acepta la IP del operador de telefonía móvil.

Compruebe el alcance antes de desactivar protecciones. Si todos los dispositivos fallan solo en una red Wi-Fi, céntrese en esa red. Si falla únicamente un dispositivo administrado, no elimine sus controles de seguridad: consulte al administrador. La secuencia de diagnóstico de Wi-Fi en Windows de Microsoft y la guía de diagnóstico de conexiones Android de Google empiezan con comprobaciones básicas de conexión y aíslan progresivamente el estado del dispositivo y de la red.

¿Qué debería restablecer y en qué orden?

Utilice primero el cambio menos disruptivo:

Evite restablecer el enrutador de fábrica a menos que tenga su configuración y credenciales. Evite dejar un firewall, VPN o un producto de seguridad desactivado simplemente porque la página se cargó una vez. Si la página se abre pero parece incompleta, ejecute el Prueba de representación del sitio web porque los activos estáticos o los scripts pueden estar fallando incluso cuando la respuesta principal HTTP tiene éxito.

¿Cuándo debería dejar de solucionar problemas localmente?

Deténgase y solicite ayuda cuando la evidencia apunte fuera de su control: fallan tanto la comprobación externa como los datos móviles; el trazado se interrumpe sistemáticamente más allá del router; todos los dispositivos de un ISP fallan mientras otra red funciona; o el sitio muestra una respuesta de política de acceso vinculada a su IP pública. Proporcione al proveedor la URL exacta, las marcas de tiempo con zona horaria, el resultado externo, el resultado DNS, la red afectada y las pruebas realizadas. Esa información resulta mucho más útil que «Internet no funciona».