コマンド編– category –

「名前解決はできているのに通信できない」「digやnslookupは成功するが、curlやncが失敗する」「pingは通るのにアプリ通信だけNG」 このトラブルは現場で非常に発生頻度が高く、かつ DNSに気を取られて本質的な原因を見落としやすいのが特徴です。 本記事...

「pingは通るのに名前解決だけ失敗する」「たまに名前解決できるが、再現性が低い」「resolv.confは正しいのにDNSエラーが出る」 このようなトラブルは、resolv.conf以外の要因が絡んでいるケースが非常に多く、 現場では切り分けに時間を取られがちです。...

ロードバランサ（LB）配下のシステムで、「通信が突然切れる」「一定時間後にRSTが返る」「再接続が頻発する」といった問題が発生する場合、LBのidle timeoutとアプリのKeepAlive設計不整合が原因であるケースが非常に多くあります。 本記事では、LB idle ...

はじめに TCP通信において RST（Reset）パケットが多発する 状態は、「通信が強制的に切断されている」ことを意味します。 RSTは 正常系ではほぼ出ない ため、 アプリ障害 設定ミス リソース枯渇 FW / LB の挙動 など、何らかの異常が裏に隠れているサイン...

FIN_WAIT_1 が増え続ける状態は、 TCP切断が正常に完了していないことを示します。 放置すると ファイルディスクリプタ枯渇 コネクション枯渇 新規通信不能 につながるため、確実な対処が必要です。 本記事では、 FIN_WAIT_1 が長時間残る理由と、 実務で...

TCP KeepAlive は、 「有効にしておけば接続が安定する」 「TIME_WAITが減る」 と誤解されがちな機能です。 しかし実際には、 使い方を間違えると障害の温床 になることも少なくありません。 本記事では、 TCP KeepAlive の正しい役割と、 実務での設計・...

LinuxサーバーでTCP接続を監視していると、 FIN_WAIT_2 が大量に残り続けるという状態に遭遇することがあります。 この状態は、 接続数の異常増加 ポート枯渇 通信遅延 の前兆であることが多く、放置すると重大障害につながります。 本記事では、 FIN_WAIT...

Linuxサーバーを運用していると、 「TCP接続数が時間とともに増え続け、減らない」 という現象に遭遇することがあります。 この状態を放置すると、 通信遅延 エフェメラルポート枯渇 アプリケーション停止 といった重大障害につながります。 本記事では、T...

SELinuxは正しく設計すれば非常に強力ですが、 設計を誤ると「無効化したくなる存在」になります。 本記事では、現場で繰り返されてきた SELinuxポリシー設計のアンチパターンを紹介し、 なぜそれが危険なのかを解説します。 アンチパターン① とりあえず s...

SELinux運用で最も多い事故の一つが、 「chconで直したはずなのに、再起動したら元に戻った」 というケースです。 この原因は、chcon と semanage fcontext の役割の違いを 正しく理解していないことにあります。 本記事では、両者の違いを仕組みから整理...