Verificador de Status do Servidor v2.0

Verifique se um site ou servidor está no ar e veja o código de status HTTP real e o que significa, o tempo de resposta, a cadeia completa de redirecionamentos, o certificado SSL e o servidor por trás. Verifique um ou cole vários. Sem cadastro.

Sobre Verificador de Status do Servidor

O verificador de status do servidor é uma ferramenta que envia uma requisição HTTP real para um endereço e informa se ele está no ar, qual código de status o servidor devolveu e quanto tempo levou para responder. A versão do ToolsPivot vai além do sim ou não: ela mostra a cadeia completa de redirecionamentos, o certificado SSL, o servidor e a CDN por trás do site e quais cabeçalhos de segurança estão presentes. Tudo roda no nosso servidor, com HTTP puro, sem cadastro e sem chave de API.

O que o verificador de status do servidor do ToolsPivot faz

Funcionalidade principal

A ferramenta recebe uma URL (ou até vinte de uma vez), faz uma requisição HTTP real a partir do nosso servidor e devolve um diagnóstico completo da resposta. Ela captura o código de status e o significado dele em português claro, o tempo até o primeiro byte, o tempo total, cada salto de redirecionamento, os dados do certificado e os cabeçalhos que o servidor expõe. Você cola o endereço na aba "Uma URL", clica em "Verificar status" e o resultado aparece em poucos segundos. Funciona com ou sem o http(s) na frente.

Usuários-alvo e casos de uso

Quem mais usa esse tipo de checagem são desenvolvedores validando um deploy, profissionais de SEO investigando por que uma página sumiu do índice e agências que administram dezenas de sites de clientes. Donos de loja no Mercado Livre ou em site próprio também recorrem à ferramenta quando o site parece fora do ar e ninguém sabe dizer se o problema é do servidor ou da conexão de quem está reclamando.

Problema e solução

O navegador não consegue ler o código de status real de outro site. Por causa da política de mesma origem, uma requisição entre domínios diferentes volta como resposta opaca, com status 0 e sem nenhum cabeçalho, justamente para impedir que um site leia os dados de outro. Rodando do lado do servidor, sem essa restrição, a ferramenta enxerga a resposta inteira e entrega o código exato, os cabeçalhos e os tempos que o navegador esconderia de você.

Principais benefícios

  • Código exato, não uma suposição: você vê o número de três dígitos que o servidor realmente devolveu, com a explicação do que ele significa segundo as definições padrão do HTTP.
  • Diagnóstico de lentidão por fase: a quebra do tempo em DNS, conexão, TLS, espera e download mostra onde está o gargalo antes de você culpar a hospedagem sem evidência.
  • Redirecionamentos visíveis salto a salto: em vez de seguir a cadeia às cegas, a ferramenta registra cada parada, o que revela loops e desvios herdados de migrações antigas.
  • Aviso antecipado de certificado: a leitura do certificado durante a conexão mostra quantos dias faltam para vencer, e um certificado vencido derruba o site inteiro no navegador.
  • Checagem em lote com exportação: até vinte endereços por vez, com filtro por classe de status e exportação em CSV para anexar em relatório de cliente.
  • Sem cadastro e sem chave de API: nada de criar conta, informar e-mail ou aguardar aprovação. Cole a URL e verifique.
  • Segurança levada a sério: a ferramenta se recusa a consultar endereços internos, o que a protege de ser usada como ponte para a rede privada de quem a hospeda.

Para um retrato mais amplo da saúde técnica do site, vale rodar a checagem junto com o verificador de SEO do site, que cobre pontos que o status HTTP sozinho não alcança.

Funcionalidades-chave

  • Requisição HEAD com retorno para GET: a ferramenta pede primeiro só os cabeçalhos, que é mais rápido e leve. Se o servidor recusa o HEAD com 405 ou simplesmente não responde, ela repete a consulta com um GET normal.
  • User-agent de navegador real: a requisição se identifica como um navegador comum, o que reduz a chance de um filtro antibot devolver um falso "acesso negado" para o verificador.
  • Classificação honesta do estado: códigos 2xx e 3xx marcam o site como online; 4xx e 5xx indicam que o servidor respondeu, mas com problema; ausência total de resposta significa inacessível.
  • Tempo até o primeiro byte e tempo total: os dois números vêm da medição da própria requisição, separando a demora do servidor da demora da transferência.
  • Barra proporcional de tempos: as fases aparecem desenhadas em escala, então dá para ver de relance que a lentidão foi o servidor pensando, e não a rede.
  • Cadeia de redirecionamentos com limite: cada salto é resolvido individualmente, absoluto ou relativo, com teto de dez saltos e detecção de loop quando uma URL aponta de volta para outra já visitada.
  • Leitura do certificado SSL: para endereços HTTPS, a ferramenta informa o emissor, a data de expiração e os dias restantes, sinalizando certificados vencidos. Para uma análise mais profunda, use o verificador de segurança de website.
  • Detecção de servidor e tecnologia: os cabeçalhos Server e X-Powered-By revelam o software por trás da resposta quando não estão ocultos.
  • Identificação de CDN: cabeçalhos característicos entregam a rede de entrega usada, como CF-Ray para Cloudflare, x-vercel-id, X-Amz-Cf-Id para CloudFront, além de Varnish, Fastly e Akamai.
  • Painel de cabeçalhos de segurança: HSTS, CSP, X-Frame-Options, X-Content-Type-Options e Referrer-Policy aparecem marcados como presentes ou ausentes. Se quiser inspecionar a resposta bruta, o leitor de cabeçalhos HTTP mostra tudo sem filtro.
  • Aba de lote com filtros: cole até vinte URLs, uma por linha, e use as marcações de filtro para exibir só uma classe de status ou só os endereços que não responderam.
  • Exportação em CSV: o lote inteiro sai em planilha, pronto para virar anexo de relatório ou base de acompanhamento semanal.

Como funciona o verificador de status do servidor do ToolsPivot

  1. Cole o endereço. Digite ou cole a URL na aba "Uma URL". Para vários sites, use a aba "URLs em lote" e coloque um endereço por linha.
  2. A ferramenta valida o destino. Antes de qualquer conexão, o host é resolvido para um IP e conferido contra as faixas proibidas, e só http e https são aceitos.
  3. A requisição sai do nosso servidor. Um HEAD é enviado primeiro; se o servidor recusar, um GET assume automaticamente, sempre com user-agent de navegador.
  4. Os redirecionamentos são percorridos um a um. Cada salto é registrado e revalidado antes do próximo, até o destino final ou até o limite de dez.
  5. O resultado é montado. Código, significado, tempos por fase, cadeia, certificado, servidor, CDN e cabeçalhos de segurança aparecem juntos na mesma tela.
  6. Filtre ou exporte. No lote, restrinja a visão por classe de status e baixe o CSV quando precisar guardar o resultado.

Quando usar a verificação de status

A checagem vale mais nos momentos em que uma mudança acabou de acontecer e ninguém confirmou o efeito dela. É nesses intervalos que erros silenciosos se instalam e só aparecem dias depois, quando o tráfego já caiu.

  • Logo após um deploy: atualizações de tema, plugin ou código costumam derrubar rotas específicas sem afetar a home.
  • Depois de trocar de hospedagem: rode as URLs principais e confira se alguma voltou 404 ou parou em um redirecionamento errado. O verificador de hospedagem ajuda a confirmar para onde o domínio está apontando.
  • Antes de ligar tráfego pago: anúncio apontando para página com erro queima verba sem retorno nenhum.
  • Quando o site "não abre" só para uma pessoa: se a ferramenta responde 200, o problema está na conexão, no DNS ou no provedor de quem reclamou.
  • Ao investigar queda de indexação: erros 5xx repetidos reduzem a frequência de rastreamento. Cruze com o verificador de indexação para saber o que ainda está no índice.
  • Na renovação de certificado: a contagem de dias restantes evita a surpresa do aviso de conexão insegura na segunda-feira de manhã.
  • Em auditoria de redirecionamentos: cadeias longas herdadas de migrações desperdiçam tempo de carregamento e confundem buscadores.

Em casos de bloqueio regional a resposta é diferente. Como a checagem parte de um único ponto, ela confirma o estado do site a partir daqui, mas não substitui uma rede de sondas distribuídas.

Casos de uso

Loja preparando data de pico

Contexto: um lojista com anúncios no Mercado Livre e site próprio precisa entrar na Black Friday sem página quebrada.

  • Reúne as URLs de categoria, produto e checkout em uma lista.
  • Roda a checagem em lote e filtra pelos códigos 4xx e 5xx.
  • Confere o tempo de resposta de cada página crítica.

Resultado: os erros são corrigidos antes de a campanha começar, e não durante o pico de visitas.

Agência com carteira grande

Contexto: uma agência administra dezenas de sites e precisa de rotina semanal de verificação sem contratar monitoramento pago para cada cliente.

  • Mantém uma lista com as páginas principais de cada conta.
  • Verifica o lote toda segunda-feira e exporta o CSV.
  • Compara com o arquivo da semana anterior para achar o que mudou.

Resultado: a agência descobre a queda antes do cliente, o que muda completamente o tom da conversa.

Desenvolvedor validando migração

Contexto: um desenvolvedor moveu um site para novo servidor e precisa provar que os redirecionamentos antigos continuam funcionando.

  • Testa as URLs legadas e acompanha a cadeia salto a salto.
  • Verifica se cada uma termina em 200 e no endereço certo.
  • Confirma o emissor e a validade do novo certificado.

Resultado: cadeias em loop e redirecionamentos apontando para o domínio antigo aparecem antes de virarem chamado de suporte.

Analista investigando lentidão

Contexto: um analista recebe reclamação de site lento, mas o relatório de performance não aponta causa clara.

  • Observa a barra de fases para isolar DNS, TLS e espera do servidor.
  • Compara o tempo até o primeiro byte com o tempo total.
  • Checa se a compressão está ativa antes de mexer no código.

Resultado: a equipe descobre que a demora estava na espera do servidor, e não na rede. O teste de compressão GZIP e o verificador de velocidade de página completam o quadro.

O que cada código HTTP revela

O código de três dígitos é a resposta mais objetiva que um servidor pode dar, e cada faixa aponta para um responsável diferente. Saber ler a faixa já elimina metade das hipóteses erradas.

  • 2xx: a requisição deu certo. O 200 é o resultado esperado para uma página normal.
  • 3xx: houve redirecionamento. O 301 é permanente e transfere autoridade; o 302 é temporário e sinaliza que a URL original pode voltar.
  • 4xx: o servidor está de pé e recusou a requisição. O 404 diz que a página não existe naquele endereço; o 403 indica acesso negado; o 429 significa que você bateu no limite de requisições.
  • 5xx: a falha é do lado do servidor. O 500 aponta erro interno, o 502 mostra que um intermediário recebeu resposta inválida da origem e o 503 indica sobrecarga ou manutenção.

Um detalhe que confunde muita gente: 4xx e 5xx não significam que o servidor está fora do ar. Ele respondeu, e respondeu rápido o bastante para dizer que algo deu errado. Fora do ar mesmo é quando nada volta. Para mapear onde os 404 se acumulam dentro do site, o verificador de links quebrados percorre as páginas e lista as ocorrências. Se a suspeita for de bloqueio por reputação, vale consultar a pesquisa em listas negras.

Como o ToolsPivot protege a própria infraestrutura

Qualquer ferramenta que busca uma URL fornecida pelo usuário é alvo clássico de abuso, porque um atacante pode pedir que o servidor consulte endereços internos aos quais só ele tem acesso. A proteção começa na resolução: o host vira IP antes da conexão, e qualquer resultado em faixa privada, de loopback, link-local ou reservada é recusado, incluindo o endereço de metadados de nuvem 169.254.169.254.

A conexão é então fixada nesse IP já validado, para que ninguém troque o destino depois da checagem. Só http e https são aceitos, cada alvo de redirecionamento passa pela mesma validação e existem tetos de tempo, tamanho e número de saltos. É por isso que a ferramenta se recusa a consultar localhost ou um IP de rede interna, mesmo que a intenção seja legítima.

Limites honestos desta verificação

Nenhuma ferramenta de status conta a história inteira, e vale saber onde esta para. A checagem parte de um único lugar, o nosso servidor, então ela responde se o site está no ar a partir daqui. Uma queda regional ou um bloqueio geográfico exige sondas distribuídas em vários países, o que é um tipo diferente de serviço.

Um 403 ou 429 vindo de serviço de proteção antibot pode significar que o verificador foi barrado, não que o site caiu; a mesma página talvez abra normalmente no seu navegador. A ferramenta também testa HTTP de verdade, e não ping: um servidor pode responder ping com o site quebrado, ou bloquear ping com o site funcionando perfeitamente. Se quiser comparar os dois comportamentos, o teste de ping online e o conversor de domínio para IP ajudam a separar camada de rede de camada de aplicação.

Por fim, a detecção de servidor, CDN e cabeçalhos de segurança é sempre o melhor esforço possível: esses cabeçalhos podem ser removidos, alterados ou forjados por um proxy no caminho. Trate o resultado como forte indício, não como prova.

Perguntas frequentes

O que é um verificador de status do servidor?

É uma ferramenta que envia uma requisição HTTP real para uma URL e informa se o servidor respondeu, com qual código e em quanto tempo. Além do estado, ela mostra a cadeia de redirecionamentos, o certificado e os cabeçalhos da resposta.

Quantas URLs posso verificar de uma vez?

A aba de lote aceita até vinte URLs, uma por linha. Cada resultado aparece em um cartão próprio, com filtro por classe de status e exportação do lote inteiro em CSV.

Por que a verificação precisa rodar no servidor de vocês?

Porque o navegador não consegue ler o código real de outro domínio. Requisições entre origens diferentes voltam como resposta opaca, com status 0 e sem cabeçalhos, então a checagem precisa sair de um servidor, que não tem essa restrição.

Qual a diferença entre site fora do ar e site com erro?

Fora do ar é quando nada volta, por falha de conexão ou tempo esgotado. Um 404 ou um 500 significa que o servidor está de pé e respondeu, só que a página tem problema.

Por que a ferramenta envia HEAD antes de GET?

O HEAD pede apenas os cabeçalhos, sem o corpo da página, o que torna a checagem mais rápida e leve. Quando o servidor recusa o HEAD com 405 ou não responde, a ferramenta repete a consulta com um GET normal.

A ferramenta consegue detectar uma queda regional?

Não. A checagem parte de um único ponto, então ela confirma o estado do site a partir do nosso servidor. Identificar indisponibilidade regional ou bloqueio geográfico exige uma rede de sondas distribuídas.

Recebi 403, mas o site abre no meu navegador. O que houve?

Provavelmente um serviço de proteção antibot barrou a requisição do verificador. Nesse caso o 403 fala sobre o filtro, não sobre a saúde do site, mesmo com o user-agent de navegador que a ferramenta usa.

O que a barra de tempos mostra exatamente?

Ela divide a requisição em consulta de DNS, conexão TCP, handshake TLS, espera do servidor e download, desenhados em proporção. Assim dá para ver se a lentidão foi processamento no servidor ou latência de rede.

Qual tempo de resposta é considerado bom?

Como referência geral, a documentação do web.dev sugere que a maioria dos sites busque um tempo até o primeiro byte de 0,8 segundo ou menos. Valores acima disso costumam aparecer como alerta em ferramentas de performance.

Por que existe limite de dez redirecionamentos?

O teto evita que a ferramenta fique presa em cadeias muito longas ou em loops. Quando uma URL aponta de volta para outra já visitada, o loop é detectado e a checagem para ali.

A verificação de certificado substitui uma análise de SSL completa?

Não. Ela é uma checagem leve, feita para pegar problemas óbvios como certificado vencido ou prestes a vencer. Para inspeção detalhada, use o verificador de SSL ou o decodificador de certificados.

Posso confiar na identificação de CDN e servidor?

Trate como indício forte, não como prova. Cabeçalhos como Server e os marcadores de CDN podem ser ocultados ou forjados por um proxy, então a detecção é sempre o melhor esforço possível.

Preciso criar conta para usar?

Não. Não existe cadastro, chave de API nem limite diário escondido. Cole a URL, clique em "Verificar status" e leia o resultado.

Como faço para acompanhar o histórico de um site?

Exporte o CSV do lote a cada rodada e compare os arquivos entre si. Muita gente combina essa rotina com o teste rápido de site fora do ar e o verificador de redirecionamento www para acompanhar mudanças de configuração ao longo do tempo.

Report a Bug
ToolsPivot

CONTACT US

marketing@toolspivot.com

ADDRESS

Ward No.1, Nehuta, P.O - Kusha, P.S - Dobhi, Gaya, Bihar, India, 824220

Our Most Popular Tools