フォワードプロキシはクローラのために robots.txt を強制するか
robots ポリシーはクローラ側に置き、転送プロキシで強制することの限界を理解しましょう。
クローラに HTTP プロキシを与えると、リクエストがサイトへ届く経路は変わります。しかしプロキシが robots.txt を取得したり、クローラのルールグループを選んだり、リクエストを礼儀正しく予定したりするわけではありません。
Robots Exclusion Protocol はクローラ向けのルールを定めています。照合、取得失敗、リダイレクト、キャッシュの扱いまで含みます。要求された文書を中継するだけのプロキシは、クローラに代わってそのポリシーを実装したことにはなりません。
ルールの判断はクローラのリクエスト待ち行列の近くに置いてください。送信前に、意図した識別子、対象 URI、スケジュール状態がそろっているのはそこです。
プロキシ側のフィルタが思ったより難しい理由
平文 HTTP なら、専用に作ったフィルタが対象パスと User-Agent を見られます。それでも実際のルール実装と、該当する robots ファイルの取得・キャッシュ・更新について定めたポリシーが必要です。Disallow の数行を静的な URL ブロックに変えるだけでは、プロトコル全体ではありません。
通常の CONNECT による HTTPS では、転送プロキシが見るのはトンネルの宛先であり、暗号化された各ページのパスや内側の User-Agent ではありません。別の意図的な仕組みが与えない限り、パス単位の robots 判断に必要な情報が欠けます。
出口アドレスを変えても、禁止されたパスが許可されたパスになるわけではありません。クローラの活動を共有するワーカー間でペースを調整してください。経路の切り替えはそのポリシーの代わりになりません。
最後に、robots のルールはアクセス許可ではありません。許可されたパスは認証やサイトの他のアクセス要件を覆さず、公開された robots ファイルは非公開コンテンツを守りません。