¿Chrome y Brave no cargan sitios web en la beta de macOS 27? Solución

Instaló la beta pública de macOS 27 «Golden Gate», abrió Chrome, escribió una URL y… nada. La pestaña gira. La barra de estado dice Conectando… y no avanza. Al rato aparece un error seco — ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED, o el alegre No se puede acceder a este sitio de Brave. Entonces prueba con otro sitio. Lo mismo. Todos los sitios. Luego, casi por costumbre, abre Safari — y carga al instante, a la primera, sin titubear. Internet claramente funciona bien. El Wi-Fi funciona bien. Sin embargo, que Chrome no cargue sitios web en la beta de macOS 27 se ha convertido en toda su tarde, y ocurre también en Brave, Edge, Arc y Vivaldi.

Si es su caso, respire hondo: su Mac no está roto y su red tampoco. Este es uno de los inconvenientes más reportados de la beta actual de macOS 27 — un patrón en el que los navegadores basados en Chromium no logran conectarse a nada mientras Safari navega sin problemas. Aparece en los foros de Brave Community, en hilos de Apple Discussions y en los tableros de beta de MacRumors, y el hilo conductor es siempre el mismo: el navegador basado en WebKit funciona, los basados en Chromium no. Esa división es en realidad la pista más importante que tenemos sobre qué está fallando, y es la razón por la que la mayoría de las soluciones a continuación son rápidas, reversibles y no requieren destruir nada.

Esta guía hace dos cosas. Primero, explica — con honestidad y con las reservas que merece una beta — por qué son los navegadores distintos de Safari los que fallan. Segundo, ofrece una escalera de soluciones que puede recorrer en orden, desde el interruptor de treinta segundos que resuelve el problema para mucha gente hasta el respaldo honesto que a nadie le gusta decir en voz alta: es una beta, y a veces lo correcto es apoyarse en Safari o volver a la versión estable de Tahoe hasta que Apple publique una nueva compilación. Recuperemos sus navegadores.

Puntos Clave

• Que Safari funcione mientras Chrome, Brave, Edge, Arc y Vivaldi fallan todos es la firma característica de este problema de la beta. Señala cómo la beta actual de macOS 27 enruta el tráfico de red para las apps que no usan WebKit — DNS, extensiones de red y la ruta de red por app — más que a un navegador en particular.
• Esto está reportado por testers de la beta, no confirmado por Apple como un error oficial. Hilos en Brave Community, Apple Discussions y MacRumors lo describen; Apple no ha publicado un reconocimiento formal. El comportamiento puede cambiar de una compilación beta a otra, así que vuelva a probar después de cada actualización.
• Las soluciones con mayor tasa de éxito son simples y reversibles: desactivar el Secure DNS / DNS-over-HTTPS del navegador, desactivar cualquier extensión de sistema de filtro de red o VPN (Little Snitch, LuLu, filtros corporativos, algunos antivirus), configurar IPv6 en Solo enlace local y vaciar la caché de DNS.
• Revise Private Relay y la VPN desde el principio. iCloud Private Relay y los túneles VPN a medio conectar se comportan de forma distinta para Safari que para las apps basadas en Chromium bajo la beta, y son un culpable frecuente.
• El respaldo honesto es Safari o revertir la actualización. En una beta, algunos problemas simplemente esperan a que Apple los resuelva. Si un navegador Chromium funcional es innegociable para usted, considere volver a la versión estable de Tahoe en lugar de seguir peleando con la compilación.

Primero: ¿Realmente Está en la Beta de macOS 27?

Antes de cambiar una sola configuración, confirme que está en la beta de la que trata este artículo — porque las soluciones aquí apuntan directamente al comportamiento de la beta y pueden ser una pérdida de tiempo (o ligeramente contraproducentes) en la versión estable.

Verifique su versión exacta

Abra el menú Apple > Acerca de este Mac y lea la línea de versión. Luego haga clic en Más información > Actualización de software (o Ajustes del Sistema > General > Actualización de software) para ver si está en una compilación beta.

• Si dice macOS 27.0 beta (o muestra el banner de beta para desarrolladores/pública), está en el lugar correcto. La beta pública llegó a mediados de julio de 2026 — Public Beta 1 el 13 de julio, Public Beta 2 el 22 de julio — y la compilación para desarrolladores más reciente al momento de escribir esto es beta 4, build 26A5388g (20 de julio). Apple no ha publicado cadenas de compilación fijas para las versiones públicas, así que no se obsesione con un número específico; «la beta pública de macOS 27» es la forma honesta de describirla.
• Si dice macOS 26.5.2 (build 25F84) o algo similar, está en Tahoe estable, no en la beta. En ese caso, un apagón total de Chromium no es el patrón conocido de la beta, y debería tratarlo como un problema de red común — empiece con nuestra guía completa para solucionar la caída del Wi-Fi y la guía de solución de problemas de VPN en lugar de los pasos específicos de la beta que siguen.

Una nota para los dueños de Mac con Intel

macOS 27 «Golden Gate» es exclusivo de Apple silicon — M1 o posterior. Todos los Mac con Intel quedaron fuera de este ciclo. Si tiene una máquina Intel, no puede estar ejecutando la beta de macOS 27 en absoluto, así que un problema de navegador ahí es algo completamente distinto. Esta guía asume un Mac de la serie M en la beta.

Recuerde qué significa «beta» aquí

Todo lo que sigue se basa en lo que reportan los testers de la beta, recopilado de foros comunitarios y cobertura de prensa. Nada de esto es un defecto reconocido por Apple con una solución oficial. Eso importa por dos razones: el comportamiento puede cambiar entre compilaciones (una solución necesaria en Public Beta 2 podría ser innecesaria tras la siguiente versión), y el remedio definitivo para algunos testers simplemente ha sido esperar a Apple. Mantenga sus expectativas calibradas para un sistema operativo previo al lanzamiento.

Por Qué Solo Fallan los Navegadores Distintos de Safari en la Beta de macOS 27

El dato de diagnóstico más útil que tiene es la división Safari/Chromium. Entender por qué estos dos se comportan de forma distinta lo lleva directo a las soluciones — así que repasemos el mecanismo, con la salvedad de que se trata de una inferencia informada a partir de reportes de la comunidad, no de una certeza obtenida por ingeniería inversa.

Safari y Chromium toman rutas de red distintas

Safari está construido sobre WebKit y está profundamente integrado en macOS. Se apoya en la pila de red nativa del sistema (NSURLSession, el resolutor del sistema, el almacén de confianza del sistema) de la manera en que lo esperan los propios frameworks de Apple, y hereda ventajas a nivel de sistema — iCloud Private Relay, la política de red por app, el resolutor de DNS del SO — como un ciudadano de primera clase.

Los navegadores basados en Chromium (Chrome, Brave, Edge, Arc y Vivaldi comparten el motor Chromium) hacen gran parte de ese trabajo por su cuenta. Chromium incluye su propio servicio de red, con frecuencia su propio resolutor DNS-over-HTTPS, su propia gestión de grupos de conexiones y sus propias ideas sobre cómo abrir sockets. Esa independencia normalmente es una fortaleza. En una beta donde Apple puede estar cambiando cómo se comporta la red por app, el DNS o el filtrado por extensiones de red, se convierte en un pasivo: las suposiciones de Chromium y el nuevo comportamiento de la beta pueden desincronizarse de una forma que Safari ni siquiera llega a encontrar, porque Safari lo hace a la manera de Apple por defecto.

El ángulo de las extensiones de red y el DNS (la versión con reservas)

El macOS moderno enruta el tráfico de las apps a través de un framework de extensión de red. Los filtros de contenido, los clientes VPN, los proxies DNS y los firewalls se registran como extensiones de red del sistema y pueden inspeccionar, redirigir o bloquear el tráfico por app. Cuando los testers de la beta reportan que Safari funciona y todo navegador basado en Chromium se cuelga, las principales teorías de la comunidad viven en esta área:

1. La resolución de DNS está fallando específicamente para las apps basadas en Chromium. Si Chrome y Brave están usando su propio Secure DNS (DNS-over-HTTPS) mientras la beta hace algo nuevo con el manejo de DNS, las búsquedas de nombres pueden quedarse colgadas para siempre — que es exactamente lo que parece un Conectando… interminable. Safari, al usar el resolutor del sistema, evita el problema. Errores como ERR_NAME_NOT_RESOLVED encajan perfectamente con esta teoría.
2. Un filtro de extensión de red está descartando silenciosamente el tráfico que no es de Safari. Las herramientas que se instalan como extensiones de red — Little Snitch, LuLu, filtros de contenido corporativos y algunas suites antivirus — arbitran la conectividad por app. Si la beta cambió cómo se evalúan o aprueban las extensiones, un filtro puede terminar dejando pasar a Safari mientras bloquea sin aviso a las apps basadas en Chromium. Esta es la misma familia de fricción de la beta que hemos documentado en torno a los filtros de contenido por extensión de red en la solución al apagado por extensión de red de macOS Tahoe 26.5.1 — distinto síntoma, el mismo subsistema bajo presión.

Ambas son consistentes con los reportes, y honestamente probablemente no exista una causa universal única — distintos testers probablemente tienen distintos desencadenantes apilados sobre la misma base de que «Chromium sigue su propia ruta de red». Esa es una buena noticia para resolverlo: no necesita saber cuál es su caso. Solo tiene que recorrer la escalera, y normalmente un peldaño resuelve el problema.

Descifrando el mensaje de error exacto

El error que le muestra Chrome acota bastante la causa, así que léalo antes de empezar a hacer clic en todo. Algunos de los más comunes y lo que suelen significar en esta beta:

• ERR_NAME_NOT_RESOLVED — una falla pura de DNS. El navegador no pudo convertir el dominio en una dirección IP en absoluto. Esto apunta con fuerza a la Solución 1 (desactivar el DNS seguro) y a la Solución 4 (vaciar la caché). Es la firma más común del patrón de la beta.
• ERR_CONNECTION_TIMED_OUT — el nombre se resolvió, pero la conexión en sí nunca se completó. Esto apunta hacia un filtro de extensión de red (Solución 2), una competencia de IPv6 (Solución 3) o una VPN a medio funcionar (Solución 5) que se traga el tráfico en silencio.
• ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET — algo cerró activamente la conexión. En un Mac con un filtro de contenido o una extensión de firewall, eso es su filtro dictando sentencia — vaya directo a la Solución 2.
• ERR_PROXY_CONNECTION_FAILED — hay un proxy configurado (a menudo por un perfil de configuración residual o una app de VPN) y está caído. Consulte la verificación de perfiles de la Solución 5.
• Una pestaña que gira sin parar y sin error — normalmente es una búsqueda de DNS que se queda colgada en lugar de fallar de plano, lo que de nuevo remite a las Soluciones 1 y 4.

Ninguno de estos es definitivo en una beta, pero le indican qué peldaño probar primero en lugar de tener que recorrerlos todos.

Qué es en realidad una «extensión de red», en palabras simples

Si la frase extensión de red no le dice nada, aquí va la versión corta — importa porque la mitad de las soluciones a continuación giran en torno a ella. Hace años, las apps que necesitaban inspeccionar o filtrar su tráfico (VPN, firewalls, controles parentales, escudos web de antivirus) lo hacían con extensiones de kernel que corrían con privilegios profundos del sistema. Apple ha dedicado varias versiones a sacar todo eso del kernel y llevarlo a un framework en sandbox, en espacio de usuario, llamado Network Extensions. Cuando hoy instala Little Snitch, un filtro corporativo o una VPN, esta se registra como una extensión de red del sistema a través de la cual macOS enruta su tráfico, para que la herramienta pueda permitir, bloquear o redirigir conexiones — a menudo por app.

Esa capacidad por app es el quid del asunto. En principio, una extensión de red puede tratar a Safari y a Chrome de forma distinta, y depende del SO para que le indique cómo están estructuradas las conexiones. Cuando una beta cambia la tubería subyacente — cómo se aprueban las extensiones, cómo se etiqueta el tráfico por app, cómo se le entrega cada conexión a la extensión — una extensión que se comporta perfectamente con Safari puede terminar descartando o estancando el tráfico de Chromium sin que nadie lo pretenda. Por eso «desactivar la extensión de red y volver a probar» es un paso tan central aquí, y por eso importa volver a aprobar las extensiones después de cada actualización de la beta.

Por qué esto grita «beta» y no «su navegador está roto»

Si el propio Chrome estuviera roto, reinstalarlo lo arreglaría, y Brave/Edge/Arc/Vivaldi no fallarían todos al unísono. Si su red estuviera rota, Safari también fallaría. Lo único que explica con claridad «todo navegador Chromium muerto, WebKit bien, la misma máquina, el mismo Wi-Fi» es algo en la capa del SO y la red que trata a esas dos clases de apps de forma distinta — que es precisamente el tipo de cosa que un SO previo al lanzamiento hace mal. Vale la pena leer el resumen de problemas conocidos de la beta de Golden Gate para tener contexto sobre cuántos inconvenientes tiene esta compilación.

Una Lista de Verificación Rápida de 60 Segundos

Antes de la escalera completa, haga estas cinco verificaciones rápidas. Casi no cuestan nada y con frecuencia lo llevan directo a la solución ganadora.

1. ¿Safari carga un sitio? Si es así, se confirma: este es el patrón específico de Chromium y aplica la escalera de abajo. Si Safari también falla, esto no es el error de navegador de la beta — es conectividad general; vaya a la guía de caída del Wi-Fi.
2. ¿Hay una VPN o un filtro de contenido en ejecución? Revise la barra de menús y Ajustes del Sistema > General > Elementos de inicio de sesión y extensiones > Extensiones de red. Si hay algo ahí, es el sospechoso número uno.
3. ¿Está activado iCloud Private Relay? Ajustes del Sistema > [su nombre] > iCloud > Private Relay. Anote si está habilitado.
4. ¿Funcionan las direcciones IP cuando los nombres de dominio no? En Chrome, intente cargar http://1.1.1.1. Si una IP directa carga pero cloudflare.com no, su problema es el DNS, y las Soluciones 1 y 4 son sus objetivos.
5. ¿Un perfil de navegador completamente nuevo se comporta igual? En Chrome, abra una ventana de invitado nueva. Si también falla, la causa es del sistema, no de su perfil — pase directamente a las soluciones de red.

Sea lo que sea que le digan esas cinco verificaciones, siempre puede simplemente empezar por la Solución 1 e ir en orden. Reinicie Chrome por completo entre soluciones (Cmd+Q, no solo cerrar la ventana) para que cada cambio surta efecto realmente.

Confirme Exactamente Dónde Está Fallando (Opcional pero Poderoso)

Si quiere tener certeza sobre qué capa está fallando antes de empezar a cambiar configuraciones, cinco comandos seguros de Terminal se lo dirán. Ninguno de ellos modifica nada — solo leen el estado — así que puede ejecutarlos todos sin riesgo. El objetivo es separar tres preguntas: ¿Se puede alcanzar la red en absoluto? ¿Funciona el DNS? ¿Funciona la ruta HTTP a nivel de sistema aunque la de Chrome no?

1. ¿Puede alcanzar internet mediante una IP directa? Esto evita el DNS por completo.

ping -c 4 1.1.1.1

Si obtiene respuestas, su Mac tiene conectividad funcional y el problema está más arriba (DNS o por app). Si esto también falla, Safari también estaría fallando y está ante un problema de conectividad general, no el patrón de navegador de la beta.

2. ¿Funciona la resolución de DNS?

ping -c 4 cloudflare.com

Si el paso 1 funcionó pero este dice cannot resolve o se queda colgado, ha confirmado un problema de DNS — exactamente lo que apuntan las Soluciones 1 y 4.

3. Consulte al resolutor directamente. dig y nslookup vienen incluidos en macOS y muestran lo que devuelve el resolutor del sistema:

dig cloudflare.com +short
nslookup cloudflare.com

Si obtiene una respuesta aquí, significa que el resolutor del sistema está bien y que lo que está atascado es el propio DNS-over-HTTPS de Chromium — una señal clara de que la Solución 1 (desactivar el DNS seguro del navegador para que dependa de este resolutor del sistema que sí funciona) ayudará.

4. ¿La pila HTTP del sistema carga una página aunque Chrome no lo haga? curl usa la red propia de macOS, el mismo tipo de ruta que usa Safari:

curl -I https://www.cloudflare.com

Si curl devuelve encabezados (HTTP/2 200 y similares) mientras Chrome se queda colgado, ese es todo el diagnóstico en una sola línea: la ruta del SO funciona, la ruta de Chromium no. Ese es el patrón de la beta, confirmado, y significa que las soluciones a nivel de sistema de más abajo son su mejor apuesta.

5. ¿Qué DNS está usando realmente el sistema?

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

Esto muestra si una VPN, un perfil o un filtro lo ha apuntado silenciosamente hacia servidores DNS que usted no eligió. Si ve direcciones inesperadas, revise las verificaciones de perfiles y VPN de la Solución 5.

Ejecute estos cinco comandos y sabrá, antes de tocar una sola configuración, si está persiguiendo un problema de DNS, de un filtro o de la ruta por app. Si Terminal no es lo suyo, sáltese esta sección por completo — la escalera de soluciones funciona bien sin ella.

La Escalera de Soluciones

Trabaje de arriba hacia abajo. Vuelva a probar después de cada paso; deténgase cuando sus sitios vuelvan a funcionar. Cada paso aquí es reversible.

Solución 1: Desactive el Secure DNS / DNS-over-HTTPS en el navegador

Esta es, con diferencia, la solución con mayor rendimiento para este patrón de la beta, porque el DNS cifrado integrado de Chromium es exactamente el tipo de red autogestionada que puede desincronizarse de un SO beta. Le está diciendo al navegador que deje de resolver nombres por su cuenta y que dependa del sistema.

En Chrome, Brave, Edge y Vivaldi:

1. Abra Configuración > Privacidad y seguridad > Seguridad.
2. Desplácese hasta Usar DNS seguro y desactívelo por completo. (No se limite a cambiar de proveedor — desactívelo del todo para que el navegador use el resolutor del SO.)
3. Cierre el navegador por completo (Cmd+Q) y vuelva a abrirlo.

En Arc: abra Arc > Configuración, busque la sección de privacidad/seguridad y desactive el DNS seguro de la misma forma; Arc expone la configuración de Chromium bajo sus propios menús.

Si en su verificación rápida una IP directa cargó pero los dominios no, este paso por sí solo suele resolver el problema muy a menudo.

Solución 2: Desactive o elimine extensiones de filtro de red, VPN y filtro de contenido

Si usa Little Snitch, LuLu, un filtro de contenido corporativo, una app de filtrado de DNS o una suite antivirus con protección web, casi con certeza se instaló como una extensión de red del sistema — y ese es el principal sospechoso de dejar pasar a Safari mientras bloquea a Chromium bajo esta beta.

1. Vaya a Ajustes del Sistema > General > Elementos de inicio de sesión y extensiones, luego haga clic en la (i) junto a Extensiones de red (ruta anterior: Extensiones de red o Contenido y privacidad, según la compilación).
2. Desactive cada extensión de filtro de red / VPN / firewall de terceros, una a la vez.
3. Cierre y vuelva a abrir Chrome por completo después de cada cambio y vuelva a probar.

Si desactivar una de ellas devuelve Chrome a la normalidad, ha encontrado al culpable. A partir de ahí puede dejarla desactivada hasta que Apple publique una compilación corregida, actualizar la herramienta a su versión más reciente (los proveedores publican parches rápido para las betas), o revisar las notas de compatibilidad con la beta del proveedor. Si está en un Mac gestionado/de trabajo, es posible que no pueda desactivar un filtro corporativo usted mismo — eso es un caso para su equipo de TI, y es una razón legítima para posponer la beta. Nuestro artículo sobre filtros de contenido por extensión de red profundiza en cómo se comportan estas extensiones cuando el SO cambia debajo de ellas.

Solución 3: Configure IPv6 en Solo enlace local para el servicio de red activo

Varios testers reportan que la competencia de conexión de doble pila (IPv4 + IPv6) de Chromium se cuelga bajo la beta cuando IPv6 se comporta mal, mientras que Safari lo tolera. Forzar que el servicio de red deje de usar IPv6 por completo empuja el tráfico hacia la ruta IPv4, que sí funciona.

A través de Ajustes del Sistema (recomendado, más suave):

1. Ajustes del Sistema > Red, seleccione su servicio activo (Wi-Fi o Ethernet), haga clic en Detalles….
2. Vaya a la pestaña TCP/IP.
3. Configure Configurar IPv6 en Solo enlace local.
4. Haga clic en Aceptar, luego cierre y vuelva a abrir Chrome por completo.

A través de Terminal (equivalente, si prefiere la línea de comandos): primero liste los nombres de sus servicios, luego desactive IPv6 para el que use. Tenga en cuenta que -setv6off desactiva IPv6 de forma más completa que la opción «Solo enlace local» de la interfaz gráfica, pero para aislar este problema cualquiera de las dos funciona.

# See the exact network service names
networksetup -listallnetworkservices

# Turn IPv6 off for Wi-Fi (use your exact service name)
sudo networksetup -setv6off "Wi-Fi"

Para restaurar el IPv6 normal más adelante:

sudo networksetup -setv6automatic "Wi-Fi"

Solución 4: Vacíe la caché de DNS

Si el DNS es el problema (y en esta beta a menudo lo es), una caché del resolutor obsoleta o corrupta puede mantener fallando las búsquedas incluso después de cambiar una configuración. Vacíela. Este es un par de comandos estándar y seguro de macOS — vacía la caché y reinicia el respondedor de DNS multicast:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Se le pedirá su contraseña de administrador. No hay salida visible cuando tiene éxito — eso es normal. Cierre y vuelva a abrir Chrome después y pruebe con un sitio. Combine esto con la Solución 1 (DNS seguro desactivado) para las mejores probabilidades; juntas ambas abordan el modo de falla de DNS más común reportado para esta beta.

Solución 5: Revise Private Relay, la VPN y los perfiles de configuración

Tanto iCloud Private Relay como las VPN modifican cómo sale el tráfico de su Mac, y ambos se manejan de forma distinta para Safari que para las apps basadas en Chromium bajo la beta — lo que los convierte en sospechosos clásicos de fallas asimétricas.

• iCloud Private Relay: Ajustes del Sistema > [su nombre] > iCloud > Private Relay. Desactívelo temporalmente y vuelva a probar Chrome. Private Relay solo enruta el tráfico de Safari y algo de tráfico del sistema, pero alternarlo puede restablecer un estado de red en el que Chromium se estaba quedando atascado.
• VPN: si hay una VPN conectada, desconéctela por completo (no se limite a minimizar la app) y vuelva a probar. Los túneles a medio conectar o incompatibles con la beta son una causa muy común de que «el navegador se cuelgue para siempre». Si la VPN resulta ser su problema, siga nuestra guía de solución de problemas de VPN en macOS — la mayoría de los clientes VPN necesitan una actualización compatible con la beta.
• Perfiles de configuración: en Ajustes del Sistema > General > Gestión de dispositivos (o Privacidad y seguridad > Perfiles), elimine cualquier perfil antiguo de DNS o proxy que no reconozca o no necesite. Los perfiles residuales pueden fijar servidores DNS defectuosos.

Solución 6: El interruptor de FaceTime / «Permitir llamadas en otros dispositivos» que juran algunos testers

Esta es rara, no confirmada, y vale la pena treinta segundos porque un grupo de usuarios en foros reporta que les devolvió la vida a sus navegadores Chromium. La teoría es que alternar esta función de Continuity empuja a la pila de red a reinicializar las rutas por app que la beta dejó en mal estado.

1. Abra FaceTime > Configuración (barra de menús: FaceTime > Configuración).
2. Busque Llamadas desde iPhone / Permitir llamadas en otros dispositivos y desactívelo y vuelva a activarlo.
3. Alternativamente, en el iPhone: Configuración > Teléfono > Llamadas en otros dispositivos, desactive y active su Mac.
4. Vuelva a probar Chrome.

Trate esto como folclore que resulta funcionar para algunas personas, no como una solución garantizada. No cuesta nada y se revierte al instante, así que se gana su peldaño en la escalera.

Solución 7: Restablezca la configuración de red del navegador o empiece un perfil nuevo

Si las soluciones a nivel de sistema no han funcionado, aísle si su perfil específico de navegador está reteniendo un estado de red corrupto.

• Chrome/Brave/Edge: abra Configuración > Restablecer configuración > Restaurar la configuración a sus valores predeterminados originales. Esto borra ajustes personalizados de DNS, proxy e inicio sin tocar sus marcadores ni contraseñas.
• Prueba con perfil nuevo: cree un perfil nuevo (icono de perfil > Agregar) o abra una ventana de invitado y pruebe con un sitio. Si el perfil nuevo funciona, el problema era local del perfil — restablezca el anterior o migre al nuevo.
• Vacíe la caché de sockets/hosts: en Chrome, visite chrome://net-internals/#sockets y haga clic en Flush socket pools, luego chrome://net-internals/#dns y Clear host cache. (Brave y Edge exponen las mismas páginas bajo su propio esquema, por ejemplo brave://net-internals.)

Solución 8: Reinstale el navegador desde cero

Si un navegador específico es el único que sigue resistiendo después de las soluciones de red, reinstálelo desde cero. Como Chrome, Brave, Edge, Arc y Vivaldi comparten el mismo motor, haga esto solo si un único navegador se queda rezagado respecto a los demás — una causa de sistema no se cura reinstalando.

1. Cierre el navegador (Cmd+Q).
2. Arrástrelo desde Aplicaciones a la Papelera.
3. Descargue la compilación más reciente directamente del proveedor — las correcciones de compatibilidad con la beta llegan constantemente en las actualizaciones de los navegadores, así que una compilación actual quizás ya maneje mejor la beta.
4. Reinstale y vuelva a probar. Sus datos sincronizados (marcadores, contraseñas) vuelven cuando inicia sesión de nuevo.

Solución 9 (el respaldo realista de la beta): use Safari, o vuelva a Tahoe

Aquí viene la parte honesta. Esto es una beta, el apagón del navegador está reportado por testers de la beta y no reconocido por Apple, y algunos testers han descubierto que nada de la escalera anterior se mantiene del todo hasta que Apple publica una nueva compilación. Si ha recorrido toda la escalera y Chromium sigue muerto, tiene dos opciones sensatas:

• Apóyese en Safari por ahora. Funciona, es rápido e importa sus marcadores. Usar Safari para su navegación diaria durante algunas semanas mientras la beta madura es una solución temporal perfectamente razonable, y puede seguir volviendo a probar Chrome después de cada nueva versión (el comportamiento realmente cambia de una compilación a otra).
• Vuelva a la versión estable de Tahoe. Si un navegador Chromium funcional es innegociable — por trabajo, por extensiones, por un flujo de trabajo que no puede mover — la solución más limpia es dejar la beta. Siga nuestra guía paso a paso para bajar de la beta de macOS 27 a Tahoe sin perder datos. Y si solo está considerando la beta, todo este problema es un fuerte argumento para instalarla de forma segura en un volumen separado la próxima vez, para que su sistema de trabajo nunca sea lo que se rompa.

No hay nada de qué avergonzarse en ninguna de estas opciones. Una beta es un adelanto que usted se ofreció a probar, no un compromiso a sufrir con un navegador roto.

Solución de Problemas Comunes

Problema: Chrome carga algunos sitios pero se cuelga en otros bajo la beta

Solución: la carga parcial casi siempre significa DNS, no un bloqueo total. Algunos nombres se resuelven desde la caché mientras las búsquedas nuevas se cuelgan. Haga la Solución 1 (desactivar el DNS seguro) y la Solución 4 (vaciar la caché de DNS) juntas, luego cierre Chrome por completo y vuelva a intentarlo. Si persiste, configure el DNS del sistema en un resolutor sencillo — Ajustes del Sistema > Red > Detalles > DNS y agregue 1.1.1.1 y 8.8.8.8 — para que el SO no dependa de un resolutor que la beta está manejando mal.

Problema: Todo funcionaba, y volvió a romperse después de una actualización de la beta

Solución: espere que esto pase. Cada nueva versión puede restablecer las aprobaciones de extensiones de red y alternar comportamientos. Después de cualquier actualización de la beta de macOS 27, vuelva a aprobar sus extensiones de red en Ajustes del Sistema > General > Elementos de inicio de sesión y extensiones > Extensiones de red, y luego repita la Solución 1 y la Solución 4. Como se trata de un comportamiento de beta no reconocido oficialmente, trate cada compilación como un diagnóstico nuevo en lugar de asumir que su solución anterior sigue vigente.

Problema: Un Mac de trabajo o de la escuela bloquea las soluciones que necesito

Solución: los Mac gestionados imponen filtros de contenido corporativos y perfiles de configuración que usted no puede desactivar por sí mismo, y esos filtros son el principal sospechoso de la división Safari-funciona/Chromium-falla. No pelee contra el MDM. Contacte a su equipo de TI, dígales que el navegador falla solo para las apps basadas en Chromium en la beta de macOS 27, y pregunte si el proveedor de su filtro tiene una compilación compatible con la beta. Si no la tiene, esta es una señal clara de que un Mac de producción/gestionado todavía no debería estar en la beta.

Problema: Desactivar mi extensión de red arregló Chrome, pero necesito esa herramienta en funcionamiento

Solución: ha confirmado al culpable — ahora restaure la protección de la manera correcta. Actualice la herramienta (Little Snitch, LuLu, su antivirus) a su versión más reciente, ya que los proveedores publican parches de compatibilidad con la beta con rapidez. Revise las notas de la versión o el foro del proveedor en busca de una nota sobre macOS 27. Si todavía no hay una compilación compatible, está eligiendo entre la herramienta y Chromium en esta beta — una razón genuina para considerar volver a Tahoe hasta que el proveedor se ponga al día.

Preguntas Frecuentes

¿Por qué funciona Safari pero Chrome y Brave no en la beta de macOS 27?

Safari usa la red y el DNS nativos de macOS, así que hereda lo que sea que la beta haya cambiado. Los navegadores basados en Chromium gestionan su propio DNS, sockets y lógica de conexión, lo que puede desincronizarse con el nuevo manejo de red por app de la beta. La misma máquina, el mismo Wi-Fi, distinta ruta de red — por eso uno funciona y los otros se cuelgan.

¿Es este un error oficial de Apple con una solución en camino?

No oficialmente. El problema es reportado por testers de la beta en Brave Community, Apple Discussions y MacRumors, y recopilado por la prensa, pero Apple no ha publicado un reconocimiento formal. Como vive en una compilación previa al lanzamiento, el comportamiento puede cambiar con cada nueva versión, así que vuelva a probar después de cada actualización de la beta de macOS 27.

¿Desactivar el DNS seguro hará que mi navegación sea menos privada?

Un poco, y solo temporalmente. Desactivar el DNS-over-HTTPS del navegador significa que las búsquedas de nombres usan su resolutor del sistema en lugar de uno cifrado. Para una solución alternativa en una beta, es un intercambio aceptable, y puede volver a activar el DNS seguro una vez que Apple publique una compilación que funcione bien con Chromium. El tráfico de sus páginas HTTPS permanece cifrado de cualquier forma.

Estoy en macOS 26.5.2, no en la beta. ¿Aplican estas soluciones?

Probablemente no. Un apagón total de Chromium es el patrón de la beta. En Tahoe estable 26.5.2 (build 25F84), un navegador que no carga sitios es más probablemente un problema de conectividad común, una VPN o un filtro. Empiece con las guías de Wi-Fi y VPN enlazadas arriba en lugar de los pasos específicos de la beta que aparecen aquí.

¿Podría reinstalar Chrome arreglarlo por sí solo?

Rara vez, para este problema. Si Brave, Edge, Arc y Vivaldi fallan todos junto con Chrome, la causa es a nivel de sistema y reinstalar un navegador no ayudará. Reinstale solo cuando un único navegador basado en Chromium se quede rezagado respecto a los demás — y siempre consiga la compilación más reciente, ya que las actualizaciones de los navegadores suelen añadir compatibilidad con la beta.

¿Debería simplemente volver a Tahoe por esto?

Si un navegador Chromium funcional es esencial para su día a día y la escalera de soluciones no funcionó, sí — es una decisión razonable. Siga la guía de bajada de versión enlazada arriba para revertir sin perder datos. Si puede vivir con Safari durante algunas semanas, quedarse en la beta y volver a probar cada nueva versión es el camino de menor esfuerzo.

Conclusión

Cuando Chrome no carga sitios web en la beta de macOS 27 pero Safari funciona perfectamente, no está ante un Mac roto ni un navegador roto — está ante un SO previo al lanzamiento que maneja la ruta de red independiente de Chromium de forma distinta a como maneja WebKit. Esa única idea es la razón por la que las soluciones son en su mayoría interruptores rápidos: desactivar el DNS seguro del navegador, desactivar una extensión de filtro de red, configurar IPv6 en Solo enlace local, vaciar la caché de DNS y revisar Private Relay y la VPN. Uno de esos peldaños resuelve el problema para la mayoría de los testers, y cada uno de ellos se revierte en segundos.

Pero mantenga el marco honesto en primer plano: esto es comportamiento reportado por testers de la beta, no un error confirmado por Apple, y en una beta la solución definitiva a veces es la paciencia. El comportamiento cambia de una compilación a otra, así que vuelva a probar después de cada nueva versión — y si un navegador Chromium funcional es algo de lo que no puede prescindir, no hay nada de qué avergonzarse en apoyarse en Safari o volver a la versión estable de Tahoe hasta que Apple lo resuelva. Usted se ofreció a probar un adelanto; tratar un navegador roto como una situación de «esperar a la siguiente compilación» es exactamente el instinto correcto.

Un último hábito práctico: vigile el ritmo de la beta. Apple ha estado publicando versiones aproximadamente cada semana o dos — Public Beta 1 llegó el 13 de julio, Public Beta 2 el 22 de julio, con la beta 4 para desarrolladores (build 26A5388g) el 20 de julio — y el comportamiento de red realmente ha cambiado entre versiones. Así que la rutina inteligente es mantener su solución funcional en su lugar, anotar qué peldaño resolvió el problema, y después de cada nueva compilación, desactivar brevemente esa solución alternativa y volver a probar Chrome. Si una versión resuelve silenciosamente el problema subyacente, querrá devolver el DNS seguro y el IPv6 a su configuración normal en lugar de dejarlos cambiados para siempre. Las betas avanzan; sus soluciones alternativas no deberían ser permanentes.

Recorra la escalera desde arriba, deténgase en el primer peldaño que devuelva sus sitios, y si está considerando si quedarse en Golden Gate, la guía de problemas conocidos y el recorrido de instalación segura le ayudarán a decidir con claridad.