3way handshakeで止まる時の完全診断ガイド【SYN/SYN-ACK/ACKのどこで詰まるかを見抜く】
TCP通信ができないとき、 ほとんどの原因は3way handshakeのどこかで止まっています。 しかし現場では、 「FWは開いているはず」 「pingは通る」 「ポートはLISTENしている」 という状態で原因特定に時間がかかります。 本記事では、 3way handshakeの各段...pingは通るのにTCP通信できない理由【原因の見抜き方と完全切り分け手順】
pingは成功する。 しかしSSHもHTTPも接続できない。 この状態は、 「ネットワークは正常」とは言えません。 pingはICMP（制御用プロトコル）、 TCPはセッション型通信です。 動作条件がまったく違います。 本記事では、 なぜpingは通るのか TCPが失敗する...ARPが正しいのに通信できない時に疑うべきポイント【L2正常でも止まる理由】
arp -a で確認するとMACアドレスは正しい。 スイッチのMACテーブルも正常。 それなのに通信できない。 この状態は、 ARPが原因ではありません。 本記事では、 ARPが正常なことをどう確認するか L2が成立しているのに止まる代表パターン どこまで到達してい...CDN＋LB＋nginx構成でIP制御を安全に行う方法【X-Forwarded-For設計の正解】
CDN＋ロードバランサ＋nginx構成でIP制限を実装する場合、 正しく設計しないとIP制限は簡単に突破されます。 よくある誤解： X-Forwarded-Forを見ればクライアントIPが分かる real_ip_recursiveをonにすれば安全 CDN配下ならIP偽装はできない すべて不十分...real_ip_recursiveを誤解すると起きる事故（IP偽装を招く設定ミスの正体）
nginxでX-Forwarded-Forを扱う際、多くの現場で見落とされているのが real_ip_recursive の正しい理解 です。 「とりあえずonにする」「サンプル通り設定する」 この状態で本番運用すると、 IP制限が突破される重大事故 が起きます。 本記事では、 real_ip...real_ip_header / set_real_ip_from の正しい設計（X-Forwarded-Forを安全に扱う方法）
ロードバランサ（LB）やプロキシ配下でnginxを使う場合、 real_ip_header / set_real_ip_from の設計を誤ると、IP制限が簡単に突破されます。 にもかかわらず、 とりあえずX-Forwarded-Forを使う サンプル設定をそのまま流用する といった導入が非常に多い...X-Forwarded-Forを信頼してはいけないケース（誤判定・事故を防ぐ判断基準）
ロードバランサ（LB）配下のHTTP/HTTPS構成で、 「クライアントIPはX-Forwarded-Forを見ればいい」 と説明されることは非常に多いです。 しかし実務では、 IP制限がすり抜ける ログのIPが信用できない 攻撃元を誤認する といった事故が、X-Forwarded-For（...Proxy Protocol導入時に必ずハマる罠（通信断・誤判定の正体）
ロードバランサ（LB）配下でクライアントIPを保持するために、 「Proxy Protocolを有効にしました」 ──その直後から、 通信できなくなった アプリが応答しない ログが壊れた というトラブルに直面するケースは非常に多いです。 Proxy Protocolは便利ですが...SNATありLB構成でクライアントIPを扱う設計判断（なぜ迷うのか・どう決めるのか）
ロードバランサ（LB）構成でよくある悩みが、 「SNATを有効にするとクライアントIPが見えなくなるが、これは問題なのか？」 というものです。 ログにLBのIPしか出ない アクセス制御ができない でも通信自体は正常 この状態で、 「SNATを切るべき？」「Prox...ロードバランサ配下で戻り通信が消える典型パターンと切り分け方法
ロードバランサ（LB）配下のシステムで、次のような現象に遭遇したことはないでしょうか。 クライアントからの通信はLBに届いている バックエンドサーバにも到達している しかし、レスポンスが返ってこない このとき多くの現場で言われるのが、 「ルーティ...
