Debugando rede na prática: curl, dig e DevTools

Toda essa trilha explicou as etapas que uma requisição percorre — DNS, TCP, TLS, proxy, cache. Debugar um problema de rede de verdade é usar ferramentas que mostram exatamente onde, dentro dessas etapas, o tempo está sendo gasto, em vez de adivinhar.

A aba Network do navegador — a primeira parada

Ao inspecionar uma requisição na aba Network do DevTools, o navegador já separa o tempo total em fases: DNS Lookup, Initial connection, SSL, Waiting (TTFB) e Content Download. Isso já diz muito antes de qualquer outra ferramenta: uma fase de Waiting longa aponta pro servidor (ele recebeu a requisição e demorou pra responder); uma fase de DNS Lookup longa aponta pra resolução de nome; uma fase de Content Download longa aponta pro tamanho da resposta, não pra "rede lenta" de forma genérica.

dig — checando a resolução DNS diretamente

dig howtodev.site +short

Quando você suspeita que o problema é DNS especificamente, dá pra consultar um servidor público direto — sem passar pelo cache do seu sistema operacional ou roteador — pra isolar se o problema é a sua rede local ou o registro DNS de verdade:

dig @8.8.8.8 howtodev.site

Se a resposta do 8.8.8.8 já vem correta e rápida, o problema não está no registro DNS em si — pode estar num cache antigo no seu resolvedor local, ou em outra etapa depois da resolução de nome.

curl -v — vendo a requisição sem a abstração do navegador

curl -v https://howtodev.site

A flag -v (verbose) mostra a conexão sendo estabelecida, o handshake TLS, e depois os headers de requisição (linhas com >) e resposta (linhas com <) exatamente como trafegaram — útil pra depurar API sem depender de interface gráfica, ou pra confirmar que um header específico (como Cache-Control ou Access-Control-Allow-Origin) realmente veio do servidor do jeito esperado.