検証時などに余計な時間をつかわないように自戒をこめて備忘録を。。
原因がわかったら大体即座に解決できる前提で対処法はあんまり書いてないです。
正しい設定するとか間違った設定をやめるとか原因がわかればできるのでは。
前にも似たのを書いたような気はするけどまあそれはそれ。
https://blog.isao.co.jp/backend_server_setting/
パブリックIPがない、NATで通信できる範囲にいない
→クラウドによって違うけど
パブリックIPがついてない、パブリックなセグメントに居ないがNATの設定ができてない通信できないとこにいる
などを疑ってコンソール確認する
名前解決ができない、
dig yahoo.co.jp
cat /etc/resolv.conf
cat /etc/hosts
cat /etc/nsswitch.conf
経路がない、GWやルーティングが間違っている、VPNなどの設定の問題や経路障害
netstat -rn
ping gw-ipaddress
ping yahoo.co.jp
なにかで遮断されている、フィルタリング設定がただしくない
→ネットワークアクセスコントロールリストやセキュリティグループなど外側からみる。
送信元や宛先のアドレスやポートに間違いがないかなど。
そのあとサーバ毎のSELinux、Firewalld、Apparmor、iptablesなどをみる
そもそもポートがListenしているのかみる
ApacheやNginxならIP制限など認証設定の部分を確認する
iptables -L
iptables -t nat -n -L
getenforce
netstat -lnpt
docker inspect conteiner-id
経由しているプロキシがまちがっている
Nginx、Haproxy、Squidなどの場合はその設定をみる。
パッケージ入れる際ならyum.confなどを確認（excludeで依存関係がアレだったこともあった）
Ansibleの場合yumモジュールのlock_timeoutの設定秒数を増やすことで解決する
（デフォが2.8からなぜか0秒で）
あとwgetやyumと何の関係もなくて内部からの通信でもないですがピンポイントな珍しいエンカウントとしては以下のようなのも。
-
fluentdの構成をLB介すようにしたらロードバランサのキューが頭打ちで握りつぶされていた
-
TCPのrecycle設定などをウッカリ有効にしていて同じIPから同時にきたwifi経由モバイル通信などが片方遮断されてる
-
アクセスする先のDBスキーマとアカウントがリセットされてた（つくりなおしで解決）またはサービスが無限ループで起動してないなど前提から疑う必要がある場合も。なにかポートListenしてるサービスならnetstatなどでわかる。
-
WindowsFireWall
これが原因でwin上のapacheのログの切り回しがうまくいかなかったとか聞いたので追記。WindowsだとVirusチェックソフトとかFW制限とかよくありそうかな。
個人的に最短ルートかなと思うのは、
わかる人に聞く、ログなどに出力されたエラーメッセージから状況判断か固有情報を除いたエラーメッセージでググる。前もって設定しておいた監視モニタで状況確認、状況を的確に表すキーワードやマニュアルがヒットしそうなマニアックなワードで気軽な気持ちで軽率にググる。
ちょっと長いルートで、その作業が繰り返しであるなら二度とやらかしようがないオートメーション組んでおく。（学習コストと対効果がどうかはものによるけど）
以上