Steering decides what the edge can see
No policy applies to traffic that never arrives. Steering is the on-ramp, and the method chosen determines not only whether traffic reaches the service but what the service knows about it when it does.
That is the frame worth holding. The five methods are not five ways of doing the same thing.
The five, and what each one knows
The endpoint client is the recommended method for end-user traffic and the only one that carries user identity and device posture with the flow. It follows the user off the corporate network, which a tunnel from a site cannot. The cost is that it must be deployed and maintained on every device.
An tunnel steers everything leaving a site, including the devices that will never run an agent — printers, appliances, contractor laptops. It preserves the user's private address, which is what makes address-based policy and detailed logging possible. It knows the site, not the person.
A is the same site-level steering without the encryption overhead. Choose it over IPsec on throughput grounds where the path is already trusted, not on convenience grounds.
An explicit proxy points the browser or the operating system at the service. It is the method for legacy and regulated environments and for cases where policy-based routing is not available. It steers what is configured to use it — an application that ignores proxy settings is simply not steered, and nothing announces that.
Proxy chaining forwards from a proxy you already run. It is a migration method: the estate moves without touching every endpoint on the same day. The old proxy stays in the path and stays yours to operate.
The interaction that surprises people
The client detects other steering methods, and by default disables itself when it finds IPsec, or an explicit proxy.
So "we have the client and a tunnel" is not automatically belt and braces. It is one of them, and which one depends on a setting most people have never opened. The client can be configured to keep steering — and there is a third arrangement worth knowing: deploy it alongside the tunnel not to steer, but to provision certificates and supply user identity. The tunnel carries the traffic; the client answers who the user is.
The hard limit
TLS inspection and authentication require the Netskope root and intermediate certificates on the endpoint.
A tunnel from a site carries traffic from devices nobody manages. If the certificate bundle cannot be installed on those devices, the traffic arrives and cannot be decrypted — policy still runs, on metadata. Any rule written as though content were visible will not do what its author believes, and it will look correct in the console.
Two distinctions worth keeping straight
A steering bypass and a do-not-decrypt rule are not the same. The first means the traffic never reaches the service; the second means it arrives and is not opened. Certificate-pinned applications usually need the first, and confusing them produces a policy that appears applied and never ran.
Declaring a non-standard port as web traffic sends it to the proxy and takes it out of cloud-firewall inspection. That is fine for traffic that really is web. For anything else it is a quiet exemption.
And a related question this does not answer
Choosing a method is a design decision. Working out what happens to one specific flow given a steering configuration already in place — modes, exceptions, fail-close behaviour — is a different question, and the steering decision explainer on this site is the tool for it.