Guias

Uma lista de servidores MCP oficiais para código, navegadores, documentação, projetos e infraestrutura, agrupados por tarefa com transporte e autenticação.

O comando claude mcp add para servidores remotos e locais, os três escopos, como funciona o login OAuth pelo /mcp e como confirmar a conexão do servidor.

Servidores remotos como conectores personalizados, servidores locais no claude_desktop_config.json, extensões de um clique, onde ficam os logs e a aba Code.

O formato do arquivo .mcp.json, expansão de variáveis de ambiente para segredos, regras de aprovação e precedência, e as correções para as falhas mais comuns.

Consulte cada registro com dig ou nslookup e leia o cabeçalho Authentication-Results de uma mensagem real para ver o que passou.

Onde o robots.txt precisa viver, a sintaxe em cinco linhas, os erros que bloqueiam um site inteiro, e como confirmar que o arquivo está acessível de toda região.

Busque a URL exata, depois use o operador site: e a Inspeção de URL do Search Console. O que descoberta e rastreada mas não indexada realmente significam.

Uma ficha WHOIS traz o registrador, as datas de criação e expiração, os códigos de status e os servidores de nomes. Os contatos vêm ocultos na maioria dos domínios hoje.

Carregue o site de uma rede que não seja a sua. Se funcionar lá, a falha é local: cache de DNS, provedor, VPN, arquivo hosts ou o seu navegador.

Resolva o domínio para um endereço IP, depois consulte quem é dono desse endereço. O WHOIS do domínio dá o registrador e os servidores de nomes, não o host.

Mudanças de DNS ficam ativas na hora. O que você espera é o cache do registro antigo expirar, controlado pelo TTL antigo, não pelo novo.

Teste a página em um navegador real a partir de uma localidade conhecida e leia três números: tempo até o primeiro byte, largest contentful paint e tempo total.

Tempo de resposta do servidor é o tempo até o primeiro byte, não o carregamento da página. Meça com curl a partir de uma localidade conhecida e compare depois.

Leia o cadeado ou rode openssl s_client contra o host. Verifique a cadeia inteira: um intermediário vencido quebra o site tanto quanto um final vencido.

Consulte seu IP de envio e domínio contra blacklists de DNS, encontre o que disparou a listagem, corrija, depois peça a remoção a cada operador.

Teste a porta a partir de outra rede com nc, nmap ou uma ferramenta de verificação. Aberto, fechado e filtrado significam três coisas diferentes.

O cache de DNS guarda respostas antigas. Limpe com ipconfig /flushdns (Windows), dscacheutil (macOS) ou resolvectl flush-caches (Linux).

"Erro de DNS" cobre várias falhas sem relação entre si. Responda três perguntas rápidas para achar qual é a sua e o guia que corrige.

Incompatibilidade de versão ou cifra, certificado com problema ou um proxy de interceptação podem quebrar um handshake. Veja como diferenciar cada causa.

Não existe rota até o endereço de destino, geralmente um IP privado, uma rota morta ou IPv6 quebrado. Veja como encontrar a causa e corrigir.

O destino recusou ativamente a conexão com um pacote de reset, geralmente porque nada escuta naquela porta. Veja como descobrir por que e corrigir.

Uma conexão que funcionava foi derrubada de repente, geralmente por firewall, software de segurança ou queda no servidor. Veja como identificar e corrigir.

Nenhuma resposta chegou à tentativa de conexão dentro do tempo limite. Veja as causas, a diferença para recusado ou resetado, e como corrigir.

A conexão foi aceita mas o servidor devolveu zero bytes. Veja as causas comuns, de workers que caem a incompatibilidades de protocolo, e como corrigir.

O TLS funcionou, mas um quadro ou stream violou as regras do HTTP/2. Causas vão de cabeçalhos grandes a um bug de HTTP/2 num proxy.

Uma consulta DNS não devolveu um endereço utilizável. Diferente de NXDOMAIN: o nome pode existir, mas a consulta em si falhou.

O handshake não encontrou versão de TLS ou cifra em comum. Geralmente um servidor que só oferece TLS 1.0/1.1 ou cifras fracas.

O navegador seguiu uma cadeia de redirecionamentos que nunca terminou. Geralmente um loop entre HTTP e HTTPS entre um proxy e a origem.

O aviso principal do Chrome para toda a família de erros NET::ERR_CERT_*. O que cada código de erro significa e como corrigir.

O título genérico do Chrome cobre vários erros diferentes. Veja a causa real pelo código abaixo dele e a correção certa para cada um.

A origem respondeu, mas de forma vazia ou ilegível, e a Cloudflare não conseguiu repassar a resposta. Como ler os logs da origem e testar direto, sem a Cloudflare.

A origem recusou a conexão da Cloudflare de forma ativa. Porta errada, faixas de firewall bloqueadas, ou modo TLS incompatível - e como o 521 difere do 523.

O handshake TCP com a origem nunca se completou em cerca de 15 segundos. Causas, correções, e como o 522 difere do 524, mais lento na resposta.

O certificado expirou ou ainda não é válido, ou o relógio do visitante está errado. Como ler as datas com openssl e corrigir os dois casos.

O handshake TLS falhou antes de qualquer certificado ser avaliado. De uma porta sem TLS ao QUIC, antivírus e o modo SSL do Cloudflare.

Uma canônica de staging em páginas ao vivo é uma configuração de URL base que viajou com um release ou uma cópia de banco. Causas, como verificar e prevenir.

A lista ordenada: ação manual, noindex, robots.txt, canônica, invasão ou blacklist, erros de servidor, domínio vencido. Seis são visíveis de fora.

O servidor recebeu a sua requisição e a recusou, quase sempre com um 403. Correções separadas para o visitante bloqueado e para o dono do site.

A consulta estourou o tempo sem nenhuma resposta. Descubra se a culpa é do resolvedor, do roteador ou da rede, e corrija em cada plataforma.

Meça a consulta antes de mudar qualquer coisa, depois corrija o resolvedor, os TTLs ou a cadeia de CNAME que está custando o atraso.

A consulta devolveu "nome inexistente", então o navegador nunca recebeu um IP. Correções para Windows, macOS, Linux, o roteador e o próprio domínio.

O que significa cada um dos cinco campos do cron, uma tabela com os agendamentos mais usados e os nove erros que fazem a tarefa rodar na hora errada.

Um 401 significa que a requisição não tem credenciais válidas. Cabeçalho WWW-Authenticate, tokens expirados, diferença de relógio e 401 versus 403.

Um 405 significa que o recurso existe mas rejeita o método HTTP usado. Cabeçalho Allow, arquivos estáticos, preflight CORS, nginx e rotas de framework.

Um 406 significa que o servidor não consegue combinar com o que o cliente aceita. Negociação de conteúdo, a causa comum de WAF/ModSecurity, e a correção.

Um 413 significa que o corpo da requisição é maior que um limite definido. Limites de upload do nginx, Apache, PHP, IIS, Cloudflare e API gateways.

Um 422 significa que a requisição foi interpretada mas um valor falha na validação. Rails, Laravel e FastAPI, 422 versus 400, e como ler o erro.

Um 499 significa que o cliente desconectou antes de o nginx responder. Log de acesso do nginx, origens lentas e alinhamento de timeouts.

Um 400 significa que o servidor não conseguiu interpretar a requisição. Cookies grandes, URLs ruins, limites de cabeçalho, regras de WAF.

O 301 move uma URL em definitivo e transfere os sinais de ranqueamento; o 302 é um desvio temporário que mantém a original. Como escolher e como verificar.

Um 403 significa que o servidor recusa a requisição e credenciais não ajudam. Permissões, bloqueios de WAF e geográficos, e como liberar um serviço de monitoramento.

Um 429 é um limite de taxa, não uma queda. Como ler o Retry-After, distinguir restrição de indisponibilidade e evitar que o seu monitoramento dispare o limite.

Um 503 significa que o servidor está vivo e recusando trabalho de propósito. Os padrões de sobrecarga, manutenção e implantação, e por que Retry-After importa.

Um 504 significa que o proxy esperou tempo demais pelo seu backend. Consultas lentas, partidas frias, ajuste de tempos limite e a comparação 502 x 503 x 504.

200 OK significa que a requisição teve sucesso, não que a página está correta. Páginas de erro, avisos de manutenção e cascas vazias também vêm com 200.

O 300 oferece ao cliente uma lista de representações para escolher. É HTTP válido mas praticamente não usado, e a maioria de quem busca por ele tem um 301 ou 302.

O 303 diz ao cliente para buscar o resultado em outra URL com GET. É o código por trás do Post/Redirect/Get, que impede recarregamentos de reenviar um formulário.

304 significa que sua cópia em cache ainda está atual, então o servidor não envia corpo. Ele só responde a requisições condicionais com ETag ou Last-Modified.

Um 404 diz que a URL não tem conteúdo atual, nada mais. Diferencie links quebrados de remoções deliberadas, e pegue soft 404s que devolvem 200.

Um 500 significa que sua aplicação quebrou e não vai dizer como. Onde encontrar o erro real, e como o 500 difere do 502, 503 e 504.

Um 502 significa que o seu proxy recebeu uma resposta inválida ou nenhuma do backend. Aprenda a ler a linha de erro do nginx e corrigir a causa real.

Um 4xx significa que o servidor recusou a requisição como foi enviada. No seu próprio site, costuma ser uma rota quebrada, um link antigo ou uma regra de firewall.

Um 5xx significa que o servidor aceitou a requisição e depois falhou. Cada código nomeia um salto diferente: o que quebrou, e como rastrear.

Um 3xx diz ao cliente que o recurso vive em outro lugar. O que 300 a 308 significam, qual usar, e como encontrar cadeias de redirecionamento quebradas.

2xx significa que o servidor aceitou e completou a requisição. O que 200, 201, 202, 204 e 206 significam, e por que um 200 não é prova de saúde.

Uma resposta 1xx é provisória: o servidor recebeu a requisição e uma resposta final de verdade ainda está a caminho. Não é sucesso nem erro.

O DKIM assina o e-mail de saída com uma chave privada; a chave pública fica no DNS em um seletor, o que sobrevive ao encaminhamento.

O DMARC alinha os resultados de SPF e DKIM e diz aos receptores se devem colocar em quarentena ou rejeitar e-mail que falha.

O TLS mútuo adiciona um certificado de cliente ao handshake, então o servidor também verifica o cliente, e não só o contrário.

Um cache de DNS é uma cópia salva de uma resposta de DNS, guardada pelo navegador, SO, roteador ou resolvedor. O TTL define quanto tempo cada cópia dura.

O handshake TLS negocia versão e cifra, verifica o certificado do servidor e deriva uma chave compartilhada, em um round trip desde o TLS 1.3.

Um registro MX indica os servidores de e-mail de um domínio; a prioridade decide qual deles um remetente tenta primeiro.

SPF é um registro TXT que lista os servidores autorizados a enviar e-mail por um domínio, com limite de 10 consultas e uma regra final.

Uma consulta de DNS passa por um resolvedor stub, um resolvedor recursivo e um servidor autoritativo, cada um com um papel diferente na busca da resposta.

O DNS roda na porta UDP 53 para consultas comuns e na porta TCP 53 para transferências de zona e respostas grandes, além de 853 e 443 nas variantes cifradas.

O llms.txt é um arquivo proposto para modelos de IA, não um padrão da web. O Google diz que não o usa na Busca. Veja o que ele faz e como verificá-lo.

Noindex mantém uma página fora dos resultados de busca enquanto ainda permite o rastreamento. O que a meta tag e o cabeçalho X-Robots-Tag fazem, e como vazam.

Uma URL canônica nomeia a única versão real de uma página para que duplicatas se consolidem nela. Autorreferência, entre domínios, e a falha de canônica de staging.

A fórmula de uptime em uma linha, quanto 99,9% vs 99,99% vs 99,999% custa em indisponibilidade real por ano, e como medir a indisponibilidade com precisão.

Por que um sistema de monitoramento reconfirma uma verificação falhada a partir de outras localidades, as três estratégias da HostTracker, e como escolher.

Verificações sintéticas rodam em uma agenda a partir de localidades que você escolhe; o RUM registra tempos de visitantes reais. O que cada um pega e perde.

Monitoramento de servidor verifica disponibilidade, desempenho e uso de recursos continuamente. O que cobre, com agente vs. sem agente, e sobre o que alertar.

Uma blacklist de DNS marca endereços IP associados a spam. Como acontece uma listagem, muitas vezes sem culpa sua, e como verificar e monitorar seu status.

Uma página de status mostra se cada parte do seu serviço funciona agora, mais o registro de incidentes. O que publicar, pública vs privada, e como escrever atualizações.

Uptime é a fração de um período medido em que um site respondeu como esperado. O que a porcentagem significa, o que os noves permitem, e como é medido.

Sem um monitor, você fica sabendo de uma indisponibilidade por um cliente. O que tira sites do ar, o que essa lacuna custa e o que observar além de no ar/fora.

Latência, tempo até o primeiro byte e tempo de resposta total medem trechos aninhados de uma requisição. Como cada um é medido, o que é bom, e o que as lacunas dizem.

Monitoramento de SLA significa medir o uptime de forma independente para comprovar se um serviço cumpriu seu compromisso de disponibilidade.

Uma verificação de API solicita um endpoint e interpreta a resposta como JSON, XML ou texto puro para você verificar um valor dentro dela, não só o status.

O monitoramento de Page Speed carrega a sua página em um navegador real e observa o carregamento: recursos falhados, uso de CPU e memória, e se bate o timeout.

O Content Check carrega a sua página em um navegador real e procura texto na página renderizada, pegando uma resposta 200 que mostra um erro ou estoque vazio.

Toda configuração da verificação de ping da HostTracker explicada: intervalo, resolução de DNS, IPs esperados, inscrições de alerta e as particularidades do ICMP.

Toda configuração da verificação de porta TCP da HostTracker explicada: validação de handshake TLS, o campo de padrão de resposta, IPs esperados e falhas comuns.

Um passo a passo da verificação de transação da HostTracker: construindo um fluxo de navegador em várias etapas, timeouts, validações e um exemplo de checkout.

Configure alertas da HostTracker no Slack via um Incoming Webhook: configuração passo a passo, mensagens de exemplo, eventos e solução de problemas.

Configure o monitoramento de Vencimento de certificado para saber de um certificado SSL/TLS vencendo semanas antes de um navegador avisar seus visitantes.

Configure o monitoramento de Vencimento de domínio para pegar um registro vencendo antes que tire seu site e e-mail do ar, e como isso difere de um SSL.

Uma verificação HTTP solicita uma URL a partir das suas localidades de monitoramento como um navegador faz, depois julga a resposta: status, velocidade e conteúdo.

Veja os dez canais de alerta da HostTracker, quais eventos disparam uma mensagem, como relatórios diferem de alertas, e como montar um escalonamento simples.

Um domínio vencido e um certificado SSL vencido parecem iguais mas não são. As causas, sintomas e correções diferentes, e como monitorar os dois.

Configure uma verificação de banco de dados que testa a saúde da conexão ou valida o resultado de uma consulta ao vivo, cobrindo provedores, credenciais e firewall.

Monitore a CPU, RAM, disco ou tempo de conexão de um servidor usando um pequeno endpoint que você mesmo hospeda, com limite e debounce que pega problemas reais.

Leia um valor ao vivo direto de um roteador, switch, nobreak ou outro dispositivo SNMP pelo OID, e veja o que alertar sobre ele pode e não pode fazer hoje.

O modo de asserções troca a checagem fixa de status e palavra-chave por regras que você escreve: a referência completa de cada sujeito, operador e atalho.

Configure o monitoramento de Web Risk para saber no momento em que o Google marcar a sua URL por malware ou phishing, e o que fazer quando isso acontecer.

Configure a verificação de BL russa para saber quando um site passa a mostrar o banner de bloqueio do regulador russo, e como ela difere de uma DNSBL de spam.

Configure o monitoramento DNSBL para pegar uma listagem em blacklist de DNS antes que ela quebre sua entregabilidade de e-mail, com cada opção explicada.