Vídeo curto, problema chato. Site em JavaScript, vibe coding, hospedado em Cloudflare Workers. Você está no Safari do iPhone ou do Mac, sai do site, faz outra coisa, volta — e cai numa página de erro, cara de 403. Atualizar uma vez ainda mostra o erro. Só um F5 de verdade, o reload completo, traz o site de volta. Eu já perguntei para a IA. Ela acerta a vizinhança e mistura com um monte de dica que você aplica e não muda nada. O que resolveu no meu domínio foi um interruptor só: Estabelecimento da conexão 0-RTT, em Velocidade > Configurações > Otimização de protocolo. Desliguei. O erro parou. Desligar o QUIC, que era o que a IA insistia, sozinho não adiantou.
No painel da Cloudflare, no domínio, abra Speed (Velocidade) > Settings (Configurações) > Protocol Optimization (Otimização de protocolo) e desative 0-RTT Connection Resumption. Se ainda falhar no Safari ao voltar para a aba, aí sim experimente o QUIC/HTTP3 — na gravação isso não bastou sem desligar o 0-RTT.
- Sintoma
- Safari, volta à aba, cara de 403; F5 raso não resolve
- Causa no painel
- 0-RTT Connection Resumption ligado
- O que não bastou
- Desligar só o QUIC, como a IA sugeriu
O que você vê no Safari quando volta para o site
O recorte é site feito com IA, em JavaScript, na Cloudflare. Eu não afirmei que o mesmo 403 aparece em todo navegador. Afirmei o que eu reproduzi: Safari no iPhone ou no computador. Você está na página, vai para outro app ou outra aba, volta, e o site não retoma. A tela é de erro, no estilo 403. Um refresh leve ainda erra. Um reload completo, F5 de verdade, carrega. Parece falha aleatória. Não é o Worker “caindo”. É a retomada da conexão.
Quem procura no chat recebe um pacote: Service Worker, visibilidade da aba, WebSocket, cache. Pode até ser o problema de outra pessoa. No meu caso essas frentes não eram a causa. Eu gastei tentativa nisso até achar o interruptor certo no domínio.
0-RTT: conexão mais rápida, retomada que o Safari rejeita
0-RTT, zero round-trip time, é um modo de retomar TLS 1.3 (e QUIC) sem a ida e volta completa do handshake. A Cloudflare documenta isso em Protocol Optimization. O ganho é tempo na segunda visita. O custo, no texto oficial, é risco de replay — por isso a Cloudflare não liga 0-RTT por padrão. Em 2026 ainda há relato de primeira navegação falhando no Safari iOS quando a retomada HTTP/3 0-RTT está disponível. Isso casa com o que eu vi: não é o HTML do Worker que quebrou, é o estabelecimento da conexão quando o Safari tenta voltar rápido demais.
No painel em português a linha que eu mostrei se chama Estabelecimento da conexão 0-RTT. Em inglês, 0-RTT Connection Resumption. Se estiver verde, desligue. Só isso, no meu domínio, acabou com o 403 de volta à aba.
O caminho no painel, na ordem da tela
Entre na Cloudflare, no domínio do site — não na conta genérica, no hostname que falha. Velocidade (Speed), depois Configurações (Settings). O bloco é Otimização de protocolo (Protocol Optimization). Lá está o 0-RTT. Desative, espere a propagação curta de ajuste de zona e teste de novo no Safari: abra o site, saia, volte, sem F5 heroico. Se carregar, era isso.
A IA, no meu caso, mandou desligar o QUIC. QUIC é o transporte do HTTP/3, outro interruptor no mesmo bairro de protocolo. Eu desliguei só ele. Não adiantou. Só resolveu quando o 0-RTT saiu. Se você desligar os dois de uma vez, não vai saber qual dos dois era o culpado. Faça o 0-RTT primeiro, que foi o que a gravação provou.
- Abra o painel da Cloudflare e escolha o domínio que falha no Safari.
- Vá em Speed > Settings (Velocidade > Configurações).
- Abra Protocol Optimization (Otimização de protocolo).
- Desative 0-RTT Connection Resumption (Estabelecimento da conexão 0-RTT).
- No Safari do iPhone ou do Mac, abra o site, saia, volte. Não use F5 no primeiro teste.
- Só se ainda falhar, desative QUIC/HTTP3 e teste de novo — na gravação isso sozinho não resolveu.
Se ainda falhar depois do 0-RTT
Aí a lista da IA volta a fazer sentido, com limite: regra de WAF que pega o IP do celular, Access na URL pública, cookie de sessão estourado, Service Worker velho. Nada disso estava no vídeo como causa. O vídeo acaba quando o 0-RTT sai e o problema some. Grupo de WhatsApp na descrição, se a dúvida for Workers; comentário, se o seu Safari ainda 403 depois desse interruptor — aí sim vale o navegador, o sistema e se o 0-RTT realmente salvou desligado.
Não trate este 403 como “JavaScript no segundo plano”. A página de erro aparece antes de o seu app retomar estado. É borda e handshake, não visibilitychange.
Na sequência
- Reproduzir no Safari: sair, voltar, sem F5, e anotar se a tela é 403.
- Confirmar que o hostname passa pela Cloudflare (laranja no DNS).
- Desligar só o 0-RTT e repetir o teste.
- Não desligar QUIC no mesmo minuto, para não misturar causa.
- Se passar, deixar o 0-RTT off nesse domínio; velocidade da primeira conexão não vale esse 403.
Onde isso quebra
Seguir o pacote da IA (QUIC, cache, Service Worker) antes de olhar o 0-RTT.
Testar só no Chrome de desktop, onde o sintoma pode não aparecer.
Achar que um F5 que “conserta” é solução: o visitante no iPhone não vai fazer isso.
Ligar 0-RTT de novo no dia seguinte porque a documentação fala em ganho de velocidade — o ganho volta com o 403.
Perguntas frequentes
Isso acontece no Chrome também?
No vídeo eu só reproduzi no Safari, iPhone ou Mac. Não afirmei o mesmo 403 em outro navegador. Se o seu caso for Chrome, ainda assim o 0-RTT é o primeiro interruptor barato de testar.
Desligar 0-RTT deixa o site mais lento?
A retomada da conexão perde o atalho de zero ida e volta. A primeira visita já não usava 0-RTT. No meu critério, um 403 na volta da aba custa mais do que alguns milissegundos na segunda visita.
Por que a IA manda desligar o QUIC?
Porque 0-RTT e HTTP/3 andam juntos na documentação. No meu domínio, QUIC sozinho não era a causa. O interruptor que zerou o erro foi o 0-RTT.
Preciso mudar código do Worker?
Não neste conserto. É ajuste de zona, em Speed > Protocol Optimization. Código de visibilidade de aba não era o que a gravação mostrou.