FortiOS supports two major inspection approaches in firewall policies: flow-based inspection and proxy-based inspection. Both can apply security controls to allowed traffic, but they process sessions differently and expose different feature behavior. The correct choice depends on the security profile, protocol, performance goal, and operational requirement.
For the NSE 4 FortiOS 7.6 Administrator, the main distinction is architectural. Flow-based inspection analyzes traffic as it passes through the FortiGate. Proxy-based inspection reconstructs and proxies application content so it can perform deeper application-level handling. Neither mode is “always more secure” or “always faster” in every design.
Flow-based inspection analyzes traffic in the forwarding path
Fortinet describes flow mode as inspecting content using pattern matching without placing a full application proxy in the middle of the session. The IPS process and related inspection engines can analyze applicable security content as packets move through the device.
This design fits environments that want strong inspection with a streamlined traffic path. FortiOS uses flow mode as the default inspection mode in common firewall-policy workflows, and many widely used security profiles support it.
Because the flow engine can apply several security checks in a coordinated pass, it is well suited to high-throughput scenarios. Hardware acceleration capabilities vary by platform and configuration, so real performance still depends on the FortiGate model, enabled profiles, traffic mix, and SSL inspection.
Proxy-based inspection reconstructs application content
Proxy mode terminates or intermediates supported application conversations at the inspection layer, reconstructs content, and then evaluates that content through proxy-capable security profiles. This architecture can expose controls that depend on deeper buffering or application-level processing.
The tradeoff is more state. Proxy inspection may need to hold and analyze more data before forwarding it, which can affect latency, memory use, and failover behavior. The difference may be small under normal traffic conditions, but workload characteristics matter.
Choose proxy mode because a required feature or inspection behavior needs it, not because “proxy” sounds inherently stronger. Fortinet’s own guidance frames the choice in terms of the features and thoroughness required for the policy.
Security-profile capabilities are not identical between modes
Antivirus, web filtering, IPS, file filtering, email security, data-loss prevention, and other controls may have different availability or options in flow and proxy mode. FortiOS exposes feature-set settings so profiles can be created for the inspection mode they support.
A profile’s mode must align with the firewall policy that uses it. For example, Fortinet notes that a flow-based web-filter profile belongs with a flow-based policy, while a proxy-based profile belongs with a proxy-based policy.
When a setting appears to be “missing” from the GUI, check the selected feature set and inspection mode before assuming the FortiGate version removed it. Some features are also CLI-only or platform-dependent.
SSL inspection can dominate the real performance cost
Most modern application traffic is encrypted. If FortiGate cannot see inside TLS, many content-security controls have limited visibility. SSL inspection therefore often matters more to performance and user experience than the abstract flow-versus-proxy label.
Certificate inspection reads enough of the TLS negotiation to make limited decisions without decrypting the full payload. Deep inspection decrypts, analyzes, and re-encrypts traffic, which requires trusted FortiGate certificates on clients and introduces substantial processing and privacy considerations.
The operational tradeoffs in SSL decryption apply directly: certificate trust, application compatibility, excluded categories, legal considerations, and capacity planning all influence whether inspection succeeds in production.
Proxy mode changes HA session-failover expectations
Fortinet documents an important HA limitation: ordinary pass-through sessions being scanned by proxy-based security profiles do not support standard FGCP session failover because the proxy maintains extensive internal state that is not synchronized between cluster members.
Flow-based sessions have different failover characteristics. This means inspection-mode choice can influence application continuity during an HA event, not just threat detection and throughput.
High-availability design should therefore test the real security profiles used by critical applications. A lab test with uninspected TCP traffic may overstate how smoothly a production proxy-inspected session will survive failover.
Resource-constrained models can limit proxy features
Fortinet notes that some proxy-related features are unavailable on FortiGate models with 2 GB of RAM or less. Hardware platform and FortiOS release therefore matter when designing inspection policy.
Capacity planning should also consider concurrent sessions, encrypted traffic, IPS signatures, antivirus scanning, logging, and other enabled services. An appliance that forwards traffic easily without inspection can behave very differently when deep TLS inspection and multiple security profiles are turned on.
Size the system for the security policy you actually intend to run, not for raw firewall throughput from an unrelated test profile.
Flow mode is often the practical default
For many deployments, flow-based inspection provides the features needed with a straightforward operating model. If the required antivirus, IPS, application control, web filtering, and TLS inspection behavior is available in flow mode, there may be no reason to add proxy state.
This does not mean proxy mode is obsolete. Some organizations need specific proxy capabilities or prefer its content-processing behavior for certain policies. FortiOS allows inspection mode to be selected per policy in supported configurations, which means one firewall can use different approaches for different traffic classes.
That flexibility is useful when a narrow set of applications needs proxy behavior while the majority of traffic can remain flow-based.
Troubleshooting starts by identifying the active mode
When a security profile behaves unexpectedly, confirm the firewall policy’s inspection mode and the profile’s feature set first. Then check whether SSL inspection is allowing the FortiGate to see the content and whether the application protocol is supported by the selected inspection path.
Logs can reveal whether the firewall policy allowed the session while a profile blocked it. Packet capture can show resets or incomplete handshakes, while session diagnostics can show which policy and inspection behavior applied.
Do not respond to every inspection problem by switching modes. A certificate-trust failure, blocked category, incompatible application, or resource limit will not necessarily disappear simply because the policy becomes proxy-based.
Choose inspection mode from requirements
A useful decision process is to list the security controls the policy needs, check which mode supports the required features, consider performance and latency, account for SSL inspection, and include HA behavior in the availability design. Then test with representative applications.
The firewall’s role is to enforce policy and reduce risk, not to maximize the number of inspection features enabled. Applying a heavy profile to traffic that does not need it can consume resources without improving the security outcome.
The FortiGate administrator needs to understand these tradeoffs because inspection mode touches security efficacy, troubleshooting, performance, and HA. Flow and proxy are tools. The better mode is the one that provides the required protection with behavior the application and operations team can support.
Inspection mode also affects how operators interpret packet captures. A proxy-based connection may involve separate client-side and server-side sessions from the perspective of the inspection engine, while flow mode follows the forwarding session more directly. Troubleshooting tools and logs should therefore be read with the active mode in mind.
Protocol support matters. Features that rely on proxy behavior may be strongest for specific application protocols, while unusual or proprietary traffic may receive less benefit. Do not enable a proxy profile based on the policy name alone; verify that the applications traversing the rule are actually supported and that the desired security module can inspect them.
Deep SSL inspection can reveal another class of compatibility issue: certificate pinning, mutual TLS, certificate transparency expectations, or applications that use nonstandard TLS behavior. Exemptions should be narrowly scoped and documented because every bypass reduces visibility for the affected traffic.
Performance tests should use representative file sizes, session counts, TLS versions, and security profiles. A short synthetic benchmark may not expose memory pressure from long-lived proxy sessions or the CPU impact of decryption. Measure latency and throughput during normal operation and during peak concurrency.
Policy segmentation can reduce unnecessary inspection. Traffic between tightly controlled internal services may need a different profile from general web browsing, while high-risk internet destinations may justify deeper inspection. Applying the same maximum-inspection profile to every session is easy to administer but can waste capacity and complicate troubleshooting.
Document why a policy uses flow or proxy mode. Future administrators should know whether the choice is driven by a specific security feature, compatibility requirement, HA behavior, or performance constraint. Without that context, later cleanup projects may switch modes and unknowingly remove a control the original designer depended on.
Mode selection should be reviewed when FortiOS or hardware changes. A feature that once required proxy mode may later be supported differently, while a new platform may have more memory or acceleration. Preserve the security requirement, then reassess whether the historical implementation is still the best way to meet it.
Conversely, avoid changing inspection mode only to chase a benchmark. If proxy mode is required for a business control, the right response may be better sizing, policy segmentation, or hardware rather than silently weakening inspection. Performance engineering should support the security requirement, not redefine it without review.
Security exceptions should have owners and expiry dates. If a business application requires a TLS-inspection bypass or a policy to remain in a less thorough mode, record the reason and review it after application or FortiOS upgrades. Temporary compatibility workarounds have a habit of becoming permanent blind spots when nobody owns the decision.
After any mode change, compare logs and detections as well as performance. A migration that improves throughput but changes which web-filter, antivirus, or DLP events are generated can affect SOC workflows and compliance evidence. Validate the complete security outcome before declaring the new inspection path equivalent.