無料プロキシのIPアドレスとポートが見つかっても、そのまま業務データの取得に使えるとは限りません。通信を中継する相手の運営元、記録の扱い、利用条件を確認できるかが先に問題になります。
Requestsにはプロキシを指定する機能があります。ただし、接続できたことは、そのプロキシを信頼できる根拠にはなりません。ここでは公開リストの推奨や稼働保証をせず、設定の読み方と、管理できる環境での確認方法を扱います。
プロキシが通信の間に入る
プロキシは接続先へ直接送る通信を別のサーバーで中継する仕組みです。どの情報が中継側から見えるかは、通信方式やTLSの終端位置によって変わります。プロキシを使うというだけで、匿名性や暗号化が保証されるわけではありません。
運営元が分からない接続先へ、ログイン情報、社内URL、顧客データを流す判断は避けます。無料か有料かという料金区分だけで、安全性や速度の優劣を決めることもできません。必要なら、組織で承認された接続先や、取得先が用意するAPIを確認します。
RequestsのキーとURLの違い
proxies辞書のhttpとhttpsは取得先URLの方式を表します。一方、値に書くURLの先頭は、プロキシへの接続方式です。
例えば、httpsのキーにhttpで始まるプロキシURLを指定する形もあります。取得先がHTTPSだからといって、値も機械的にhttpsへ書き換える設定ではありません。実際に対応する方式や認証方法は、プロキシ側の案内に従います。
Requestsの公式資料は、環境変数のプロキシ設定がSession.proxiesと干渉する場合を説明しています。個別の通信を確認するときは、そのリクエストのproxies引数に明示します。接続先を変える前に、HTTP_PROXY、HTTPS_PROXY、NO_PROXYなど既存設定の有無も確認します。
管理できるテスト環境で一度だけ確認する
次は手元で用意したHTTPページと、使用を許可されたHTTPプロキシがある場合の例です。127.0.0.1:8000が取得先、127.0.0.1:8080が中継先という架空の構成です。コードだけではプロキシサーバーは起動しません。
import requests
url = "http://127.0.0.1:8000/example.html"
proxy = "http://127.0.0.1:8080"
proxies = {"http": proxy, "https": proxy}
response = requests.get(
url,
proxies=proxies,
timeout=(3, 10),
allow_redirects=False,
)
if response.status_code != 200:
raise RuntimeError(f"取得を止めました: HTTP {response.status_code}")
print(response.status_code)
print(response.headers.get("Content-Type"))
print(response.text[:100])起動していないポートを指定すれば接続に失敗します。失敗時に別の公開プロキシを次々と試す構成にはしていません。接続先とポート、プロキシが対応する方式、認証、タイムアウトの順に確認できます。
この例では、手元のHTTPサーバーへローカルの中継を通し、指定した取得先が中継側の記録に残ることを確認しました。公開されている無料プロキシやHTTPSの通信は検証していません。
証明書エラーや拒否を設定変更だけで消さない
HTTPSで証明書エラーが出ても、verify=Falseで検証を無効にする方法を解決策にしないようにします。Requestsの公式資料でも、検証を無効にすると相手の証明書を受け入れ、中間者攻撃に弱くなることが説明されています。組織のプロキシで証明書が必要なら、管理者の案内と信頼する証明書の設定を確認します。
取得先から拒否やアクセス制限を受けた場合は、許可された取得方法と利用条件へ戻ります。プロキシの切り替えは、取得許可の代わりにはなりません。設定例が動くかという技術上の確認と、その経路で取得してよいかという判断を分けて進めます。
関連する作業
取得を始める前の確認と、Pythonでの取得・保存の流れは次の記事にまとめています。
