O site está em baixo ou é a minha ligação?

Uma página que não abre pode ter um problema no alojamento, mas também pode estar a recusar apenas a sua ligação. Antes de concluir que o site está em baixo para todos, compare o mesmo endereço em condições diferentes. Uma tentativa falhada mostra uma falha de acesso naquele momento; falta descobrir a causa e a extensão.

Para comparar com uma consulta a partir de outro servidor, use O site está em baixo?. A ferramenta distingue possíveis falhas de bloqueios ao verificador; confirme também o acesso nas suas redes.

Comece por estes passos

1. Confirme o endereço. Verifique letras, domínio e caminho. Experimente a página inicial: uma ligação antiga pode falhar enquanto o resto do site funciona.
2. Abra outro site. Se vários endereços falham, investigue primeiro a sua ligação à Internet.
3. Compare outra rede. No telemóvel, desligue o Wi-Fi e use dados móveis. Abra exatamente a mesma página e anote a diferença.
4. Compare outro navegador. Uma janela privada também ajuda a testar uma sessão diferente, embora não elimine todas as extensões, filtros ou definições da rede. Tenha em conta se precisa de iniciar sessão.
5. Guarde a mensagem e a hora. «Acesso negado», «servidor não encontrado» e «tempo de espera excedido» apontam para investigações diferentes.

Abre nos dados móveis e falha no Wi-Fi? Investigue essa rede, o DNS e eventuais filtros ou bloqueios. Falha nas duas redes? Há mais motivo para investigar o site, mas duas tentativas não demonstram uma falha mundial.

Como se relacionam domínio, DNS, IP e alojamento?

O domínio é o nome que escreve. O DNS ajuda a encontrar o destino desse nome. Um endereço IP identifica um destino na rede, que pode ser um servidor ou um intermediário. A ligação HTTPS verifica a identidade apresentada pelo destino e protege a comunicação. Por fim, o servidor e a aplicação precisam de responder ao pedido.

Estas etapas podem falhar separadamente. Um domínio registado pode não ter o DNS configurado; um nome que resolve para um IP pode levar a um servidor com problemas; uma página inicial acessível pode coexistir com um início de sessão avariado.

Quando consultar WHOIS ou RDAP

Use a consulta WHOIS / RDAP para investigar dados públicos de registo, datas e estados disponíveis. O RDAP permite consultar dados de registo num formato normalizado. Os campos e a disponibilidade variam com a extensão do domínio; dados pessoais podem não ser públicos. Uma consulta sem resultado não prova que o domínio esteja livre ou que o site tenha desaparecido.

Também é preciso interpretar os estados: clientTransferProhibited impede a transferência do domínio e não significa que o site esteja bloqueado. Já clientHold ou serverHold podem impedir a ativação no DNS. Consulte a explicação dos estados na ICANN. Se o domínio for seu, confirme a renovação e eventuais pendências junto da entidade onde o registou; os prazos não são iguais para todas as extensões.

O que procurar numa consulta DNS

Na ferramenta Consultar DNS, introduza o nome que falha, incluindo o subdomínio quando existe. www e o domínio sem www podem ter configurações diferentes.

• A e AAAA: associam o nome a endereços IPv4 e IPv6, respetivamente.
• CNAME: aponta para outro nome, cujo destino também precisa de resolver. A ausência de um registo A isolado não chega para concluir que não existe um destino.
• NS: identifica servidores responsáveis pelas respostas oficiais de DNS.
• TTL: indica durante quanto tempo uma resposta pode ficar em cache antes de ser novamente consultada.

Esta ferramenta consulta um resolvedor público: o resultado pode diferir do DNS usado pela sua rede. Depois de uma alteração, compare as respostas e o TTL, em vez de assumir um prazo fixo para tudo ficar atualizado. Encontrar registos ajuda a confirmar essa etapa; não testa o funcionamento da página.

O IP que vejo é o do site?

A ferramenta Qual é o meu IP? mostra o IP público da sua ligação. Pode ajudar a identificar uma diferença entre Wi-Fi, dados móveis ou VPN. Não mostra automaticamente o endereço do site que está a investigar.

O IP obtido por DNS também pode pertencer a uma rede de distribuição de conteúdos, ou CDN, que recebe pedidos antes do alojamento. Por exemplo, um registo com proxy na Cloudflare devolve endereços dessa rede. Assim, encontrar um IP não identifica necessariamente o servidor de origem nem demonstra que a aplicação está a funcionar.

Como interpretar os erros mais comuns

Se uma ferramenta ou o navegador apresentar um código HTTP, use-o como pista sobre aquele pedido. A referência da MDN explica os códigos:

• 200: o pedido teve sucesso, mas confirme se recebeu a página esperada; o conteúdo pode apresentar um erro da aplicação.
• 301 ou 302: redirecionamento para outro endereço. Pode ser normal; um ciclo de redirecionamentos é um problema diferente.
• 401: pode ser necessário autenticar-se. 403: acesso recusado, incluindo possíveis regras de proteção.
• 404: o recurso pedido não foi encontrado; experimente a página inicial.
• 429: demasiados pedidos. Aguarde antes de repetir.
• 500, 502 ou 503: erro no servidor, num intermediário ou indisponibilidade temporária. Compare outras páginas e redes.

Um tempo limite é menos específico: pode resultar da rede, de um bloqueio ou do destino. Um aviso de certificado HTTPS pode dever-se a validade, identidade ou confiança; confirme também a data e a hora do dispositivo. Não ignore o aviso para introduzir palavras-passe ou dados pessoais.

Porque pode um verificador dizer que falhou quando o site abre?

Um verificador automático não faz necessariamente o mesmo pedido que o seu navegador. Pode usar outro IP, outra região e não executar JavaScript nem completar um CAPTCHA. Uma proteção contra robôs ou uma firewall de aplicações web (WAF) pode recusar esse pedido e permitir o acesso de uma pessoa.

A documentação dos desafios da Cloudflare mostra como uma página de verificação pode interromper o acesso até o navegador passar o desafio. Nesse caso, o resultado adequado é «verificação bloqueada» ou «inconclusiva», até haver mais evidência de uma falha do site.

Para investigar uma recusa de acesso em detalhe, siga O site abre, mas a verificação falha, com passos para visitantes, registos de segurança e robôs de pesquisa.

Há ainda o CORS: são permissões que limitam o que uma página pode ler de outro site através do navegador. Um erro de CORS numa ferramenta não demonstra que o destino esteja em baixo. Abrir um endereço diretamente e consultá-lo a partir de outra página são situações diferentes.

Dois exemplos para decidir o próximo passo

O navegador abre, mas o verificador recebe 403. Há acesso a partir do seu navegador e uma recusa naquele pedido automático. Se gere o site, procure o evento nos registos de segurança, pela hora e pelo identificador do pedido. Reveja a regra correspondente antes de alterar proteções gerais.

A página inicial abre, mas uma ligação recebe 404. Comece por procurar a página na navegação do site. Se gere o conteúdo, confirme se o endereço mudou e se deve criar um redirecionamento. A falha dessa ligação não demonstra que todo o alojamento esteja indisponível.

Ter domínio e DNS válidos garante que o site funciona?

Não. São partes do caminho até ao site. A ligação, o certificado, o servidor ou uma funcionalidade podem continuar a falhar. Confirme sempre a página e a ação que pretende usar: carregar a entrada do site não testa, por exemplo, o envio de um formulário.

Para acompanhar as consultas com exemplos, leia WHOIS, DNS e IP na prática: explica que nome consultar, como seguir os destinos e como comparar as respostas.

Porque abre no telemóvel e falha no computador?

Compare primeiro se usam a mesma rede. Depois verifique navegador, sessão, extensões e VPN. Altere uma condição de cada vez para perceber o que faz diferença. Se o problema persistir, envie ao suporte o endereço completo, a hora com fuso horário, a mensagem exata e as redes testadas; não envie palavras-passe nem cookies de sessão.