-
DNSは引けるが特定ポートだけ通信できない原因
「DNSは正常に引ける」「pingも通る」「80番は通るのに443番だけNG」「同じIPなのにポートによって結果が違う」 この症状はネットワーク・OS・ミドルウェア・LBの どこか1箇所でも設計ミスがあると必ず発生します。 本記事では、特定ポートだけ通信できな... -
DNSは引けるが通信できない時の切り分け
「名前解決はできているのに通信できない」「digやnslookupは成功するが、curlやncが失敗する」「pingは通るのにアプリ通信だけNG」 このトラブルは現場で非常に発生頻度が高く、かつ DNSに気を取られて本質的な原因を見落としやすいのが特徴です。 本記事... -
Linuxで名前解決が不安定になる原因（resolv.conf以外）
「pingは通るのに名前解決だけ失敗する」「たまに名前解決できるが、再現性が低い」「resolv.confは正しいのにDNSエラーが出る」 このようなトラブルは、resolv.conf以外の要因が絡んでいるケースが非常に多く、 現場では切り分けに時間を取られがちです。... -
LB idle timeoutとアプリKeepAlive設計の落とし穴
ロードバランサ（LB）配下のシステムで、「通信が突然切れる」「一定時間後にRSTが返る」「再接続が頻発する」といった問題が発生する場合、LBのidle timeoutとアプリのKeepAlive設計不整合が原因であるケースが非常に多くあります。 本記事では、LB idle ... -
RSTが多発する時の原因と切り分け
はじめに TCP通信において RST（Reset）パケットが多発する 状態は、「通信が強制的に切断されている」ことを意味します。 RSTは 正常系ではほぼ出ない ため、 アプリ障害 設定ミス リソース枯渇 FW / LB の挙動 など、何らかの異常が裏に隠れているサイン... -
FIN_WAIT_1が長時間残る原因と実践的な解決方法
FIN_WAIT_1 が増え続ける状態は、 TCP切断が正常に完了していないことを示します。 放置すると ファイルディスクリプタ枯渇 コネクション枯渇 新規通信不能 につながるため、確実な対処が必要です。 本記事では、 FIN_WAIT_1 が長時間残る理由と、 実務で... -
TCP KeepAlive設定の正しい考え方【有効化すれば安心ではない】
TCP KeepAlive は、 「有効にしておけば接続が安定する」 「TIME_WAITが減る」 と誤解されがちな機能です。 しかし実際には、 使い方を間違えると障害の温床 になることも少なくありません。 本記事では、 TCP KeepAlive の正しい役割と、 実務での設計・... -
FIN_WAIT_2が残り続ける原因と対処【TCP接続異常の正体】
LinuxサーバーでTCP接続を監視していると、 FIN_WAIT_2 が大量に残り続けるという状態に遭遇することがあります。 この状態は、 接続数の異常増加 ポート枯渇 通信遅延 の前兆であることが多く、放置すると重大障害につながります。 本記事では、 FIN_WAIT... -
LinuxでTCP接続数が増え続ける原因と対策【調査から設計改善まで】
Linuxサーバーを運用していると、 「TCP接続数が時間とともに増え続け、減らない」 という現象に遭遇することがあります。 この状態を放置すると、 通信遅延 エフェメラルポート枯渇 アプリケーション停止 といった重大障害につながります。 本記事では、T... -
SELinuxポリシー設計のアンチパターン集【やってはいけない設計】
SELinuxは正しく設計すれば非常に強力ですが、 設計を誤ると「無効化したくなる存在」になります。 本記事では、現場で繰り返されてきた SELinuxポリシー設計のアンチパターンを紹介し、 なぜそれが危険なのかを解説します。 アンチパターン① とりあえず s...
