--- title: 【AWS】低頻度で発生する ALB の ClientTLSNegotiationErrorCount を CloudFront ログから読み解く｜Nextmode Blog description: CloudFront配下のALBでClientTLSNegotiationErrorCountが低頻度で計上される事象について、CloudFront標準ログとALB接続ログを突合して調査しました。証明書やTLS設定に不備がなくても、ビューワー側の通信中断で計上されることを再現試験で確認しました。 image: https://info.nextmode.co.jp/hubfs/Blog_aws.png --- [![nextmode blog](https://info.nextmode.co.jp/hubfs/raw_assets/public/NextMode_Theme/nextmode%20blog.png)](https://info.nextmode.co.jp/blog) [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) [資料請求](https://info.nextmode.co.jp/request/) [お問い合わせ](https://nextmode.co.jp/contact/) - [会社TOP](https://nextmode.co.jp/) - [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/) - [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/) - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/) - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/) - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/) - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/) - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/) - [AWS総合支援](https://nextmode.co.jp/services/aws/) - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/) - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/) - [導入事例](https://nextmode.co.jp/casestudy/) - [会社情報](https://nextmode.co.jp/company/) - [セミナー](https://info.nextmode.co.jp/seminar/) - [ブログ](https://info.nextmode.co.jp/blog) [![YouTube](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/@nextmode) 目次 2026/08/13 15:00 # 【AWS】低頻度で発生する ALB の ClientTLSNegotiationErrorCount を CloudFront ログから読み解く [» AWS](https://info.nextmode.co.jp/blog/tag/aws) [» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» 運用](https://info.nextmode.co.jp/blog/tag/運用) [![yuki](https://info.nextmode.co.jp/hs-fs/hubfs/avator_yukinawa.jpg?width=40&name=avator_yukinawa.jpg) yuki](https://info.nextmode.co.jp/blog/author/yuki) 共有： [facebook-f icon](http://www.facebook.com/share.php?u=https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect) [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect) [Twitter icon](https://twitter.com/intent/tweet?url=https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect) [pinterest-p icon](http://pinterest.com/pin/create/link/?url=https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect) [envelope icon](mailto:?body=https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect) ## はじめに --- こんにちは、ネクストモードのゆきなわです。 CloudFront のオリジンに Application Load Balancer（ALB）を設定した環境で、[ALB の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) `ClientTLSNegotiationErrorCount` がごく低頻度で断続的に計上されていたため、原因を調査しました。本記事では、実環境のログを調べ、検証環境でリクエストを意図的に中断して再現した過程を紹介します。 > **本記事のポイント** > > - ビューワーから CloudFront へのリクエストを中断する試験で、その先の ALB に TLS 接続の失敗が記録されるケースを再現しました。このとき、CloudWatch メトリクスと ALB 接続ログでは、TLS エラーの件数も一致しました。 > - ただし、何 ms 以内に中断すると発生する、といった明確な閾値は確認できず、同じ中断タイミングでも発生件数にばらつきがありました。 > - 証明書や TLS 設定に不備がなくても、ALB の `ClientTLSNegotiationErrorCount` は計上されることがあります。今回は CloudFront と ALB の 5xx やオリジン系のエラーは観測されませんでした。 関連記事として、CloudFront から ALB への TLS ハンドシェイクに起因する 502 エラーを調査した、[まなべ](https://info.nextmode.co.jp/blog/author/manabe)による下記記事もあわせてご覧ください。 ## 低頻度で計上される ClientTLSNegotiationErrorCount --- 調査対象は、CloudFront、ALB、バックエンド（EC2）からなる企業 Web サイトです。CloudFront から ALB への通信にも HTTPS を使用しており、この区間の TLS は ALB で終端しています。平日の日中にアクセスが集中し、1 日あたり数百万件規模のリクエストを処理します。運用監視では、ALB の `ClientTLSNegotiationErrorCount` が全体のリクエスト数に対してごく低頻度で断続的に計上される状況が続いていました（下図）。ただし、5xx エラーは伴っておらず、メトリクスの集計値だけでは原因が判断できない状況でした。 ![実環境の CloudWatch メトリクス。ALB の ClientTLSNegotiationErrorCount が低頻度で断続的に計上されている](https://info.nextmode.co.jp/hs-fs/hubfs/figure-00-clienttlsnegotiationerrorcount-metrics-1.png?width=4564&height=2414&name=figure-00-clienttlsnegotiationerrorcount-metrics-1.png) *実環境で断続的に計上された ClientTLSNegotiationErrorCount* なお、本システムでは、[マネージドプレフィックスリスト](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list)を用いて、ALB への接続元を CloudFront に限定しています。そのため、ALB に TLS 接続するクライアントは CloudFront であり、このメトリクスは CloudFront と ALB の間の TLS 接続の失敗回数を表しています。以降、CloudFront へ接続する側を**ビューワー**、接続先の ALB を**オリジン**と呼びます。 ### ログ調査 同じ時間帯について、次の 3 点を確認しました。 - `ClientTLSNegotiationErrorCount`（CloudFront → ALB）：TLS セッションを確立できなかった接続の集計値 - [ALB 接続ログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-connection-logs.html)の `Failed:UnmappedConnectionError`：失敗した個々の接続のステータス / 理由。送信元は CloudFront のオリジン向け IP アドレス - [CloudFront 標準ログ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html)の `ClientCommError`（ビューワー → CloudFront）：ビューワーとの通信上の問題により応答が中断されたリクエストの結果タイプ 対象とした時間帯（平日日中の 7 時間）の ALB 接続ログでは、106,232 接続のうち 32 件（約 0.03%）が `Failed:UnmappedConnectionError` で失敗していました。いずれも CloudFront のオリジン向け IP アドレスからの TLS 1.2・ハンドシェイク未完了の接続でした。1 秒単位で見ると 32 件は 16 秒に分布しており、その 16 秒すべてで、CloudFront ログにも `ClientCommError` が記録されていました。 一方、この時間帯全体では、`ClientCommError` が記録された秒は約 1 割でした。この時間的な重なりに加え、大半の接続は同じ条件で成功し、同じ時刻に 5xx やオリジン系のエラーも見られなかったことから、設定の不備による恒常的な失敗というより、個々のビューワーの通信中断に関連するものではないかと考えました。 ### 仮説 公開情報では、CloudFront が応答する前にビューワーが接続を閉じた場合は `sc-status = 000`、CloudFront とビューワー間の通信上の問題で応答が中断した場合は `ClientCommError` が記録されると説明されています。また、TLS 確立前の失敗は [ALB 接続ログで確認できます](https://dev.classmethod.jp/articles/tsnote-alb-clienttlsnegotiationerrorcount-not-found-in-access-logs/)。ただし、**ビューワー側の通信中断がオリジン TLS 接続の失敗として現れるか**を両者のログで突き合わせた事例は、調べた範囲では見つかりませんでした。 そこで、次の仮説を立てました。 > ビューワーがレスポンスの完了前にリクエストを中断すると、CloudFront はビューワーとの通信を `ClientCommError` として記録する。その時点で CloudFront から ALB への TLS 接続が確立途中だった場合、その接続も完了せず、ALB では `ClientTLSNegotiationErrorCount` と `Failed:UnmappedConnectionError` として記録される。 CloudFront 標準ログと ALB 接続ログには共通の接続 ID がなく、実環境のログだけでは個々の接続を一対一に結びつけられません。そのため、本番から切り離した検証環境を構築し、意図的にリクエストを中断して同じ組み合わせが現れるかどうかを検証しました。 ## 検証方法 --- ビューワー → CloudFront → ALB → バックエンドという通信経路を、検証用に単純化し最小構成で用意しました（下図）。 ![検証環境の構成図。テストクライアントから CloudFront を経由し、ALB、バックエンドへと接続する](https://info.nextmode.co.jp/hs-fs/hubfs/figure-01-aws-architecture.png?width=3082&height=1500&name=figure-01-aws-architecture.png) *検証環境の構成* 主な条件は次の通りです。 - CloudFront のキャッシュを無効化し、各リクエストがオリジン経路を通るようにする - CloudFront から ALB へは、実環境でエラーが記録された接続と同じ HTTPS（HTTP/1.1、TLS 1.2）で接続する - バックエンドは 2 秒待ってから応答し、レスポンスが返る前にストリームを中断できる状態を保つ（CloudFront と ALB 間の TLS ハンドシェイクを遅らせる設定ではない） - CloudFront 標準ログ、ALB アクセスログ、ALB 接続ログ、CloudWatch メトリクスを同じ試験時間帯で突合する テストクライアントは Node.js の `http2` モジュールで実装しました。1 本の HTTP/2 セッション上に複数のストリームを作成し、リクエスト開始から一定時間後に `RST_STREAM(CANCEL)` を送ります。この待ち時間（`cancelAfterMs`）を以降では**中断タイミング**と呼びます。 ストリームの中断に関係する部分を抜粋すると、以下の通りです。 ``` const stream = session.request(headers, { endStream: true }); setTimeout(() => { if (!stream.closed && !stream.destroyed) { stream.close(constants.NGHTTP2_CANCEL); } }, cancelAfterMs); ``` 試行の構成は次の通りです。 - 1 試行は 3 ラウンド × 300 リクエストの計 900 ストリーム（HTTP/2 では 1 リクエストが 1 ストリームに対応） - 同時実行数は 100、ラウンド間隔は 6 秒 - リクエスト頻度は実測で約 64 リクエスト/秒（中断タイミングを 10 ms に設定した試行） このリクエスト頻度は、単純平均では実環境（CloudFront で平均約 59 リクエスト/秒）と同程度です。ただし、クライアント数やセッション数、リクエストの時間分布まで再現した負荷試験とはしていません。 なお、テストクライアントから CloudFront までの HTTP/2 ストリームと、CloudFront から ALB への HTTP/1.1 接続は別の通信区間です。CloudFront はオリジンとの接続を独自に確立・再利用するため、ストリーム数と ALB 側の接続数は一対一には対応しない点にご注意ください。 試験中の通信の流れは次の通りです（下図）。 ![ストリーム中断時の通信の流れ。テストクライアントが CloudFront へ HTTP/2 ストリームを中断すると、CloudFront から ALB への TLS ハンドシェイク中の接続が終了し、ALB で TLS エラーが記録される](https://info.nextmode.co.jp/hs-fs/hubfs/figure-02-http2-cancel-sequence.png?width=1926&height=2050&name=figure-02-http2-cancel-sequence.png) *ストリーム中断時の通信の流れ* ## 結果 --- ### エラーの再現 | 中断タイミング | 中断したストリーム | TLS エラー （CloudWatch メトリクス） | TLS エラー （ALB 接続ログ） | | --- | --- | --- | --- | | 10 ms | 900 / 900 | 7 | 7 | **10 ms の試行では、CloudWatch の `ClientTLSNegotiationErrorCount` が 7 件、同じ集計時間帯の ALB 接続ログにある `Failed:UnmappedConnectionError` も 7 件となり、件数が一致しました。** 証明書や TLS 設定を変更せず、ビューワー側のストリームを中断した試験で、実環境と同じメトリクスと接続ログの組み合わせが現れました。7 接続はいずれも TLS 1.2・実環境と同じ暗号スイートで、`tls_handshake_latency` は `-`（ハンドシェイク未完了）でした。同じ時間帯の CloudFront ログには `ClientCommError` が記録され、5xx は 0 件でした。なお、TLS エラーの 7 件は ALB への接続単位の件数で、中断した 900 ストリームとはカウントする対象が異なります。 ### 中断タイミングを変えた追加試験 その他の条件は変えず、中断タイミングだけを 10〜250 ms の範囲で段階的に変えた追加試験も行いました。ALB 接続ログでは、合計 32,874 接続のうち 1,311 件で TLS エラーを観測しました。なお、この件数は意図的に大量の中断を発生させた検証条件でのもので、実環境の発生率を示すものではない点にご留意ください。 また、発生の有無を分ける明確な閾値は見つかりませんでした。中断タイミングと発生件数は単純な比例関係にならず、同じ 10 ms でも試行によって件数が変わるなど、観測上は確率的に現れる振る舞いを示しました。実測では 10 ms の設定でも、ストリームが閉じるまでの平均時間は試行によって約 94〜116 ms でした。 上記の結果は、設定した時間そのものではなく、TLS ハンドシェイク中のオリジン接続とビューワー側の中断が重なった場合に発生する、という仮説と整合しています。ただし、CloudFront 内部の接続終了処理は直接観測できないため、あくまでもログと試験結果に基づいた推定になります。 ## 調査と検証から分かったこと --- 1. **ビューワー側の通信中断とオリジン側の記録**：TLS ハンドシェイク中の接続が終了すれば失敗として記録されること自体は、仕組み上は自然です。個々の接続を一対一に追跡したわけではありませんが、ビューワー側のストリームを中断する試験で、CloudFront の `ClientCommError`、ALB の `ClientTLSNegotiationErrorCount`、接続ログの `Failed:UnmappedConnectionError` が揃って現れました。 2. **実環境での見立て**：実環境では読み込み中の離脱や再読み込み、画面遷移などで、リクエストが途中で中断されることがあります。一方で、CloudFront は[オリジンとの接続を再利用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-persistent-connections)ため、TLS ハンドシェイクが発生するのは新規に接続を確立する一部のリクエストに限られます。中断がたまたまこのハンドシェイクと重なったときにだけ TLS エラーが記録されるとすれば、計上がごく低頻度で断続的だったことも自然に説明できそうです。 3. **証明書や TLS 設定に不備がなくても計上されるケース**：今回は同じ TLS 1.2 と暗号スイートで大半の接続が成功し、失敗は断続的でした。少なくとも、証明書や TLS 設定の恒常的な不備だけでは説明しにくい結果でした。 4. **メトリクスとログによる影響範囲と原因の切り分け**：ALB 接続ログでは、総接続数に占める TLS 接続失敗の割合と失敗理由を確認します。あわせて、ALB とターゲットの 5xx、CloudFront の 5xx エラー率、CloudFront 標準ログの結果タイプ（`ClientCommError` やオリジン系エラー）も同じ時間帯で見ます。今回はこれらを突合し、TLS エラーが `ClientCommError` と同じ時間帯に低頻度で発生し、CloudFront、ALB、ターゲットの障害を示す 5xx を伴わないことを確認しました。ただし、該当リクエストでは、ビューワーへのレスポンスが中断されたことが `ClientCommError` として記録されています。 ## おわりに --- 本記事では、低頻度で計上される `ClientTLSNegotiationErrorCount` について、実環境のログ調査から検証環境での再現までを紹介しました。接続が途中で終われば TLS ハンドシェイクも失敗するという意味では当たり前の結果ですが、ビューワー側の中断がオリジン側の記録にも現れるかどうかは必ずしも自明ではありませんでした。   検証の結果、ALB 接続ログに失敗が記録され、`ClientTLSNegotiationErrorCount` にも計上される場合があること、また、記録の有無は中断のタイミングによってばらつくことを確認しました。 調査には、運用で取得していた ALB 接続ログと CloudFront 標準ログを利用しました。両者を突き合わせることで、HTTP リクエストとして記録される前に発生した接続失敗まで追うことができました。本記事がメトリクスだけでは判断がつかない事象を調査する際の参考になれば幸いです。 ## 参考ドキュメント --- - [Application Load Balancer の CloudWatch メトリクス - AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) - [Application Load Balancer の接続ログ - AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-connection-logs.html) - [CloudFront 標準ログのフィールド - AWS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html) - [カスタムオリジンのリクエストとレスポンスの動作 - AWS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) - [CloudFront マネージドプレフィックスリスト - AWS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) - [ALB の ClientTLSNegotiationErrorCount メトリクスが記録されているのにアクセスログに出力されないのはなぜですか - DevelopersIO](https://dev.classmethod.jp/articles/tsnote-alb-clienttlsnegotiationerrorcount-not-found-in-access-logs/) ### 関連記事 [![【AWS】CloudFront＋ALB構成で遭遇した502（OriginCommError）の調査記録](https://info.nextmode.co.jp/hubfs/Blog_aws.png) 【AWS】CloudFront＋ALB構成で遭遇した502（OriginCommError）の調査記録 ![](https://info.nextmode.co.jp/hubfs/%E3%83%97%E3%83%AD%E3%83%95/IMG_6316%20-%20%E3%82%B3%E3%83%94%E3%83%BC.png) まなべ 2026/08/11](https://info.nextmode.co.jp/blog/cloudfront-alb-502-sni-default-certificate) [![【AWS】Claude Platform on AWSの利用状況の詳細を可視化したい](https://info.nextmode.co.jp/hubfs/aws_ai.png) 【AWS】Claude Platform on AWSの利用状況の詳細を可視化したい ![](https://info.nextmode.co.jp/hubfs/Gemini_Generated_Image_pw0ms8pw0ms8pw0m.png) ホワイトバード先輩 2026/07/22](https://info.nextmode.co.jp/blog/aws-claude-platform-on-aws-visualization) [![【Oktane26】セッション：Okta Workflows 顧客事例と今後のロードマップ](https://info.nextmode.co.jp/hubfs/%E3%83%96%E3%83%AD%E3%82%B0%EF%BC%BF%E3%82%AD%E3%83%BC%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB/oktane26.png) 【Oktane26】セッション：Okta Workflows 顧客事例と今後のロードマップ ![](https://info.nextmode.co.jp/hubfs/kusumi.png) kusumin 2026/09/24](https://info.nextmode.co.jp/blog/oktane26-workflows-flowcase) ### Category [» 技術](https://info.nextmode.co.jp/blog/tag/技術) [» Okta](https://info.nextmode.co.jp/blog/tag/okta) [» Notion](https://info.nextmode.co.jp/blog/tag/notion) [» イベントレポート](https://info.nextmode.co.jp/blog/tag/イベントレポート) [» Netskope](https://info.nextmode.co.jp/blog/tag/netskope) [» CrowdStrike](https://info.nextmode.co.jp/blog/tag/crowdstrike) [» Notion AI](https://info.nextmode.co.jp/blog/tag/notion-ai) [» AWS](https://info.nextmode.co.jp/blog/tag/aws) [» Asana](https://info.nextmode.co.jp/blog/tag/asana) [» カルチャー](https://info.nextmode.co.jp/blog/tag/カルチャー) [» ワーケーション](https://info.nextmode.co.jp/blog/tag/ワーケーション) [» 生成AIセキュリティ対策シリーズ](https://info.nextmode.co.jp/blog/tag/生成aiセキュリティ対策シリーズ) [» Oktane25](https://info.nextmode.co.jp/blog/tag/oktane25) [» SaaS](https://info.nextmode.co.jp/blog/tag/saas) [» re:Invent](https://info.nextmode.co.jp/blog/tag/reinvent) [» AI](https://info.nextmode.co.jp/blog/tag/ai) [» リモートワーク](https://info.nextmode.co.jp/blog/tag/リモートワーク) [» Keeper](https://info.nextmode.co.jp/blog/tag/keeper) [» ネクストモードアドベントカレンダー2024](https://info.nextmode.co.jp/blog/tag/ネクストモードアドベントカレンダー2024) [» Oktane24](https://info.nextmode.co.jp/blog/tag/oktane24) [» Oktane23](https://info.nextmode.co.jp/blog/tag/oktane23) [» Asana AI](https://info.nextmode.co.jp/blog/tag/asana-ai) [» Slack](https://info.nextmode.co.jp/blog/tag/slack) [» Oktane26](https://info.nextmode.co.jp/blog/tag/oktane26) [» OIGシリーズ](https://info.nextmode.co.jp/blog/tag/oigシリーズ) [» その他](https://info.nextmode.co.jp/blog/tag/その他) [» 脱Excelシリーズ](https://info.nextmode.co.jp/blog/tag/脱excelシリーズ) [» Oktane22](https://info.nextmode.co.jp/blog/tag/oktane22) [» SysCloud](https://info.nextmode.co.jp/blog/tag/syscloud) [» Google](https://info.nextmode.co.jp/blog/tag/google) [» HubSpot](https://info.nextmode.co.jp/blog/tag/hubspot) [» Zapier](https://info.nextmode.co.jp/blog/tag/zapier) [» Azure AD](https://info.nextmode.co.jp/blog/tag/azure-ad) [» Entra ID](https://info.nextmode.co.jp/blog/tag/entra-id) [» Googleドライブ](https://info.nextmode.co.jp/blog/tag/googleドライブ) [» SentinelOne](https://info.nextmode.co.jp/blog/tag/sentinelone) [» ゼロトラスト](https://info.nextmode.co.jp/blog/tag/ゼロトラスト) [» DocuSign](https://info.nextmode.co.jp/blog/tag/docusign) [» Jamf](https://info.nextmode.co.jp/blog/tag/jamf) [» セキュリティ対策](https://info.nextmode.co.jp/blog/tag/セキュリティ対策) [» トラブルシューティング](https://info.nextmode.co.jp/blog/tag/トラブルシューティング) [» 利用者目線](https://info.nextmode.co.jp/blog/tag/利用者目線) [» 運用](https://info.nextmode.co.jp/blog/tag/運用) [» GitHub](https://info.nextmode.co.jp/blog/tag/github) [» GitHub Gist](https://info.nextmode.co.jp/blog/tag/github-gist) [» JOUG](https://info.nextmode.co.jp/blog/tag/joug) [» Notion Calendar](https://info.nextmode.co.jp/blog/tag/notion-calendar) [» Proflly](https://info.nextmode.co.jp/blog/tag/proflly) [» kintone](https://info.nextmode.co.jp/blog/tag/kintone) [![ネクストモード株式会社](https://nextmode.co.jp/assets/images/common/logo_white.svg)](https://nextmode.co.jp/) Service - [生成AIセキュリティ](https://nextmode.co.jp/services/ai/security/) - [SaaSライセンス＆サポート](https://nextmode.co.jp/services/saas/) - [Oktaライセンス＆サポート](https://nextmode.co.jp/services/saas/okta/) - [Netskopeライセンス＆サポート](https://nextmode.co.jp/services/saas/netskope/) - [Notionライセンス＆サポート](https://nextmode.co.jp/services/saas/notion/) - [Asanaライセンス＆サポート](https://nextmode.co.jp/services/saas/asana/) - [SysCloudライセンス＆サポート](https://nextmode.co.jp/services/saas/syscloud/) - [CrowdStrikeライセンス＆サポート](https://nextmode.co.jp/services/saas/crowdstrike/) - [Keeperライセンス＆サポート](https://nextmode.co.jp/services/saas/keeper/) - [AWS総合支援](https://nextmode.co.jp/services/aws/) - [AWS導入コンサル・構築](https://nextmode.co.jp/services/aws_consulting/) - [AWS運用・保守代行](https://nextmode.co.jp/services/aws_operation/) Company - [会社情報](https://nextmode.co.jp/company/) - [サービス一覧](https://nextmode.co.jp/services/) - [導入事例](https://nextmode.co.jp/casestudy/) - [お知らせ](https://nextmode.co.jp/news/) - [サステナビリティ](https://nextmode.co.jp/sustainability/) - [採用](https://nextmode.co.jp/recruit/) - [私たちの働き方](https://nextmode.co.jp/workstyle/) - [カルチャー](https://nextmode.co.jp/culture/) Contact - [お問い合わせ](https://nextmode.co.jp/contact/) - [資料請求](https://info.nextmode.co.jp/request/) Media - [セミナー](https://info.nextmode.co.jp/seminar) - [ブログ](https://info.nextmode.co.jp/blog) - [ホワイトペーパー](https://info.nextmode.co.jp/white-paper/) - [![ネクストモード公式YouTubeチャンネル](https://nextmode.co.jp/assets/images/common/icon_youtube.svg)](https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA) - [![ネクストモード公式Xアカウント](https://nextmode.co.jp/assets/images/common/icon_x.svg)](https://twitter.com/Nextmode_Inc) [English](https://nextmode.co.jp/en/) - [NTTグループカスタマーハラスメント基本方針](https://group.ntt/jp/group/customer_harassment/) - [就活ハラスメント防止方針](https://docs.nextmode.co.jp/nextmode_recruit_harassment.pdf) - 運用アシスタント利用規約([AWS](https://docs.nextmode.co.jp/nextmode-unyo-assistant-aws-terms-of-use.pdf)/[Azure](https://docs.nextmode.co.jp/nextmode-unyo-assistant-azure-terms-of-use.pdf)) - [日中運用支援定型約款](https://docs.nextmode.co.jp/nextmode-nittyu-unyo-shien-terms-of-use.pdf) - [定型約款](https://docs.nextmode.co.jp/nextmode-standard-contracts.pdf) [プライバシーポリシー](https://nextmode.co.jp/company/privacy.html) Copyright(c) Nextmode, Inc. ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "yuki", "url" : "https://info.nextmode.co.jp/blog/author/yuki" }, "dateModified" : "2026-08-13T06:53:41.839Z", "datePublished" : "2026-08-13T06:00:00.000Z", "headline" : "【AWS】低頻度で発生する ALB の ClientTLSNegotiationErrorCount を CloudFront ログから読み解く｜Nextmode Blog", "image" : [ "https://info.nextmode.co.jp/hubfs/Blog_aws.png" ], "mainEntityOfPage" : { "@id" : "https://info.nextmode.co.jp/blog/alb-clienttlsnegotiationerrorcount-cloudfront-client-disconnect", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://info.nextmode.co.jp/hubfs/nm_l_color.png" }, "name" : "ネクストモード株式会社" } } ``` ```json { "@context" : "https://schema.org", "@id" : "https://nextmode.co.jp/#organization", "@type" : "Organization", "alternateName" : "Nextmode, Inc.", "logo" : "https://nextmode.co.jp/assets/images/common/logo_white.svg", "name" : "ネクストモード株式会社", "sameAs" : [ "https://www.youtube.com/channel/UCeW8ocoe9C3E0GOINh167MA", "https://twitter.com/Nextmode_Inc", "https://info.nextmode.co.jp/" ], "url" : "https://nextmode.co.jp/" } ```