Azure SQLで「An existing connection was forcibly closed」OS error 10054が出る原因と対処法

Azure SQLへの接続時に「An existing connection was forcibly closed by the remote host」「OS error 10054」が出る場合、最初に疑うべきは単なるネットワーク断ではなく、TLSハンドシェイクの失敗です。特に、古いSQL Serverドライバー、TLS 1.0/1.1に依存したクライアント、暗号スイートの制限、証明書検証の設定変更が絡むと、ログイン前後で接続が強制的に切断されたように見えます。

2026年5月下旬に更新されたMicrosoft公式のトラブルシューティング情報では、このエラーを「クライアントとSQL Server側でTLSプロトコルや暗号スイートに合意できない状態」として整理しています。Azure SQLを利用している管理者・開発者は、Azure SQL側の最小TLSバージョン、クライアントドライバー、接続文字列、OSのSchannel設定、展開手順をセットで確認することが重要です。(Microsoft Learn)

Azure SQLでOS error 10054が出るときに起きていること

「An existing connection was forcibly closed by the remote host」は、直訳すると「既存の接続がリモートホストによって強制的に閉じられた」という意味です。SQL Server接続では、次のようなメッセージとして表示されることがあります。

A connection was successfully established with the server,
but then an error occurred during the login process.
(provider: SSL Provider, error: 0 -
An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server,
but then an error occurred during the pre-login handshake.
(provider: TCP Provider, error: 0 -
An existing connection was forcibly closed by the remote host.)

ポイントは、TCP接続そのものは一度成立しているように見えることです。その後、ログイン処理やpre-login handshakeの段階でTLSの合意に失敗すると、クライアント側では「接続が強制終了された」と見えます。Microsoftの公式情報でも、OS error 10054はWindows sockets層で発生するエラーとして説明されています。(Microsoft Learn)

そのため、Azure SQLでこのエラーが出たときに「ファイアウォールだけ」を見ても原因にたどり着けないことがあります。実務では、次の順番で切り分けると効率的です。

優先度	確認対象	見るべきポイント
高	クライアントドライバー	ODBC、OLE DB、JDBC、.NET SqlClientがTLS 1.2以上に対応しているか
高	Azure SQLの最小TLS設定	最小TLSバージョンがクライアントより高くないか
高	接続文字列	`Encrypt`、`TrustServerCertificate`、証明書名検証の指定
中	OSのTLS設定	Schannel、グループポリシー、暗号スイート制限
中	ネットワーク経路	Public Endpoint、Private Endpoint、Proxy/Redirect接続ポリシー
低〜中	SQL Server側の証明書	Managed InstanceやSQL Server on Azure VMで証明書を管理している場合

今回の公式情報で押さえるべき変更点

今回の更新で重要なのは、新しいエラーコードが追加されたことではありません。OS error 10054を「TLSハンドシェイク失敗」として体系的に切り分ける観点が明確になったことです。

Microsoftの公式情報では、主な原因として次のようなシナリオが整理されています。

原因	具体例	対応の方向性
TLSプロトコルの不一致	クライアントがTLS 1.0/1.1しか使えず、サーバー側はTLS 1.2以上を要求	ドライバー、ランタイム、OSを更新
暗号スイートの不一致	セキュリティ強化で利用可能な暗号スイートを絞りすぎた	クライアントとサーバーで共通の暗号スイートを確認
`TLS_DHE_*`暗号スイートの問題	異なるWindows Server世代間でDHE系スイートの扱いが合わない	`TLS_DHE_*`の利用状況を確認し、必要に応じて無効化
弱いハッシュアルゴリズムの証明書	MD5など、TLS 1.2で問題になる証明書を使用	証明書の置き換え、用途設定の見直し
古いクライアントコンポーネント	SQL Server Native Client、古いODBC/OLE DB/JDBC	現行ドライバーへ移行

Microsoftは、TLS 1.2以上を扱うための一般的な安全ラインとして、Microsoft ODBC Driver 17/18、Microsoft OLE DB Driver 18/19、.NET Framework 4.6.2以降またはサポート中の.NET、Microsoft JDBC Driver 9.4以降などを挙げています。一方で、SQL Server Native Clientや古いSQLOLEDBは非推奨のため、Azure SQL接続では移行対象として扱うべきです。(Microsoft Learn)

Azure SQLで影響を受けやすい環境

Azure SQL DatabaseやAzure SQL Managed Instanceを使っている場合、影響を受けやすいのは「データベース本体」よりも、そこへ接続するクライアント側です。特に次の環境では、OS error 10054が発生しやすくなります。

環境	影響を受けやすい理由
古い業務アプリ	同梱ドライバーがTLS 1.2に未対応、または設定変更できない場合がある
古いWindows Server上のバッチ	Schannel設定や.NET Frameworkが古い可能性がある
SSIS、ETL、BIツール	内部で使うSQL Serverドライバーが古いことがある
Javaアプリ	JVM、JDBC Driver、trustStore設定の組み合わせで失敗することがある
Python、PHP、Node.jsアプリ	実際にはODBCドライバー経由で接続している場合がある
セキュリティ強化済み端末	GPOやEDR方針で暗号スイートが制限されていることがある
Private Endpoint移行中の環境	ネットワーク経路変更とTLSエラーが同時期に発生し、原因を誤認しやすい

Azure SQLでは、TLS 1.0/1.1の扱いにも注意が必要です。Azure SQL Databaseの接続設定では、現在サポートされる最小TLSバージョンはTLS 1.2とされ、TLS 1.0/1.1は廃止済みとして扱われます。また、最小TLSバージョンを設定すると、そのサーバーに関連付くデータベースへの接続に影響します。(Microsoft Learn)

Azure SQL Managed Instanceでも、最小TLSバージョン1.2が適用され、TLS 1.2以上の接続のみが受け入れられると説明されています。古いクライアントライブラリやフレームワークがTLS 1.2をサポートしていない場合、接続は失敗します。(Microsoft Learn)

管理者が最初に確認すべきAzure SQL側の設定

最小TLSバージョンを確認する

Azure SQL Databaseでは、論理サーバーの接続設定から最小TLSバージョンを確認します。Azure portalでは、対象のSQL論理サーバーを開き、Security配下のNetworkingからConnectivityタブを確認します。

Azure CLIで確認する場合は、次のように実行します。

az sql server show \
  -n <sql-server-name> \
  -g <resource-group-name> \
  --query "minimalTlsVersion"

TLS 1.2に設定する場合は、事前に検証環境で接続確認を済ませたうえで、次のように更新します。

az sql server update \
  -n <sql-server-name> \
  -g <resource-group-name> \
  --set minimalTlsVersion="1.2"

最小TLSバージョンの設定は、適用後すぐに接続へ影響します。要件を満たさないクライアントが残っていると、業務アプリやバッチが突然接続できなくなる可能性があります。Microsoftの接続設定ドキュメントでも、接続関連の設定は適用後すぐに有効になり、条件を満たさない場合は接続が失われる可能性があると説明されています。(Microsoft Learn)

TLS 1.0/1.1で接続しているクライアントを洗い出す

Azure SQLの設定を変える前に、まず古いTLSで接続しているクライアントを特定します。Azure portalのメトリックでSuccessful connectionsを確認し、TLSバージョンでフィルターする方法があります。また、SQL監査ログを有効にして、client_tls_version_nameを確認する方法もあります。(Microsoft Learn)

確認すべき項目は次の通りです。

確認項目	判断基準
TLS 1.0/1.1の接続があるか	1件でもあれば、該当クライアントを移行対象にする
接続元IP	アプリサーバー、運用端末、ETLサーバーを特定する
ホスト名・アプリ名	ログに出る場合は担当チームへ確認する
接続頻度	月次・日次バッチなど、常時接続でない処理も見落とさない
失敗時刻	リリース、OS更新、ドライバー更新、GPO変更と照合する

よくある失敗は、Webアプリだけを確認して、運用端末のSSMS、古い帳票ツール、月末バッチを見落とすことです。TLS移行では「常時稼働アプリ」よりも「たまに動くジョブ」が本番障害の原因になりやすいため、監査ログの期間は最低でも業務サイクルを1周できる長さで見るのが安全です。

開発者が確認すべきドライバーと接続文字列

ドライバーは「動いているから安全」と判断しない

Azure SQL接続では、アプリケーションコードよりもドライバーの古さが問題になることがあります。たとえば、アプリ側では同じ接続文字列を使っていても、実行環境にインストールされているODBC DriverやJDBC Driverが変わるだけで挙動が変わります。

最低限、次の観点で棚卸ししてください。

言語・環境	確認するもの	推奨アクション
.NET / C#	Microsoft.Data.SqlClient、System.Data.SqlClient、.NET Framework	サポート中の.NETまたは.NET Framework 4.6.2以降を基準に見直す
C++ / Python / PHP	ODBC Driver for SQL Server	ODBC Driver 17/18以降を候補にする
COM / 古いWindowsアプリ	OLE DB Provider	MSOLEDBSQL 18/19へ移行を検討する
Java	Microsoft JDBC Driver for SQL Server、JVM	JDBC Driver 9.4以降、JVMのTLS設定、trustStoreを確認する
レガシーアプリ	SQL Server Native Client、SQLOLEDB	非推奨のため置き換えを計画する

Microsoft公式情報では、SQL Server Native Clientと、Windowsに同梱されていた古いSQL Server OLE DB Providerは非推奨とされています。Azure SQLへの長期接続を維持するなら、「エラーが出たら対処」ではなく、計画的に現行ドライバーへ置き換えるべきです。(Microsoft Learn)

接続文字列はEncryptとTrustServerCertificateを明示する

Azure SQLでは、Microsoftが提供またはサポートするドライバーでTLSが使われます。Microsoftは、Azure SQL DatabaseやAzure SQL Managed Instanceへの接続では、Encrypt = On、TrustServerCertificate = Off、必要に応じてHostNameInCertificate相当の設定を使うことを推奨しています。これにより、クライアントドライバーがサーバー証明書のIDを検証できます。(Microsoft Learn)

ADO.NETの例は次の通りです。

Server=tcp:<server-name>.database.windows.net,1433;
Database=<database-name>;
Authentication=Active Directory Default;
Encrypt=True;
TrustServerCertificate=False;

JDBCで証明書名を明示したい場合は、環境に応じて次のような指定を検討します。

jdbc:sqlserver://<server-name>.database.windows.net:1433;
database=<database-name>;
encrypt=true;
trustServerCertificate=false;
hostNameInCertificate=*.database.windows.net;

本番環境では、安易にTrustServerCertificate=Trueへ逃げないことが重要です。この設定は証明書検証を省略するため、検証目的の一時回避には使えても、恒久対策としては推奨しにくい設定です。JDBC Driverの公式ドキュメントでも、trustServerCertificate=trueはサーバーTLS証明書を検証しない設定として説明されています。(Microsoft Learn)

ドライバー更新後の「証明書チェーンが信頼されない」に注意する

ODBC Driver 18やOLE DB Driver 19へ更新した後、OS error 10054とは別に、証明書チェーンの信頼エラーが出ることがあります。これは、古いドライバーでは暗号化が既定で無効だったのに対し、新しいドライバーでは暗号化や証明書検証が既定で有効になり、これまで見えていなかった証明書設定の問題が表面化するためです。(Microsoft Learn)

この場合、やるべきことは「暗号化を無効にする」ではなく、次の順で確認することです。

確認項目	対応
接続先ホスト名	Azure SQLのFQDNで接続しているか確認する
証明書名検証	`HostNameInCertificate`が必要か確認する
ルート証明書	クライアントOSやコンテナイメージのCA証明書を更新する
ドライバー設定	`Encrypt`と`TrustServerCertificate`を明示する
一時回避	検証環境のみ、期限付きで`TrustServerCertificate=True`を検討する

TLSプロトコルと暗号スイートの切り分け方法

クライアント側でTLS 1.2以上が有効か確認する

WindowsクライアントやWindows Serverでは、Schannelの設定やグループポリシーでTLSバージョンが制限されていることがあります。特に、古いOSを長く使っている環境や、セキュリティ基準に合わせて暗号スイートを独自に絞っている環境では注意が必要です。

Windowsでは、暗号スイートを次のPowerShellで確認できます。

Get-TlsCipherSuite

レジストリで確認する場合は、主に次の配下を確認します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Microsoft公式情報でも、Get-TlsCipherSuiteやSchannel配下のレジストリキーを使って、クライアントとサーバーのTLSバージョン・暗号スイートを比較する方法が案内されています。(Microsoft Learn)

Azure SQL Databaseでは利用者がサーバー側OSへ直接入ってパケットキャプチャを取ることはできません。そのため、実務では次の情報を組み合わせます。

クライアント側のネットワークトレース
アプリケーションログ
Azure SQLのメトリック
SQL監査ログ
ドライバーの詳細ログ
OS更新履歴、GPO変更履歴
リリース時刻と失敗時刻の照合

「Client Hello」と「Server Hello」を見る

ネットワークトレースを取れる場合は、TLSのClient HelloとServer Helloを確認します。

パケット	見る内容	判断
Client Hello	クライアントが提示したTLSバージョン、暗号スイート	古いTLSや弱い暗号スイートしか出していない場合はクライアント側が原因
Server Hello	サーバーが選択したTLSバージョン、暗号スイート	返ってこない場合は合意できず切断された可能性
Alert	handshake failureなど	TLS交渉失敗の裏付けになる

暗号スイートの不一致では、クライアントが提示した候補とサーバー側が受け入れられる候補に共通点がなく、接続が閉じられます。Microsoft公式情報でも、Client HelloとServer Helloを確認して、TLSバージョンと暗号スイートを調べる方法が示されています。(Microsoft Learn)

Azure SQLのネットワーク設定とTLSエラーを混同しない

OS error 10054はTLSが原因で起きることが多い一方、Azure SQLのネットワーク設定変更と同時に発生すると、原因を誤認しやすくなります。

たとえば、次の変更を同じ日に実施すると、どれが原因か分からなくなります。

同時にやりがちな変更	切り分けが難しくなる理由
Private Endpoint化	DNS、ルーティング、証明書名検証が同時に変わる
最小TLSバージョン変更	古いクライアントだけが失敗し始める
ODBC Driver 18導入	暗号化と証明書検証の既定動作が変わる
Redirect接続ポリシーへ変更	必要なアウトバウンド許可ポートが変わる
OSセキュリティ基準の適用	TLSプロトコルや暗号スイートが制限される

Azure SQL Databaseの接続アーキテクチャでは、クライアントはまずポート1433でゲートウェイへ接続し、接続ポリシーに応じてProxyまたはRedirectでトラフィックが転送されます。Redirectは低遅延・高スループットのため推奨されますが、11000〜11999番ポートなど追加のアウトバウンド許可が必要になる場合があります。(Microsoft Learn)

したがって、ネットワーク変更とTLS変更は同時に実施しない方が安全です。どうしても同時に行う場合は、検証環境で次の組み合わせを再現してください。

再現条件	確認内容
本番と同じOS	Schannel、CA証明書、GPOが同じか
本番と同じドライバー	ODBC/JDBC/.NETのバージョンが同じか
本番と同じ接続経路	Public Endpoint、Private Endpoint、Proxy/Redirectを合わせる
本番と同じ認証方式	SQL認証、Microsoft Entra ID認証、Managed Identityを合わせる
本番と同じ接続文字列	`Encrypt`や`TrustServerCertificate`の差分をなくす

移行・展開時の実践手順

Azure SQLのOS error 10054対策は、設定を1つ変えて終わりではありません。安全に進めるなら、次の順番で実施します。

手順	作業	完了条件
1	接続元を棚卸しする	アプリ、バッチ、ETL、運用端末、BIツールを一覧化
2	TLS 1.0/1.1利用を確認する	メトリックまたは監査ログで古いTLS接続を特定
3	ドライバーを更新する	TLS 1.2以上対応のドライバーへ移行
4	接続文字列を明示する	`Encrypt=True`、`TrustServerCertificate=False`を基準化
5	検証環境で最小TLSを上げる	主要処理と月次・日次ジョブが成功
6	本番へ段階展開する	監視を有効化し、失敗接続を即時確認
7	古い設定を撤去する	一時回避の`TrustServerCertificate=True`や古いドライバーを残さない

特に重要なのは、最小TLSバージョンの変更前にクライアント側を直すことです。Azure SQL側で先にTLS 1.2以上を強制すると、古いクライアントは接続できなくなり、アプリ側からはOS error 10054やログイン失敗として見える可能性があります。

よくある失敗と回避策

SSMSでは接続できるのにアプリだけ失敗する

SSMSが新しいドライバーや新しい.NET環境を使っている一方で、アプリは古いODBC DriverやSQL Server Native Clientを使っていることがあります。この場合、SSMSの成功は本番アプリの安全性を保証しません。

確認すべきなのは、実際にアプリプロセスがロードしているドライバーです。WindowsならODBCデータソースアドミニストレーター、アプリのログ、インストール済みドライバー一覧を確認してください。

開発環境では動くのに本番だけ失敗する

本番だけ失敗する場合は、OSのTLS設定、グループポリシー、プロキシ、EDR、ファイアウォール、証明書ストアの差分が原因になりがちです。DockerコンテナやLinux環境では、ベースイメージのCA証明書が古いこともあります。

この場合、接続文字列だけを見ても解決しません。OSイメージ、証明書ストア、JVM、OpenSSL、ODBC Driverのバージョンを本番と開発で比較してください。

TrustServerCertificate=Trueで直ったので完了にしてしまう

TrustServerCertificate=Trueで接続できるようになる場合、原因はTLSプロトコルではなく証明書検証にある可能性があります。ただし、この設定は証明書検証を省略するため、本番の恒久対策としては避けるべきです。

正しい対応は、接続先ホスト名、証明書の信頼チェーン、HostNameInCertificate、CA証明書を整えることです。検証を省く設定は、切り分け用の一時対応として期限を決めて使いましょう。

TLS 1.3を急いで強制する

TLS 1.3は新しい選択肢ですが、すべてのOSやドライバーが同じように対応しているわけではありません。Azure SQL Databaseの接続設定ドキュメントでも、TLS 1.3の強制は、TLS 1.3をサポートしないクライアントで問題を起こす可能性があると注意されています。(Microsoft Learn)

実務では、まずTLS 1.2を安定した基準にし、すべてのクライアントと監視体制が整ってからTLS 1.3を検討する方が安全です。

Azure SQL管理者・開発者向けチェックリスト

最後に、OS error 10054が出たときに確認すべき項目をまとめます。

役割	チェック項目	判断基準
管理者	Azure SQLの最小TLS設定	TLS 1.2以上を前提に、変更前に影響調査済みか
管理者	監査ログ・メトリック	TLS 1.0/1.1の接続元を特定できているか
管理者	ネットワーク設定	Public/Private Endpoint、Proxy/Redirect、アウトバウンド許可を確認済みか
開発者	ドライバー	ODBC、OLE DB、JDBC、SqlClientが古くないか
開発者	接続文字列	`Encrypt`、`TrustServerCertificate`を明示しているか
開発者	証明書検証	ホスト名、CA証明書、trustStoreを確認済みか
運用担当	展開順序	ドライバー更新後にTLS設定を変更する順番になっているか
運用担当	ロールバック	一時回避策と恒久対策を分けているか

まずやるべきこと

Azure SQLで「An existing connection was forcibly closed」「OS error 10054」が出たら、まず次の3つを実施してください。

Azure SQLのメトリックまたは監査ログで、TLS 1.0/1.1を使う接続元がないか確認する
該当アプリのSQL Serverドライバー、.NET/JVM/ODBC/OLE DBのバージョンを棚卸しする
接続文字列でEncrypt=True、TrustServerCertificate=Falseを基準にし、証明書検証エラーが出る場合は証明書・ホスト名・CAストアを直す

このエラーは、ネットワーク担当、DBA、アプリ開発者のどこか1チームだけでは解決しにくい問題です。Azure SQL側の最小TLSバージョン、クライアントドライバー、OSのTLS設定、接続文字列を1枚の一覧にまとめ、古いクライアントから順に潰していくのが最短ルートです。

この記事を書いた人

佐藤健司

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

Azure SQLで「An existing connection was forcibly closed」OS error 10054が出る原因と対処法

Azure SQLでOS error 10054が出るときに起きていること

今回の公式情報で押さえるべき変更点

Azure SQLで影響を受けやすい環境

管理者が最初に確認すべきAzure SQL側の設定

最小TLSバージョンを確認する

TLS 1.0/1.1で接続しているクライアントを洗い出す

開発者が確認すべきドライバーと接続文字列

ドライバーは「動いているから安全」と判断しない

接続文字列はEncryptとTrustServerCertificateを明示する

ドライバー更新後の「証明書チェーンが信頼されない」に注意する

TLSプロトコルと暗号スイートの切り分け方法

クライアント側でTLS 1.2以上が有効か確認する

「Client Hello」と「Server Hello」を見る

Azure SQLのネットワーク設定とTLSエラーを混同しない

移行・展開時の実践手順

よくある失敗と回避策

SSMSでは接続できるのにアプリだけ失敗する

開発環境では動くのに本番だけ失敗する

TrustServerCertificate=Trueで直ったので完了にしてしまう

TLS 1.3を急いで強制する

Azure SQL管理者・開発者向けチェックリスト

まずやるべきこと

この記事を書いた人

コメント

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

Azure SQLで「An existing connection was forcibly closed」OS error 10054が出る原因と対処法

Azure SQLでOS error 10054が出るときに起きていること

今回の公式情報で押さえるべき変更点

Azure SQLで影響を受けやすい環境

管理者が最初に確認すべきAzure SQL側の設定

最小TLSバージョンを確認する

TLS 1.0/1.1で接続しているクライアントを洗い出す

開発者が確認すべきドライバーと接続文字列

ドライバーは「動いているから安全」と判断しない

接続文字列はEncryptとTrustServerCertificateを明示する

ドライバー更新後の「証明書チェーンが信頼されない」に注意する

TLSプロトコルと暗号スイートの切り分け方法

クライアント側でTLS 1.2以上が有効か確認する

「Client Hello」と「Server Hello」を見る

Azure SQLのネットワーク設定とTLSエラーを混同しない

移行・展開時の実践手順

よくある失敗と回避策

SSMSでは接続できるのにアプリだけ失敗する

開発環境では動くのに本番だけ失敗する

TrustServerCertificate=Trueで直ったので完了にしてしまう

TLS 1.3を急いで強制する

Azure SQL管理者・開発者向けチェックリスト

まずやるべきこと

この記事を書いた人

関連記事

コメント

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

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