Squid のログで失敗したリクエストを見つける
access.log でトランザクション結果、cache.log で Squid 自身の障害を確認し、トンネルの状態と宛先の状態を区別します。
Debian の Squid 6 パッケージでは、まず通常のトランザクションログとデーモンログを確認します。
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.log独自のログ設定やサービスマネージャーにより、出力先が別の場所になっていることがあります。既知の送信元から範囲を限定したリクエストを一つ再現し、時刻、メソッド、宛先を記録して、正しいログ行と対応付けます。
| 証拠 | 読み取る内容 |
|---|---|
| access.log のネイティブ形式の結果 | Squid の結果コードと HTTP ステータスは、トランザクションの別々の要素です。 |
| アクセス階層情報 | 転送で親プロキシや別の経路をどう利用したか。 |
| CONNECT の成功 | トンネルが開いたことを示し、暗号化された TLS 内で後から返される Web サイトのステータスではありません。 |
| cache.log | Squid 自身のヘルパー、起動、名前解決、設定の障害。 |
一致するリクエストがなければ、そのクライアントがこのインスタンスとリスナーに到達したか確認します。ログの ACL、バッファリング、ローテーション、トランザクションがまだ継続中かを調べてください。長時間のトンネルには最終的なアクセス記録がまだない場合があります。迂回や古いプロキシプロセスにより通信が別の場所へ向かうこともあるため、アクセスポリシーを編集する前に、待ち受けプロセスと読み込み済み設定を対応付けます。
機密部分を伏せた関連トランザクションと前後のエラーを共有します。URL、クエリ、送信元アドレス、ユーザー名には私的情報が含まれ得ます。明確な必要性もなくログ全体を出力したり、ヘッダー全体のログを有効にしたりしても、有用な証拠より情報露出が増えます。