Linux版Microsoft Defender for Endpointでmdatp connectivity testが失敗し、プロキシ、ファイアウォール、ミラーサーバーのどこを直せばよいか分からない場合は、最初にDefenderのプラットフォームバージョンを確認してください。
Linux版プラットフォーム101.26052.0012では、x64とARM64の対応環境において、接続テストが実際のオフラインセキュリティインテリジェンス更新経路を検証するようになりました。失敗時には、failure type、対象機能、プロキシ検出状態も同じテスト結果内に表示されます。また、URLの照合不一致によって正常な接続が失敗と判定される問題も修正されています。(Microsoft Learn)
実務では、次の順番で確認するのが効率的です。
- Defenderを
101.26052.0012以降へ更新する - オフライン定義更新の設定状態を確認する
mdatp connectivity testを実行する- failure type、対象機能、プロキシ検出状態から原因を絞る
- 修正後に定義更新を実行し、実際に更新できることを確認する
Linux版Defender 101.26052.0012の接続テスト変更点
Microsoft Defender for Endpoint on Linuxの2026年7月版では、接続テストの精度と診断情報が次のように改善されました。
| 変更点 | 実務上の意味 |
|---|---|
| 実際のオフライン更新経路を検証 | テスト用のURLだけでなく、セキュリティインテリジェンス更新で使用する経路に沿って確認できる |
| x64とARM64に対応 | Intel・AMD系サーバーだけでなく、対応するARM64 Linuxでも利用できる |
| failure typeを表示 | 接続失敗の種類を特定しやすくなる |
| affected featureを表示 | どのDefender機能に影響する接続なのかを判断しやすくなる |
| proxy detection statusを表示 | Defenderがプロキシを検出しているか確認しやすくなる |
| URL照合の不一致を修正 | 通信できているのに失敗と表示されるfalse failureを減らせる |
対象となるプラットフォームバージョンは101.26052.0012です。リリースノートには、リリースバージョン30.126052.0012.0、エンジンバージョン1.1.26040.3001、シグネチャバージョン1.449.136.0と記載されています。(Microsoft Learn)
なお、オフラインセキュリティインテリジェンス更新そのものが、このバージョンで初めて追加されたわけではありません。Linux向けのオフライン更新は2026年6月版で一般提供となっており、2026年7月版では主に、その更新経路を接続テストで正確に検証できるようになりました。(Microsoft Learn)
オフライン更新経路とは何か
オフラインセキュリティインテリジェンス更新は、インターネットへの直接接続が制限されたLinuxサーバーへ、ローカルのミラーサーバーを経由してDefenderの定義ファイルを配布する仕組みです。
基本的な通信経路は次のようになります。
Microsoftの配布元
↓
社内のミラーサーバー
↓
Linux版Microsoft Defender for EndpointLinux端末は、HTTP、HTTPS、NFSなどで提供されたミラーサーバーへ接続します。ミラーサーバー側は、Microsoftの配布元から定義ファイルを取得できる必要があります。(Microsoft Learn)
今回の改善で重要なのは、Linux端末側から見た接続テストが、実際のオフライン定義更新と同じ経路を検証するようになったことです。
従来は、接続テストの一部が成功していても、実際に使用する更新経路の問題を見落とす可能性がありました。反対に、URLの照合方法が原因で、通信できている接続を失敗と判定するケースもありました。101.26052.0012では、このようなテスト結果と実際の更新可否のずれを減らす改善が行われています。(Microsoft Learn)
ただし、オフラインセキュリティインテリジェンス更新は、Defender for Endpointのすべてのクラウド通信をミラーサーバーへ置き換える機能ではありません。対象は主にウイルス対策用の定義ファイルであり、EDRテレメトリなどの通信要件は別途確認する必要があります。(Microsoft Learn)
接続テストの前にDefenderのバージョンを確認する
最初に、インストールされているDefenderのプラットフォームバージョンを確認します。
mdatp health --field app_version古いバージョンで--field指定が利用できない場合は、次のコマンドを実行し、出力内のapp_versionを確認します。
mdatp healthapp_versionは、Linux端末上で動作しているMicrosoft Defenderのアプリケーションバージョンを示します。(Microsoft Learn)
表示された値が101.26052.0012未満の場合、接続テストの改善やfalse failureの修正が適用されていません。ファイアウォールやプロキシ設定を大きく変更する前に、可能であればDefenderを更新してください。
ディストリビューション別の更新コマンド
| Linuxディストリビューション | 更新コマンド |
|---|---|
| RHEL、CentOS、Oracle Linux系 | sudo yum update mdatp |
| SUSE Linux Enterprise Server系 | sudo zypper update mdatp |
| Ubuntu、Debian系 | sudo apt-get install --only-upgrade mdatp |
Defender for Endpoint on Linuxは定期的に更新されており、Microsoftは利用可能な修正や機能を受け取るため、最新バージョンの利用を推奨しています。更新チャネルや社内の変更管理ルールがある場合は、検証環境から段階的に展開してください。(Microsoft Learn)
オフライン定義更新の設定状態を確認する
接続テストだけを実行する前に、端末がどの更新元を使用する設定になっているか確認します。
mdatp health --details definitions特に確認したい項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
definitions_status | 定義ファイルが最新か、更新中か、利用不能か |
definitions_update_fail_reason | 前回の更新が失敗した理由 |
definitions_update_source_uri | 実際に定義ファイルを取得した更新元 |
offline_definition_url_configured | 管理設定で指定されているミラーサーバーのURL |
offline_definition_update | オフライン更新が有効になっているか |
offline_definition_update_verify_sig | ダウンロードした定義ファイルの署名検証が有効か |
offline_definition_update_fallback_to_cloud | オフライン更新失敗時にクラウドへフォールバックするか |
オフライン更新を正常に利用するには、offline_definition_updateが有効になっていることに加え、更新成功後のdefinitions_update_source_uriが、設定したoffline_definition_url_configuredと一致しているか確認します。(Microsoft Learn)
たとえば、設定したミラーサーバーが次のURLだったとします。
http://mirror.example.local/linux/production/ところが、definitions_update_source_uriにMicrosoftのクラウドURLが表示されている場合、ミラー経由ではなくクラウドから更新されている可能性があります。フォールバック設定の有無も含めて確認が必要です。
Defender Linuxの接続テストを実行する
接続テストは、次のコマンドで実行します。
mdatp connectivity testこのコマンドは、現在のネットワーク設定を使用して、Defender for Endpointが必要な接続先へ通信できるか検証します。101.26052.0012では、オフラインセキュリティインテリジェンス更新で使用する経路についても、実際の更新処理に沿った検証が行われます。(Microsoft Learn)
新しく確認できる3つの診断情報
接続に失敗した場合は、単にFAILEDと表示された行だけを見るのではなく、次の情報を確認します。
| 診断情報 | 見るべきポイント |
|---|---|
| failure type | どの種類の通信エラーとして分類されたか |
| affected feature | オフライン更新など、どの機能に影響する接続か |
| proxy detection status | Defenderがプロキシを検出した状態でテストしているか |
出力内でオフライン更新機能に関係する失敗が示された場合、一般的なDefenderクラウド接続ではなく、Linux端末からミラーサーバーまでのURL、ポート、名前解決、証明書などを優先して調べます。
プロキシを経由する環境にもかかわらず、プロキシが検出されていないことを示す結果になった場合は、OS全体のプロキシ設定ではなく、Defenderのランタイムプロキシ設定が不足している可能性があります。
接続テストが失敗する主な原因と対処方法
| テスト結果や状況 | 主な確認箇所 | 対処方法 |
|---|---|---|
| 必要なプロキシが検出されていない | Defenderのランタイムプロキシ設定 | mdatp config proxy setで静的プロキシを設定する |
| プロキシは検出されるが接続できない | プロキシの許可先、ポート、匿名通信 | Defender関連URLへの通信を許可する |
| 証明書検証やTLS関連で失敗する | SSL/TLSインスペクション | Defender関連通信を復号・検査対象から除外する |
| オフライン更新機能の経路で失敗する | ミラーURL、DNS、Webサーバー、NFS | Linux端末からミラーへ直接アクセスできるか確認する |
| 接続テストは成功するが定義更新に失敗する | 定義ファイル、署名、更新元設定 | definitions_update_fail_reasonを確認する |
| 古いDefenderだけ失敗する | URL照合のfalse failure | 101.26052.0012以降へ更新して再テストする |
Microsoft Defender for Endpoint on Linuxでサポートされるプロキシ方式には制限があります。基本的に静的プロキシまたは透過型プロキシを使用し、PAC、WPAD、認証付きプロキシはサポートされません。また、SSL/TLSインスペクションや通信を中継して証明書を置き換えるプロキシもサポートされません。(Microsoft Learn)
プロキシが検出されない場合の設定方法
インストール後のDefenderへ静的プロキシを設定する場合は、次のコマンドを使用します。
mdatp config proxy set --value http://address:port設定例は次のとおりです。
mdatp config proxy set --value http://192.0.2.10:8080設定後はDefenderサービスを再起動し、接続テストをやり直します。
sudo systemctl restart mdatp
mdatp connectivity testDefenderのインストール時に使用するパッケージマネージャーのプロキシと、インストール後にDefender本体が使用するランタイムプロキシは別に扱われる場合があります。「インストールは成功したがDefenderの通信だけ失敗する」という場合は、インストール後の静的プロキシ設定を確認してください。(Microsoft Learn)
プロキシが検出されても失敗する場合
プロキシが検出されているのに接続できない場合、設定値そのものよりも、プロキシ側のアクセス制御を確認します。
主な確認項目は次のとおりです。
- Defenderの必要な接続先が許可されているか
- プロキシが接続先URLをカテゴリ判定などで遮断していないか
- 認証を要求していないか
- SSL/TLS通信を復号していないか
- Linux端末とプロキシ間で名前解決やルーティングが成立しているか
Defender for Endpointの必要なURLに対して、プロキシやファイアウォールが匿名の送信通信を許可する必要があります。(Microsoft Learn)
curlでプロキシ経由の通信を補助確認する
Microsoftのトラブルシューティング手順では、静的プロキシ環境で次のようなcurlによる確認方法も案内されています。
curl -x http://proxy_address:port \
-w ' %{url_effective}\n' \
'https://x.cp.wd.microsoft.com/api/report' \
'https://cdn.x.cp.wd.microsoft.com/ping'ここで指定するプロキシアドレスとポートは、Defenderに設定したものと同じ値を使用します。このテストが失敗する場合は、Defender固有の問題ではなく、プロキシ、ファイアウォール、DNS、TLS処理などのネットワーク側に問題がある可能性が高くなります。(Microsoft Learn)
SSL/TLSインスペクションによる失敗を確認する
Defender for Endpoint on Linuxは、SSL/TLSインスペクションをサポートしていません。
プロキシや次世代ファイアウォールがHTTPS通信を一度復号し、組織内の認証局で発行した証明書へ差し替えている場合、次のようなエラーが発生することがあります。
| エラー例 | 想定される状態 |
|---|---|
curl error 35 | TLSセッションの確立失敗 |
curl error 60 | サーバー証明書の検証失敗 |
CERTIFICATE_VERIFY_FAILED | 証明書チェーンが置き換えられている |
HTTP 502 Bad Gateway | プロキシやファイアウォールでTLS通信が中断された |
端末の信頼済み証明書ストアへ組織の証明書を追加するだけでは、Defenderの通信を正常化できない場合があります。Defender関連ドメインをSSL/TLSインスペクションの対象外にし、通信をそのまま通過させる必要があります。(Microsoft Learn)
設定変更後は、次の順番で再確認します。
sudo systemctl restart mdatp
mdatp connectivity testオフライン更新経路だけが失敗する場合
affected featureがオフラインセキュリティインテリジェンス更新に関係している場合は、クラウド側の接続先ではなく、ミラーサーバーを中心に確認します。
Linux端末側で確認する項目
offline_definition_url_configuredのURLに誤字がないか- URL末尾のパスやスラッシュが正しいか
- Linux端末からミラーサーバーを名前解決できるか
- HTTPまたはHTTPSポートへ接続できるか
- NFSを利用している場合は共有先を参照できるか
- HTTPSの場合は証明書の名前とホスト名が一致しているか
- ミラーサーバー上に対象アーキテクチャ向けのファイルが存在するか
Microsoftのトラブルシューティング手順では、definitions_update_source_uriとoffline_definition_url_configuredが一致していることも確認項目に含まれています。(Microsoft Learn)
ミラーサーバー側で確認する項目
接続テストが成功しても、ミラーサーバー側のダウンロード処理が停止していれば、新しい定義ファイルは配布されません。
次の点も別途確認してください。
- 定義ダウンロード用スクリプトが定期実行されているか
- 最終成功日時が古くなっていないか
- ミラーサーバーのディスク容量が不足していないか
- Microsoftの配布元へ接続できるか
- 配布ディレクトリの権限が正しいか
- WebサーバーやNFSサービスが動作しているか
ミラーサーバーにはDefender本体をインストールする必要はありませんが、Microsoftの定義配布元へ接続し、ダウンロードしたファイルをLinux端末へ提供できる状態が必要です。(Microsoft Learn)
接続テスト成功後に実際の定義更新を確認する
mdatp connectivity testが成功しただけでは、定義ファイルの更新処理まで成功したとは限りません。
接続テスト成功後は、手動更新を実行します。
mdatp definitions update続いて、更新状態を確認します。
mdatp health --details definitions正常な場合は、少なくとも次の状態を確認します。
definitions_status : "up_to_date"
definitions_update_fail_reason : ""オフライン更新を使用している場合は、次の項目も確認してください。
offline_definition_update : "enabled"
definitions_update_source_uri : 設定したミラーサーバー
offline_definition_url_configured : 設定したミラーサーバーMicrosoftの公式手順でも、接続テストが成功した後にmdatp definitions updateを実行し、mdatp health --details definitionsで結果を確認する流れが案内されています。(Microsoft Learn)
false failureを避けるために監視方法も見直す
今回のURL照合修正により、古いバージョンで失敗していた接続テストが、101.26052.0012以降では成功する可能性があります。
そのため、複数のLinuxサーバーを監視している環境では、次の点に注意してください。
プラットフォームバージョンをそろえる
同じネットワークにある端末でも、Defenderのバージョンが異なると接続テスト結果が一致しない可能性があります。
障害調査では、ネットワーク設定だけでなく、各端末のapp_versionも記録してください。
出力文字列の完全一致に依存しすぎない
failure type、対象機能、プロキシ検出状態が追加されたことで、接続テストの出力形式が以前と変わる可能性があります。
監視スクリプトを作成している場合は、出力全体の完全一致ではなく、成功・失敗の判定や必要な項目を検証環境で確認したうえで処理してください。
x64とARM64の両方を検証する
x64とARM64を混在させている場合は、アーキテクチャごとに少なくとも1台ずつ接続テストと定義更新を実行します。
接続経路が同じでも、ミラーサーバー上の配置ファイルやディレクトリ構成がアーキテクチャによって異なる場合があります。今回の接続テスト改善は対応するx64とARM64プラットフォームが対象です。(Microsoft Learn)
接続障害を最短で切り分ける確認手順
Linux版Defenderの接続テストが失敗した場合は、次の順番で調べると不要な設定変更を避けられます。
# 1. Defenderのバージョン確認
mdatp health --field app_version
# 2. 定義更新設定と前回の失敗理由を確認
mdatp health --details definitions
# 3. 接続テストを実行
mdatp connectivity test
# 4. 必要に応じて静的プロキシを設定
mdatp config proxy set --value http://address:port
# 5. 設定変更後にサービスを再起動
sudo systemctl restart mdatp
# 6. 接続テストを再実行
mdatp connectivity test
# 7. 実際の定義更新を実行
mdatp definitions update
# 8. 更新結果を確認
mdatp health --details definitions最も重要なのは、古いプラットフォームの接続テスト結果だけを根拠に、ファイアウォールやプロキシの許可設定を追加し続けないことです。
まず101.26052.0012以降へ更新し、新たに表示されるfailure type、対象機能、プロキシ検出状態を確認します。その後、ミラーサーバー、静的プロキシ、SSL/TLSインスペクション、更新元URLの順に調べ、最後に実際の定義更新が成功することまで確認してください。
コメント