Triagem de Conectividade

Localize uma falha de conectividade ativa sem alterar a configuração de rede. Colete o menor conjunto de evidências útil, distinga observações de inferências e pare quando o domínio da falha estiver claro o suficiente para a próxima ação segura.

Quando Usar Esta Habilidade

Use este fluxo de trabalho quando um endpoint macOS apresentar um sintoma ativo, como:

• Uma API, site ou serviço MCP com tempo limite ou desconectando;
• Falhas na consulta DNS ou resolução de nomes inconsistente;
• Perda de pacotes, latência ou tráfego interativo instável;
• Um aplicativo que parece offline enquanto outro tráfego funciona;
• Incerteza sobre se o problema é local, upstream ou no serviço.

Este é um fluxo de trabalho de diagnóstico, não um fluxo de trabalho de remediação. Não altere o estado da interface, configurações de DNS, configuração de VPN/firewall ou estado do serviço remoto enquanto estiver estabelecendo o domínio da falha.

Fluxo de Decisão Rápida

Trabalhe a partir do sintoma em direção à verificação discriminatória mais restrita:

symptom
  -> local link / LAN evidence
  -> DNS configuration and resolution
  -> destination reachability
  -> path quality
  -> application / service timing
  -> fault-domain assessment

Pare cedo quando as evidências já forem suficientes. Não execute todas as sondas mecanicamente.

1. Defina o sintoma

Registre o aplicativo ou processo afetado, o nome do host ou URL de destino, quando a falha começou, se é contínua ou intermitente e se destinos não relacionados ainda funcionam.

Se o sintoma for específico do aplicativo, preserve o nome do host ou URL exato que o aplicativo usa. Testar um site público não relacionado pode estabelecer conectividade geral, mas não pode provar que o serviço afetado está saudável.

2. Verifique evidências de link local / LAN

Quando disponível, execute uma amostra limitada de networkQuality para um sinal amplo de responsividade e taxa de transferência. Se networkQuality não estiver disponível, continue; é opcional.

Se um gateway local conhecido ou um alvo na mesma LAN estiver disponível, compare uma amostra curta e limitada de ping para esse alvo local com uma amostra curta para o destino remoto. Não invente um endereço de gateway. Se nenhum alvo local for conhecido, deixe o segmento de LAN sem comprovação e continue.

Padrão útil:

ping -c 5 <known-local-target>
ping -c 5 <destination>

3. Separe a configuração de DNS do comportamento de DNS

Inspecione o estado do resolvedor do sistema, especialmente quando VPNs, DNS dividido ou resolvedores com escopo podem estar envolvidos:

scutil --dns

Em seguida, teste o nome de destino diretamente com uma consulta DNS limitada:

dig +time=2 +tries=1 <hostname>

Trate isso como evidências diferentes. scutil --dns mostra a configuração do resolvedor; dig mostra o comportamento da consulta. Uma consulta bem-sucedida não prova que o endpoint retornado é alcançável.

4. Teste a alcançabilidade e a qualidade do caminho

Use uma amostra curta de ping quando o ICMP for um sinal útil:

ping -c 5 <destination>

Se o nome do host for resolvido, teste o endereço retornado separadamente apenas quando isso ajudar a distinguir o comportamento do DNS da falha do caminho. Se a resolução falhar atualmente, use um endereço apenas quando ele foi observado anteriormente a partir de evidências confiáveis de incidentes; caso contrário, deixe a alcançabilidade em nível de endereço desconhecida.

Use um traceroute numérico limitado quando a visibilidade do caminho reduzir a incerteza:

traceroute -n -q 1 -m 20 <destination>

Um salto silencioso ou em mudança é uma observação, não prova de que o salto está quebrado. Roteadores podem filtrar ou limitar a taxa de tráfego de traceroute enquanto encaminham o tráfego do aplicativo normalmente.

5. Inspecione a atividade de rede ativa do aplicativo afetado

Quando o problema for específico do processo, use uma captura limitada de nettop em vez de observar indefinidamente:

nettop -n -L 3 -p <process-name-or-pid>

Use-a para confirmar se o processo está abrindo conexões, quais endpoints ele está usando e se o tráfego está fluindo. A falta de atividade visível pode significar que o aplicativo nunca tentou a conexão; isso por si só não identifica o motivo.

6. Meça o tempo do caminho do aplicativo

Para HTTP(S), use a temporização de fase do curl contra o endpoint afetado real quando uma solicitação segura de somente leitura estiver disponível. Confirme se o endpoint fornecido no incidente é um http:// ou URL https:// completo, preserve seu esquema original e passe o URL como um argumento entre aspas, em vez de interpolar texto arbitrário do incidente no comando do shell:

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \

…