HTTP Header Inspector
Introduza um URL completo. A KernelHost vai buscar a resposta em direto a partir de Frankfurt FRA01: status code, todos os headers, cadeia de redirecionamentos, verificação TLS e auditoria de security headers.
O que é um HTTP header
Os HTTP headers são pares chave-valor que um servidor web envia com cada resposta, antes do conteúdo propriamente dito. Controlam como o navegador renderiza a página, se pode fazer cache, se pode ser embebida em iframes, que scripts pode executar e se deve forçar HTTPS.
Quando se pede um URL, este inspector devolve o status code, todos os response headers, a cadeia completa de redirecionamentos, o protocolo HTTP utilizado, o certificado TLS verificado, e uma auditoria de segurança dos headers de proteção mais importantes.
- Status code: 200 OK, 301 Redirect, 404 Not Found, 500 erro de servidor, e por aí. O badge de cor mostra a classe num relance.
- Cadeia de redirecionamentos: Cada salto de HTTP para HTTPS, de www para o domínio nu, cada redirecionamento de tracker fica exposto.
- Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy num bloco de auditoria.
- Verificação TLS: Certificado, issuer, validade e o código de verify do OpenSSL. Self-signed ou expirado torna-se óbvio na hora.
Compreender HSTS, CSP e CORS
O HSTS (Strict-Transport-Security) diz ao navegador para usar apenas HTTPS para este domínio a partir de agora, mesmo que o utilizador escreva http://. Uma vez definido com max-age=63072000 (dois anos), o site fica HTTPS-only durante dois anos sem perguntar ao servidor. includeSubDomains estende a regra a cada subdomínio. preload permite adicionalmente a inclusão nas listas preload do Chrome e Firefox.
A CSP (Content-Security-Policy) é uma whitelist: apenas as fontes de recursos explicitamente permitidas podem carregar. default-src 'self' bloqueia tudo fora do próprio origin. script-src, style-src, img-src, connect-src, frame-src especificam exceções. CSPs baseadas em nonce ou hash permitem adicionalmente scripts inline em segurança. Uma CSP afinada corretamente é a mais forte defesa XSS oferecida pela web.
O CORS (Cross-Origin Resource Sharing) não é proteção, é permissão: Access-Control-Allow-Origin diz que origens externas podem ler a resposta. Mal configurado (Access-Control-Allow-Origin: * combinado com cookies) abre uma falha, configurado corretamente permite chamadas API seguras a partir do seu próprio SPA.
Cadeias de redirecionamentos e SEO
Cada redirecionamento custa um round-trip. Uma cadeia http -> https -> www -> /pt/ soma quatro saltos e pode demorar mais de um segundo numa ligação móvel lenta antes do conteúdo real começar a carregar. Os motores de busca penalizam cadeias longas e perdem uma pequena fração de link equity em cada salto.
- 301 vs 302: 301 é permanente e em cache, 302 é temporário. Redirecionamentos permanentes de migração devem usar 301, caso contrário, o Google mantém o URL antigo no índice.
- Ligar diretamente: Os links internos devem apontar sempre para o URL final, nunca para um redirecionamento conhecido, caso contrário cada clique paga um salto desnecessário.
- Deteção de loop: Mais de 5 saltos ou loops são má configuração. O inspector aborta após 10 redirecionamentos e torna o problema visível.
Um domínio bem estruturado tem no máximo um redirecionamento (HTTP -> HTTPS, ou bare -> www), nunca mais.
Boas práticas de Cache-Control
O Cache-Control decide se navegadores, CDNs e proxies podem reutilizar uma resposta. Um Cache-Control bem afinado reduz a carga sobre a origem, acelera as visitas repetidas em ordens de magnitude e melhora diretamente os Core Web Vitals.
- Assets estáticos: public, max-age=31536000, immutable para ficheiros bundle com hash (style.abc123.css). Um ano de cache, sem revalidação.
- Páginas HTML: no-cache, must-revalidate (cada pedido valida, mas é permitido 304 Not Modified) ou s-maxage=60 para cache curto no edge do CDN.
- Conteúdo privado: private, no-store para respostas com cookies de sessão ou conteúdo personalizado. Nunca permitir que um cache partilhado os armazene.
- ETag e Last-Modified: Fornecem validadores para a resposta 304 Not Modified. Poupam largura de banda e são definidos gratuitamente pelo servidor web (NGINX, Apache).
Cenários comuns de debug
Da prática real, é para isto que o header inspector é mesmo usado:
- Verificar status de cache do CDN: A Cloudflare expõe cf-cache-status (HIT, MISS, BYPASS), a Fastly usa x-cache, a KeyCDN x-cache. Visível diretamente no bloco de headers.
- Verificar flags de cookies: Os headers Set-Cookie aparecem com todos os atributos. Secure, HttpOnly, SameSite têm de estar definidos para cookies de sessão.
- Verificar migração HTTPS: Uma entrada http:// deve dar 301 para https:// mais um header HSTS na resposta final. Ambos visíveis na cadeia de redirecionamentos e na auditoria.
- Regras de deteção de bots: WAFs definem frequentemente x-firewall, x-rate-limit-* ou server: cloudflare. Visível no header de servidor e na auditoria de headers.
- Isolar problemas TLS: Um código verify != 0 sugere certificados expirados ou self-signed; o campo issuer revela imediatamente se está a ser usado Let's Encrypt, Sectigo, DigiCert ou uma CA interna.
A KernelHost define estes headers de origem
Cada plano de webhosting da KernelHost entrega o vhost NGINX por defeito já com HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy e uma CSP conservadora ativa. Os domínios dos clientes não precisam de configurar nada, os valores chegam automaticamente na resposta.
Em VPS e servidores dedicados KernelHost, o nosso bundle de tweaks (script de auto-setup) entrega a mesma configuração default, mais overrides por vhost via includes do NGINX. Atingir A+ no securityheaders.com é um trabalho de dois minutos por lá.
Privacidade
O HTTP Header Inspector funciona inteiramente no lado do servidor, em infraestrutura KernelHost (Frankfurt FRA01, Alemanha). Sem APIs externas, sem tracking de terceiros.
- Os URLs introduzidos são usados apenas para o pedido único e não são guardados de forma persistente.
- A resposta do servidor de destino é renderizada no seu navegador e descartada da memória do servidor depois.
- Os dados de rate limit guardam apenas um hash anónimo do IP do cliente até 60 segundos, para evitar abuso.
- O pedido de saída para o URL alvo leva o User-Agent KernelHost-Header-Inspector/1.0 e nenhum cookie ou auth header.
Perguntas frequentes
Porque não vejo o mesmo status code que o meu navegador?
Alguns sites devolvem respostas diferentes consoante o user-agent ou o estado dos cookies. O inspector usa um user-agent limpo sem cookies, esta é a resposta crua do servidor. Com geo-blocks ou testes A/B, o código pode diferir.
O que significa 405 ou 501 numa resposta a HEAD?
405 Method Not Allowed ou 501 Not Implemented significa que o servidor bloqueia pedidos HEAD. O inspector troca então automaticamente para GET e descarta o body. A linha de resultado mostra 'Método: GET' em vez de 'HEAD'.
Porque é que a verificação TLS falha quando o meu navegador não mostra problema?
Os navegadores aceitam frequentemente raízes mais antigas ou raízes adicionais geridas pela Microsoft, Mozilla ou Apple, que não estão no trust store default do OpenSSL. Certificados self-signed, certificados assinados internamente ou um intermédio em falta são as causas mais comuns.
Posso verificar URLs http:// também?
Sim. O inspector aceita http:// e https://. Com http:// não há bloco TLS, mas vê a resposta HSTS do servidor (ou a sua ausência) e a cadeia de redirecionamentos para a variante https://.
Os IPs privados são suportados (192.168, 10.x, ::1)?
Não, por motivos de segurança. O servidor verifica cada hostname contra um filtro de IP público antes do pedido (RFC1918, loopback, link-local e reservados são bloqueados), para impedir ataques SSRF contra a infraestrutura interna da KernelHost.
Qual é a profundidade máxima de redirecionamentos que o inspector segue?
Até 10 redirecionamentos, depois o curl aborta. Mais de 10 saltos na prática indicam quase sempre um loop ou má configuração e são reportados como erro na resposta.
Porque não vejo um header Set-Cookie embora a página defina cookies?
Set-Cookie aparece apenas na resposta imediata do servidor, não depois de um redirecionamento. Se a página final definiu o cookie antes (num salto de redirecionamento), aparece na cadeia de redirecionamentos em vez da tabela de headers. Muitas SPAs modernas definem cookies apenas via login JavaScript, o que um inspector do lado do servidor naturalmente não vê.
HTTP/3 ou QUIC são detetados?
O pedido corre sobre HTTP/1.1 ou HTTP/2 (consoante a build do libcurl, no container da KernelHost é HTTP/2). Um header alt-svc na resposta indica se o servidor oferece adicionalmente HTTP/3, mas o pedido em si corre sobre a ligação H1/H2 estabelecida.
Todos os produtos KernelHost
Precisa de mais do que ferramentas? Confira nossa linha de hospedagem comercial.