事象
サーバー側：Visual SVN
クライアント側：TortoiseSVN
でsvnのチェックアウトをしたところ
しばらく応答がなく、
その後、
「502 Bad Gateway」
というエラーが出た。
結論
クライアントPC側で常駐している
セキュリティ関係のソフトウェアがhttpのポート番号(443)を塞いでいた。
（※Visual SVNはデフォルトでポート番号(443)を使用している）
ソフトウェアを無効化をしたところ、
svnのチェックアウトができるようになった。
詳細：サーバー側が原因だと思っていたが。。
「svn 502 Bad Gateway」
などの検索ワードで調べると
サーバー側に問題がある
などの記事が散見されました。
URL１:TortoiseSVN 502エラーでコミットできない
しかし、
他のクライアントPCでもチェックアウトを試みたところ
チェックアウトができました。
なので、
サーバー側の問題ではないと判断しました。
チェックアウトできるPCと
「502 Bad Gateway」できないPCを比較したところ
セキュリティ関係のソフトが常駐しているかしないか
違いだったので判明しました。
なぜ502 Bad GateWayがでるのか？
ここからは原因について深堀。
では？なぜ。502Bad Gate Wayというメッセージがでたのでしょうか？
正直わかりません。
そもそもGateWayとは
私が重宝させていただいている
「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
のサイトによると
規格の違うネットワーク間を中継してくれるもの
「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
なのですが、
今回、サーバー側もクライアント側も
同じLAN内に接続しているので、
規格違いでもなんでもないわけです。
しかも原因はセキュリティソフトなわけなんですが、、、
あれかな？
セキュリティソフト邪魔すると
svnが規格違いだと認識してしまうのかな？
またわかったら書きます。
どうすればよかったか？
解決に時間がかかったのは
テキトーにググって
サーバー側に問題があると決めつけた
ところに問題があります。
また、GateWayという意味のないメッセージにも惑わされました。
- 本当にサーバー側に問題があるのか？
- 本当にGateWayに問題があるのか？
ということを、切り分けて進めていけば最短で解決できたのかもしれません。
また、
ネットワークがつながらないといった場合、
主に
- IPは認識しているか？
- ポートは接続できているか？
という順番で考えることも重要だと思いました。
要は
- 問題の切り分けスキルの不足
- ネットワークの基礎知識不足
が今回、時間がかかってしまった原因です。
上記のスキルが備わっている人は
そもそもググる必要もなく、
私のようにブログ記事にして書き起こす必要もないわけです。
スキルのあるエンジニアってすごいですね。。
http接続は今後も接続しにくくなる
今回は
セキュリティソフトがhttpのポートを塞いでいた
と言うのが原因ですが、
svnは基本、httpのポートを介して接続するのが主流です。
なぜならhttpのポートはファイルの追加・変更なども比較的簡単にできるし、様々なアプリケーションで接続を許可しているからです。
しかし、その分、セキュリティの危険度は高くなります。
なので、強固なセキュリティソフトを導入してしまうと
今回のようにhttp接続をするようなアプリケーションは
セキュリティソフトによっては使えなくなってしまうことがおこるわけです。
どちらかと言うと、セキュリティソフトの方が正しい判断をしていると思います。
だってhttp接続は柔軟性がある分、危険なのですから。
今後もhttp接続は厳しくなっていくのだと思います。
なので、
svnやeclipseでwebアプリケーションを開発する時など
はhttp接続をメインとしているので、
制限がかかってしまうことが予想されます。
