# Netskope steering decision explainer > Paste a compact steering spec - mode, tunnel state, Fail Close, dynamic location, one flow, and the exceptions it matches - and walk the documented decision order to a verdict: steered, bypassed, blocked, or direct, with the why-ledger. Where the docs publish no rule (cross-family exception precedence), it says so instead of inventing one. - Tool: https://ronutz.com/en/tools/netskope-steering-decision-explainer - Family: Networking --- # Netskope steering decision explainer Paste a compact description of a steering configuration and one flow, and walk the documented decision order to a verdict - **steered**, **bypassed**, **blocked**, or **direct** - with a ledger explaining every check along the way. This is a why-explainer, not a simulator: each step in the ledger cites documented behavior, and where the public documentation publishes no rule, the ledger says so instead of inventing one. ## The grammar Key–value lines, one decision input per line: ``` mode: web # cloud-apps | web | all dynamic: on # optional; then mode-on-prem / mode-off-prem (none allowed) location: off-prem # on-prem | off-prem tunnel: up # up | down fail-close: off # on | off flow: web app.example.com # web | app | non-web | rfc1918 | loopback non-standard-port: ip # optional; fqdn | ip - how a non-standard web port is reached exception: domain *.example.com # 0+ lines; kinds: cert-pinned, domain, category, dest-location, firewall-app flow-matches: domain # which configured exception kinds this flow matches (or none) ``` The `flow-matches` line is deliberate honesty: whether a real flow matches a category or a destination-location object depends on tenant data this local tool cannot see, so you declare the match and the engine explains the documented consequence. ## What the ledger knows The three traffic modes and who each is for (Cloud Apps Only for Cloud Inline/CASB-only, Web Traffic for most organizations, All Traffic for Cloud Firewall subscribers). The always-on default bypass of RFC1918 space. The exception families and their documented behaviors - including the certificate-pinned family's per-profile **Steer and decrypt at Netskope Cloud** opt-in, the one match that steers instead of bypassing. Dynamic steering's per-location modes, including **None**: no tunnel, and exceptions not processed. **Fail Close**'s documented split: domain-based, IP-based, and cert-pinned exceptions are still applied while category-based exceptions are blocked. And the non-standard-port pitfall: an FQDN-configured port reached by IP address is treated as non-web, with the documented remedy of configuring both. ## Where it hands off A **steered** verdict is where the next decision begins - whether the session is decrypted belongs to the TLS policy, and [the inline TLS decryption article](https://ronutz.com/en/learn/netskope-inline-tls-decryption) picks up exactly there. The steering landscape itself - Client, explicit proxy and PAC, tunnels, reverse proxy - is [the steering methods article](https://ronutz.com/en/learn/netskope-steering-methods); the PAC layer has [its own explainer](https://ronutz.com/en/tools/pac-file-explainer). ## Sources - Netskope docs: Configure a Steering Profile - modes, default bypasses - Netskope docs: Creating a Steering Configuration - Fail Close, non-standard ports - Netskope docs: Enabling Dynamic Steering - per-location modes, None semantics - Netskope docs: Certificate Pinned Applications - steer-and-decrypt ## Standards and references - [Netskope docs: Configure a Steering Profile - the three traffic modes and their audiences; RFC1918 always bypassed by default; the Netskope-maintained cert-pinned bypass list](https://docs.netskope.com/en/configure-a-steering-profile) - traffic modes (Cloud Apps Only / Web Traffic / All Traffic), default bypasses, exception surface - [Netskope docs: Creating a Steering Configuration - Fail Close behavior (domain/IP/cert-pinned exceptions applied, category exceptions blocked); the non-standard-port-accessed-by-IP pitfall and its FQDN+IP remedy](https://docs.netskope.com/en/creating-a-steering-configuration) - Fail Close split, non-standard web ports, dynamic-toggle exception-loss warning - [Netskope docs: Enabling Dynamic Steering - On-Premises Detection Profiles, per-location traffic modes including None (no tunnel, exceptions not processed), per-location firewall/category exception sets](https://docs.netskope.com/en/enabling-dynamic-steering) - dynamic steering semantics - [Netskope docs: Certificate Pinned Applications - per-profile exception actions including Steer and decrypt at Netskope Cloud](https://docs.netskope.com/en/certificate-pinned-applications) - cert-pinned exception actions and the steer-and-decrypt opt-in ## Related reading - [Netskope Steering Methods: Getting Traffic to the Cloud That Inspects It](https://ronutz.com/en/learn/netskope-steering-methods.md): A cloud security platform inspects nothing until traffic reaches it, which is why 'traffic steering' anchors every Netskope blueprint. The full menu: the Netskope Client's per-device tunnel, explicit proxy and PAC files, GRE and IPsec tunnels from sites, reverse proxy for unmanaged devices, and the honest decision logic - who owns the device, where the user is, and what traffic classes need inspecting - that picks among them.