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

Webサイトは開ける。チャットも届く。それなのに、Windowsの表示だけが「インターネットなし」になっている。

「いまネットを使っているのに、なぜ『なし』なのか」と思いますが、ここには理由があります。WindowsにはWindows自身の接続確認があり、その結果と、いま使っているアプリの通信結果は別だからです。 たとえば、普段のWebサイトには届いていても、Windowsの接続確認先にだけ届かないことがあります。¹

だから、最初からWi-Fiの設定を消したり、ネットワークを丸ごとリセットしたりする前に、「表示だけがおかしいのか、使いたい通信も失敗しているのか」を分けます。

この記事では、先に表示が食い違う仕組みを説明し、よくある場面、症状別の見方、実際の確認手順へと進みます。仕組みを知りたい方は3章まで、調査する方は4・5章、Windowsアプリの開発者は6章も読んでください。Windows 11を中心にWindows 10との違いも扱い、確認例にはWindows PowerShell 5.1とcurl.exeを使います。

1. Windowsは「いま見ているサイト」だけを見ていない

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

ここで、会社のネットワークが「普段使うサイトへの通信は通すが、接続確認先への通信は通さない」という設定だったらどうでしょう。ブラウザの通信は成功しても、Windowsの確認用通信は失敗します。同じPCでも、確かめている相手が違えば、結果は食い違い得るのです。¹

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

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

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

「何か返ってきた」ではなく、確認用の内容が返るかを見る

Windows 10 バージョン1607以降の標準的なHTTP確認先は、次のURLです。期待する本文はMicrosoft Connect Testです。企業が管理するPCでは確認先が変更されることもあります。²

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

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

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

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

なお、NCSIはこの確認用通信だけで動いているわけではありません。自分から確認する方法をアクティブプローブ、受信パケットなどの情報から判断する方法をパッシブプローブと呼び、両方を使います。そのため、図のHTTP要求が1回失敗したことと、最終的な接続状態が「なし」になることは同じではありません。¹

ここまでの要点は、Wi-Fiにつながったこと、あるサイトを使えたこと、WindowsがInternetと判定したことは、それぞれ別の確認だということです。Wi-Fiへの接続だけでは外部への経路や利用認証は分かりませんし、一つのサイトに届いても、別の宛先や別のアプリまで使える保証にはなりません。

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

2. 表示と通信が食い違う、よくある三つの場面

会社では、ブラウザと接続確認で通り道が違うことがある

冒頭の会社の例を、もう少し具体的にします。企業ネットワークでは、外部へ直接接続せず、プロキシという中継先を経由する構成があります。その中継先を、アクセスするURLなどに応じて選ぶ仕組みがPACファイルです。自動検出が使われることもあります。⁴

この構成では、普段のサイトには適切なプロキシが選ばれても、接続確認先だけは対象から漏れるかもしれません。プロキシの検出が間に合わない場合や、確認先へのHTTP通信だけが遮断される場合も調査の候補です。¹

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

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

したがって、ブラウザが成功したかどうかだけでなく、NCSIの要求ではどのプロキシが選ばれ、どのアカウントや認証条件で通信したかを調べます。後で使う手動確認用のcurlについても同じです。三者を同じ条件の通信だと考えないことが、切り分けの出発点になります。

ホテルでは、Wi-Fi接続の後にログインが残っていることがある

ホテルなどのWi-Fiでは、電波につながった後で、利用規約への同意やログインを求められることがあります。この認証用の入口がキャプティブポータルです。確認用の要求が認証ページへ転送されたり、ログイン画面を返されたりすれば、通常の確認応答にはなりません。Windowsがブラウザを開いてサインインを促す動作も、この仕組みに関係します。³

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

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

施設の案内ページだけ見られるような場合もあるため、一つページが開いただけで「外部通信はすべて許可された」とは判断しません。施設の正規の案内に従って認証し、その後で実際の通信とWindowsの表示を確かめます。不審なログイン画面へアカウントやカード情報を入力しないでください。

VPNでは、「どの接続の結果か」が変わる

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

このときは、PC全体を一つの「つながる／つながらない」で見ず、物理LAN・Wi-FiとVPNを分けます。たとえば、物理側がLocalNetworkでも、VPN側を通ってインターネットへ出る設計なら、物理側の一行だけで異常とは判断できません。4章の接続プロファイルと、実際に使われた経路を対応させて読みます。⁵⁶

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

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

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

VPNを切って比較する場合は、組織の許可を得た検証端末や変更時間帯で行ってください。常時接続VPNを、調査のために無断で切断しないようにします。

3. 最初に分けるのは「表示だけか、通信も駄目か」

原因の候補が分かったら、次は自分の症状に当てはめます。まず、許可されたサイトで新しいページを開くなど、いま新しい通信ができるかを確認してください。以前から開いている画面が見えるだけでは、現在の通信状態は分かりません。

「ネットは使える」ではなく、「この時刻に、このアプリで、この宛先の、この操作が成功した」と書けるところまで具体化すると、調べる対象が絞れます。

これは原因を断定する表ではなく、次に確認する場所を選ぶための表です。表示の異常がきっかけでも、使いたい業務アプリが失敗しているなら、その通信結果も別に残します。

ここから先は調査の手順です。状態を残す → 確認先の設定を読む → 手動で通信を比べる → NCSI自身の記録で確かめる、という順で進めます。企業のプロキシ・VPN・セキュリティ設定は無断で変更せず、読み取りと少数回の通信確認から始めてください。

4. 設定を変える前に、どこで失敗したかを確かめる

4.1 発生時刻と接続状態を残す

最初に、発生時刻、OSのビルド、接続方法、VPNの有無、失敗するアプリを記録します。OSの版はwinverで確認できます。続いて、PowerShellで接続プロファイルを表示します。⁵

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は、インターネット接続判定とは別の分類です。PublicをPrivateへ変える操作は、「インターネットなし」の一般的な修復手順ではありません。 出力には社内ネットワーク名などが含まれるので、第三者へ渡す際は不要な識別情報を伏せてください。⁵

4.2 このPCが、どこを確認する設定なのかを読む

標準の確認先を試す前に、このPCでも同じ設定なのかを確かめます。次のコードは値を表示するだけで、レジストリを変更しません。IPv4側・IPv6側の確認先と期待する本文、アクティブテストなどを制御するポリシーを読み取ります。¹⁷

$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付きの値も合わせて残します。独自の確認先が設定されていたら、以下の手動テストも、その設定と管理方針に合わせてください。

ポリシーキーがないという出力は、そのパスに設定がないという意味です。MDMなどを含む管理設定が一切ない証明ではありません。見つからないキーを推測で作らず、管理者に確認します。

プロキシはWindowsの設定画面と管理ポリシーを確認します。WinHTTPの設定は、対応環境ならnetsh winhttp show advproxy、古い環境ならnetsh winhttp show proxyが比較材料になります。ただし、ここで分かるのは設定です。PACや自動検出でNCSIが実際に選んだ経路は、後述の通信記録と突き合わせます。⁸⁴

4.3 名前を引けるか、TCP接続ができるかを分ける

ここからは、標準の確認先に対する手動の比較テストです。調べたいのは、「宛先の名前を解決できないのか」「その先の接続で止まるのか」です。まず、名前解決とTCP接続を別々に確認します。

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

Resolve-DnsNameの-Type Aは、IPv4のアドレスを調べる指定です。最初は普段使っているDNS設定のまま観測します。いきなり公共DNSへ変更すると、社内の名前解決や管理方針まで変わり、元の問題を追いにくくなるためです。⁹

Test-NetConnection -Port 80で分かるのは、指定先へのTCP接続です。HTTP本文やプロキシ認証までは確認しません。直接接続は禁止され、HTTPプロキシ経由だけ許される環境では、このTCPテストの失敗が正常なこともあります。 InterfaceAliasとSourceAddressも保存し、どの経路を試した結果かを確認してください。⁶

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

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

4.4 HTTPでは、ステータスだけでなく本文も見る

次に、1章で説明した確認用の本文が戻るかを見ます。curl.exeが使える端末で、次のように少数回だけ実行します。PowerShellの別名と混同しないよう、.exeまで書きます。

curl.exe -q --connect-timeout 5 --max-time 15 --include 'http://www.msftconnecttest.com/connecttest.txt'

--includeはヘッダーと本文を表示する指定です。接続時と処理全体にタイムアウトを付け、-Lは付けていないため、転送先へ自動で進まず最初の応答を見られます。先頭の-qはcurlの既定設定ファイルを読み込まない指定ですが、プロキシ関連の環境変数までは消しません。¹⁰

期待する内容の最小例は次のとおりです。これは説明用であり、この記事の実測ログではありません。実際にはほかのヘッダーも付きます。²

HTTP/1.1 200 OK
...

Microsoft Connect Test

ここで大切なのは、手動テストはNCSIの代わりではなく、比べるための材料だということです。curlはWindowsのPACやブラウザの認証状態を同じように引き継ぐテストではありません。「ブラウザは成功、curlは失敗」という結果だけでは、NCSIの異常は確定しません。

必要なプロキシの使い方は管理者に確認し、認証情報をコマンド履歴へ直接書かないでください。また、このHTTP確認が成功しても、業務APIのHTTPSや認証まで成功する保証にはなりません。

4.5 最後に、NCSIが実際に失敗した記録を探す

手動テストで候補が見えたら、NCSI自身の動作を確認します。入口は、イベントビューアーの「アプリケーションとサービスログ → Microsoft → Windows → NCSI」です。Operationalログを発生時刻付近で確認します。¹¹

一つのエラー行だけでなく、「どのインターフェースで始まり、完了したか」「失敗理由は何か」「その後の接続状態はどう変わったか」を続けて見ます。手動テストと同じ時刻・同じ経路で照合し、必要なら承認されたパケット採取を併用します。¹¹

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

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

結果コードがWinHTTPのエラーなら、WinHTTPの表で意味を確認します。たとえば12007は名前を解決できなかったこと、12002はタイムアウトです。ただし、分かるのは失敗した段階の手がかりであり、それだけでDNSサーバーの故障や回線断に決まるわけではありません。¹²

詳細が足りない場合は、管理者が「分析およびデバッグログの表示」からAnalyticを有効化します。これは診断設定の変更なので、有効化の時刻を残してから再現し、採取後は元の状態へ戻します。有効化前の詳細イベントを後から取り出せるわけではありません。¹¹

また、再現のためのWi-Fi再接続やアダプターの無効化は、RDPなどの管理接続も切断し得ます。本番端末や遠隔操作中の端末で、いきなり実行しないでください。通信記録にはホスト名、IPアドレス、認証関連情報が入り得るため、保存先と共有範囲も限定します。

冒頭の会社の例なら、ここで手動HTTPの403と、同時刻のNCSIログ、管理者が確認できるプロキシの拒否記録を照合します。確認先だけが拒否されていたなら、そのルールを修正して再検証する。手動テストだけが別経路を通っていたなら、比較条件を見直す。403という数字だけで「NCSIのバグ」「自社プロキシの問題」と決めず、記録に応じて次の操作を選びます。 これは架空の切り分け例で、実案件の調査結果ではありません。

5. 古い対処法で、表示だけを直そうとしない

Windows 11のDNS通信を、旧版のDNSプローブと混同しない

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

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の版と実際のログを確認"]

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

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

もう一つ紛らわしいのが、設定場所の名前です。Windows 11ではNCSIの実行主体が従来のNLAからNetwork List Manager側へ移っていますが、確認先などの設定には4章のNlaSvcを含むレジストリパスを使います。パスにNlaSvcとあることだけで、実行サービスを決めつけないようにしてください。¹

確認を止めても、通らなかった通信は直らない

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

同じ理由で、偽の正常応答を返す、ファイアウォールを丸ごと止める、根拠なくIPv6を無効にする、といった方法を最初の手順にはしません。表示が変わったことと、使いたい通信が改善したことは別だからです。

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

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

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

6. 開発者向け：NCSIだけで「通信しない」と決めない

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

OS全体の接続判定を取得するINetworkListManager::get_IsConnectedToInternetは、ローカルマシンのインターネット接続状態を返すAPIです。個別のAPIや共有フォルダーの稼働・認証・利用権限を保証するものではありません。¹³

設計では、OSの接続状態は表示や再接続の参考にし、目的の通信の成否は別に管理すると整理できます。「Windowsの判定はローカル接続だが、業務APIには接続できた」という二つの事実を、同時に扱えるようにするのです。

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

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

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

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

7. まとめ：表示と通信を、別々の事実として読む

「ネットは使えるのにインターネットなし」は、必ずしも矛盾ではありません。Wi-Fiへの接続、使いたい相手との通信、Windows自身のNCSI判定は、確かめていることが違います。

まず、表示だけが食い違っているのか、必要な通信も失敗しているのかを分ける。調査するときは、確認先の設定と手動テストを比較材料にし、NCSI自身のログで実際の動作を確かめる。そして、変更後はアイコンだけでなく、確認用通信と目的の通信が改善したかを見る。

「つながっているはず」から、「どの通信が、どこで失敗したか」へ。 この順で考えると、設定を手当たり次第に変える前に、調べる場所を絞れます。

関連記事

• Windowsファイアウォールと業務アプリ
• Windowsの証明書ストア実務ガイド

参考リンク

確認日: 2026年9月11日。OS差分はNCSI専用の公式FAQを優先し、古いクライアント向け説明の手順をWindows 11の固定仕様として扱っていません。ログの表示名や利用できるコマンドは、実際のOSビルドと管理設定でも確認してください。

関連する記事

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

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

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

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

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。