What is an App Connector?
An App Connector is the software component of Zscaler Private Access (ZPA) that runs in the internal network close to the applications and brokers access for authorised users to those applications. The connector only ever opens outbound, TLS-encrypted connections to the ZPA cloud; no inbound firewall ports get opened. When a user reaches an approved app segment, the ZPA cloud joins both sides together: the tunnel from the Zscaler Client Connector on the endpoint, and the App Connector's connection to the application. The application itself stays invisible from the internet. App Connectors are organised into groups and run redundantly; their health is a key factor in ZPA availability.
App Connector in detail
The App Connector is deployed as a virtual machine, as an image in public clouds, or as a package or container on Linux. A provisioning key binds it to your own ZPA tenant and assigns it to a connector group; app segments link to these connector groups through server groups, which fixes which connectors can reach an application. The connector resolves the applications' internal names itself, so it needs working internal DNS and a network route to the application.
For stable operation, at least two App Connectors per group is standard, so updates and outages do not interrupt access. The connectors report health data to the ZPA cloud, including load and reachability. Maintenance mainly means keeping an eye on capacity, keeping the operating system and connector software up to date, and aligning placement with the topology.
Why App Connectors matter in Zscaler operations
In ZPA operations, the App Connector is the link to check first when several users cannot reach the same application. The diagnostic chain runs: user and client, access policy, app segment, connector. If a connector is overloaded, offline, or cannot resolve the application, it looks like an application outage even though the policy and client are correct. Without visibility into this chain, the helpdesk escalates every case to the ZPA team as a matter of course.
Capacity planning matters for operations too: as user numbers grow or data-intensive applications get added, connector groups need to grow with them. Updates need planning so that redundancy is preserved. For evidence purposes, what counts in the end is that the access path to critical applications is documented: which segments run over which groups, and how their health is monitored.
Common sources of error
- Single connector with no redundancy: every maintenance window and every fault immediately becomes an application access outage.
- DNS gaps: if the connector cannot resolve internal names, the application stays unreachable even though the policy is correct.
- Blocked egress: firewalls that restrict the connector's outbound connections cut off its link to the ZPA cloud.
- Wrong group assignment: an app segment points to a connector group that cannot reach the application on the network at all, for example after a move to the cloud.
App Connectors in practice: what CentaurNexus contributes
CentaurNexus makes the ZPA chain tangible for support: Connectivity Triage Map pulls together the ZDX chain and the policy status and names the cause in plain language, whether the problem sits with the ISP, Wi-Fi, device, or Zscaler. User Support Center gives the helpdesk a 360-degree user finding across ZIA, ZPA, and ZDX, showing which segments and access rights affect a user, without Zscaler admin rights. Whether the cause lies with the App Connectors themselves is shown by Connector Status Overview, a read-only view of status, version, and upgrade state for the app and cloud connectors, so a failed or outdated connector stands out before it lands in a ticket as a vague application fault. That makes it possible to tell whether a single user is affected or a whole application, before anyone escalates. The guide below shows how this triage takes minutes: Is it Zscaler or the Wi-Fi?.
Related terms
Frequently asked questions about App Connector
ZPA does not connect directly from the internet to the application. The App Connector runs close to the application and opens outbound connections to the ZPA cloud, where the user side and the application side get joined together. That keeps internal applications invisible from the internet, and no inbound firewall ports need to be opened.
No. The connector always initiates connections outbound itself, typically TLS-encrypted into the ZPA cloud. What is needed is outbound access towards Zscaler, plus internal network access to the applications and to internal DNS. Zscaler documents the exact egress requirements and destination addresses in the Help Portal.
The right number depends on user count, data volume, and the topology of the environment. As a rule of thumb: at least two connectors per group for redundancy, plus extra capacity for load peaks and updates. Sites with their own applications, such as a data centre, cloud VPC, or plant, usually get their own groups close to the applications.
The App Connector establishes the connection to the application; it is the application-side component. A Private Service Edge, by contrast, brings the ZPA cloud's brokering function closer to users, for example at large sites. The two complement each other: the service edge brokers, the connector provides the path to the application.
A typical pattern: several users report the same application, other applications work fine, and the affected segments all hang off the same connector group. That is when it is worth checking connector status, load, and DNS resolution. If only a single user is affected, the cause is more likely to be the client, the network, or the policy.
- Zscaler Help Portal: ZPA documentation, help.zscaler.com/zpa
- Zscaler Help Portal: About App Connectors - help.zscaler.com/zpa/about-connectors
- NIST SP 800-207: Zero Trust Architecture, csrc.nist.gov/pubs/sp/800/207/final
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.