O Zscaler Client Connector () é o método de encaminhamento que viaja com o dispositivo, e a inteligência dele fica em dois documentos de configuração que quem está começando confunde o tempo todo. O responde como o tráfego sai deste dispositivo, nesta situação de rede: é o documento que cuida do caminho do tráfego. O app profile responde que política de plataforma vale para esta instalação: configurações por sistema operacional, listas de bypass, referências a , tratamento de certificados. Com essa divisão clara (o caminho do tráfego de um lado, a política do outro), o portal deixa de ser um labirinto. Tudo o que vem abaixo se baseia na documentação do Client Connector do fabricante, conferida em 21/07/2026.

Os três estados de rede

O coração do forwarding profile é uma pequena máquina de estados. O ZCC classifica o tempo todo a situação do dispositivo como on (dentro da rede confiável, a corporativa, conforme a definição mais abaixo), off trusted network (em qualquer outro lugar: a cafeteria, a casa do usuário) ou (rede privada virtual) trusted network (uma VPN de terceiros está ativa). Para cada estado, o perfil define uma ação de encaminhamento. No , as opções são: 1.0, Z-Tunnel 2.0, Tunnel with Local Proxy, Enforce Proxy ou None; no , é simplesmente Tunnel ou None. O que interessa são as combinações que isso permite: um desenho comum encaminha por Z-Tunnel 2.0 fora da rede corporativa e muda para None na trusted network, onde um túnel da localidade já leva o tráfego do site; ou seja, o agente sai do caminho exatamente onde encaminhar duas vezes atrapalharia. A orientação de interoperabilidade do fabricante traz um alerta importante, que vale reproduzir pelo menos na ideia: os modos de túnel baseados em rota trabalham na mesma camada que os clientes de VPN, então, para o estado de VPN trusted network, a recomendação é evitar o Tunnel (Route-Based) e deixar que um estado não atrapalhe o outro.

Como detectar a trusted network: prefira o que é estático

A máquina de estados só funciona bem se o sensor dela funcionar bem. Uma trusted network é definida por critérios que o administrador configura, e a recomendação da documentação não deixa dúvida: prefira as propriedades estáticas, ou seja, os servidores DNS que a rede corporativa entrega e os DNS search domains do adaptador, à propriedade dinâmica, a resolução de hostname e IP, em que o ZCC precisa resolver um nome e conferir a resposta. A resolução pode falhar no meio da troca de uma rede para outra; quando isso acontece, o app conclui que está numa rede não confiável e aplica a ação de encaminhamento errada. É uma detecção errada que aparece como "o Zscaler quebrou no do escritório", quando na verdade é uma questão de qual sensor foi escolhido. Combinar servidor DNS com search domain dá o sinal mais confiável, e isso vem direto das boas práticas do próprio fabricante.

O app profile: bypasses, PAC e política de plataforma

O app profile é onde ficam os detalhes de cada plataforma. O recurso mais importante dele no dia a dia da operação é o mecanismo de bypass: os destinos que não podem entrar no túnel. O caso clássico é a convivência com o gateway de VPN: a lista de bypass de VPN gateway do perfil aceita endereços, sub-redes ou FQDNs, e as ressalvas da documentação são do tipo que só aparece depois de muito sofrimento em campo. Os FQDNs são resolvidos quando o túnel sobe, então um nome que depois passar a resolver para outro endereço pode sair do bypass (prefira IPs e sub-redes); listas longas de FQDNs atrasam a subida do túnel, porque cada nome é resolvido antes; e, no Z-Tunnel 1.0 e no Tunnel with Local Proxy, os subdomínios dos FQDNs da lista também entram no bypass, a menos que uma opção diga o contrário. O mesmo perfil traz as referências a arquivos PAC que orientam a escolha do proxy na hora de encaminhar, e itens da plataforma, como a instalação do certificado raiz da Zscaler: cada um é um ajuste pequeno com um impacto enorme.

Os bypasses por processo e por aplicação levam a mesma ideia para softwares que nunca vão aceitar um proxy inline; os agentes com certificate pinning são os casos clássicos dessa lista, por motivos que os padrões do artigo sobre identidade e a história da inspeção TLS deixam previsíveis.

Como um operador analisa um problema de ZCC

A ordem do troubleshooting sai da própria arquitetura: primeiro, em que estado de rede o agente acha que está (o sensor); depois, que ação de encaminhamento o perfil define para esse estado (o caminho do tráfego); depois, quais bypasses afetaram este destino (as exceções); e só então o túnel em si. A maioria dos chamados do tipo "o agente quebrou" cai num dos três primeiros: um critério de detecção que oscilou, um estado ligado a uma ação que ninguém revisou ou uma lista de bypass com uma entrada a mais. Os perfis são documentos pequenos; a disciplina está em saber qual deles responde pelo sintoma.