Chrome e Brave Não Carregam Sites no Beta do macOS 27? Como Corrigir

Você instalou o beta público do macOS 27 Golden Gate, abriu o Chrome, digitou uma URL e… nada. A aba fica girando. A barra de status mostra Conectando… e nunca avança. Depois de um tempo você recebe um erro seco — ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED, ou a mensagem animada do Brave Este site não pode ser acessado. Então você tenta outro site. A mesma coisa. Todos os sites. Depois, quase por hábito, você abre o Safari — e ele carrega instantaneamente, na primeira tentativa, sem hesitação. A internet claramente está bem. Seu Wi-Fi está bem. Ainda assim, o Chrome não carregando sites no beta do macOS 27 virou sua tarde inteira, e isso acontece também no Brave, Edge, Arc e Vivaldi.

Se esse é o seu caso, respire fundo: seu Mac não está quebrado e sua rede também não. Esta é uma das arestas mais reportadas do atual beta do macOS 27 — um padrão em que navegadores baseados em Chromium não conseguem acessar nada enquanto o Safari passa direto. Isso aparece nos fóruns da Comunidade Brave, em tópicos do Apple Discussions e nos fóruns de beta do MacRumors, e o fio condutor é sempre o mesmo: o navegador WebKit funciona, os Chromium não. Essa divisão é, na verdade, a maior pista que temos sobre o que está dando errado, e é o motivo pelo qual a maioria das correções abaixo são rápidas, reversíveis e não exigem que você destrua nada.

Este guia faz duas coisas. Primeiro, explica — com honestidade e com as ressalvas que um beta merece — por que os navegadores que não são o Safari são os que quebram. Segundo, oferece uma escada de correções que você pode subir em ordem, desde o ajuste de trinta segundos que resolve para muita gente até o recurso honesto que ninguém gosta de dizer em voz alta: é um beta, e às vezes a atitude certa é se apoiar no Safari ou voltar para o Tahoe estável até a Apple lançar uma nova build. Vamos recuperar seus navegadores.

Principais Conclusões

• O Safari funcionar enquanto Chrome, Brave, Edge, Arc e Vivaldi falham todos é a assinatura desse problema do beta. Isso aponta para como o atual beta do macOS 27 roteia o tráfego de rede para apps que não são WebKit — DNS, extensões de rede e o caminho de rede por aplicativo — em vez de apontar para um navegador específico.
• Isso é relatado por beta testers, não confirmado pela Apple. Tópicos na Comunidade Brave, no Apple Discussions e no MacRumors descrevem o problema; a Apple não publicou um reconhecimento formal. O comportamento pode mudar de uma build de beta para outra, então teste novamente após cada atualização.
• As correções com maior taxa de acerto são simples e reversíveis: desligar o Secure DNS / DNS-over-HTTPS do navegador, desativar qualquer extensão de sistema de filtro de rede ou VPN (Little Snitch, LuLu, filtros corporativos, alguns antivírus), definir o IPv6 como apenas Link-local e limpar o cache de DNS.
• Verifique o Private Relay e a VPN logo no início. O iCloud Private Relay e túneis de VPN meio conectados se comportam de forma diferente para o Safari do que para apps Chromium sob o beta e são um culpado frequente.
• O recurso honesto é o Safari ou uma reversão. Em um beta, algumas questões simplesmente esperam pela Apple. Se um navegador Chromium funcional é inegociável para você, considere voltar para o Tahoe estável em vez de brigar com a build.

Primeiro: Você Está Realmente no Beta do macOS 27?

Antes de mudar uma única configuração, confirme que você está no beta a que este artigo se refere — porque as correções aqui são direcionadas especificamente ao comportamento do beta e podem ser uma perda de tempo (ou levemente contraproducentes) na versão estável.

Verifique sua versão exata

Abra o menu Apple > Sobre Este Mac e leia a linha de versão. Depois clique em Mais Informações > Atualização de Software (ou Ajustes do Sistema > Geral > Atualização de Software) para ver se você está em uma versão de teste (seed) de beta.

• Se aparecer macOS 27.0 beta (ou mostrar o banner de beta para desenvolvedores/público), você está no lugar certo. O beta público chegou em meados de julho de 2026 — Beta Público 1 em 13 de julho, Beta Público 2 em 22 de julho — e a mais nova versão de teste para desenvolvedores no momento em que este artigo foi escrito é a beta 4, build 26A5388g (20 de julho). A Apple não publicou strings de build fixas para as versões públicas, então não se apegue demais a um número específico; "o beta público do macOS 27" é a forma honesta de descrevê-lo.
• Se aparecer macOS 26.5.2 (build 25F84) ou similar, você está no Tahoe estável, não no beta. Nesse caso, um apagão total do Chromium não é o padrão conhecido do beta, e você deve tratá-lo como um problema comum de rede — comece com nosso guia completo de correção do Wi-Fi que cai e o guia de solução de problemas de VPN em vez das etapas específicas do beta abaixo.

Uma observação para donos de Mac Intel

O macOS 27 Golden Gate é exclusivo para Apple silicon — M1 ou posterior. Todo Mac Intel foi descartado neste ciclo. Se você está em uma máquina Intel, não pode estar rodando o beta do macOS 27 de forma alguma, então um problema de navegador ali é outra coisa completamente diferente. Este guia assume um Mac da série M no beta.

Lembre-se do que "beta" significa aqui

Tudo abaixo é estruturado em torno do que beta testers relatam, agregado em fóruns de comunidade e cobertura de imprensa. Nada disso é um defeito reconhecido pela Apple com uma correção oficial. Isso importa por dois motivos: o comportamento pode mudar entre builds (uma correção necessária no Beta Público 2 pode ser desnecessária depois da próxima versão de teste), e o remédio final para alguns testadores tem sido simplesmente esperar a Apple. Mantenha suas expectativas calibradas para um sistema operacional pré-lançamento.

Por Que Apenas Navegadores Não-Safari Quebram no Beta do macOS 27

O fato diagnóstico mais útil que você tem é a divisão Safari/Chromium. Entender por que essas duas categorias se comportam de forma diferente aponta diretamente para as correções — então vamos percorrer o mecanismo, com a ressalva de que isso é inferência informada a partir de relatos da comunidade, não uma certeza de engenharia reversa.

Safari e Chromium seguem caminhos de rede diferentes

O Safari é construído sobre o WebKit e está entrelaçado profundamente ao macOS. Ele se apoia na pilha de rede nativa do sistema (NSURLSession, o resolvedor do sistema, o armazém de confiança do sistema) da forma que os próprios frameworks da Apple esperam, e herda vantagens de nível de sistema — iCloud Private Relay, política de rede por aplicativo, o resolvedor de DNS do SO — como cidadão de primeira classe.

Navegadores Chromium (Chrome, Brave, Edge, Arc, Vivaldi — todos compartilham o motor Chromium) fazem boa parte desse trabalho por conta própria. O Chromium embarca seu próprio serviço de rede, frequentemente seu próprio resolvedor DNS-over-HTTPS, seu próprio pooling de conexões e suas próprias regras sobre como abrir sockets. Essa independência normalmente é um ponto forte. Em um beta em que a Apple pode estar mudando como funciona a rede por aplicativo, o DNS ou a filtragem de extensões de rede, ela se torna um passivo: as suposições do Chromium e o novo comportamento do beta podem se dessincronizar de um jeito que o Safari nunca chega a encontrar, porque o Safari faz tudo do jeito da Apple por padrão.

O ângulo das extensões de rede e do DNS (a versão com ressalvas)

O macOS moderno roteia o tráfego dos apps por meio de um framework de extensão de rede. Filtros de conteúdo, clientes de VPN, proxies de DNS e firewalls todos se registram como extensões de rede do sistema e podem inspecionar, redirecionar ou bloquear o tráfego por aplicativo. Quando beta testers relatam que o Safari funciona e todo navegador Chromium trava, as principais teorias da comunidade vivem nessa área:

1. A resolução de DNS está falhando especificamente para os apps Chromium. Se Chrome e Brave estão usando seu próprio Secure DNS (DNS-over-HTTPS) enquanto o beta faz algo novo com o tratamento de DNS, as buscas de nome podem travar para sempre — que é exatamente a cara de um Conectando… infinito. O Safari, usando o resolvedor do sistema, escapa disso. Erros como ERR_NAME_NOT_RESOLVED se encaixam perfeitamente nessa teoria.
2. Um filtro de extensão de rede está silenciosamente descartando tráfego que não é do Safari. Ferramentas que se instalam como extensões de rede — Little Snitch, LuLu, filtros de conteúdo corporativos e alguns pacotes de antivírus — arbitram a conectividade por aplicativo. Se o beta mudou como as extensões são avaliadas ou aprovadas, um filtro pode acabar liberando o Safari enquanto engole o tráfego do Chromium. Isso é do mesmo tipo de atrito de beta que já documentamos em torno de filtros de conteúdo por extensão de rede na correção de desligamento por extensão de rede do macOS Tahoe 26.5.1 — sintoma diferente, o mesmo subsistema sob pressão.

Ambas são consistentes com os relatos, e honestamente provavelmente não é uma causa universal — testadores diferentes provavelmente têm gatilhos diferentes empilhados sobre a mesma base de "o Chromium está no seu próprio caminho de rede". Isso é uma boa notícia para resolver: você não precisa saber qual é o seu caso. Basta descer a escada e um degrau costuma resolver.

Decifrando a mensagem de erro exata

O erro que o Chrome mostra a você restringe bastante a causa, então leia-o antes de começar a clicar em qualquer coisa. Alguns comuns e o que costumam significar nesse beta:

• ERR_NAME_NOT_RESOLVED — uma falha pura de DNS. O navegador não conseguiu transformar o domínio em um endereço IP de forma alguma. Isso aponta forte para a Correção 1 (desligar o secure DNS) e a Correção 4 (limpar o cache). É a assinatura mais comum do padrão do beta.
• ERR_CONNECTION_TIMED_OUT — o nome foi resolvido, mas a própria conexão nunca se completou. Isso pende mais para um filtro de extensão de rede (Correção 2), corrida de IPv6 (Correção 3) ou uma VPN meio ativa (Correção 5) engolindo o tráfego silenciosamente.
• ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET — algo fechou ativamente a conexão. Em um Mac com filtro de conteúdo ou extensão de firewall, isso é seu filtro em pleno veredito — vá direto para a Correção 2.
• ERR_PROXY_CONNECTION_FAILED — um proxy está configurado (frequentemente por um perfil de configuração esquecido ou um app de VPN) e está morto. Veja a verificação de perfil da Correção 5.
• Uma aba que gira para sempre sem erro algum — geralmente uma busca de DNS que está travando em vez de falhar de forma explícita, o que também remete às Correções 1 e 4.

Nenhum desses é definitivo em um beta, mas eles indicam qual degrau tentar primeiro em vez de você percorrer todos eles.

O que uma "extensão de rede" realmente é, em linguagem simples

Se a expressão extensão de rede não significa nada para você, aqui vai a versão resumida — importa porque metade das correções abaixo giram em torno disso. Anos atrás, apps que precisavam inspecionar ou filtrar seu tráfego (VPNs, firewalls, controles parentais, escudos web de antivírus) faziam isso com extensões de kernel que rodavam com privilégios profundos do sistema. A Apple passou várias versões movendo tudo isso para fora do kernel e para dentro de um framework em espaço de usuário, isolado em sandbox, chamado Network Extensions. Quando você instala o Little Snitch, um filtro corporativo ou uma VPN hoje, ela se registra como uma extensão de rede do sistema que o macOS usa para rotear seu tráfego, para que a ferramenta possa permitir, bloquear ou redirecionar conexões — geralmente por aplicativo.

Essa capacidade por aplicativo é o cerne da questão. Uma extensão de rede pode, em princípio, tratar o Safari e o Chrome de forma diferente, e depende do SO para saber como as conexões estão estruturadas. Quando um beta muda a engrenagem por baixo — como as extensões são aprovadas, como o tráfego por aplicativo é marcado, como a extensão recebe cada conexão — uma extensão que funciona perfeitamente para o Safari pode acabar descartando ou travando o tráfego do Chromium sem que ninguém tenha pretendido isso. É por isso que "desativar a extensão de rede e testar de novo" é uma etapa tão fundamental aqui, e por que reaprovar extensões após cada atualização do beta importa.

Por que isso grita "beta", não "seu navegador está quebrado"

Se o Chrome em si estivesse quebrado, reinstalá-lo resolveria e o Brave/Edge/Arc/Vivaldi não falhariam todos em sincronia. Se sua rede estivesse quebrada, o Safari também falharia. A única coisa que explica claramente "todo navegador Chromium morto, WebKit funcionando, a mesma máquina, o mesmo Wi-Fi" é algo na camada de SO e rede que trata essas duas categorias de app de forma diferente — que é exatamente o tipo de coisa que um sistema operacional pré-lançamento erra. Ler o resumo de problemas conhecidos do beta Golden Gate vale a pena para ter contexto sobre quantas arestas vivem nessa build.

Uma Lista de Triagem de 60 Segundos

Antes da escada completa, execute estas cinco verificações rápidas. Elas custam quase nada e frequentemente apontam direto para a correção vencedora.

1. O Safari carrega um site? Se sim, confirmado: este é o padrão específico do Chromium e a escada abaixo se aplica. Se o Safari também falhar, isso não é o bug de navegador do beta — é conectividade geral; vá para o guia de Wi-Fi que cai.
2. Há alguma VPN ou filtro de conteúdo em execução? Olhe na barra de menu e em Ajustes do Sistema > Geral > Itens de Login e Extensões > Extensões de Rede. Se houver algo lá, é o suspeito número um.
3. O iCloud Private Relay está ativado? Ajustes do Sistema > [seu nome] > iCloud > Private Relay. Anote se está ativado.
4. Endereços IP funcionam quando os nomes de domínio não funcionam? No Chrome, tente carregar http://1.1.1.1. Se um IP puro carregar mas cloudflare.com não, seu problema é DNS, e as Correções 1 e 4 são seus alvos.
5. Um perfil de navegador novinho em folha se comporta da mesma forma? No Chrome, abra uma janela anônima nova (convidado). Se ela também falhar, a causa é do sistema, não do seu perfil — pule direto para as correções de rede.

Seja qual for a conclusão dessas cinco, você ainda pode simplesmente começar pela Correção 1 e seguir em ordem. Reinicie o Chrome completamente entre as correções (Cmd+Q, não apenas fechar a janela) para que cada mudança realmente entre em vigor.

Confirme Exatamente Onde Está a Falha (Opcional, mas Poderoso)

Se você quer certeza sobre qual camada está falhando antes de começar a mudar configurações, cinco comandos seguros de Terminal vão te contar isso. Nenhum deles modifica nada — apenas leem o estado — então você pode rodar todos sem risco. O objetivo é separar três perguntas: A rede está acessível? O DNS está funcionando? O caminho HTTP em nível de sistema funciona mesmo que o do Chrome não funcione?

1. Você consegue alcançar a internet por IP puro? Isso ignora o DNS completamente.

ping -c 4 1.1.1.1

Se você receber respostas, seu Mac tem conectividade funcional e o problema está mais acima (DNS ou por aplicativo). Se isso também falhar, o Safari também estaria falhando e você está diante de conectividade geral, não do padrão de navegador do beta.

2. A resolução de DNS funciona?

ping -c 4 cloudflare.com

Se a etapa 1 funcionou mas essa diz não foi possível resolver ou trava, você confirmou um problema de DNS — exatamente o que as Correções 1 e 4 miram.

3. Pergunte diretamente ao resolvedor. dig e nslookup vêm junto com o macOS e mostram o que o resolvedor do sistema retorna:

dig cloudflare.com +short
nslookup cloudflare.com

Uma resposta aqui significa que o resolvedor do sistema está bem e que o próprio DNS-over-HTTPS do Chromium é o que está travado — um forte sinal de que a Correção 1 (desligar o secure DNS do navegador, para que ele delegue a este resolvedor do sistema que está funcionando) vai ajudar.

4. A pilha HTTP do sistema carrega uma página mesmo que o Chrome não carregue? O curl usa a própria rede do macOS, a mesma classe de caminho que o Safari usa:

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

Se o curl retornar cabeçalhos (HTTP/2 200 e afins) enquanto o Chrome trava, esse é o diagnóstico inteiro em uma linha: o caminho do SO funciona, o caminho do Chromium não. Esse é o padrão do beta, confirmado, e significa que as correções em nível de sistema abaixo são sua melhor aposta.

5. Que DNS o sistema está realmente usando?

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

Isso mostra se uma VPN, um perfil ou um filtro te apontou silenciosamente para servidores de DNS que você não escolheu. Se você ver endereços inesperados, revisite as verificações de perfil e VPN da Correção 5.

Rode esses cinco comandos e você saberá, antes de mexer em qualquer configuração, se está atrás de DNS, de um filtro ou de um problema de caminho por aplicativo. Se o Terminal não é sua praia, pule esta seção inteira — a escada de correções funciona bem sem ela.

A Escada de Correções

Trabalhe de cima para baixo. Teste novamente após cada etapa; pare quando seus sites voltarem. Toda etapa aqui é reversível.

Correção 1: Desligue o Secure DNS / DNS-over-HTTPS no navegador

Esta é a correção com maior taxa de acerto para esse padrão do beta, porque o DNS criptografado embutido do Chromium é exatamente o tipo de rede autogerenciada que pode se dessincronizar de um SO em beta. Você está dizendo ao navegador para parar de resolver nomes por conta própria e delegar ao sistema.

No Chrome, Brave, Edge e Vivaldi:

1. Abra Configurações > Privacidade e segurança > Segurança.
2. Role até Usar DNS seguro e desative completamente. (Não apenas troque de provedor — desligue totalmente, para que o navegador use o resolvedor do SO.)
3. Feche o navegador por completo (Cmd+Q) e reabra-o.

No Arc: abra Arc > Configurações, encontre a seção de privacidade/segurança e desative o secure DNS da mesma forma; o Arc expõe a configuração do Chromium em seus próprios menus.

Se um IP puro carregou na sua verificação de triagem mas os domínios não, essa etapa sozinha muitas vezes já resolve.

Correção 2: Desative ou remova extensões de filtro de rede, VPN e filtro de conteúdo

Se você usa Little Snitch, LuLu, um filtro de conteúdo corporativo, um app de filtragem de DNS ou um pacote de antivírus com proteção web, ele quase certamente se instalou como uma extensão de rede do sistema — e esse é o principal suspeito por liberar o Safari e bloquear o Chromium sob esse beta.

1. Vá em Ajustes do Sistema > Geral > Itens de Login e Extensões, depois clique no (i) ao lado de Extensões de Rede (caminho mais antigo: Extensões de Rede ou Conteúdo e Privacidade, dependendo da build).
2. Desative uma a uma cada extensão de terceiros de filtro de rede / VPN / firewall.
3. Feche completamente e reabra o Chrome após cada mudança e teste novamente.

Se desativar uma trouxer o Chrome de volta, você encontrou seu culpado. A partir daí você pode deixá-la desativada até a Apple lançar uma build corrigida, atualizar a ferramenta para sua versão mais recente (fornecedores corrigem rápido para betas) ou verificar as notas de compatibilidade com beta do fornecedor. Se você está em um Mac gerenciado/de trabalho, talvez não possa desativar um filtro corporativo sozinho — esse é um caso para sua equipe de TI, e é um motivo legítimo para adiar o beta. Nosso artigo sobre filtro de conteúdo por extensão de rede se aprofunda em como essas extensões se comportam quando o SO muda por baixo delas.

Correção 3: Defina o IPv6 como apenas Link-local para o serviço de rede ativo

Vários testadores relatam que a corrida de conexão dual-stack do Chromium (IPv4 + IPv6) trava sob o beta quando o IPv6 se comporta mal, enquanto o Safari tolera isso. Forçar o serviço de rede a desligar totalmente o IPv6 empurra o tráfego para o caminho IPv4, que está funcionando.

Via Ajustes do Sistema (recomendado, mais suave):

1. Ajustes do Sistema > Rede, selecione seu serviço ativo (Wi-Fi ou Ethernet), clique em Detalhes….
2. Vá até a aba TCP/IP.
3. Defina Configurar IPv6 como Somente link local.
4. Clique em OK, depois feche completamente e reabra o Chrome.

Via Terminal (equivalente, se preferir a linha de comando): primeiro liste os nomes dos seus serviços, depois desligue o IPv6 para o que você usa. Note que -setv6off desativa o IPv6 de forma mais completa do que o "Somente link local" da interface gráfica, mas para isolar esse problema qualquer um funciona.

# Veja os nomes exatos dos serviços de rede
networksetup -listallnetworkservices

# Desligue o IPv6 para o Wi-Fi (use o nome exato do seu serviço)
sudo networksetup -setv6off "Wi-Fi"

Para restaurar o IPv6 normal depois:

sudo networksetup -setv6automatic "Wi-Fi"

Correção 4: Limpe o cache de DNS

Se o DNS for o problema (e nesse beta frequentemente é), um cache de resolvedor obsoleto ou corrompido pode manter buscas fixas em falha mesmo depois de você mudar uma configuração. Limpe-o. Este é um par de comandos padrão e seguro do macOS — ele limpa o cache e reinicia o respondedor de DNS multicast:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Você será solicitado a informar sua senha de administrador. Não há saída visível quando dá certo — isso é normal. Feche e reabra o Chrome depois e tente um site. Combine isso com a Correção 1 (secure DNS desligado) para as melhores chances; as duas juntas cobrem o modo de falha de DNS mais comum relatado para esse beta.

Correção 5: Verifique o Private Relay, a VPN e os perfis de configuração

O iCloud Private Relay e as VPNs remodelam como o tráfego sai do seu Mac, e ambos são tratados de forma diferente para o Safari do que para apps Chromium — o que os torna suspeitos clássicos de falha assimétrica.

• iCloud Private Relay: Ajustes do Sistema > [seu nome] > iCloud > Private Relay. Desative-o temporariamente e teste o Chrome novamente. O Private Relay só roteia o Safari e um pouco de tráfego do sistema, mas alternar isso pode reiniciar um estado de rede em que o Chromium estava preso.
• VPN: se uma VPN estiver conectada, desconecte-a completamente (não apenas minimize o app) e teste novamente. Túneis meio conectados ou incompatíveis com o beta são uma causa muito comum de "o navegador trava para sempre". Se a VPN acabar sendo o seu problema, siga nosso guia de solução de problemas de VPN no macOS — a maioria dos clientes de VPN precisa de uma atualização compatível com o beta.
• Perfis de configuração: em Ajustes do Sistema > Geral > Gerenciamento de Dispositivos (ou Privacidade e Segurança > Perfis), remova qualquer perfil antigo de DNS ou proxy que você não reconhece ou não precisa. Perfis esquecidos podem fixar servidores de DNS ruins.

Correção 6: O alternador de FaceTime / "Permitir Chamadas em Outros Dispositivos" que alguns testadores juram funcionar

Este é estranho, não confirmado e vale trinta segundos, porque um grupo de pessoas nos fóruns relata que ele trouxe seus navegadores Chromium de volta à vida. A teoria é que alternar esse recurso do Continuity empurra a pilha de rede a reinicializar os caminhos por aplicativo que o beta deixou em um estado ruim.

1. Abra FaceTime > Configurações (barra de menu: FaceTime > Configurações).
2. Encontre Chamadas do iPhone / Permitir Chamadas em Outros Dispositivos e desative, depois reative.
3. Alternativamente, no iPhone: Ajustes > Telefone > Chamadas em Outros Dispositivos, desative e reative seu Mac.
4. Teste o Chrome novamente.

Trate isso como folclore que acontece de funcionar para algumas pessoas, não uma correção garantida. Não custa nada e reverte instantaneamente, então merece seu degrau.

Correção 7: Redefina as configurações de rede do navegador ou comece um perfil novo

Se as correções em nível de sistema não resolveram, isole se o perfil específico do seu navegador está mantendo um estado de rede corrompido.

• Chrome/Brave/Edge: abra Configurações > Redefinir configurações > Restaurar configurações para os padrões originais. Isso limpa DNS personalizado, proxy e ajustes de inicialização sem tocar em seus favoritos ou senhas.
• Teste com perfil novo: crie um perfil novo (ícone de perfil > Adicionar) ou abra uma janela de Convidado e tente um site. Se o perfil novo funcionar, o problema era local ao perfil — redefina o antigo ou migre para o novo.
• Limpe o cache de sockets/hosts: no Chrome, visite chrome://net-internals/#sockets e clique em Flush socket pools, depois chrome://net-internals/#dns e Clear host cache. (Brave e Edge expõem as mesmas páginas em seu próprio esquema, por exemplo brave://net-internals.)

Correção 8: Reinstale o navegador do zero

Se um navegador específico for o único que ainda resiste depois das correções de rede, reinstale-o do zero. Como Chrome, Brave, Edge, Arc e Vivaldi compartilham o mesmo motor, faça isso apenas se um único navegador estiver atrasado em relação aos outros — uma causa de sistema não será curada com uma reinstalação.

1. Feche o navegador (Cmd+Q).
2. Arraste-o de Aplicativos para a Lixeira.
3. Baixe a build mais nova diretamente do fornecedor — correções de compatibilidade com beta chegam constantemente em atualizações de navegador, então uma build atual já pode lidar melhor com o beta.
4. Reinstale e teste novamente. Seus dados sincronizados (favoritos, senhas) voltam quando você fizer login novamente.

Correção 9 (o recurso de realidade do beta): use o Safari, ou volte para o Tahoe

Aqui vai a parte honesta. Isto é um beta, o apagão de navegador é relatado por beta testers e não reconhecido pela Apple, e alguns testadores descobriram que nada na escada acima se sustenta completamente até a Apple lançar uma nova build. Se você trabalhou toda a escada e o Chromium ainda está morto, você tem duas opções sensatas:

• Apoie-se no Safari por enquanto. Ele funciona, é rápido e importa seus favoritos. Rodar sua navegação diária no Safari por algumas semanas enquanto o beta amadurece é uma solução temporária perfeitamente razoável, e você pode continuar testando o Chrome após cada nova versão (o comportamento genuinamente muda de build para build).
• Volte para o Tahoe estável. Se um navegador Chromium funcional é inegociável — para trabalho, para extensões, para um fluxo de trabalho que você não pode mudar — a correção mais limpa é sair do beta. Siga nosso guia passo a passo para reverter o beta do macOS 27 de volta ao Tahoe sem perder dados. E se você está apenas considerando o beta, todo esse problema é um forte argumento para instalá-lo com segurança em um volume separado na próxima vez, para que seu sistema de trabalho nunca seja o que quebra.

Não há vergonha em nenhuma dessas opções. Um beta é uma prévia que você se voluntariou para testar, não um compromisso de sofrer com um navegador quebrado.

Solução de Problemas Comuns

Problema: o Chrome carrega alguns sites mas trava em outros sob o beta

Solução: Carregamento parcial quase sempre significa DNS, não um bloqueio total. Alguns nomes são resolvidos a partir do cache enquanto buscas novas travam. Faça a Correção 1 (desligar o secure DNS) e a Correção 4 (limpar o cache de DNS) juntas, depois feche o Chrome completamente e tente de novo. Se persistir, defina o DNS do sistema para um resolvedor simples — Ajustes do Sistema > Rede > Detalhes > DNS e adicione 1.1.1.1 e 8.8.8.8 — para que o SO não dependa de um resolvedor que o beta está tratando mal.

Problema: tudo funcionava e voltou a quebrar depois de uma atualização do beta

Solução: Espere por isso. Cada nova versão pode redefinir as aprovações de extensões de rede e alternar comportamentos. Depois de qualquer atualização do beta do macOS 27, reaprove suas extensões de rede em Ajustes do Sistema > Geral > Itens de Login e Extensões > Extensões de Rede, depois execute novamente a Correção 1 e a Correção 4. Como esse é um comportamento não reconhecido de beta, trate cada build como um diagnóstico novo em vez de presumir que sua correção anterior ainda funciona.

Problema: um Mac de trabalho ou escola bloqueia as correções de que preciso

Solução: Macs gerenciados impõem filtros de conteúdo corporativos e perfis de configuração que você não pode desativar sozinho, e esses filtros são um suspeito principal para a divisão Safari-funciona/Chromium-falha. Não brigue com o MDM. Contate sua equipe de TI, informe que o navegador falha apenas para apps Chromium no beta do macOS 27, e pergunte se o fornecedor do filtro deles tem uma build compatível com beta. Se não, esse é um sinal claro de que um Mac de produção/gerenciado ainda não deveria estar no beta.

Problema: desativar minha extensão de rede corrigiu o Chrome, mas eu preciso daquela ferramenta rodando

Solução: Você confirmou o culpado — agora restaure a proteção da forma certa. Atualize a ferramenta (Little Snitch, LuLu, seu antivírus) para a versão mais recente, já que os fornecedores lançam correções de compatibilidade com beta rapidamente. Verifique as notas de lançamento ou o fórum do fornecedor em busca de uma observação sobre o macOS 27. Se ainda não houver uma build compatível, você está escolhendo entre a ferramenta e o Chromium neste beta — um motivo genuíno para considerar voltar ao Tahoe até o fornecedor se atualizar.

Perguntas Frequentes

Por que o Safari funciona mas o Chrome e o Brave não no beta do macOS 27?

O Safari usa a rede e o DNS nativos do macOS, então herda o que o beta mudou. Os navegadores Chromium gerenciam seu próprio DNS, sockets e lógica de conexão, o que pode se dessincronizar do novo tratamento de rede por aplicativo do beta. Mesma máquina, mesmo Wi-Fi, caminho de rede diferente — é por isso que um funciona e os outros travam.

Isso é um bug oficial da Apple com uma correção a caminho?

Não oficialmente. O problema é relatado por beta testers na Comunidade Brave, no Apple Discussions e no MacRumors, e agregado pela imprensa, mas a Apple não publicou um reconhecimento formal. Como vive em uma build pré-lançamento, o comportamento pode mudar a cada nova versão, então teste novamente após cada atualização do beta do macOS 27.

Desligar o secure DNS vai deixar minha navegação menos privada?

Ligeiramente, e apenas temporariamente. Desativar o DNS-over-HTTPS do navegador significa que as buscas de nome usam seu resolvedor de sistema em vez de um criptografado. Para uma solução alternativa em um beta, essa é uma troca razoável, e você pode reativar o secure DNS assim que a Apple lançar uma build que funcione bem com o Chromium. Seu tráfego de página HTTPS permanece criptografado de qualquer forma.

Estou no macOS 26.5.2, não no beta. Essas correções se aplicam?

Provavelmente não. Um apagão total do Chromium é o padrão do beta. No Tahoe 26.5.2 estável (build 25F84), um navegador que falha ao carregar sites é mais provavelmente conectividade comum, uma VPN ou um filtro. Comece com os guias de Wi-Fi e VPN linkados acima em vez das etapas específicas do beta aqui.

Reinstalar o Chrome poderia corrigir isso sozinho?

Raramente, para esse problema. Se Brave, Edge, Arc e Vivaldi falharem junto com o Chrome, a causa é de nível de sistema e reinstalar um navegador não vai ajudar. Reinstale apenas quando um único navegador Chromium estiver atrasado em relação aos outros — e sempre pegue a build mais nova, já que atualizações de navegador frequentemente adicionam compatibilidade com beta.

Devo simplesmente voltar para o Tahoe por causa disso?

Se um navegador Chromium funcional é essencial para o seu dia e a escada de correções não resolveu, sim — é uma decisão razoável. Siga o guia de downgrade linkado acima para reverter sem perder dados. Se você consegue viver no Safari por algumas semanas, ficar no beta e testar cada nova versão é o caminho de menor esforço.

Conclusão

Quando o Chrome não carrega sites no beta do macOS 27 mas o Safari funciona perfeitamente, você não está diante de um Mac quebrado ou de um navegador quebrado — você está diante de um sistema operacional pré-lançamento tratando o caminho de rede independente do Chromium de forma diferente de como trata o WebKit. Esse único insight é o motivo pelo qual as correções são, na maioria, ajustes rápidos: desligue o secure DNS do navegador, desative uma extensão de filtro de rede, defina o IPv6 como Somente link local, limpe o cache de DNS e verifique o Private Relay e a VPN. Um desses degraus resolve para a maioria dos testadores, e todos eles revertem em segundos.

Mas mantenha o enquadramento honesto em primeiro plano: isso é um comportamento relatado por beta testers, não um bug confirmado pela Apple, e em um beta a correção definitiva às vezes é paciência. O comportamento muda de build para build, então teste novamente após cada nova versão — e se um navegador Chromium funcional é algo que você não pode dispensar, não há vergonha em se apoiar no Safari ou voltar para o Tahoe estável até a Apple resolver isso. Você se voluntariou para testar uma prévia; tratar um navegador quebrado como uma situação de "esperar pela próxima build" é exatamente o instinto certo.

Um último hábito prático: observe o ritmo do beta. A Apple tem lançado versões aproximadamente a cada uma ou duas semanas — o Beta Público 1 chegou em 13 de julho, o Beta Público 2 em 22 de julho, com a beta 4 para desenvolvedores (build 26A5388g) em 20 de julho — e o comportamento de rede genuinamente mudou entre as versões. Então a rotina inteligente é manter sua correção funcional em vigor, anotar qual degrau resolveu, e depois de cada nova build, desativar brevemente essa solução alternativa e testar o Chrome de novo. Se uma versão resolver silenciosamente o problema subjacente, você vai querer voltar o secure DNS e o IPv6 para suas configurações normais em vez de deixá-los alterados para sempre. Betas mudam; suas soluções alternativas não deveriam ser permanentes.

Trabalhe a escada de cima para baixo, pare no primeiro degrau que trouxer seus sites de volta, e se você está pesando se vale a pena continuar no Golden Gate, o guia de problemas conhecidos e o passo a passo de instalação segura vão te ajudar a decidir com clareza.