同期HttpWebRequestがTLS接続でハングする.NET不具合｜KB5101001・KB5100998の対処法

同期のHttpWebRequestを使う.NET FrameworkアプリがHTTPS通信で戻らなくなる場合、Windows側に修正があります。Microsoftは、2026年7月14日に公開した.NET Framework累積更新で、この不具合を修正済みとしています。

Windows 11 24H2ではKB5101001、25H2ではKB5100998が主な対象です。23H2と26H1にもOSバージョン別の更新があります。アプリやサーバーの設定を変更する前に、端末のWindows 11バージョンを確認し、対応する2026年7月の.NET Framework累積更新を適用してください。(Microsoft Learn)

結論：OSに合った2026年7月の.NET Framework更新を適用する

同期HttpWebRequestがTLS接続でハングする不具合に対するMicrosoft公式の対処法は、対象OS向けの.NET Framework累積更新を適用することです。

Windows 11のバージョン	対象.NET Framework	2026年7月の更新
23H2	3.5、4.8.1	KB5101004
24H2	3.5、4.8.1	KB5101001
25H2	3.5、4.8.1	KB5100998
26H1	4.8.1	KB5101002

Windows 11 26H1の.NET Framework 3.5は配布方式が異なり、Microsoftの7月リリースノートではKB5101014が別の製品更新として案内されています。26H1では、アプリが使用している.NET Frameworkのバージョンも確認してください。(Microsoft Learn)

特に間違えやすいのが、次の組み合わせです。

Windows 11 24H2：KB5101001
Windows 11 25H2：KB5100998

KB5100998はMicrosoft server operating system 24H2にも使われますが、Windows 11 24H2向けではありません。Windows 11 24H2にはKB5101001を適用します。(Microsoft サポート)

どのような不具合が発生するのか

問題の対象となるのは、.NET FrameworkアプリがHttpWebRequestを同期方式で実行するケースです。

代表的には、次のようなコードが該当します。

var request = (HttpWebRequest)WebRequest.Create(
    "https://api.example.com/data");

request.Method = "GET";
request.Timeout = 30000;

using (var response =
    (HttpWebResponse)request.GetResponse())
{
    // 応答を処理
}

問題が起きる環境では、GetResponse()などの同期呼び出しが完了せず、アプリが応答を待ち続ける状態になります。

利用者からは、次のような症状として報告されることがあります。

HTTPS通信を開始すると画面が固まる
バッチ処理やWindowsサービスが途中で停止したように見える
通信エラーが記録されず、処理だけが進まない
HTTPでは成功するが、HTTPSでは戻らない
同じアプリでも、接続先サーバーによって成功と失敗が分かれる
一定回数の通信後にワーカースレッドが不足する

ただし、こうした症状だけで今回の不具合と断定することはできません。プロキシ、DNS、証明書、サーバー応答、アプリ内のデッドロックでも似た症状が発生するためです。

原因は.NET Frameworkの同期HttpWebRequest処理

Microsoftは、この問題を.NET Frameworkの「.NET Libraries」に関する品質および信頼性の問題として修正しています。

公式説明では、特定のサーバー構成を利用した一部のセキュア接続シナリオにおいて、同期HttpWebRequestの要求がハングする可能性があるとされています。(Microsoft Learn)

重要なのは、Microsoftが公開している範囲では、次の詳細までは特定されていないことです。

特定の暗号スイートだけで発生するのか
TLS 1.2とTLS 1.3のどちらに限定されるのか
証明書チェーン検証が直接の原因なのか
プロキシやロードバランサーのどの設定が引き金になるのか
TLSハンドシェイクのどの段階で停止するのか

そのため、「証明書が悪い」「サーバーのTLS設定が間違っている」と決めつけるのは適切ではありません。

サーバー側の構成が発生条件の一部になる可能性はありますが、Microsoftが提供した恒久対処は、サーバー設定の変更ではなく.NET Frameworkの更新です。

影響を受ける可能性が高い環境

今回の不具合を疑う場合は、次の条件を順番に確認します。

確認項目	該当する可能性が高い状態
実行基盤	.NET Frameworkで動作するアプリ
通信API	`HttpWebRequest`または`WebRequest.Create()`を使用
呼び出し方式	`GetResponse()`や`GetRequestStream()`などの同期呼び出し
通信先	HTTPSを使用する特定のサーバー
OS	Windows 11 23H2、24H2、25H2、26H1
更新状況	2026年7月の.NET Framework累積更新が未適用
発生状況	通信エラーではなく、呼び出しが戻らない

HttpWebRequestを直接記述していない場合も確認する

アプリのソースコードにHttpWebRequestが見当たらなくても、次のような場合は内部で使用されている可能性があります。

古いSDKやAPIクライアントライブラリを使用している
ベンダー製ミドルウェアがHTTP通信を実行している
WebRequest.Create()だけが記述されている
独自の通信ラッパークラスを使用している
古い.NET Framework向けライブラリが通信処理を隠蔽している

ソースコードを検索するときは、次の識別子を確認します。

HttpWebRequest
WebRequest.Create
WebRequest.CreateHttp
GetResponse
GetRequestStream

非同期通信やHttpClientの問題とは分けて考える

Microsoftの修正説明で明示されているのは、同期HttpWebRequest接続です。

次のケースは、同じ原因とは限りません。

HttpClient.SendAsync()が戻らない
GetResponseAsync()が完了しない
.NET 8や.NET 10アプリで通信できない
ブラウザやcurlでも同じ接続先に接続できない
HTTPとHTTPSの両方が失敗する

非同期APIやHttpClientでも問題が起きている場合は、ネットワーク、プロキシ、DNS、証明書、接続先サーバーも含めて調査する必要があります。

Windows 11のバージョンを確認する方法

最初に、対象端末のWindows 11バージョンを確認します。

最も簡単なのは、WindowsキーとRキーを押し、次のコマンドを実行する方法です。

winver

表示された画面で、23H2、24H2、25H2、26H1のいずれかを確認します。

PowerShellで確認する場合は、次のコマンドも利用できます。

Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object ProductName, DisplayVersion, CurrentBuild

DisplayVersionに表示された値を、対応するKB番号と照合してください。

Microsoft公式の修正を適用する手順

.NET Frameworkアプリを終了する

更新前に、対象となる.NET Frameworkアプリを終了します。

Windowsサービスや常駐アプリが.NET Frameworkを使用している場合は、業務影響を確認したうえで停止します。Microsoftも、更新前に.NET Frameworkベースのアプリを終了することを推奨しています。(Microsoft サポート)

OSに対応する更新を配布する

更新は、次の経路で提供されています。

環境	適用方法
個人または少数端末	Windows Update
組織管理端末	Windows Update for Business
WSUS管理環境	対応するWindows 11製品のSecurity Updatesを承認
オフライン端末	Microsoft Update Catalogから対応パッケージを取得

Microsoftのサポート情報では、Windows UpdateとMicrosoft Updateでは自動的にダウンロード、インストールされると案内されています。WSUSでは、対象OSの製品と「Security Updates」分類を有効にします。(Microsoft サポート)

必要に応じて再起動する

更新対象ファイルが使用中だった場合、更新後に再起動が必要です。

ハングが解消したかを確認するときは、更新をインストールしただけで判断せず、端末を再起動してからテストしてください。

同じ条件で再テストする

更新後は、問題発生時と同じ条件で確認します。

同じアプリのバージョン
同じHTTPS接続先
同じプロキシ設定
同じ認証方式
同じ要求データ
同じ実行アカウント

接続先や認証方式を変えてしまうと、更新によって直ったのか、試験条件が変わったため成功したのかを判断できません。

更新のインストール確認で注意すること

通常は、次の画面から確認します。

設定
→ Windows Update
→ 更新の履歴
→ 品質更新プログラム

ただし、Microsoftの.NET Frameworkリリースノートには、OS単位で案内されるKB番号は更新の提供判定に使用され、端末の「インストールされた更新プログラム」に同じKB番号が表示されない場合があると説明されています。

これは、端末に実際に存在する.NET Frameworkのバージョンに応じて、個別のコンポーネント更新が選択されるためです。したがって、Get-HotFix -Id KB5101001などの結果だけで未適用と断定しないでください。(Microsoft Learn)

組織環境では、次の情報を組み合わせて確認します。

Windows Updateの更新履歴
WSUSやWindows Update for Businessの準拠状況
Microsoft Update Catalog上の適用対象
端末のWindows 11バージョン
インストール済み.NET Frameworkのバージョン
更新後の再起動状況

2026年5月のプレビュー更新を別途入れる必要はない

同期HttpWebRequestの修正は、2026年5月26日の.NET Framework累積更新プレビューにも含まれていました。

ただし、2026年7月14日の更新は累積更新であり、同じ品質修正に加えてセキュリティ修正も含まれています。そのため、7月の累積更新を適用する場合、5月のプレビュー更新を先に個別適用する必要はありません。(Microsoft Learn)

運用環境では、オプションのプレビュー更新を探すより、OSに対応する7月のセキュリティ累積更新を適用する方法が分かりやすいでしょう。

更新をすぐ適用できない場合の暫定対策

恒久対処は.NET Framework累積更新の適用です。メンテナンス日まで更新できない場合は、アプリ側で影響を限定する対策を検討します。

同期要求に明示的なタイムアウトを設定する

HttpWebRequest.Timeoutを指定していない場合、既定値は100秒です。このプロパティは、同期GetResponse()とGetRequestStream()が待機する時間に適用されます。(Microsoft Learn)

var request = (HttpWebRequest)WebRequest.Create(url);

request.Timeout = 30000;
request.ReadWriteTimeout = 30000;

タイムアウト値は、通常の応答時間に余裕を持たせて設定します。通常2秒で完了するAPIなら30秒、長時間処理を伴うAPIなら業務要件に応じて調整します。

ただし、タイムアウト設定は障害の影響を抑えるための防御策であり、Microsoftが提供した修正の代替ではありません。

UIスレッドで同期通信を実行しない

Windows FormsやWPFのUIスレッド上でGetResponse()を直接実行すると、通信待機中に画面操作ができなくなります。

既存アプリをすぐ全面改修できない場合でも、通信処理をUIスレッドから分離すると、少なくとも画面全体が固まる影響を減らせます。

無制限に再試行しない

ハングやタイムアウト後に無制限再試行を行うと、次の問題を招きます。

接続先サーバーへの負荷増加
ワーカースレッドの枯渇
同じ要求の重複送信
バッチ処理の滞留
障害復旧後の一斉再送

再試行回数には上限を設け、待機時間を段階的に長くします。更新系APIでは、同じ要求を再送しても安全かどうかも確認してください。

避けるべき対処

証明書検証を無効にしない

ハングの原因を証明書と決めつけ、証明書検証を常時成功させるコードを追加するのは危険です。

ServicePointManager.ServerCertificateValidationCallback =
    delegate { return true; };

このような設定は、中間者攻撃や偽装サーバーを検出できなくするおそれがあります。今回のMicrosoft公式対処でもありません。

古いTLSを有効化しない

TLS 1.0やTLS 1.1を再度有効にして接続を試す方法も、恒久対処にはなりません。

Microsoftの説明は「特定のセキュア接続シナリオ」に関するものであり、特定のTLSバージョンを有効化すれば直るとは案内されていません。セキュリティレベルを下げる前に、まず.NET Framework更新を適用してください。

OSバージョンが違うKBを手動配布しない

次のような配布は避けます。

24H2端末にKB5100998を割り当てる
25H2端末にKB5101001を割り当てる
23H2から26H1まで同じKBを一律配布する
x64とArm64を区別せずにパッケージを配置する

Windows Updateでは適用可否が自動判定されますが、オフライン配布やソフトウェア配布ツールでは、OSバージョンとアーキテクチャを配布条件に含める必要があります。

更新後もハングする場合の切り分け

更新と再起動を行っても問題が続く場合は、今回の.NET Framework不具合以外も調査します。

症状	次に確認する項目
特定のHTTPSサーバーだけ失敗する	証明書チェーン、プロキシ、ロードバランサー、サーバーTLS設定
すべてのHTTPS通信が失敗する	プロキシ、DNS、端末時刻、ルート証明書、セキュリティ製品
HTTPでもHTTPSでも失敗する	ネットワーク経路、名前解決、サーバー停止
`HttpClient`やブラウザでも失敗する	.NET Framework固有ではない通信障害
一定回数の通信後に停止する	応答やストリームの解放漏れ、接続プール、スレッド枯渇
UIだけが固まる	UIスレッドでの同期通信、アプリ内デッドロック
更新直後で未再起動	再起動後に再テスト

調査時には、少なくとも次の情報を記録します。

Windows 11のバージョンとOSビルド
適用した.NET Framework更新
再起動日時
.NET Frameworkのバージョン
アプリのバージョンと32ビット・64ビットの違い
問題が起きた接続先ホスト名
プロキシの有無
発生日時とタイムアウトまでの時間
同期呼び出しを行っているスレッドのスタック
正常端末と異常端末の構成差

「更新を適用した」という情報だけではなく、更新後に再起動したか、同じ接続条件で再現したかまで残すことが重要です。

長期的にはHttpClientへの移行も検討する

今回の不具合はWindows側の更新で修正できますが、新規開発や既存アプリの近代化ではHttpClientへの移行も検討すべきです。

Microsoftは、HttpWebRequest、WebRequest、WebClientを新規開発で使用せず、HttpClientを利用するよう案内しています。また、公式の移行ガイドも提供しています。(Microsoft Learn)

移行時は、単にクラス名を置き換えるだけではなく、次の点を設計します。

非同期処理
キャンセル処理
タイムアウト
再試行回数
接続の再利用
エラー分類
ログと監視
プロキシや認証の互換性

ただし、HttpClientへの移行にはテストが必要です。現在稼働中の.NET Frameworkアプリに問題が起きている場合は、まず2026年7月の累積更新を適用し、その後に計画的な移行を進めるのが現実的です。

まず実施すべき対応

同期HttpWebRequestがHTTPS通信で戻らない場合は、次の順序で対応します。

アプリが.NET Frameworkの同期HttpWebRequestを使用しているか確認する
winverでWindows 11のバージョンを確認する
23H2はKB5101004、24H2はKB5101001、25H2はKB5100998、26H1はKB5101002を基準に更新する
.NET Frameworkアプリを終了して更新を適用する
必要に応じて端末を再起動する
問題発生時と同じ接続先、認証、プロキシ条件で再テストする
解消しない場合は、TLS以外のネットワーク要因やアプリ内の待機状態を調査する

Microsoftは2026年7月の累積更新にこの修正を含めており、公開時点で更新自体の既知の問題は報告していません。証明書検証の無効化やTLS設定の弱体化を行う前に、OSに対応する.NET Framework更新の適用状況を確認してください。(Microsoft Learn)

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

同期HttpWebRequestがTLS接続でハングする.NET不具合｜KB5101001・KB5100998の対処法

結論：OSに合った2026年7月の.NET Framework更新を適用する

どのような不具合が発生するのか

原因は.NET Frameworkの同期HttpWebRequest処理

影響を受ける可能性が高い環境

HttpWebRequestを直接記述していない場合も確認する

非同期通信やHttpClientの問題とは分けて考える

Windows 11のバージョンを確認する方法

Microsoft公式の修正を適用する手順

.NET Frameworkアプリを終了する

OSに対応する更新を配布する

必要に応じて再起動する

同じ条件で再テストする

更新のインストール確認で注意すること

2026年5月のプレビュー更新を別途入れる必要はない

更新をすぐ適用できない場合の暫定対策

同期要求に明示的なタイムアウトを設定する

UIスレッドで同期通信を実行しない

無制限に再試行しない

避けるべき対処

証明書検証を無効にしない

古いTLSを有効化しない

OSバージョンが違うKBを手動配布しない

更新後もハングする場合の切り分け

長期的にはHttpClientへの移行も検討する

まず実施すべき対応

この記事を書いた人

コメント

コメントするコメントをキャンセル

同期HttpWebRequestがTLS接続でハングする.NET不具合｜KB5101001・KB5100998の対処法

結論：OSに合った2026年7月の.NET Framework更新を適用する

どのような不具合が発生するのか

原因は.NET Frameworkの同期HttpWebRequest処理

影響を受ける可能性が高い環境

HttpWebRequestを直接記述していない場合も確認する

非同期通信やHttpClientの問題とは分けて考える

Windows 11のバージョンを確認する方法

Microsoft公式の修正を適用する手順

.NET Frameworkアプリを終了する

OSに対応する更新を配布する

必要に応じて再起動する

同じ条件で再テストする

更新のインストール確認で注意すること

2026年5月のプレビュー更新を別途入れる必要はない

更新をすぐ適用できない場合の暫定対策

同期要求に明示的なタイムアウトを設定する

UIスレッドで同期通信を実行しない

無制限に再試行しない

避けるべき対処

証明書検証を無効にしない

古いTLSを有効化しない

OSバージョンが違うKBを手動配布しない

更新後もハングする場合の切り分け

長期的にはHttpClientへの移行も検討する

まず実施すべき対応

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル