Verificador de Status do Site
Um verificador de status de site envia uma requisição HTTP a uma URL e informa o código de status que o servidor devolve. Códigos 200–399 contam como online; 400–599 ou um tempo de conexão esgotado contam como offline. Verificar https://example.com aqui devolve 200 OK em algumas dezenas de milissegundos, ou seja, o site responde para nós, não só para você.
Códigos de status HTTP e o que este verificador informa
| Código | Frase de motivo | Veredito aqui | O que isso significa para a sua verificação |
|---|---|---|---|
| 200 | OK | Online | O servidor respondeu normalmente. Não há nada a corrigir. |
| 301 | Moved Permanently | Online | Redirecionamento permanente. Esta ferramenta não o segue, então você vê o 301 e o cabeçalho Location. |
| 302 | Found | Online | Redirecionamento temporário, muitas vezes para uma página de manutenção, de login ou de roteamento geográfico. |
| 304 | Not Modified | Online | A cópia em cache ainda é válida. Só é devolvido quando a requisição leva validadores. |
| 403 | Forbidden | Offline | O servidor respondeu, portanto o host está acessível e isto não é uma queda. Um WAF, um filtro anti-bot ou uma lista de IPs permitidos recusou este cliente; o veredito continua Offline porque 403 é um código 4xx. |
| 404 | Not Found | Offline | O host respondeu, então está acessível — só falta o caminho que você pediu. Teste em seguida o domínio puro. |
| 429 | Too Many Requests | Offline | Limite de requisições: pedidos demais em pouco tempo. Se a resposta trouxer um cabeçalho Retry-After, espere até o momento que ele indica — um número de segundos ou uma data HTTP — antes de testar de novo. |
| 500 | Internal Server Error | Offline | A aplicação quebrou na origem. Consulte o log de erros da origem. |
| 502 | Bad Gateway | Offline | Um proxy ou CDN não conseguiu alcançar a origem, muitas vezes durante um deploy. |
| 503 | Service Unavailable | Offline | Sobrecarga ou manutenção planejada. Temporário por definição; verifique o Retry-After. |
| 504 | Gateway Timeout | Offline | A origem demorou mais para responder do que o proxy estava disposto a esperar. |
| 0 | Sem resposta | Offline | Nada respondeu: falha de DNS, conexão recusada, certificado TLS inválido ou tempo esgotado — 8 segundos para estabelecer a conexão e 15 segundos no total. |
Os vereditos seguem as classes de status da RFC 9110: 200–399 é informado como online e 400–599 como offline. O veredito descreve a URL que você digitou, não a máquina por trás dela — com 403 ou 404 o servidor respondeu, portanto o host está acessível e nenhum dos dois é uma queda. Um 304 conta como online porque o recurso existe; um 404 conta como offline porque a URL pedida não existe.
O site está fora do ar ou o problema é só meu?
A verificação acima roda no nosso servidor, não no seu navegador, e é exatamente isso que torna a comparação útil. Se esta página informa 200 OK enquanto o seu navegador mostra erro de conexão, a falha é local: um resolvedor DNS com um registro morto em cache, uma VPN ou proxy corporativo, uma entrada no seu arquivo hosts ou um problema de roteamento do seu provedor. Se os dois falharem, a origem ou a CDN dela está realmente fora do ar e não há nada a corrigir na sua máquina.
Por que os sites saem do ar?
Quase todas as quedas cabem em seis famílias, e o código de status diz qual delas você tem pela frente:
- Certificado TLS expirado ou emitido para outro nome — a conexão falha antes de o HTTP começar, por isso você vê o status 0.
- Registros DNS alterados ou expirados: o nome de host não resolve mais, novamente status 0.
- O processo da aplicação quebrou ou ficou sem memória — 500 vindo da origem, 502 vindo do proxy à frente dela.
- Tráfego acima da capacidade, ou uma janela de manutenção planejada — 503, normalmente com Retry-After.
- Um banco de dados lento ou uma partida a frio que estoura o tempo limite do proxy — 504.
- Um incidente do provedor em uma CDN, uma região de nuvem ou um registrador, capaz de derrubar ao mesmo tempo milhares de sites sem relação entre si.
O que fazer se o meu site estiver fora do ar?
Trabalhe de fora para dentro, nesta ordem:
- Rode a verificação aqui para confirmar que a falha não é apenas da sua rede.
- Leia o código. 0 aponta para DNS ou TLS; 5xx, para a origem; 403, para uma regra de firewall; 404, para vhost ou caminho errado.
- Abra a lista de cabeçalhos de resposta — Server, Location e Retry-After identificam a camada que respondeu a você.
- Confira as páginas de status da sua hospedagem e da sua CDN antes de abrir um chamado de suporte.
- Repita a verificação depois de cada mudança e exporte o CSV, para que o chamado leve horários em vez de capturas de tela.
Em quanto tempo um site deve responder?
O tempo de resposta exibido é a ida e volta que o nosso servidor levou para uma única requisição HEAD: resolução DNS, conexão TCP, handshake TLS e a primeira resposta do servidor. Não inclui imagens, CSS, JavaScript nem renderização, por isso é muito menor que um tempo de carregamento do Lighthouse. Estas são as faixas de cor usadas nesta página:
| Tempo de resposta | Cor | Leitura |
|---|---|---|
| < 500 ms | Verde | Saudável. Típico de uma borda de CDN ou de um cache quente. |
| 500–1500 ms | Amarelo | Aceitável, mas vale acompanhar: normalmente é uma ida à origem sem cache na borda. |
| > 1500 ms | Vermelho | Lento. Verifique CPU da origem, consultas ao banco de dados, partidas a frio e roteamento entre continentes. |
Sobre Verificador de Status do Site
Um verificador de status de site responde bem a uma pergunta bem estreita: o servidor respondeu e o que ele disse? Esta ferramenta abre uma única requisição HTTP HEAD para o endereço que você digita, concede 8 segundos para estabelecer a conexão e 15 segundos para a requisição inteira, e informa quatro coisas — o código de status numérico, o tempo de ida e volta em milissegundos, o Content-Type e o cabeçalho Server — além da lista completa de cabeçalhos de resposta devolvidos pela origem.
Duas decisões de projeto tornam a leitura inequívoca. Primeiro, os redirecionamentos não são seguidos. Se example.com responde 301, você vê 301 e o cabeçalho Location, em vez do status de outra página três saltos adiante; é isso que você quer ao conferir uma regra de HTTP para HTTPS ou de non-www. Segundo, o veredito segue as classes de status definidas na RFC 9110: de 200 a 399 é informado como online, de 400 a 599 como offline, e um status 0 significa que a requisição nunca se completou — o DNS não resolveu, a conexão foi recusada, o certificado TLS não passou na validação ou a origem estourou o tempo limite.
A verificação roda no nosso servidor e não no seu navegador, e é por isso que ela resolve a dúvida entre uma queda real e um problema só seu. Se a sua máquina não carrega um site enquanto esta página informa 200 OK, a falha é local: seu resolvedor, seu provedor, uma VPN, um proxy corporativo ou uma entrada velha no arquivo hosts. Se os dois falham, o problema está na origem ou na CDN dela.
O modo em massa aceita até 10 endereços, um por linha, e os verifica em sequência com uma pausa de 300 ms entre as requisições, para que uma única execução não esgote a cota de 60 verificações por minuto. Os resultados voltam como uma lista compacta que você pode baixar em CSV ou copiar como tabela separada por tabulações direto para uma planilha ou para um chamado. Cada verificação também gera um link compartilhável que se executa sozinho quando alguém o abre, então o aviso de queda chega com a evidência anexada em vez de uma captura de tela.
Uma ressalva que vale lembrar: as requisições saem de um IP de data center com o user agent FreeWebTools Status Checker/1.0. Sites com filtragem agressiva de bots podem nos responder 403 enquanto atendem os navegadores normalmente, portanto leia um 403 como «recusou este cliente», e não automaticamente como «fora do ar».
Casos de uso
Como verificar se um site está fora do ar
Deixe a aba URL único selecionada e digite o endereço que você quer testar, por exemplo example.com; se faltar o prefixo https://, ele é adicionado automaticamente.
Clique em Verificar status. Uma requisição HTTP sai do nosso servidor e o aviso mostra O site está ONLINE para os códigos 200–399, ou O site está OFFLINE para 400–599 e tempos esgotados.
Veja os quatro blocos: Código de status, Tempo de resposta, Tipo de conteúdo e Servidor. Tempos abaixo de 500 ms aparecem em verde e acima de 1500 ms em vermelho.
Abra a lista Cabeçalhos de resposta para ver tudo o que a origem enviou, inclusive Location em um 301 e Retry-After em um 429 ou 503.
Vá até a aba Verificação em massa para colar até 10 URLs, uma por linha, e guarde o resultado com Baixar CSV ou Copiar como tabela.
Use Copiar link compartilhável para enviar um endereço que refaz exatamente a mesma verificação quando alguém o abre.
Dicas Pro
- Teste separadamente o domínio puro e a versão www. example.com e www.example.com costumam apontar para hosts diferentes, e talvez só um deles esteja falhando.
- O status 0 não é um 500. Ele quer dizer que nada respondeu, então confira a resolução DNS e a validade do certificado TLS antes de culpar a aplicação.
- Tempos de resposta abaixo de 500 ms aparecem em verde, de 500 a 1500 ms em amarelo e acima de 1500 ms em vermelho. O número é só a ida e volta até o servidor: sem imagens, CSS ou JavaScript.
- Se você recebe 403 aqui mas o site abre no seu navegador, um WAF está filtrando IPs de data center ou o nosso user agent FreeWebTools Status Checker/1.0. Isso não é uma queda.
- O modo em massa é limitado a 10 URLs e a API permite 60 verificações por minuto por IP. Divida listas maiores em lotes em vez de insistir até tomar um 429.
Solução de problemas
A verificação devolve o código de status 0 e nenhum cabeçalho.
Nada respondeu. O nome de host pode não resolver, a conexão pode ter sido recusada, o certificado TLS pode estar expirado ou emitido para outro nome, ou a requisição pode ter estourado o tempo — 8 segundos para estabelecer a conexão e 15 segundos no total. Confira primeiro DNS e certificado e depois teste a versão http:// para isolar uma falha de TLS.
Informamos 403 Forbidden, mas o site abre normalmente no navegador.
Uma regra de WAF ou de proteção anti-bot está bloqueando IPs de data center ou o user agent FreeWebTools Status Checker/1.0. O site está online: ele apenas recusa clientes automatizados. Coloque a verificação na lista de permissões ou confirme a partir de uma conexão residencial.
A verificação em massa para no meio com uma mensagem de limite de requisições.
A API permite 60 verificações por minuto por endereço IP. Espere sessenta segundos e reenvie as URLs restantes, ou divida a lista em lotes menores. A execução já espaça as requisições em 300 ms.
Uma página que funciona no navegador devolve 404 aqui.
Provavelmente você está testando um caminho que não existe nesse host, ou o domínio cai em um virtual host padrão. Teste primeiro o domínio puro e acrescente o caminho quando a raiz responder 200.
Perguntas frequentes
Digite o endereço no campo acima e clique em “Verificar status”. A ferramenta envia uma única requisição HTTP a partir do nosso servidor e informa o código de status, o tempo de resposta e todos os cabeçalhos da resposta. Um código entre 200 e 399 significa que o site está no ar; de 400 a 599, ou um status 0, significa que está fora do ar. O tempo de resposta exibido é a ida e volta que o nosso servidor precisou, não o seu navegador — resolução de DNS, conexão TCP, handshake TLS e a primeira resposta —, muitas vezes algumas dezenas de milissegundos para uma origem próxima.
Este verificador roda no nosso servidor, não no seu navegador, então comparar os dois resultados localiza a falha. Se nós obtivermos 200 OK e você ainda não conseguir carregar a página, o problema está do seu lado: cache de DNS, VPN, proxy, cache do navegador ou arquivo hosts. Se nós também obtivermos um 502 ou um tempo esgotado, a falha está do lado do site e não do seu — embora um bloqueio geográfico ou uma regra de firewall contra o nosso IP pareça igual daqui.
503 Service Unavailable significa que o servidor está acessível mas se recusa a atender a requisição neste momento, normalmente por sobrecarga ou manutenção programada. É temporário por definição e muitas vezes vem com um cabeçalho Retry-After que indica quando tentar de novo. Os buscadores leem um 503 curto como “volte mais tarde”, e não como uma falha permanente.
Na prática: certificados TLS vencidos ou que não conferem e registros DNS quebrados (ambos aparecem como status 0), uma aplicação que quebrou ou ficou sem memória (500), um proxy que não alcança a origem no meio de um deploy (502), tráfego acima da capacidade ou manutenção (503), um banco de dados mais lento que o tempo limite do proxy (504) e incidentes de CDN ou de nuvem que atingem um provedor inteiro.
Confirme aqui primeiro que a falha não é local à sua rede. Depois leia o código: 5xx pede que você olhe os logs da origem e o gerenciador de processos, 0 pede checar o DNS e o vencimento do certificado, 403 aponta para uma regra de firewall ou WAF, e um 404 no domínio puro, para um host virtual errado. Consulte a página de status do seu provedor antes de abrir um chamado.
Sim. Vá para a aba “Verificação em massa” e cole até 10 URLs, uma por linha. Elas são verificadas uma a uma com 300 ms de intervalo entre as requisições, e os resultados aparecem como uma lista com veredito, código de status e tempo de resposta. Depois você pode baixar a rodada inteira em CSV ou copiá-la como tabela separada por tabulações.
Não, e isso é proposital. Os redirecionamentos não são seguidos para que um 301 ou 302 apareça exatamente como o servidor enviou, junto com o cabeçalho Location — é isso que você precisa ao conferir uma regra de HTTP para HTTPS ou de non-www. Para percorrer uma cadeia inteira de redirecionamentos salto a salto, use o nosso Verificador de redirecionamentos.
Porque a requisição parte de um IP de data center com o user agent FreeWebTools Status Checker/1.0. Serviços anti-bot, WAFs e regras de firewall de CDN costumam responder a clientes automatizados com 403 Forbidden ou uma página de desafio, enquanto atendem normalmente os navegadores reais. Por isso um 403 desta ferramenta significa «este cliente foi recusado», nem sempre «fora do ar».
É o tempo, em milissegundos, que o nosso servidor levou para concluir uma única requisição HEAD, incluindo resolução DNS, conexão TCP e handshake TLS. Não inclui imagens, CSS, JavaScript nem renderização, por isso é muito menor que uma pontuação de carregamento do Lighthouse. Compare medições entre si e conte com 100–300 ms a mais para uma origem distante.
Não. O endpoint recusa os nomes localhost, 127.0.0.1, 0.0.0.0 e ::1, qualquer IP de faixa privada ou reservada como 192.168.x.x ou 10.x.x.x, endereços de metadados de nuvem como 169.254.169.254 e portas sensíveis como 22, 3306 e 6379. O nome de host é resolvido uma vez e recusado se esse endereço IPv4 for privado; a verificação é apenas IPv4, portanto trate-a como uma proteção contra server-side request forgery e não como garantia. Para hosts internos, use curl de dentro da rede.
Fontes e padrões
As cinco classes de status e o significado de cada código vêm da especificação HTTP e do registro da IANA listados abaixo. As páginas da MDN e do Google Search Central são documentação, não especificações, e o 429 Too Many Requests é definido na RFC 6585, não na RFC 9110. O veredito online/offline é a nossa própria leitura desses limites de classe: esta página trata 200–399 como online e 400–599, assim como qualquer requisição que não receba código de status algum, como offline.
- RFC 9110, HTTP Semantics, seção 15 — a definição normativa de cada classe de status.
- Registro de códigos de status HTTP da IANA — a lista oficial dos códigos atribuídos.
- MDN, códigos de status de resposta HTTP — notas práticas sobre cada código.
- Google for Developers, «How HTTP Status Codes Affect Google's Crawlers» — o que cada código significa para rastreamento e indexação.
- Google for Developers, «Debug Network and DNS Errors for Google's Crawlers» — o que significa quando uma requisição não recebe código de status algum.
- RFC 6585, Additional HTTP Status Codes, seção 4 — a definição do 429 Too Many Requests e da sua indicação Retry-After.