A FortiGate that begins dropping sessions under load can resemble a firewall with the wrong policy. Users may lose a subset of applications, proxy-based inspection can behave differently, and an overloaded management interface can make diagnostics slower just when evidence matters most. Changing the allow rule because the outage looks like a policy denial risks missing the real fault: the appliance is protecting itself against dangerously low available memory.

The Fortinet NSE 4 – FortiOS 7.6 Administrator exam lists resource problems, high CPU/memory usage, memory conserve mode and connectivity diagnosis under deployment and system configuration. This is a distinct task from reading a packet capture or configuring a firewall rule. Fortinet’s 7.6 exam objectives still cover it, although newer FortiOS versions exist and may expose differing defaults.

Consider a fictional company with a smaller FortiGate handling many concurrent web sessions. Users report that some new connections stop, while established sessions sometimes continue. The team sees a log indicating memory conserve mode. Before reducing inspection or increasing memory thresholds, the operator must establish what the appliance was doing and which setting or workload caused the pressure.

Distinguish system load from a failed forwarding decision

A conventional policy failure often appears as a predictable mismatch for a particular source, destination or service. Memory pressure can affect many unrelated sessions at once, especially during a peak period or after a change that expands inspection work. A high CPU reading is not the same as exhausted memory; both deserve measurement but have different consequences and remedies.

Check resource observations alongside the incident time. FortiOS supports commands such as get system performance status to review appliance resources and diagnose hardware sysinfo conserve to examine conserve-mode state. Fortinet’s 7.6 conserve-mode documentation provides fields for memory used, freeable and configured thresholds. Read values for the actual platform before interpreting them; a sample from a different model is not proof of this unit’s condition.

Identify whether new sessions, existing sessions or management access are affected. A user who can maintain an existing connection while new requests fail gives different evidence from a user whose service is entirely offline. Also identify the traffic’s inspection mode and whether the affected functions require a proxy. These details narrow the appropriate diagnostics without prematurely changing security posture.

Understand red, green and extreme thresholds

FortiOS uses configurable memory-use thresholds. The red threshold marks entry into conserve mode, the green threshold governs exit once memory use has fallen sufficiently, and the extreme threshold relates to more severe behavior such as dropping new sessions. In Fortinet’s FortiOS 7.6 documentation, illustrative defaults are red 88%, green 82% and extreme 95%, but actual settings and supported model behavior must be read from the device.

The separation between red and green helps avoid rapid mode changes when memory fluctuates near one boundary. If conserve mode enters during a workload spike and leaves soon afterward, the incident may still be serious: the user experience and inspection continuity depend on which sessions were affected. Persistent conserve mode is an urgent signal to find the source of consumption rather than repeatedly rebooting the appliance without a diagnosis.

Do not treat threshold increases as a normal capacity-tuning solution. Moving the red threshold upward can simply delay protective behavior until even less memory is available. A production change needs current Fortinet guidance, model-specific capacity evidence and review of its impact on security services. The correct response often targets the workload, software defect, session growth or device sizing rather than hiding the alarm.

Inspect what proxy-based security profiles do

Conserve mode can change the behavior of traffic inspected by the antivirus proxy. Fortinet documents an av-failopen behavior setting with options that determine whether affected proxy traffic is bypassed or blocked in specific conditions. Those options create explicit availability-versus-security tradeoffs; they must not be changed casually during an incident just to reduce help-desk tickets.

The choice between flow and proxy inspection behavior changes which inspection components consume resources and where a session can be affected by proxy pressure. When FortiGate enters conserve mode, identify the actual traffic using proxy-based processing and determine whether the configured fail-open or fail-close behavior applies. A general memory percentage without inspection-path and session evidence is insufficient to explain why one flow failed while another continued.

A bypass may preserve access while reducing specific security inspection; a blocking policy may protect security controls while interrupting applications. Neither is automatically appropriate for an organization. Record the approved requirements for confidentiality, malware inspection and service continuity before recommending a setting, and always confirm how the selected FortiOS build implements it.

Find the real source of resource consumption

A sudden memory increase can follow high session volume, a legitimate traffic spike, expanded proxy inspection, a software defect or a configuration change. A sample CPU graph that rises in the same minute does not identify the cause by itself. Compare the change window with memory, session count and known resource-heavy components. Check if only one process is increasing or if total session and inspection demand is growing across the appliance.

Fortinet’s CLI troubleshooting reference distinguishes commands for CPU profiling and WAD/proxy diagnostics and notes that real-time debugging can be CPU intensive. Unfiltered tracing during a memory crisis can worsen conditions. Use approved narrow observation windows, capture needed evidence and disable temporary debug promptly.

A maintenance response might involve reducing an unintended flood of connections, reversing a known defective configuration, isolating a resource leak under vendor guidance or moving load to a correctly sized device. None of these conclusions follows from conserve mode alone. Use evidence to identify which hypothesis is supported and which remains untested.

Read traffic, system events and crash evidence together

System events can record when memory conserve mode begins or ends, while firewall traffic logs describe the sessions that were logged under their configured policy. A log showing entry into conserve mode near the complaint time is relevant correlation, but it does not automatically prove that every failed application connection was dropped for that reason.

Fortinet’s conserve-mode documentation includes execute log filter category 1, execute log display and diagnose debug crashlog read for specific evidence views. These should be used within the supported device context and with authorization. A lack of local logs could reflect storage or configured forwarding decisions, not absence of the event. Preserve timestamps and compare them to collector and monitoring views.

Use packet sniffer and debug flow only after narrowing the suspected traffic by interface, address, port and time window. A sniffer can show that packets arrive or leave; debug flow can help interpret policy or routing decisions for controlled test traffic. Neither by itself identifies the process causing memory growth. Start with lower-impact resource observations and use packet-level diagnostics to test a specific forwarding hypothesis.

Build an incident timeline before changing settings

Use a safe synthetic exercise rather than intentionally exhausting a production firewall. Construct a timeline with resource measurements, peak sessions, entry into conserve mode, first user complaint and policy or firmware changes. Ask which observations support a real resource problem and which could instead indicate WAN failure or a remote application issue.

Different firewall symptoms demand different first observations. In a synthetic three-case comparison, a policy mismatch should produce a rule-match or denial decision, a correctly permitted session with an unreachable destination calls for routing and upstream reachability evidence, and a conserve-mode incident calls for actual memory thresholds, conserve-state logs, session symptoms and the affected inspection path. Check those observations before proposing any policy edit or threshold change; raising the red threshold is not a safe default repair. A third-party FortiOS 7.6 memory-conserve practice case is useful when the candidate selects a discriminating observation and a reversible next diagnostic for each situation. This is independent preparation, not Fortinet exam registration or the result of an executed device test.

The final incident note should include model/build, memory used and threshold settings, mode state, number of active/new sessions affected, inspection path, relevant system logs, contributing workload and the authorized recovery action. Repeat a controlled permitted and blocked traffic test afterward to confirm that security policy and service availability are both acceptable. No production FortiGate performance experiment or conserve-mode trigger was executed in preparing this article.