--- title: "診断割り込み" slug: "server-ts-interrupt-vpc" tags: ["troubleshooting", "vpc", "Server"] updated: 2026-10-20T09:00:48Z published: 2026-10-20T09:00:48Z canonical: "guide.ncloud-docs.com/server-ts-interrupt-vpc" --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # 診断割り込み VPC環境で利用できます。 OSの設定によりメモリダンプ(Memory Dump)を取得できる NAVERクラウドプラットフォームの診断割り込みについて説明します。診断割り込みはユーザー CLIと APIを通じて実行でき、診断割り込みを使用するための条件は次の通りです。 - ハイパーバイザおよび OSごとのサポート有無 | ハイパーバイザ | OS | サポート有無 | | --- | --- | --- | | **KVM** | Linux | O | | Windows | O | | **XEN** | Linux | X | | Windows | O | - サーバ外部で NAVERクラウドプラットフォームの API、CLIを使用できる場合 注意 診断割り込みは、サーバに BSOD(ブルースクリーン)を強制的に発生させる機能です。データが消失する恐れがありますので、当該機能の使用にはご注意ください。 参考 - Bare Metal Serverは診断割り込み機能をサポートしていません。 - 作成された Memory Dumpの分析はサポートしていません。 ## 必要状況 診断割り込みが必要な状況は、次の通りです。 - ユーザーアプリケーションに対してメモリダンプ分析が必要な場合 - その他の OSの問題で分析が必要な場合 ## Windows完全メモリダンプのプリセット - KVM & XEN デフォルト設定の場合は「Automatic memory dump」が設定されていますが、この場合は完全メモリダンプが欠落し、アプリケーションのメモリを確認することは困難です。したがって、Windowsで BSODが発生する際にメモリ全体に対してダンプができるように設定し、Pageファイルに対して設定する必要があります。 完全メモリダンプを可能に設定することは OSの性能に大きな影響は与えず、問題が解決された場合に復元しても構いません。ただし、復元する場合、診断割り込み(または BSOD)が発生する際に完全メモリダンプは取得されません。 ### Windowsメモリダンプの設定 Windowsで BSOD発生時に完全メモリダンプができるように設定する方法は、次の通りです。 1. **![i-server_window_start(1)](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/i-server_window_start(1).png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) > ![i-server_setting](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/i-server_setting.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) > System > Advanced system settings > [Advanced]** を順にクリックします。 ![server-diagnostic-interrupt-windows-1](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/server-diagnostic-interrupt-windows-1.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) 2. **System failure**の **Automatically restart**チェックボックスをクリックして選択します。 3. **Startup and Recovery**の **[Settings]** ボタンをクリックし、**Write debugging information**のドロップダウンメニューで **Complete memory dump**を選択します。 ![server-diagnostic-interrupt-windows-2](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/server-ts-intrrupt-windows02_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) 4. ポップアップの **[OK]** ボタンをクリックします。 5. **Write debugging information**の **Overwrite any existing file**チェックボックスをクリックして選択します。 6. **[OK]** ボタンをクリックします。 ### Pagingファイルの設定 Pagingファイルを設定する方法は、次の通りです。 参考 `%SystemRoot%`パーティションは起動システムファイルが存在するパーティションで、そのパーティションに Pagingファイルが存在する必要があります。デフォルトで Windowsをインストールした場合、C:\になります。 1. **![i-server_window_start(1)](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/i-server_window_start(1).png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) > ![i-server_setting](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/i-server_setting.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) > System > Advanced system settings > [Advanced]** を順にクリックします。 2. **Performance**の **[Settings]** ボタンをクリックし、**[Advanced]** タブをクリックして **Virtual memory**の **[Change]** ボタンをクリックします。 ![server-diagnostic-interrupt-windows-3](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/server-ts-intrrupt-windows03_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) 3. **Automatically manage paging file size for all drives**チェックボックスをクリックして選択を解除します。 4. **Custom size**をクリックして選択した後、RAMより大きい C:\の下位に存在するように Pagingファイルサイズを設定します。 - 次の画像は、物理メモリが8GBの場合の設定例です。 ![server-diagnostic-interrupt-windows-4](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/server-ts-intrrupt-windows04_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T17%3A06%3A38Z&se=2026-10-30T18%3A06%3A38Z&sr=c&sp=r&sig=ak3LMXmnBs%2Bcr%2FePMIKjLzJlaxJOQQ2dl21YLBJ7dMg%3D) - Pagingファイルのサイズは、物理的なメモリより少なくとも257MB大きく設定する必要があります。 | サーバの RAM容量 | 推奨 Paging Fileサイズ | | --- | --- | | 4 GB | 4,353MB以上 | | 8 GB | 8,449MB以上 | | 16 GB | 16,641MB以上 | | 32 GB | 33,025MB以上 | | 64 GB | 65,793MB以上 | 5. **[Set] > [OK]** ボタンを順にクリックします。 注意 - メモリダンプは C:\ Windowsに保存されます。C:\ボリュームに最小メモリ容量以上の空き容量がある必要があります。空き容量を十分に確保してください。メモリ容量が大きいサーバの場合、D:\ボリューム(追加ディスク)を活用して2番の手順でダンプファイルの位置を修正してください。 - メモリ容量が大きいサーバの場合、メモリダンプの取得に時間がかかることがあります。 ### 適用 Windowsを再起動することで設定が適用されます。設定の適用が完了すると、診断割り込み発生時に BSODが発生し、この時、完全メモリダンプが取得されます。 参考 Windowsに関する技術的なお問い合わせが必要な場合は、以下をご参照ください。 - [Knowledge Base](https://support.microsoft.com/ko-kr/)の検索と参考 - [コミュニティ](https://answers.microsoft.com/ko-kr)にお問い合わせ - Visual Studioサブスクライバー(旧 MSDNサブスクリプション)の場合、次の方法で MSの公式サポートを受けることができます。 - コールセンター(080-986-1000) - [サブスクライバーポータル](https://my.visualstudio.com/)にお問い合わせ ## Linux完全メモリダンプのプリセット - RHEL系(KVM) RHEL系(RHEL、Rocky Linux、Navix)の OSでは、kdumpを利用してカーネルパニック発生時のメモリダンプを収集します。デフォルト設定では、診断割り込みとして送信された NMI(Non-Maskable Interrupt)をカーネルが処理せず無視するため、診断割り込みを実行する前に、kdumpのインストールおよびカーネルパニックとの連携設定を完了しておく必要があります。 kdumpを設定することは OSの性能に大きな影響は与えず、問題が解決された場合に復元しても構いません。ただし、復元する場合、診断割り込みが発生する際にメモリダンプは取得されません。 注意 プリセットを完了していない状態で診断割り込みを実行すると、ゲスト OSが NMIを無視します。この場合、カーネルパニックとサーバの再起動が行われず、メモリダンプも収集されないため、必ず以下の設定を先に完了してください。 参考 - crashkernel予約メモリの設定は、カーネル起動オプションの変更を含んでいるため、設定を適用するにはサーバを再起動します。 - Windowsの **Overwrite any existing file**のような上書きオプションは提供されないため、診断割り込みを実行するたびにダンプファイルが累積します。ディスク容量の管理が必要な場合、ダンプファイルの累積管理を設定します。 ### kdumpパッケージインストール kdumpの動作に必要な kexec-toolsパッケージをインストールする方法は、次の通りです。 1. 以下のコマンドを実行して、kexec-toolsパッケージをインストールします。 ``` dnf install -y kexec-tools ``` 参考 dnfを提供しない RHEL 7系の場合、`yum install -y kexec-tools`コマンドを使用します。 ### crashkernel予約メモリの設定 kdumpはカーネルパニックが発生するとメモリダンプを収集するために、別途のキャプチャーカーネル(capture kernel)を実行します。キャプチャーカーネルが使用するメモリはサーバ起動時に予め予約する必要があり、予約されたメモリが足りないと、ダンプ収集に失敗します。 以下の2つの方法の中から選択して設定します。 **方法1. RAM容量に応じてカーネルが自動的に予約(推奨)** 1. 以下のコマンドを実行して、RAM区間ごとの予約容量を設定します。 ``` grubby --update-kernel=ALL --args="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M" ``` 1. 上記の設定を適用した場合、サーバの RAM容量に応じて以下のように予約されます。 | RAMの範囲 | 予約容量 | | --- | --- | | 1GB以上、4GB未満 | 192 MB | | 4GB以上、64GB未満 | 256 MB | | 64GB以上 | 512 MB | **方法2. サーバの RAM容量を確認して直接指定** 1. 以下のコマンドを実行して、予約メモリの容量を直接設定します。 ``` grubby --update-kernel=ALL --args="crashkernel=256M" ``` 1. RAM容量ごとに推奨する予約容量は、次の通りです。 | サーバの RAM容量 | 推奨 crashkernelサイズ | | --- | --- | | 4 GB ~ 32 GB | 256 MB | | 64GB以上 | 512 MB | ### カーネルパニックの連携設定 診断割り込みは、サーバに NMIを渡す方式で動作します。RHEL系は原因を特定できない NMIを基本的に無視するため、NMI受信時にカーネルパニックが発生するよう設定します。 1. 以下のコマンドを実行して、カーネルパニックの連携オプションを追加します。 ``` echo 'kernel.unknown_nmi_panic = 1' > /etc/sysctl.d/99-nmi-panic.conf ``` 1. 以下のコマンドを実行して、設定を適用します。 ``` sysctl --system ``` ### メモリダンプの収集範囲を設定 Windowsの **Complete memory dump**と同様にアプリケーションメモリまで確認できるようダンプ収集範囲を設定する方法は、次の通りです。 1. 以下のコマンドを実行して、kdump設定ファイルをエディタで開きます。 ``` vi /etc/kdump.conf ``` 1. ファイル内容から以下の項目を検索して変更するか、項目がない場合は追加します。 ``` path /var/crash core_collector makedumpfile -l --message-level 7 -d 23 ``` 1. 各項目についての説明は、次の通りです。 | 項目 | 説明 | | --- | --- | | `path /var/crash` | メモリダンプファイルを保存するパス | | `-l` | ダンプファイルを lzo形式に圧縮 | | `--message-level 7` | ダンプ収集プロセスの詳細ログを出力 | | `-d 23` | ダンプから除外するページを指定。0で埋められたページ、キャッシュページ、キャッシュプライベートページ、使用しない(free)ページを除き、ユーザープロセスメモリは含めるため、アプリケーションのステータスを確認できます。 | ### ダンプファイルの累積管理 Windowsは上書き設定(**Overwrite any existing file**)を通じて常に直近のダンプファイル1つのみを維持しますが、Linux系は診断割り込みを実行するたびにダンプファイルが累積されます。ディスク容量の管理が必要な場合、以下のように保管期間を設定します。 1. 以下のコマンドを実行して、設定ファイルをエディタで開きます。 ``` vi /etc/tmpfiles.d/kdump-cleanup.conf ``` 1. 以下の内容を追加します。アクセス時間や変更時間が30日を超過したダンプファイルが削除されます。 ``` e /var/crash - - - 30d ``` ### kdumpの有効化と適用 設定内容を適用する方法は、次の通りです。 1. 以下のコマンドを実行して、kdumpサービスを有効にし、起動します。 ``` systemctl enable --now kdump ``` 1. 以下のコマンドを実行して、kdumpサービスのステータスを確認します。 ``` kdumpctl status ``` 1. 以下のコマンドを実行して、サーバを再起動します。crashkernel予約メモリは、再起動後に適用されます。 ``` reboot ``` ### 設定確認 サーバ再起動後にプリセットが正常に適用されたか確認する方法は、次の通りです。 1. 以下のコマンドを実行して、crashkernel予約メモリがカーネル起動オプションに適用されたかを確認します。 ``` cat /proc/cmdline | grep crashkernel ``` 1. 以下のコマンドを実行して、予約メモリが実際に割り当てられたか確認します。 ``` cat /proc/iomem | grep -i "crash kernel" ``` 1. 以下のコマンドを実行して、kdumpサービスが有効になっているか確認します。 ``` systemctl is-enabled kdump kdumpctl status ``` 1. 以下のコマンドを実行して、カーネルパニックの連携オプションが適用されたか確認します。値が `1`で出力される必要があります。 ``` sysctl kernel.unknown_nmi_panic ``` ### メモリダンプファイルの確認 診断割り込みを実行した後にメモリダンプが正常に収集されたか確認する方法は、次の通りです。 1. 診断割り込み実行時にサーバコンソールに以下のようなカーネルパニックメッセージが出力されるか確認します。 ``` Uhhuh. NMI received for unknown reason 30 on CPU 0. Kernel panic - not syncing: NMI: Not continuing CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted ``` 1. サーバを再起動して運用中ステータスになると、サーバにアクセスして以下のコマンドを実行し、ダンプディレクトリを確認します。ダンプは `<수집 IP>-<수집 일시>`形式のディレクトリに保存されます。 ``` ls -al /var/crash/ ``` 1. 以下のコマンドを実行して、ダンプファイルが作成されたか確認します。 ``` ls -al /var/crash/127.0.0.1-2026-08-04-20:20:11/ ``` 1. 作成されるファイルは次の通りです。 | ファイル | 説明 | | --- | --- | | `vmcore` | 収集されたメモリダンプファイル | | `vmcore-dmesg.txt` | カーネルパニック時のカーネルログ | | `kexec-dmesg.log` | ダンプ収集に使用されたキャプチャーカーネルの起動ログ | 参考 NAVERクラウドプラットフォームは、メモリダンプファイルについての分析は行いません。収集された `vmcore`ファイルは、`crash`ユーティリティなどの別途のツールを使用して分析します。 ## Linux完全メモリダンプのプリセット - Ubuntu系(KVM) Ubuntu系の OSは、kdump-toolsを利用してカーネルパニック発生時のメモリダンプを収集します。デフォルト設定では、診断割り込みとして送信された Non-Maskable Interrupt(NMI)をカーネルが処理せず無視するため、診断割り込みを実行する前に、kdump-toolsのインストールおよびカーネルパニックの連携設定を完了しておく必要があります。 kdumpを設定することは OSの性能に大きな影響は与えず、問題が解決された場合に復元しても構いません。ただし、復元する場合、診断割り込みが発生する際にメモリダンプは取得されません。 注意 プリセットを完了していない状態で診断割り込みを実行すると、ゲスト OSが NMIを無視します。この場合、カーネルパニックとサーバの再起動が行われず、メモリダンプも収集されないため、必ず以下の設定を先に完了してください。 参考 - カーネル起動オプションが変更されるため、設定を適用するにはサーバを再起動する必要があります。 - Windowsの **Overwrite any existing file**のような上書きオプションは提供されないため、診断割り込みを実行するたびにダンプファイルが累積します。ディスク容量の管理が必要な場合、ダンプファイルの累積管理を設定します。 ### linux-crashdumpパッケージをインストール kdumpの動作に必要なパッケージをインストールする方法は、次の通りです。 1. 以下のコマンドを実行して、linux-crashdumpパッケージをインストールします。 ``` apt update && apt install -y linux-crashdump ``` 1. インストール中に kdump-toolsの使用有無を確認する画面が表示されたら、 **** を選択します。 参考 `linux-crashdump`パッケージは kdump-tools、makedumpfileなど、ダンプ収集に必要な構成要素もインストールします。 ### crashkernel予約メモリの確認 kdumpはカーネルパニックが発生するとメモリダンプを収集するために、別途のキャプチャーカーネル(capture kernel)を実行します。キャプチャーカーネルが使用するメモリはサーバ起動時に予め予約する必要があり、Ubuntu系はパッケージインストール時に予約メモリの設定ファイルが自動的に作成されます。 1. 以下のコマンドを実行して、設定ファイルが作成されたか確認します。 ``` cat /etc/default/grub.d/kdump-tools.cfg ``` 1. 以下のように RAM区間ごとの予約容量が設定されているか確認します。 ``` GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M" ``` 1. 上記の設定を適用した場合、サーバの RAM容量に応じて以下のように予約されます。 | RAMの範囲 | 予約容量 | | --- | --- | | 2GB以上、4GB未満 | 320 MB | | 4GB以上、32GB未満 | 512 MB | | 32GB以上、64GB未満 | 1,024 MB | | 64GB以上、128GB未満 | 2,048 MB | | 128GB以上 | 4,096 MB | 参考 予約メモリ容量の変更が必要な場合、`/etc/default/grub.d/kdump-tools.cfg` ファイルを変更して `update-grub` コマンドを実行し、ブートローダ設定に反映します。 ### カーネルパニックの連携設定 診断割り込みは、サーバに NMIを渡す方式で動作します。Ubuntu系は原因を特定できない NMIを基本的に無視するため、NMI受信時にカーネルパニックが発生するよう設定します。 1. 以下のコマンドを実行して、カーネルパニックの連携オプションを追加します。 ``` cat < /etc/sysctl.d/99-diagnostic-interrupt.conf kernel.unknown_nmi_panic = 1 kernel.panic_on_unrecovered_nmi = 1 kernel.panic_on_io_nmi = 1 EOF ``` 1. 各オプションについての説明は、次の通りです。 | オプション | 説明 | | --- | --- | | `kernel.unknown_nmi_panic` | 原因を特定できない NMI受信時のカーネルパニックが発生 | | `kernel.panic_on_unrecovered_nmi` | 復旧できない NMI受信時のカーネルパニックが発生 | | `kernel.panic_on_io_nmi` | I/O関連 NMI受信時のカーネルパニックが発生 | 2. 以下のコマンドを実行して、設定を適用します。 ``` sysctl --system ``` ### kdumpサービス設定の確認 kdump-toolsサービスのステータスが使用中になっているかを確認する方法は、次の通りです。 1. 以下のコマンドを実行します。 ``` cat /etc/default/kdump-tools | grep USE_KDUMP ``` 1. `USE_KDUMP=1`で出力されているか確認します。値が `0`の場合、`/etc/default/kdump-tools` ファイルをエディタで開き、`USE_KDUMP=1`に変更します。 ### ダンプファイルの累積管理 Windowsは上書き設定(**Overwrite any existing file**)を通じて常に直近のダンプファイル1つのみを維持しますが、Linux系は診断割り込みを実行するたびにダンプファイルが累積されます。ディスク容量の管理が必要な場合、以下のように保管期間を設定します。 1. 以下のコマンドを実行して、設定ファイルをエディタで開きます。 ``` vi /etc/tmpfiles.d/kdump-cleanup.conf ``` 1. 以下の内容を追加します。アクセス時間や変更時間が30日を超過したダンプファイルが削除されます。 ``` e /var/crash - - - 30d ``` ### 適用 設定内容を適用する方法は、次の通りです。 1. 以下のコマンドを実行して、サーバを再起動します。crashkernel予約メモリは、再起動後に適用されます。 ``` reboot ``` ### 設定確認 サーバ再起動後にプリセットが正常に適用されたか確認する方法は、次の通りです。 1. 以下のコマンドを実行して、crashkernel予約メモリがカーネル起動オプションに適用されたかを確認します。 ``` cat /proc/cmdline | grep crashkernel ``` 1. 以下のように予約メモリ区間が含まれて出力されているかを確認します。 ``` BOOT_IMAGE=/boot/vmlinuz-6.8.0-124-generic root=UUID=... ro crashkernel=auto console=ttyS0,115200n8 console=tty0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ``` 1. 以下のコマンドを実行して、kdumpの設定とサービスのステータスを確認します。 ``` kdump-config show kdump-config status ``` 1. 以下のコマンドを実行して、カーネルパニックの連携オプションが適用されたか確認します。3つの項目の値がすべて `1`で出力される必要があります。 ``` sysctl kernel.unknown_nmi_panic kernel.panic_on_unrecovered_nmi kernel.panic_on_io_nmi ``` ### メモリダンプファイルの確認 診断割り込みを実行した後にメモリダンプが正常に収集されたか確認する方法は、次の通りです。 1. サーバを再起動して運用中ステータスになると、サーバにアクセスして以下のコマンドを実行し、ダンプディレクトリを確認します。ダンプは `<수집 일시>`形式のディレクトリに保存されます。 ``` ls -al /var/crash/ ``` 1. 以下のコマンドを実行して、ダンプファイルが作成されたか確認します。 ``` ls -al /var/crash/202608052118/ ``` 1. 作成されるファイルは次の通りです。 | ファイル | 説明 | | --- | --- | | `dump.<수집 일시>` | 収集されたメモリダンプファイル | | `dmesg.<수집 일시>` | カーネルパニック時のカーネルログ | | `linux-image-<커널 버전>-<수집 일시>.crash` | カーネルクラッシュのサマリー情報ファイル | | `kexec_cmd` | ダンプ収集に使用された kexecの実行情報 | 参考 NAVERクラウドプラットフォームは、メモリダンプファイルについての分析は行いません。収集されたダンプファイルは、`crash`ユーティリティなどの別途のツールを使用して分析します。 ## API/CLIの使用方法 APIおよび CLIを介して診断割り込みを使用する方法は、次の通りです。 1. 診断割り込みが[必要な状況](/docs/ja/server-ts-interrupt-vpc#%ED%95%84%EC%9A%94%EC%83%81%ED%99%A9)に該当するか確認します。 2. 次のガイドを参照して APIと CLIを実行します。 - [APIガイド](https://api.ncloud-docs.com/docs/ja/compute-server-interruptserverinstance) - [CLIガイド](https://cli.ncloud-docs.com/docs/ja/cli-server-interruptserverinstance) 3. NAVERクラウドプラットフォームコンソールの VPC環境で、**Menu** > **All Services** > **Compute** > **Server**メニューを順にクリックし、サーバの**設定中**ステータスを確認します。 4. サーバの**再起動**の状態を確認します。 5. サーバの状態が**運用中**に変更されたら、アクセスしてみます。 参考 - API、CLIを実行すると、すぐにサーバに強制割り込みが発生します。 - **[サーバ管理と設定変更] > サーバコンソールのスクリーンショット**機能により、現在の割り込み発生後の進捗状況を確認できます。 - 診断割り込み発生時、正常に再起動が行われない場合、**[強制停止]** ボタンが有効になります。**[強制停止]** 機能についての詳細は、[強制停止と返却](/docs/ja/server-ts-return-vpc)をご参照ください。