Quando você pede ao UpOrNot para verificar um site, ele faz mais ou menos o que o seu navegador faz ao abrir uma página — mas para assim que sabe se o servidor respondeu, e explica a resposta em linguagem simples. Veja o que acontece por trás do botão.
Etapa 1 — Resolução DNS: encontrar o servidor
Computadores se comunicam com endereços numéricos (como 93.184.215.14), não com nomes. O DNS (Domain Name System) é a lista telefônica da internet: ele transforma example.com no endereço do servidor que hospeda o site.
- Se o nome não tem nenhum registro, o site não existe (ou o domínio expirou).
- Se os servidores DNS não respondem, ainda não dá para saber — é um problema temporário ou de configuração.
- Se o nome aponta para um endereço privado ou interno, nos recusamos a continuar. Mais detalhes abaixo.
Etapa 2 — Tentativas de conexão
Em seguida, o verificador abre uma conexão com o servidor, normalmente uma conexão segura HTTPS na porta 443. Várias coisas podem dar errado: o servidor pode recusar a conexão, não responder em alguns segundos ou apresentar um certificado de segurança inválido. Se o HTTPS falhar e você não tiver digitado o protocolo, também tentamos HTTP na porta 80.
Etapa 3 — Ler o código de status HTTP
Depois de conectado, o verificador pede a página e lê o código de status HTTP de três dígitos no início da resposta. É o resumo mais rápido do que aconteceu:
- 200OKA página foi entregue normalmente. O site está no ar.
- 301 / 302RedirecionamentoA página está em outro endereço. Seguimos até 5 redirecionamentos e mostramos o destino final.
- 401 / 403RestritoO servidor respondeu, mas recusa o acesso — geralmente um login ou proteção contra robôs. O site está acessível.
- 404Não encontradoO servidor está no ar, mas esta página específica não existe.
- 429Solicitações demaisO servidor está limitando visitantes automatizados. Está no ar, só é cauteloso.
- 500Erro no servidorO servidor travou ou encontrou um bug ao montar a página.
- 502 / 503 / 504Gateway ou sobrecargaUm proxy ou o próprio servidor está sobrecarregado, em manutenção ou não alcança o backend.
Etapa 4 — Transformar códigos em um veredito claro
| O que observamos | O que dizemos a você |
|---|---|
| 2xx ou um redirecionamento válido | Este site está no ar. |
| 404 ou 410 | O site está no ar, mas esta página não foi encontrada. |
| 5xx | O site está acessível, mas o servidor retornou um erro. |
| 401, 403, 429, CAPTCHA ou desafio antirrobô | O site está acessível, mas não permite verificações automáticas. |
| As duas sondas não conseguem conectar | Este site parece estar indisponível. |
| Tempo esgotado ou sinais mistos | Não conseguimos verificar este site agora. |
Por que verificações transparentes e limitadas importam
Um verificador de status faz solicitações aos servidores de outras pessoas em seu nome. Fazer isso com responsabilidade exige algumas regras firmes:
- Nos identificar. Nossas solicitações usam um user agent semelhante ao de um navegador que também cita o UpOrNot e aponta para esta página.
- Ser leves. Uma solicitação por sonda, tempo limite curto, leitura limitada e nenhum rastreamento. Por isso as verificações não deixam os sites lentos nem afetam o SEO.
- Nunca contornar proteções. Se um site mostra um CAPTCHA ou bloqueia robôs, informamos que ele está protegido. Não tentamos burlar o Cloudflare, logins ou outros controles de acesso.
- Proteger redes privadas. Só contatamos endereços públicos nas portas 80 e 443, verificamos cada redirecionamento e recusamos localhost, faixas privadas e endpoints de metadados de nuvem. Isso impede que a ferramenta seja usada para varrer redes internas (um ataque chamado SSRF).
- Limitar o uso. Cada visitante pode fazer um número limitado de verificações por minuto, o que mantém o serviço justo e evita abusos.
- Publicar só o que é seguro. A lista pública “Verificados recentemente” mostra apenas nomes de domínio — nunca caminhos, parâmetros ou credenciais.
Descubra em segundos se um site está fora do ar para todos.