"Não consigo navegar" através de uma plataforma de segurança em nuvem é uma frase com cinco sujeitos possíveis - o dispositivo, a rede local, o provedor de identidade, o túnel ou a nuvem - e quem resolve mais rápido é quem localiza antes de consertar. O artigo de perfis explicou o que o Zscaler Client Connector () é mandado fazer; este é sobre descobrir o que ele está de fato fazendo. Fundamentado na documentação oficial de troubleshooting e nos runbooks da Zscaler, verificados em 2026-07-21.
O kit que o agente carrega
O ZCC embarca seu próprio diagnóstico, e o menu documentado é o kit de perícia: Export Logs empacota os logs do agente num ZIP para o suporte; Start Packet Capture - quando o admin da organização habilitou - grava o fio enquanto você reproduz o problema; Restart Service reinicia o agente sem impactar a aplicação de segurança, a propriedade documentada que o torna um primeiro movimento seguro; Clear Logs zera o registro antes de uma reprodução limpa; e o Log Mode eleva a verbosidade apenas para a sessão de conexão atual, revertendo ao padrão da organização na próxima - profundidade de debug sem armadilha residual. O log que o túnel escreve - ZSATunnel entre eles - é onde o vocabulário de erros abaixo de fato aparece.
As quatro primeiras verificações
Um: o que o agente diz? O estado de conexão na cara do app localiza sozinho - um estado de autenticação aponta para a conversa com o ; um estado conectado sem tráfego aponta rio abaixo. Dois: o tráfego está de fato transitando pelo Zscaler? A página de verificação do serviço em ip.zscaler.com responde do ponto de vista autoritativo: se o tráfego deste navegador está chegando pela plataforma, e por qual nó - o divisor mais rápido entre "o encaminhamento quebrou" e "o encaminhamento está bem, procure em outro lugar". Três: há um portal cativo no caminho? A detecção documentada sonda http://gateway.<cloud>.net:443/generate_204 e espera um HTTP 204; qualquer outra coisa - a página de login do hotel, um redirect - significa que a rede quer um humano primeiro, e o agente está corretamente esperando. Quatro: algo local está comendo o agente? A checklist de interferência documentada: clientes reivindicando rotas que precisam excluir a faixa reservada 100.64.0.0/24 de health check, firewalls de endpoint e antivírus filtrando os fluxos do agente, e um segundo produto de inspeção quebrando o TLS do próprio agente - a classe de falha em que o ZCC funciona depois de um boot limpo e degrada quando o outro agente sobe.
Lendo o vocabulário do túnel
Duas assinaturas documentadas recompensam memorização. SERVER_DOWN_ERROR e FIREWALL_BLOCK_ERROR nos logs do túnel, numa operadora conhecida por estrangular , é a assinatura do transporte UDP do Z-Tunnel 2.0 sendo espremido - e a cura documentada é trocar o túnel para TLS, negociando um pouco de eficiência por um transporte que os middleboxes deixam em paz. E falhas com formato de DNS nos logs - erros de resolução contra os nomes de gateway - apontam para o resolvedor local ou para software de segurança interceptando DNS, não para a Zscaler; o agente não alcança uma nuvem cujo nome não consegue resolver.
A disciplina
Cada verificação acima é isolamento de falhas vestindo um crachá de produto: estabeleça qual segmento é dono da falha antes de tocar em qualquer coisa, capture evidência (logs exportados, captura rodando) enquanto a falha está viva, e deixe o ZDX responder a versão em escala de frota da mesma pergunta - um usuário falhando é conversa de dispositivo; uma localidade falhando é conversa de rede; todos falhando é página de status.