Wi-Fiにつながっているのに「インターネットなし」と表示されるのはなぜですか？

Wi-Fiへの接続、目的のサービスとの通信、WindowsのNCSIによる接続判定は別だからです。回線自体の障害だけでなく、確認用通信のDNS・プロキシ・VPN・認証ポータルの問題でも表示が食い違うことがあります。まず実際に何が通信できるかを確認します。

ブラウザでサイトが開けば、NCSIも正常だと判断できますか？

できません。宛先、プロキシの選択、認証状態、IPv4・IPv6、実行時刻が異なる場合があります。手動アクセスは比較材料にし、NCSI自身のイベントログと必要に応じたパケット記録で確認します。

Windows 11でもdns.msftncsi.comへのDNSプローブが必須ですか？

NCSIの公式FAQでは、Windows 11以降のアクティブプローブはHTTPを使うと説明されています。HTTPの宛先を解決するDNS通信と、旧版で使われるDNSプローブを区別してください。古い手順の全リクエストが必須だと一律に考えないことが重要です。

EnableActiveProbingを0にすれば直りますか？

確認用通信を止める設定であり、DNSや経路などの原因を修復する設定ではありません。閉域網などの管理方針として扱う場合を除き、表示を消す目的で変更せず、まず失敗箇所を調べます。

NCSIがInternetなら、業務システムにも必ず接続できますか？

できるとは限りません。OSの接続判定は、個別のAPIや共有フォルダーの稼働・認証・利用権限を保証しません。アプリでは目的の通信を実行し、タイムアウト、キャンセル、失敗の種類、再試行の安全性を扱う必要があります。

ネットは使えるのに「インターネットなし」？── WindowsのNCSI・DNS・プロキシ・VPNを切り分ける

2026年09月11日 01:00 · 小村豪 · Windows, Windows開発, ネットワーク, NCSI, DNS, プロキシ, VPN, PowerShell

更新履歴(初版のみ・2026年09月11日公開)

2026年09月11日: 初版公開

Wi-Fiへの接続、目的の通信、WindowsのNCSI判定を分け、設定の読み取りと少数回の手動確認をNCSI自身のログに照合します。表示だけで修復と判断せず、未解決時に引き継ぐ証拠まで整理します。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全5件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

Webサイトは開ける。チャットも届く。それなのに、Windowsの表示だけが「インターネットなし」になっている。Wi-Fiにもつながっているのに、なぜ判定が食い違うのでしょうか。

調べたいのは、表示だけが食い違う場合と、使いたい業務アプリの通信も失敗する場合です。最初からWi-Fi設定を削除したり、ネットワークを丸ごとリセットしたりせず、どの通信を確認すればよいかを説明します。

対象環境

主な対象はWindows 11の利用者・管理者で、後半ではWindowsアプリの開発者向けの設計も扱います。Windows 10との違いはプローブ方式などの版差を説明するためのもので、すべての旧版へ同じ診断手順を適用する趣旨ではありません。

確認例はWindows PowerShell 5.1とcurl.exeを使用します。有線LAN、Wi-Fi、企業プロキシ、VPN、認証ポータルでは条件が異なります。標準の公開確認先を使うコードは、その宛先への少数回の通信確認が許可された端末向けです。独自の確認先がある場合は、管理者と対象を合わせてください。

読み取りから始め、権限不足やコマンドの未対応を理由に設定を勝手に変更しません。Analyticログの有効化や接続の変更は、管理権限・承認・保存先・復旧手段を確認してから行います。遠隔操作中のネットワーク切断は、管理接続を失う危険があります。

以下は公式資料に基づく切り分け手順です。特定のOSビルドで障害を再現・解消したという実測報告ではありません。会社やホテルの例、HTTP応答の最小例も、実案件の測定結果とは区別します。

回答・解決方法

Wi-Fiへの接続、目的のサービスとの通信、NCSIの接続判定は別の観測です。まず新しい通信が実際にできるかを確認し、時刻と接続状態を残します。そのうえで確認先の設定を読み、DNS・TCP・HTTPの手動確認とNCSI自身のログを、同じ時刻・インターフェースで比較してください。[S1][S12]

この段階では根本原因は未確定です。ブラウザやcurlの成否だけをNCSIの成否に置き換えず、実際の確認要求とその後の状態変更を調べます。変更が必要なら根拠のある箇所だけを管理者と直し、表示と目的の通信の両方を再確認します。

仕組みを理解する場合は「定義」から、調査を始める場合は「具体例」の症状表と「手順」を読んでください。結果の判断と未解決時の引き継ぎは「確認」、古い対処法の注意とアプリ設計は「制約」にまとめます。

定義

NCSI

NCSI（Network Connectivity Status Indicator）は、Windowsがネットワークの接続状態を判定する仕組みです。インターネットへの接続があるか、ローカル接続にとどまるかを判定し、ネットワーク表示やアプリが使う情報を提供します。個々のWebサイトや業務システムの稼働監視ではありません。[S1]

Wi-Fiに接続したという事実だけでは、外部への経路や利用認証が整ったかは分かりません。あるサイトを使えたという事実は、その時点のその要求の成功です。別の宛先やアプリも使えるという保証にはならず、WindowsがInternetと判定したこととも区別します。

NCSIはアクティブプローブとパッシブプローブを組み合わせます。そのため、HTTP要求が一回失敗したことと、最終的な接続状態が「なし」になることは同じではありません。[S1]

アクティブプローブ

アクティブプローブは、NCSIが自分から確認要求を送り、その結果を接続判定に使う方法です。Windows 11ではHTTPを使います。要求の送信先と期待する応答は、実際の端末設定と照合します。[S1][S2]

パッシブプローブ

パッシブプローブは、受信パケットなどから得た情報を利用して接続状態を判定する方法です。NCSIは確認用のHTTP要求だけでなく、この観測も判断材料にします。[S1]

プロキシ

プロキシは、外部への要求を中継する接続先です。企業ネットワークでは、外部へ直接接続せず、プロキシを経由する構成があります。確認用通信でも、中継先の選択や到達性が調査対象になります。[S1]

PACファイル

PACファイルは、アクセスするURLやホスト名などに応じて、利用するプロキシや直接接続を選ぶためのファイルです。プロキシの自動検出が使われることもあります。設定が存在することと、ある要求にどの経路が選ばれたかは別に確認します。[S5]

キャプティブポータル

キャプティブポータルは、ネットワークの利用規約への同意やログインを求める認証用の入口です。ホテルなどのWi-Fiでは、電波につながった後も、この利用認証が残ることがあります。[S3]

役割

目標は警告アイコンだけを消すことではありません。何が通り、何が失敗し、どの条件が違うかを確認して、必要な通信を使える状態にすることです。

接続状態の共有

NCSIは、アプリがOSの接続状態を知るための共通の情報源です。ただし、OSの接続判定と目的の要求の結果は別です。「Windowsの判定はローカル接続だが、業務APIには接続できた」という二つの事実は同時に成り立ち得ます。[S1][S4]

診断情報の分担

切り分けでは、利用者は成功・失敗した操作と発生時刻を残し、管理者は確認先・DNS・プロキシ・VPNの設定と通信記録を照合します。開発者は目的の要求に対するDNS、接続、TLS、認証、HTTP応答などを記録します。「オフライン」の一語でまとめないことが、担当者の違う記録を結び付ける助けになります。

構成

通信の主体、確認先、経路、インターフェースを分けて整理します。同じPCから出る要求でも、同じ条件を使うとは限りません。

要求ごとの通信条件

ブラウザ、NCSI、手動確認用のcurlでは、宛先、プロキシの選択、実行アカウント、認証状態、IPファミリー、実行時刻が違う場合があります。ブラウザの成功だけで、NCSIの確認要求にも同じ経路が選ばれたとは判断しません。NCSIでは、プロキシ未検出・到達不能・PACの誤設定などが失敗候補になります。[S1]

flowchart TB
    accTitle: ブラウザとNCSIの経路を別々に確認する
    accDescr: ブラウザの通信成功は、別の宛先やプロキシ選択を使うNCSIの成功を保証しない。
    pc["同じPC"] --> browser["ブラウザの要求"]
    pc --> ncsi["NCSIの確認要求"]
    browser --> bpath["その要求のプロキシ・認証"]
    ncsi --> npath["確認要求のプロキシ・認証"]
    bpath --> site["利用したWebサイト"]
    npath --> probe["接続確認先"]

図1: 「同じPCだから同じ経路」とは限りません。要求ごとに宛先・プロキシ・認証を確認します。

したがって、NCSIの要求ではどのプロキシが選ばれ、どのアカウントや認証条件で通信したかを調べます。設定画面や手動テストは比較材料であり、実際に選ばれた経路はNCSI自身のログと通信記録で確かめます。

インターフェースとIPファミリー

PC全体を一つの「つながる／つながらない」で見ず、物理LAN・Wi-FiとVPNを分けます。接続プロファイルの各行と、実際に通信に使われたインターフェース・送信元を対応させてください。[S6][S10]

flowchart TB
    accTitle: 接続経路とIPファミリーを分ける
    accDescr: 物理LANとVPN、IPv4とIPv6を分け、通信に使われた経路と各判定を対応づける。
    pc["接続を一覧にする"] --> physical["物理LAN・Wi-Fi"]
    pc --> vpn["VPNアダプター"]
    physical --> p["IPv4・IPv6の判定"]
    vpn --> v["IPv4・IPv6の判定"]
    p --> route["実際の通信経路と照合"]
    v --> route

図2: 物理接続かVPNか、IPv4かIPv6かを区別したまま、実際の通信経路と比べます。

NCSIはIPv4とIPv6のアクティブプローブを並行して扱い、どちらかの成功でインターネット接続ありと判断できます。片方がInternetではないことだけで、PC全体が未接続とは言えません。特定アプリがどちらを使ったかは、その通信を別に観測します。[S1]

仕組み

NCSIのHTTP確認は、応答が届くことと、期待する内容が戻ることを分けて判断します。OSの版と管理設定も確認します。

HTTPの確認応答

Windows 10 バージョン1607以降の標準的なHTTP確認先は、次のURLです。期待する本文はMicrosoft Connect Testです。企業が管理するPCでは確認先が変更されることもあるため、調査では実際の設定を先に読みます。[S2]

http://www.msftconnecttest.com/connecttest.txt

このファイルを取りに行ったのに、ホテルのログイン画面や会社の遮断ページが返ってきたら、通信先から何かが届いていても期待した確認結果ではありません。HTTPのステータスが200でも、本文まで同じとは限らないのです。[S3]

flowchart TB
    accTitle: HTTPプローブが確認するもの
    accDescr: 確認先への要求に対して、期待する応答と本文が戻るかを見る。
    start["確認先へHTTP要求"] --> response{"応答を受信したか"}
    response -->|"いいえ"| failed["未完了・通信失敗を調査"]
    response -->|"はい"| content{"期待する応答と本文か"}
    content -->|"はい"| success["接続ありの判断材料"]
    content -->|"いいえ"| changed["認証・遮断・内容変更を調査"]

図3: 確認先から応答があることと、期待した内容が戻ることを分けて見ます。

図はHTTP要求の確認範囲を説明するもので、NCSI全体の状態機械ではありません。受信パケットを利用するパッシブプローブもあるため、一回のHTTP失敗だけで最終状態を決めつけません。状態変更までNCSI自身の記録を追います。[S1]

名前解決とDNSプローブ

古い解説にはdns.msftncsi.comへのDNSプローブが登場します。しかし、NCSI専用の公式FAQでは、Windows 11以降のアクティブプローブはHTTPを使うと説明されています。Windows 11の記録にDNS通信があっても、それはHTTPの宛先を解決するためかもしれません。[S2]

flowchart TB
    accTitle: DNS通信の役割を区別する
    accDescr: Windows 11のHTTP宛先の名前解決と、旧版のDNSプローブを別のものとして読む。
    dns["記録にDNS通信がある"] --> purpose{"何のための通信か"}
    purpose --> http["HTTP宛先の名前解決"]
    purpose --> legacy["旧版のDNSプローブ"]
    http --> win11["Windows 11でも必要になり得る"]
    legacy --> version["OSの版と実際のログを確認"]

図4: HTTPの送信先を調べるDNS通信と、DNSプローブそのものは別です。

旧版の「HTTPと別のDNS問い合わせが全部成功しなければならない」という説明を、すべてのWindowsに共通する規則にはできません。調べるOSの版と実際のログを合わせて読みます。

NCSIの実行サービス

設定場所の名前と実行サービスは一致するとは限りません。Windows 11ではNCSIの実行主体が従来のNLAからNetwork List Manager側へ移っていますが、確認先などの設定にはNlaSvcを含むレジストリパスを使います。パスにNlaSvcとあることだけで、実行サービスを決めつけないでください。[S1]

具体例

次の会社・ホテル・VPNの例は、観測する条件を具体化するための説明です。特定端末で再現した障害や、確認済みの根本原因として記載しているものではありません。

次の表は原因を断定する表ではありません。表示の異常がきっかけでも、業務アプリが失敗するならその通信結果を別に残します。

いま起きていること	最初に確認する場所
Webも業務アプリも使えない	NCSIに限定せず、IP設定・DNS・経路・利用認証を調べる
Webは使えるが、Windowsだけ「なし」	NCSIの確認先と、その通信が失敗した記録を見る
VPNを接続したときだけ表示が変わる	接続前後のアダプター・IPv4/IPv6・DNS・経路を比べる
Wi-Fi接続後に認証画面が出る	正規の利用認証を済ませ、通信と再判定を確認する
手動HTTPは成功するが、NCSIは失敗する	時刻・実行アカウント・プロキシ・経路の違いを調べる
WindowsはInternetだが、一つのアプリが失敗する	そのアプリの宛先・認証・TLS・タイムアウトを調べる

Webも業務アプリも使えない

新しいWebページも開けず業務操作も失敗するなら、NCSIの確認用通信だけの問題と決めつけません。IP設定、DNS、通信経路、ネットワークの利用認証を含め、通常のネットワーク障害として切り分けます。[S2]

最初に発生時刻と成功・失敗した操作を記録します。以前から開いていた画面が見えるだけなら、現在も通信できている証拠にはしません。

Webは使えるが「インターネットなし」

会社のPCでいつものWebサイトを開く場面を考えます。ブラウザがそのサイトと通信できればページは表示されます。一方、Windowsは別に接続確認用の小さなファイルを取りに行きます。

仮に「普段使うサイトへの通信は通すが、接続確認先への通信は通さない」設定なら、ブラウザは成功しても確認用通信は失敗します。同じPCでも、確かめている相手が違えば結果は食い違い得ます。PACの対象漏れ、プロキシ検出の遅れ、確認先へのHTTP遮断などを候補として調べます。[S1]

flowchart TB
    accTitle: Webサイトを使えても接続確認だけが失敗する例
    accDescr: 同じPCのブラウザが普段のWebサイトへ接続できる一方、NCSIの確認要求は別の確認先へ届かない仮の例です。NCSIの最終状態を一回の要求だけで決める図ではありません。
    pc["同じPC"] --> browser["ブラウザの通信"]
    pc --> probe["Windowsの確認用通信"]
    browser --> site["普段のWebサイト<br/>ページを開ける"]
    probe --> blocked["接続確認先<br/>ここへの通信だけ失敗"]

図5: 仕組みを理解するための仮の例です。普段の通信と接続確認は、別の相手への通信です。

たとえば手動HTTPで403が返ったら、同時刻のNCSIログと管理者が確認できるプロキシの拒否記録を照合します。確認先だけの拒否を記録で確かめた場合は、そのルールを管理者が修正して再検証します。手動要求だけが別経路を通ったなら、比較条件を見直します。403という数字だけで「NCSIのバグ」「自社プロキシの問題」と断定しません。

VPN接続後に表示が変わる

VPNの接続前後では、通信経路やDNSの利用条件が変わることがあります。接続直後に設定がそろわない、確認用通信が意図しない経路へ向かう、といった条件も失敗候補です。[S2]

一方、物理側がLocalNetworkでも、VPN側を通ってインターネットへ出る設計なら、物理側の一行だけで異常とは判断できません。物理接続とVPNの各行、IPファミリー、実際の送信元・経路を合わせて確認します。常時接続VPNの無断切断は比較方法にしません。[S2][S10]

Wi-Fi接続後に認証画面が出る

ホテルなどのWi-Fiで利用認証が残っていると、確認要求が認証ページへ転送されたりログイン画面を返されたりして、通常の確認応答にならない場合があります。Windowsがブラウザを開いてサインインを促す動作も、この仕組みに関係します。[S3]

flowchart TB
    accTitle: Wi-Fi接続とポータル認証の違い
    accDescr: 無線接続の成功後も、ネットワーク側の認証が済むまで外部通信が制限される場合がある。
    wifi["Wi-Fiに接続"] --> portal{"利用認証は済んだか"}
    portal -->|"未完了"| signin["正規の案内から認証"]
    portal -->|"完了"| test["実際の通信と判定を再確認"]
    signin --> test

図6: Wi-Fiへの接続が終わっても、そのネットワークの利用認証が終わったとは限りません。

施設の案内ページだけ見られる場合もあるため、一つページが開いただけで外部通信がすべて許可されたとは判断しません。正規の案内に沿った認証後、実際の通信とWindowsの表示を別々に確認します。

手動HTTPは成功するがNCSIは失敗する

手動HTTPで期待する応答が戻っても、成功したのはその手動要求です。NCSIの要求と時刻、実行アカウント、プロキシ、IPファミリー、インターフェースが同じかを調べます。NCSI自身の開始・完了・状態変更を、手動テストの記録と照合してください。[S12]

別経路を通った手動要求の成功を、NCSIの修復確認には使いません。違いが分からなければ、比較条件の不足を未確認事項として残します。

Internet表示でもアプリが失敗する

WindowsがInternetと判定していても、目的のAPIや共有フォルダーの稼働、認証、利用権限までは保証されません。そのアプリの宛先と操作を記録し、DNS、接続、TLS、認証、HTTP応答のどこで失敗したかを調べます。[S4]

NCSIの確認先だけを繰り返し試すのではなく、実際に失敗した業務要求の結果を開発者・管理者へ渡します。タイムアウトや再試行の扱いは「制約」で確認します。

手順

状態を残す、確認先の設定を読む、手動で通信を比べる、NCSI自身の記録で確かめる、という順で進めます。認証ポータルやVPNの比較は該当する場合だけ選びます。企業のプロキシ・VPN・セキュリティ設定は無断で変更せず、読み取りと少数回の通信確認から始めてください。

通信状態を記録する

調査を許可された端末と宛先で行います。ログを共有する際に伏せる社内ネットワーク名などを確認します。PublicをPrivateへ変更したり、接続設定を消したりする手順ではありません。

許可されたサイトで新しいページを開くなど、いま新しい通信ができるかを確かめます。

以前から開いている画面が見えるだけでは、現在の通信状態は分かりません。「この時刻に、このアプリで、この宛先の、この操作が成功した」と記録し、失敗する業務操作も別に残します。

発生時刻、OSのビルド、接続方法、VPNの有無を記録し、接続プロファイルを表示します。

OSの版はwinverで確認できます。続いてPowerShellで次を実行します。[S6]

Get-Date -Format o
Get-NetConnectionProfile |
    Select-Object Name, InterfaceAlias, InterfaceIndex,
        NetworkCategory, IPv4Connectivity, IPv6Connectivity |
    Format-Table -AutoSize
    

各行のInterfaceAlias・InterfaceIndexとIPv4Connectivity・IPv6Connectivityを、接続名と一緒に保存します。

NetworkCategoryのPublic / Private / DomainAuthenticatedは、インターネット接続判定とは別の分類です。複数行を一つの結果に潰さず、後の手動確認やログと同じ時刻・接続で照合します。[S6]

表示だけの食い違いか、目的の通信も失敗するかを分ける基準が残ります。コマンドが未対応・権限不足なら、その事実を記録して管理者へ引き継ぎ、空の結果を正常判定にしません。

確認先と管理設定を読み取る

レジストリは表示するだけで変更しません。読み取りが許可されない、またはキーがない場合は、推測でキーを作らず管理者へ確認します。標準の公開確認先を試す前に実際の設定を確かめます。

IPv4側・IPv6側の確認先と期待する本文、プローブを制御する設定を表示します。

確認先の設定場所とアクティブテストを制御する管理ポリシーは、公式資料も参照してください。[S1][S7]

$internetKey = 'HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet'
Get-ItemProperty -LiteralPath $internetKey |
    Select-Object EnableActiveProbing, ActiveWebProbeHost,
        ActiveWebProbePath, ActiveWebProbeContent,
        ActiveWebProbeHostV6, ActiveWebProbePathV6,
        ActiveWebProbeContentV6 |
    Format-List
    
$policyKey = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator'
if (Test-Path -LiteralPath $policyKey) {
    Get-ItemProperty -LiteralPath $policyKey |
        Select-Object NoActiveProbe, DisablePassivePolling |
        Format-List
} else {
    'このレジストリパスにNCSIポリシーはありません。'
}
    

ActiveWebProbeHost・ActiveWebProbePath・ActiveWebProbeContentと、V6付きの値を保存します。

独自の確認先が設定されていれば、以降の手動確認のホスト・URL・期待する本文を管理方針に合わせます。ポリシーキーがないという出力は、そのパスに設定がないという意味であり、MDMを含む管理設定が一切ない証明ではありません。
Windowsのプロキシ設定画面と管理ポリシーを確認し、対応するWinHTTP設定表示と比べます。

対応環境ではnetsh winhttp show advproxy、古い環境ではnetsh winhttp show proxyが比較材料になります。これは設定の表示であり、PACや自動検出でNCSIが実際に選んだ経路の証明ではありません。コマンドが未対応なら設定変更で補わず、その結果を残します。[S8][S5]

この端末が使う確認先・期待する内容・管理上の制約が整理できます。読み取り結果の欠落や設定と実行経路の差は未確認事項として残し、次の通信確認の対象を決めます。

認証Wi-Fiの利用認証を済ませる

認証ポータルを使うネットワークに限る手順です。施設の正規の案内でSSIDと認証先を確認します。不審なログイン画面へアカウントやカード情報を入力せず、証明書警告を無視して先へ進みません。

施設の案内に従って必要な利用規約への同意・認証を行います。

正規の案内か判断できない場合は入力を止め、施設や管理者に確認します。Windowsが開いた画面であることだけを、安全性の根拠にしません。
認証後に新しい外部通信を試し、NCSIの接続状態も別に記録します。

施設の案内ページだけが開く状態と、外部通信が許可された状態を区別します。期待する確認応答が戻るかも、対象設定と照合します。[S2]

認証前後の違いを、実際の通信とWindowsの判定の両方で比較できます。認証しても改善しなければ無断で制限を回避せず、時刻・応答・残る症状を管理者へ渡します。

DNSとTCP接続を確認する

標準の確認先に対する手動の比較例です。独自の確認先があれば管理者と変更対象を合わせます。直接接続は禁止されHTTPプロキシ経由だけ許される環境では、このTCPテストの失敗が正常なこともあります。ファイアウォールやDNS設定は変更しません。

普段使っているDNS設定のまま名前を引き、指定先へのTCP接続を別に確認します。

Resolve-DnsName -Name 'www.msftconnecttest.com' -Type A -DnsOnly
Test-NetConnection -ComputerName 'www.msftconnecttest.com' -Port 80 -InformationLevel Detailed
    

DNS応答とTCP接続結果を、InterfaceAlias・SourceAddress・時刻と一緒に保存します。

-Type AはIPv4のアドレスを調べる指定です。IPv6側の成否をこの一行で判断しません。公共DNSへの変更は社内の名前解決や管理方針まで変えるため、元の問題の観察と分けます。[S9]
直接接続を試した結果なのか、実際のHTTP要求が使うプロキシ経路とは異なるのかを整理します。

Test-NetConnection -Port 80が確認するのは指定先へのTCP接続であり、HTTP本文やプロキシ認証ではありません。次のHTTP確認と同じ経路だと無条件に考えないでください。[S10]

名前解決で止まったか、直接TCP接続で止まったかを区別できます。どちらかが成功しても次の層の成功ではなく、どちらかが失敗してもNCSI自体の障害の確定ではありません。

flowchart TB
    accTitle: 手動テストが答える問い
    accDescr: 名前解決、TCP接続、HTTP応答は確認範囲が異なるため、成功を次の層の保証にしない。
    name["DNSで名前を解決"] --> tcp["宛先へのTCP接続を確認"]
    tcp --> http["HTTP応答と本文を確認"]
    http --> own["NCSI自身の記録と比較"]
    tcp -.-> proxy["プロキシ必須環境では別経路"]

図7: 名前解決、TCP接続、HTTPの応答は、順に別のことを確かめています。

HTTP応答と本文を確認する

curl.exeが利用でき、少数回のHTTP確認が許可された端末で行います。実際の確認先を先に読み、必要なプロキシの利用方法は管理者へ確認します。認証情報をコマンド履歴へ直接書かず、証明書検証やセキュリティ機能を無効にしません。

標準の確認先を使う場合は、次のコマンドでヘッダーと本文を表示します。

PowerShellの別名と混同しないよう.exeまで書きます。独自の確認先を使う端末では管理者が確認したURLと比較してください。
```
curl.exe -q --connect-timeout 5 --max-time 15 --include 'http://www.msftconnecttest.com/connecttest.txt'
    
```
応答コード、転送先があればその宛先、本文、実行時刻を記録します。

--includeはヘッダーと本文を表示します。接続時と全体にタイムアウトを付け、-Lを付けないため転送先へ自動で進まず最初の応答を見られます。先頭の-qは既定設定ファイルを読み込まない指定ですが、プロキシ関連の環境変数までは消しません。[S11]
実際の設定が要求するステータスと本文を確認し、「確認」の結果表で次の観測を選びます。

標準設定で期待する内容の最小例を示します。これは説明用であり、この記事の実測ログではありません。実際にはほかのヘッダーも付きます。[S2]
```
HTTP/1.1 200 OK
...
    
Microsoft Connect Test
    
```

この手動HTTP要求で何が戻ったかが分かります。curlはWindowsのPACやブラウザの認証状態を同じように引き継ぐテストではありません。「ブラウザは成功、curlは失敗」だけでNCSIの異常とはせず、成功時もNCSI自身の記録と比べます。業務APIのHTTPSや認証まで成功する保証ではありません。

VPN接続前後を比較する

VPNに連動する症状がある場合に選びます。常時接続VPNを無断で切断しません。切断を伴う比較は組織が許可した検証端末・時間帯に限定し、作業の保存、元の状態への戻し方、代替の管理接続を確保します。確保できなければ記録の比較だけにとどめます。

物理側とVPN側の接続プロファイル、IPファミリー、DNSと経路に関する記録を並べます。

設定変更の権限がなければ管理者の記録を使います。物理側LocalNetworkとVPN経由の通信成功が併存する設計もあり、一行だけを異常判定に使いません。[S2]
比較が承認されている場合だけ、接続前後で同じ宛先・同じ操作を試し、時刻と送信元・インターフェースを残します。

VPN設定の反映前後や接続直後の遅延も区別します。別の経路へ変わった結果を、同一経路上の修復結果とは呼びません。
一時的に変えた接続状態を元へ戻し、必要な業務通信と管理接続を再確認します。

比較中に予想外の業務影響が出たら中止し、事前に決めた復旧手順を使います。接続条件を恒久的に緩めて比較を続けません。

症状とVPN状態・経路の対応を、元へ戻した確認を含めて整理できます。比較不能の場合も、許可や復旧手段がないという理由を残して引き継げます。

NCSIイベントを照合する

ログの閲覧権限と保存・共有範囲を確認します。既存ログの消去や、再現のためのネットワーク切断は行いません。ログがないことを正常の証拠にせず、取得できた期間とチャンネルを記録します。

イベントビューアーで「アプリケーションとサービスログ → Microsoft → Windows → NCSI」を開き、Operationalを発生時刻付近で確認します。

既に取得済みのAnalyticがあれば併せて読みます。詳細な開始・完了イベントが不足する場合は、次の承認付き採取へ進みます。[S12]
どのインターフェースで開始・完了したか、結果コード、失敗理由、その後の状態変更をつなげます。

一つのエラー行だけでなく、時刻とインターフェース、IPv4・IPv6を保ったまま追います。手動テストやプロキシの拒否記録、承認済みのパケット記録があれば同じ条件で照合します。[S12]
WinHTTPの結果コードなら対応表で意味を確認し、断定できる範囲を記録します。

12007は名前を解決できなかったこと、12002はタイムアウトです。失敗段階の手がかりであって、それだけでDNSサーバーの故障や回線断に決まるわけではありません。[S13]

NCSI自身の要求が発生したか、完了したか、何を理由に状態が変わったかを、取得できた記録の範囲で確認できます。手動要求と条件が違えば、その差を次の調査対象にします。

flowchart TB
    accTitle: NCSIログを読む順番
    accDescr: 開始、完了、失敗理由、状態変更を時刻とインターフェースでつなぐ。
    start["どの経路で開始したか"] --> finish["完了したか"]
    finish --> reason["結果コード・失敗理由"]
    reason --> state["その後の接続状態"]
    state --> correlate["同時刻の通信記録と照合"]

図8: 開始から状態変更までをつなぐと、手動テストとNCSIで何が違ったかを追いやすくなります。

Analyticログを採取する

管理者が承認した場合だけ診断設定を変更します。元のログ有効状態、保存先、共有先を記録し、必要な既存ログを先に保存します。有効化時に既存の分析・デバッグイベントを失う可能性がある警告にも注意します。Wi-Fi再接続やアダプター無効化はRDPなどを切断し得るため、本番端末・遠隔操作中の端末でいきなり行いません。[S12]

NCSIの「分析およびデバッグログの表示」からAnalyticを表示し、承認された範囲で有効化時刻を残してログを有効にします。

既に有効なら、無効化してやり直さず現在の状態を記録します。有効化前の詳細イベントを後から取り出せるわけではありません。[S12]
安全な再現方法で症状を確認し、Operational・Analyticと必要な承認済み通信記録を保存します。

ネットワーク変更を伴う再現は、代替管理手段と復旧手順がある場合だけ管理者が実施します。保存形式と時刻範囲を記録し、ホスト名・IPアドレス・認証関連情報が入り得る記録は共有範囲を限定します。
採取が成功した場合も、中止・失敗した場合も、一時的な診断設定と接続状態を元へ戻して確認します。

元からAnalyticが有効だった端末を一律に無効にはしません。変更前の状態と照合し、業務通信・管理接続が維持されることを確認します。復旧できなければ追加変更を止め、管理者へ状況を報告します。

取得した時間帯のNCSIイベントと通信記録を照合でき、一時的な設定の復旧結果も残ります。再現しなかった場合や記録が不足した場合は未解決として扱い、確認できたこととできなかったことを分けます。

確認

手動要求の結果、NCSI自身の結果、業務通信の結果を三つに分けて判断します。検証できなかった条件は正常とは記載しません。

手動HTTPの結果

手動テストはNCSIの代わりではなく比較材料です。HTTP応答と本文、認証やプロキシの条件を確認し、同時刻のNCSIログへつなぎます。

戻った結果	次に見ること
応答がない	名前解決・接続・タイムアウトのどこで止まったか
302などの転送	どこへ転送されるか。利用認証が残っていないか
403	誰が拒否した応答か。確認先への遮断記録がないか
407	プロキシから認証を要求されていないか
200だが本文がログイン画面など	確認用ファイルではない内容を、誰が返しているか
期待したステータスと本文	この手動要求は成功。続いてNCSI自身の記録と比べる

確認用通信と業務通信の再検証

管理者が記録に基づいて設定を修正した場合は、同じ宛先・操作・接続条件で比較します。NCSIの確認用通信とその後の状態変更、使いたい通信がそれぞれどう変わったかを残します。表示が変わっただけでは修復完了としません。

flowchart TB
    accTitle: 表示だけで修復を判定しない
    accDescr: 設定変更後は表示の変化だけでなく、失敗箇所と目的の通信の改善を確認する。
    change["根拠のある変更"] --> probe["確認用通信を再確認"]
    change --> app["目的の通信を再確認"]
    probe --> judge["両方の結果で改善を判断"]
    app --> judge

図9: 根拠のある変更を行った後も、確認用通信と、使いたい通信の両方を確かめます。

改善が一時的なら、時刻、VPNの接続直後か、プロキシ検出や経路の変化があったかを照合します。不要な一時設定は戻し、業務機能と管理接続も確認します。手動HTTPだけが成功してNCSIが失敗し続けるなら、実行アカウント・プロキシ・IPファミリーなどの比較条件へ戻ります。

未解決事項と引き継ぎ記録

改善しない、再現しない、権限がない場合も調査結果です。「ネットは使えるはず」ではなく、成功・失敗した具体的な通信と、実施できなかった確認をまとめます。機密情報を必要以上に渡さず、元の詳細記録は管理者が指定した保存先に残してください。

発生時刻とタイムゾーン、OSビルド：
表示と、成功・失敗したアプリ／宛先／操作：
物理LAN・Wi-Fi・VPNの状態、IPv4・IPv6の判定：
InterfaceAlias・InterfaceIndex、手動確認のSourceAddress：
設定された確認先・期待する本文、プロキシ・管理方針：
DNS・直接TCP・手動HTTPそれぞれの結果と実行時刻：
NCSIログのチャンネル・取得期間・結果コード・状態変更：
通信記録との一致点／条件が違う点／未確認の点：
変更した項目、変更前の値、復旧と業務通信の再確認結果：

この記録により、利用者の手動要求と管理者が見ているNCSI要求が同じ条件かを確認できます。根拠が足りなければ原因を確定せず、次に必要な記録と、その取得を担当する管理者・開発者を決めます。

制約

接続判定の変更、個別アプリの修復、ネットワークの管理方針は別の作業です。観測結果が保証しないことを残して判断します。

プローブ無効化の影響

EnableActiveProbingを0にする、管理ポリシーでアクティブテストを禁止する、といった操作は接続確認を制限する設定です。DNSの失敗やプロキシの経路を修復する操作ではありません。閉域網の管理方針として採用する場合と、警告を消すための変更は分けます。MicrosoftもNCSI問題の解決策としてアクティブプローブの無効化を推奨していません。[S7][S1]

偽の正常応答を返す、ファイアウォールを丸ごと止める、根拠なくIPv6を無効にする、といった方法を最初の手順にはしません。表示の変化と必要な通信の改善は別だからです。PublicからPrivateへの変更も、NCSIの一般的な修復方法ではありません。

確認先の固定IP指定

企業の許可ルールを直す場合も、古い記事のIPアドレスを固定登録して終わりにはしません。公開確認先は配信基盤が変わることがあり、Microsoftは特定IPに依存した許可を避けるよう案内しています。実際の確認先・サービス・経路に合うルールを管理者と確認してください。[S2]

OS判定と業務通信の独立性

OSが「インターネットなし」だからといって、目的の要求を一度も試さずオフラインにしてしまうと、実際には使える通信まで止める可能性があります。逆に、OSがInternetだから業務APIも必ず成功するという扱いも誤りです。

INetworkListManager::get_IsConnectedToInternetはローカルマシンのインターネット接続状態を返すAPIです。個別のAPIや共有フォルダーの稼働・認証・利用権限を保証するものではありません。設計ではOSの状態を表示や再接続の参考にし、目的の通信の成否を別に管理します。[S4]

flowchart TB
    accTitle: OSの判定と業務通信の結果を別管理にする
    accDescr: OSの接続情報は参考として使い、目的の通信には独立した成功と失敗の処理を持たせる。
    status["OSの接続状態"] --> hint["表示・再接続の参考"]
    request["目的の要求"] --> outcome{"実際の結果"}
    outcome --> ok["成功として処理"]
    outcome --> error["失敗理由を記録"]
    error --> retry["安全性を確認して再試行"]

図10: OSの判定を参考にしつつ、業務通信には独立した成功・失敗の扱いを持たせます。

タイムアウトと再試行

ログは「オフライン」の一語にせず、DNS、接続、TLS、認証、HTTP応答など、観測できた失敗段階を残します。要求にはタイムアウトとキャンセルを設け、UIを待たせ続けないようにします。

ただし、発注や送金のような更新処理は、応答が間に合わなくても相手側では実行済みかもしれません。「タイムアウトしたから未実行」と決めて再送せず、再試行の可否、重複を防ぐ仕組み、結果照会をアプリの仕様として決めます。NCSIが代わりに解決してくれる問題ではありません。

参考資料

Microsoft Learnとcurl projectの一次資料です。OS差分はNCSI専用の公式FAQを優先し、旧版向け説明をWindows 11の固定仕様として扱いません。ログの表示名やコマンドの対応は、実際のOSビルドと管理設定でも確認してください。本文の[S1]〜[S13]は次の資料に対応します。

Microsoft Learn, NCSI overview [S1]。アクティブ・パッシブプローブ、Windows 11の実行主体、設定場所、IPv4・IPv6と無効化に関する注意。
Microsoft Learn, Answers to common questions about NCSI [S2]。Windows 11のHTTPプローブ、確認先、VPN・DNSなどの失敗候補、固定IPによる許可の注意。
Microsoft Learn, An Internet Explorer or Edge window opens when your computer connects to a corporate network or a public network [S3]。認証ポータルとブラウザ表示、確認用のHTTP応答。旧版を含む説明として参照。
Microsoft Learn, INetworkListManager::get_IsConnectedToInternet [S4]。OSのインターネット接続状態を取得するAPI。
Microsoft Learn, WinHTTP AutoProxy Support [S5]。PACと自動プロキシ検出の位置づけ。
Microsoft Learn, Get-NetConnectionProfile [S6]。接続プロファイル、NetworkCategory、IPv4・IPv6の状態。
Microsoft Learn, Connectivity Policy CSP [S7]。NCSIアクティブテストを制御する管理ポリシー。
Microsoft Learn, Netsh.exe commands [S8]。WinHTTPのプロキシ設定表示。対応環境ではshow advproxyを使用。
Microsoft Learn, Resolve-DnsName [S9]。DNS照会の範囲とパラメーター。
Microsoft Learn, Test-NetConnection [S10]。TCP接続、経路、送信元の診断。
curl project, curl man page [S11]。設定ファイルの抑止、タイムアウト、ヘッダー表示、リダイレクトとプロキシの取り扱い。
Microsoft Learn, How to collect data to diagnose NCSI issues [S12]。Operational・Analyticログと通信記録の照合。
Microsoft Learn, Error Messages (Winhttp.h) [S13]。WinHTTPの結果コードの意味。

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

不具合調査・原因解析

ブラウザは使えるのに業務アプリだけがオフラインになる現象を、接続判定・実行アカウント・プロキシ・通信ログに分けて調査します。

サービスを見るお問い合わせ

Windowsアプリ開発

接続状態の表示に依存しすぎず、実際の通信結果と再試行を適切に扱うWindows業務アプリの設計・改修をご相談いただけます。