FortiGate node メモリ増大｜Bug ID 1227167 の回避策

はじめに

FortiGate を長期間稼働させている環境で、メモリ使用率が徐々に上昇し、ある日 Conserve Mode へ移行して通信品質が低下するという事象が報告されています。プロセス別に確認すると、node プロセスが単独でメモリの大部分を占有しているケースがあり、これは FortiOS の既知不具合 Bug ID 1227167（Memory usage issues caused by the node process）に該当する可能性があります。

本記事では、この既知不具合の内容と影響を受ける FortiOS バージョン、自機での確認手順、そして公式情報に基づく回避策の設定方法と選定基準を整理します。

結論を先に述べると、本不具合は FortiOS 7.4 系・7.6 系の広い範囲に存在する既知不具合であり、2026 年 7 月時点で修正版としての明確な案内は確認できていません。公式リリースノートに記載された回避策は web-svc-auto-restart の有効化ですが、有効化できるバージョンには条件があり、一部バージョンでは CLI コンソールが切断される副作用も報告されています。そのため、稼働中の FortiOS バージョンに応じて回避策を選定することを推奨します。

Bug ID 1227167 の概要と node プロセスの役割

Bug ID 1227167 は、node プロセスに起因するメモリ使用量の問題として、FortiOS のリリースノートの Known Issues（既知の問題）に記載されている不具合です。要約すると、node プロセスが長期稼働に伴いメモリを解放しきれず、装置全体のメモリ使用率を押し上げ、結果として Conserve Mode への移行を誘発するというものです。

リリースノートにおける記載内容

FortiOS 7.6.7 のリリースノートでは、System カテゴリの既知の問題として以下のように記載されています。

参考: FortiOS 7.6.7 Release Notes – Known issues
“Memory usage issues caused by the node process”
（node プロセスに起因するメモリ使用量の問題）
https://docs.fortinet.com/document/fortigate/7.6.7/fortios-release-notes/236526/known-issues

この記載は「New known issues（新規の既知の問題）」ではなく「Existing known issues（既存の既知の問題）」に分類されています。つまり、以前のバージョンで確認された不具合が FortiOS 7.6.7 でも解消されずに残っている状態であり、リリースノート上では回避策（Workaround）として web-svc-auto-restart の有効化が案内されています。回避策の具体的な設定方法と注意点は後述します。

node プロセスが担う役割

node プロセスは、FortiOS 上で Node.js ランタイムとして動作し、主に GUI・Web 管理系の機能を担っています。Fortinet Community の技術記事によると、担当する機能はバージョンによって異なり、FortiOS 6.4 ではレポート管理（Security Fabric・FortiView・Security Rating を含む）、WebSocket、GUI 上の CLI コンソールウィジェットの維持を担当していました。FortiOS 7.0 以降では、これらに加えて HTTP / HTTPS で受信するすべての静的ファイル配信の処理 も node プロセスが担うようになっています（7.0 より前は httpsd プロセスが担当）

つまり FortiOS 7.0 以降の node プロセスは、管理 GUI へのアクセスがあるたびに動作する常駐プロセスであり、担当範囲の拡大に伴いメモリへの影響も大きくなりやすい構造です。GUI をほとんど使わない運用であっても、Security Fabric や Security Rating などのバックグラウンド機能で node プロセスが動作するため、「GUI を開いていないから無関係」とは言い切れない点に注意が必要です。

Conserve Mode への波及

FortiGate は、メモリ使用率が一定のしきい値を超えると、自己保護機能である Conserve Mode へ移行します。Conserve Mode 中は新規セッションの取り扱いなどが制限されるため、ユーザー側からは通信品質の低下として観測されます。

本不具合の問題は、node プロセスという管理系のプロセスが原因でありながら、影響が通信そのものに波及する点にあります。管理 GUI の応答が遅い程度であれば運用への影響は限定的ですが、Conserve Mode への移行は業務通信への影響を意味します。長期稼働により顕在化する性質上、導入直後には問題がなく、数か月後に事象が発生するというパターンが想定されるため、該当バージョンを利用中の場合は事象の発生を待たずに予防的な対処を検討する価値があります。

影響を受ける FortiOS バージョンと自機での確認手順

このセクションでは、Bug ID 1227167 の影響を受けるバージョンの整理と、稼働中の装置で node プロセスのメモリ占有と Conserve Mode の状態を確認する手順をまとめます。

影響を受けるバージョンの整理

公式リリースノートの Known Issues に Bug ID 1227167 の記載が確認できるのは、2026 年 7 月時点で以下のバージョンです。

一方、node プロセスのメモリ増大という事象自体は、Bug ID の記載より前のバージョンでも報告されています。Fortinet Community の技術記事では、FortiOS 7.4.9 で node プロセスの高いメモリ消費が引き続き観測されている旨が記載されているほか、別の技術記事では FortiOS 7.4.8 および 7.6.3 における node プロセスのメモリリークによる Conserve Mode 移行が扱われています。

参考: Technical Tip: High memory usage of node process（Fortinet Community）
“High memory consumption on the Node.js process is still being observed in FortiOS v7.4.9.”
（Node.js プロセスの高いメモリ消費は FortiOS v7.4.9 でも引き続き観測されている）
https://community.fortinet.com/fortigate-3/technical-tip-high-memory-usage-of-node-process-114615

つまり、リリースノートに Bug ID が明記されたバージョンだけが対象という見方は安全側ではなく、7.4 系・7.6 系を長期稼働させている環境全般で、node プロセスのメモリ推移を確認する価値がある と考えられます。なお、本不具合を修正したバージョンについては、2026 年 7 月時点の公式リリースノート上で明確な案内を確認できていません。最新の 7.4.12 / 7.6.7 でも Existing known issues として記載が残っているため、現時点では回避策による運用が前提となります。

現在のバージョンが古く、回避策の適用に合わせてバージョンアップも検討する場合は、関連記事『FortiGate アップグレードパスの確認方法』で経由バージョンの調べ方と所要時間の目安を解説しています。

node プロセスのメモリ占有を確認する

プロセス別のメモリ使用状況は、以下のコマンドで確認できます。いずれも Fortinet Community の技術記事に記載されている確認方法です。

diagnose sys top-mem
diagnose sys top 1 20 1

diagnose sys top の出力では、プロセス名の右側にメモリ使用率（％）が表示されます。以下は同記事に掲載されている出力例です。

Version: FortiGate-400E v6.4.7,build1911,210825 (GA)
Run Time: 43 days, 22 hours and 40 minutes
0U, 0N, 1S, 99I, 0WA, 0HI, 0SI, 0ST; 7852T, 2818F
node        197      S       0.0     31.1

この例では、node プロセス（PID 197）が装置全体のメモリの 31.1％ を使用しています。長期稼働している装置で node プロセスの使用率が突出している場合、本不具合に該当している可能性を疑う判断材料になります。あわせて Run Time（連続稼働時間）にも注目すると、稼働時間とメモリ使用率の相関を把握しやすくなります。

Conserve Mode のしきい値と現在の状態を確認する

FortiGate は、メモリ使用率が memory-use-threshold-red を超えると Conserve Mode へ移行し、memory-use-threshold-green を下回ると解除されます。さらに memory-use-threshold-extreme を超えると、新規セッションの破棄が始まります。公式管理ガイドに記載されている既定値は以下のとおりです。

いずれも総メモリに対する割合で、設定可能な範囲は 70〜97 です。red（88％）と green（82％）の間に差が設けられているのは、しきい値付近でモードの出入りが頻発すること（フラッピング）を防ぐためです。

現在の Conserve Mode の状態と、しきい値の実メモリ換算値は、以下のコマンドで確認できます。

diagnose hardware sysinfo conserve

参考: Conserve mode（FortiOS Administration Guide）
“To control how FortiOS functions when the available memory is very low”
（使用可能なメモリが非常に少なくなったときの FortiOS の動作を制御するため）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/194558/conserve-mode

出力には、Conserve Mode の on / off、総メモリ、使用中メモリ、解放可能（freeable）メモリ、各しきい値の MB 換算値が表示されます。本不具合への該当を判断する際は、「メモリ使用率が red しきい値に近づいているか」と「node プロセスがその主因になっているか」の 2 点をセットで確認する ことを推奨します。メモリ使用率が高くても主因が別プロセス（wad や ipsengine など）であれば、本不具合とは別の要因を調査する必要があるためです。

また、Conserve Mode への移行はイベントログにも記録されます。GUI では Log & Report から、GUI が応答しない場合は CLI の execute log filter category 1 および execute log display でシステムイベントを確認できます。過去に原因不明の通信品質低下があった場合、この方法で Conserve Mode への移行履歴を遡って確認できます。

公式回避策 web-svc-auto-restart の設定と挙動

このセクションでは、リリースノートに回避策として記載されている web-svc-auto-restart の設定方法と、公開情報から確認できる挙動・注意点をまとめます。結論として、この設定は node プロセスのメモリ使用量を契機とした自動再起動を有効化するもので、FortiOS 7.4.11 / 7.6.6 以降で使用できますが、一部バージョンでは CLI コンソールの切断という副作用が知られています。

設定コマンド

リリースノートの Known Issues に記載されている回避策は、以下のコマンドによる有効化です。

config system global
    set web-svc-auto-restart enable
end

参考: FortiOS 7.4.12 Release Notes – Known issues
“Workaround: Enable web-svc-auto-restart by running the command”
（回避策: 次のコマンドを実行して web-svc-auto-restart を有効化する）
https://docs.fortinet.com/document/fortigate/7.4.12/fortios-release-notes/236526/known-issues

このコマンドは FortiOS 7.4.11 および 7.6.6 で追加されたもので、node プロセスのメモリ使用量が高い状態を検出した際に、node プロセスを自動的に再起動します。Conserve Mode のしきい値（装置全体のメモリ使用率）とは別に、node プロセス単体のメモリ使用量を監視する 点が特徴です。装置全体の使用率が red しきい値へ到達する前に node プロセス側で対処が走るため、Conserve Mode 移行の予防として機能します。

運用上の注意点として、このコマンドは隠しコマンドであり、show や CLI の入力補完に表示されません。設定後にコンフィグバックアップを取得しても設定行として現れないため、設定の有無を後から確認しにくい性質があります。適用時は、変更管理の記録（作業手順書やチケット）に設定内容と適用日を明示的に残しておくことを推奨します。

隠しパラメータによるしきい値調整

Fortinet Community の技術記事に対する Fortinet Staff の返信（2026 年 7 月）によると、web-svc-auto-restart を有効化すると、以下の 2 つの隠しパラメータが追加で使用可能になります。いずれも入力補完には表示されません。

web-svc-auto-restart-mem-threshold（単位: MB）

node プロセスの再起動判定に使うメモリしきい値です。設定可能な値は 0 および 100〜500 で、0 を指定した場合はプラットフォームに応じたハードコード値が使われます。

設定値	動作
0（既定）	2 GB メモリモデルは 100 MB、それ以外のモデルは 200 MB のハードコード値を使用
100〜500	指定した MB 値を node プロセスのメモリしきい値として使用

web-svc-auto-restart-time-threshold（単位: 分）

メモリ判定を開始するまでの node プロセスの最小稼働時間です。node プロセスが起動してからこの時間を経過するまでは、メモリしきい値の判定が行われません。起動直後の一時的なメモリ使用でむやみに再起動が繰り返されることを防ぐ位置づけと考えられます。

既定値のままでも回避策としては機能しますが、メモリ搭載量の小さいモデルで Conserve Mode までの余裕が少ない場合など、環境に応じて mem-threshold を引き下げる調整余地があります。ただし隠しパラメータであり公式リファレンスに記載がないため、調整する場合は検証環境での動作確認を経てから適用する ことを推奨します。

副作用: CLI コンソールの Connection Lost

web-svc-auto-restart の適用を判断するうえで、把握しておくべき副作用があります。Fortinet Community の技術記事によると、web-svc-auto-restart enable および後述の web-svc-perf enable を設定した環境では、GUI 上の CLI コンソールが「Connection Lost」のメッセージとともに断続的に切断される事象が知られています。この事象は FortiOS 7.4.12 / 7.6.7 / 8.0.0 で解消済み とされています。

バージョンとの関係を整理すると、以下のようになります。

この整理から、7.4.12 または 7.6.7 まで上げたうえで web-svc-auto-restart を有効化するのが、副作用を含めて最も条件のよい組み合わせ といえます。7.4.11 / 7.6.6 に留まる場合は、GUI 経由の CLI コンソールを日常的に使う運用かどうかが判断材料になります。SSH での CLI アクセスが主体であれば、影響は限定的と考えられます。

web-svc-perf によるメモリ使用状況の記録

再起動の自動化とは別に、node プロセスのメモリ使用状況を継続的に記録するオプションも用意されています。FortiOS 7.4.10 以降および 7.6.5 以降では、以下の設定でログ出力を有効化できます。

config log settings
    set web-svc-perf enable
end

Fortinet Community の技術記事によると、有効化後は diagnose nodejs process restart で node プロセスを再起動することで記録が開始されます。取得したログは、GUI の Log & Report から Web Service Events としてダウンロードできます。回避策の適用前にこのログでメモリの増加ペースを把握しておくと、しきい値調整や後述するスケジュール再起動の間隔設計に根拠を持たせられます。なお、この設定も前述の Connection Lost の副作用の対象であるため、7.4.11 / 7.6.6 以前で常時有効化する場合は同様の注意が必要です。

Conserve Mode 契機とスケジュール契機の自動化

このセクションでは、web-svc-auto-restart が使用できないバージョン（7.4.9 / 7.4.10 など）での代替策と、再起動タイミングを運用側で制御したい場合の設定方法をまとめます。いずれも通常の設定としてコンフィグに残るため、隠しコマンドに依存しない構成を組める点が共通の利点です。

Conserve Mode トリガーによる自動化

FortiGate の Automation Stitch には、Conserve Mode への移行を検知する予定義トリガーが用意されています。公式管理ガイドでは、このトリガーを契機に CLI Script でデバッグ情報を収集し、結果をメール通知する構成例が示されています。

参考: Execute a CLI script based on memory and CPU thresholds（FortiOS Administration Guide）
“an automation stitch is created that runs a CLI script to collect debug information”
（デバッグ情報を収集する CLI スクリプトを実行する Automation Stitch を作成する）
https://docs.fortinet.com/document/fortigate/7.6.1/administration-guide/702937/execute-a-cli-script-based-on-memory-and-cpu-thresholds

この枠組みの CLI Script に node プロセスの再起動を組み込めば、「Conserve Mode へ移行したら node を再起動して自動復旧し、あわせて管理者へ通知する」という動作を実現できます。メール通知を併用することで、回避策が作動した事実を運用側が確実に把握できる 点が、この方式の実務上の価値です。作動の頻度が分かれば、根本対処（バージョンアップ）の優先度判断にも使えます。

node プロセスの再起動には、以下のコマンドを使用します。

diagnose nodejs process restart

このコマンドは、公式 CLI リファレンス（FortiOS 7.6 系および 8.0.0 の diagnose nodejs）に「Node.JS へ SIGKILL を送信して再起動する」操作として記載されています。FortiOS 7.4.10 についても、Fortinet 公式 KB（web-svc-perf の有効化手順）の中で本コマンドによる node 再起動が案内されています。なお、7.4 系の CLI リファレンスでの記載は確認できていないため、7.4 系で使用する場合は事前に検証環境で diagnose nodejs ? によりコマンドの存在を確認する ことを推奨します。

留意点として、この方式は Conserve Mode への移行を検知してから動作するため、性質としては「予防」ではなく「復旧の自動化」です。移行時点で通信品質への影響は一度発生します。影響を未然に防ぎたい場合は、次のスケジュール再起動との併用を検討する余地があります。

auto-script によるスケジュール再起動

メモリが高騰する前に、業務影響の少ない時間帯を選んで定期的に node プロセスを再起動する方式です。Fortinet Community の技術記事では、config system auto-script を使った以下の設定例が示されています。

config system auto-script
    edit restart_node
        set interval 86400
        set repeat 100
        set start auto
        set script 'diagnose nodejs process restart'
    next
end

この例では、24 時間（86,400 秒）ごとに node プロセスを再起動します。ただし、この設定例をそのまま流用する場合、注意すべき落とし穴があります。公式 CLI リファレンスによると、repeat はスクリプトの実行回数であり、0 を指定した場合のみ無限に繰り返されます。

参考: config system auto-script（FortiOS CLI Reference）
“set repeat {integer} Number of times to repeat this script (0 = infinite).”
（set repeat {整数} スクリプトを繰り返す回数（0 = 無限））
https://help.fortinet.com/cli/fos50hlp/56/Content/FortiOS/fortiOS-cli-ref-56/config/system/auto-script.htm

つまり上記の例（set repeat 100）では、約 100 日後にスクリプトの実行が停止します。設定直後は問題なく動作するため停止に気づきにくく、数か月後に Conserve Mode が再発して初めて発覚するという事態になりかねません。恒久的な回避運用として使う場合は set repeat 0 を指定することを推奨します。

interval の設計は、メモリの増加ペースに依存します。前セクションで触れた web-svc-perf ログや、diagnose sys top-mem の定点観測でペースを把握したうえで、増加分が Conserve Mode のしきい値に到達する前に再起動が入る間隔を設定します。間隔内にメモリが想定より早く高騰した場合は防げない という構造上の弱点があるため、間隔は余裕を持たせ、定期的に見直すことを推奨します。

なお、時刻指定（毎週日曜 23 時など）で制御したい場合は、Automation Stitch の scheduled トリガーと CLI Script アクションの組み合わせでも同様の構成が可能です。Automation Stitch の設定手順の詳細は、稿を改めて解説する予定です。

再起動時の影響と避けるべき操作

node プロセスの再起動に伴い、GUI・Web 管理系の機能は一時的に影響を受けます。前述のとおり、FortiOS 7.0 以降の node プロセスは GUI の静的ファイル配信や CLI コンソールを担うため、再起動のタイミングで GUI 操作中の管理者がいた場合、画面の再読み込みや再ログインが必要になる可能性があります。スケジュール再起動の実行時刻は、管理作業が行われない時間帯に設定することを推奨します。

また、node プロセスの停止手段として fnsysctl killall node や、PID を指定した diagnose sys kill も技術的には存在しますが、Fortinet Community の技術記事には killall の実行がシステムを不安定にしうる旨の記載があります。スケジュール実行に組み込むコマンドとしては、公式リファレンスに記載のある diagnose nodejs process restart を第一候補とし、killall 系のコマンドの常用は避ける ことを推奨します。

HA 構成での考慮点

node プロセスは HA クラスタの各メンバー上でそれぞれ独立して動作します。このため、プライマリ機のみで node の再起動が行われる構成では、セカンダリ機の node プロセスのメモリが解放されないまま蓄積し、フェイルオーバー直後に Conserve Mode へ移行する というシナリオが考えられます。

Fortinet Community の技術記事（Automation Stitch によるスケジュール再起動）には、HA 構成でクラスタ全体を対象とする場合は追加の設定が必要である旨が記載されています。HA 環境で本記事の回避策を適用する際は、両系で node プロセスの再起動が行われる構成になっているかを設計段階で確認することを推奨します。HA 構成でのバージョンアップを含めた対処を検討する場合は、関連記事『FortiGate アップグレードパスの確認方法と HA 構成の手順』もあわせて参照してください。

回避策の選定基準と恒久対策の見通し

このセクションでは、ここまで解説した 3 つの回避策の使い分けと、恒久対策であるバージョンアップの考え方をまとめます。結論として、稼働中の FortiOS バージョンによって取れる選択肢が異なるため、まずバージョンを確認し、そのうえで運用要件（GUI の利用頻度、変更管理の制約、HA 構成の有無）に応じて組み合わせを決める流れを推奨します。

3 つの回避策の比較

バージョン別の推奨構成

FortiOS 7.4.12 / 7.6.7 以降の場合

回避策 A の単独適用を推奨します。CLI コンソール切断の副作用が解消されており、node プロセスのメモリ量を直接監視する仕組みとして最も的確に機能するためです。作動状況を把握したい場合は、回避策 B の通知部分（Conserve Mode トリガー ＋ メール通知）を保険として併設する構成も考えられます。

FortiOS 7.4.11 / 7.6.6 の場合

回避策 A を基本としつつ、GUI 経由の CLI コンソールを日常的に使う運用では副作用の影響を評価してから適用を判断します。副作用を避けたい場合は、回避策 C を主軸に置き、回避策 B を最後の砦とする二段構成が代替になります。

FortiOS 7.4.10 以前の場合

回避策 A が使用できないため、回避策 C（予防）と回避策 B（復旧の自動化と通知）の組み合わせを推奨します。あわせて 7.4.10 では web-svc-perf ログが使用できるため、メモリ増加ペースを記録して再起動間隔の設計根拠とすることができます。

いずれの構成でも、隠しコマンドである回避策 A はコンフィグバックアップに現れないため、適用した事実を変更管理の記録に明示的に残す 運用をあわせて推奨します。担当者の交代や障害調査の際に、「なぜこの装置ではメモリが安定しているのか」を追跡できる状態を保つためです。

回避策はあくまで一時的な対処

留意すべき点として、Fortinet の公式 KB では、node プロセスの定期再起動による回避は一時的な対処と位置づけられています。

参考: Troubleshooting Tip: How to enable web service logs in FortiOS v7.4.10, v7.6.5, and v8.0.0（Fortinet Community）
“This workaround should only be used as a temporary measure.”
（この回避策はあくまで一時的な措置としてのみ使用すべきである）
https://community.fortinet.com/fortigate-3/troubleshooting-tip-how-to-enable-web-service-logs-in-fortios-v7-4-10-v7-6-5-and-v8-0-0-221399

同 KB では、恒久的な修正につなげるため、web-svc-perf で取得したログを Fortinet サポートへ共有することが推奨されています。事象が発生した環境では、回避策の適用と並行して、サポート契約の範囲でログの提供とケースの起票を検討する価値があります。

恒久対策の見通し

2026 年 7 月時点で、Bug ID 1227167 は最新の FortiOS 7.4.12 および 7.6.7 のリリースノートにおいても Existing known issues として記載されており、本不具合の修正を明記したバージョンは公式情報から確認できていません。したがって現時点では、修正版のリリースを待ちながら回避策で運用する体制が前提となります。

今後の対応方針としては、以下の 2 点を推奨します。

1 点目は、リリースノートの継続的な確認 です。新しいバージョンがリリースされた際に、Resolved issues（解決済みの問題）に Bug ID 1227167 が記載されているかを確認することで、恒久対策への移行タイミングを判断できます。

2 点目は、バージョンアップ計画への織り込み です。副作用が解消された 7.4.12 / 7.6.7 への更新は、それ自体が回避策 A の適用条件を整える意味を持ちます。なお、FortiGate には設定によって自動アップグレードが行われる仕様があるため、バージョンを固定して回避策を運用したい環境では、関連記事『FortiGate 強制自動アップグレードの仕様と無効化手順』で解説している設定の確認もあわせて推奨します。

まとめ

FortiOS の既知不具合 Bug ID 1227167 は、GUI・Web 管理系を担う node プロセスのメモリが長期稼働で増大し、Conserve Mode 移行による通信品質の低下を招く点が本質です。修正版が確認できない現時点では、バージョンに応じた回避策の選定と、修正版リリースの継続的な確認が現実的な対処となります。

• Bug ID 1227167 は 7.4.11 / 7.4.12 / 7.6.6 / 7.6.7 のリリースノートに記載された既知不具合
• node プロセスのメモリ増大事象は 7.4.8 や 7.6.3 など、より広いバージョンで報告あり
• 公式回避策は web-svc-auto-restart の有効化（7.4.11 / 7.6.6 以降で使用可能）
• 7.4.11 / 7.6.6 では CLI コンソール切断の副作用があり、7.4.12 / 7.6.7 で解消済み
• 7.4.10 以前はスケジュール再起動と Conserve Mode 契機の自動化の併用が現実的
• auto-script の repeat は 0 指定で無限繰り返し、既定例の 100 では約 100 日で停止
• HA 構成では両系で node プロセスの再起動が行われる設計かの確認が必要

以上、最後までお読みいただきありがとうございました。