Evomi

Evomiはスイスのプロキシプロバイダーで、7年以上にわたり独自のプロキシインフラを構築してきました。プロキシ製品は5種類、スクレイピング製品は2種類を提供しており、価格モデルも市場の中でもかなり低価格帯に位置しています。例として、Core Residentialプランは$0.49/GBから利用でき、これは私たちがこれまでに見てきたレジデンシャルプロキシの中でもおそらく最安クラスです。ただし、ここでは全体像を整理し、提供されている製品と料金を説明した上で、プロキシ種別の主な違いを押さえ、ダッシュボードの使い勝手を実際に検証し、Evomiのプロキシ品質も評価します。

結論から言うと、Evomiは、倫理的に調達されたプロキシを競争力のある価格で必要とする個人開発者、小規模チーム、データエンジニアに非常に適しています。業界で最も有名なブランドというわけではありませんが、プロダクト構成はよく整理されており、いくつか注意点もあるため、それは後ほど触れます。無料トライアルが用意されているので、初めて試す際のリスクはほとんどありません。

Evomiはどの種類のプロキシを提供しているのか？

Evomiは5つの独立したプロキシ製品を提供しており、これは中堅プロバイダーの多くと比べてもかなり豊富です。少し詳しく見ると、IP単位で課金される固定（スタティック）プロキシプランが1つ、トラフィック量に応じて課金されるローテーションプロキシプランが4つ用意されています。

固定プロキシについては、プランが1種類のみで国の選択肢もやや限られるため、ここでは深掘りしません。ただし重要な点として、これらのプロキシはトラフィック無制限で、マルチアカウント運用など、長時間にわたって同じIPが必要なケースでよく使われます。

ローテーションプロキシについてはEvomiが4製品を提供しており、購入前に違いを理解しておくことが重要です。特にCore ResidentialとPremium Residentialの違いは要チェックです。というのも、基本的には同系統のプロキシでありながら機能が異なるためです。一方で、Core ResidentialはPremium Residentialのほぼ6分の1の価格です。

ここからは理屈ではなく実際の違いを、表で整理して見ていきましょう。ちなみに、この表はかなり珍しく、公式Evomiサイトにもここまで詳細な比較は掲載されていません。

主な違いは、料金、各プランに含まれる最小トラフィック量、料金の計算方法、そして設定オプションの柔軟性に集約されます。

CoreとPremiumのレジデンシャルプロキシを比較する際は、Premiumの方が実はコストパフォーマンスが良くなるケースがある点を理解しておく必要があります。Coreプランは使用する設定に応じて料金倍率が適用されるため、Premiumと同程度の大きなプロキシプールが必要だったり、詳細なISP単位のターゲティングが必要だったりする場合、すべての倍率を加味すると最終的にPremiumの方が安くなることもあります。

とはいえ、Coreのデフォルト設定で約90%の用途は十分にカバーでき、追加オプションが不要なまま終わることも珍しくありません。そのため、手頃で高品質なレジデンシャルプロキシを探しているなら、Evomiは非常に有力な選択肢です。

料金の詳細

先ほどはサブスクリプションと従量課金の観点から料金を見て、購入量によってコストがどう変化するかも示しました。ここでは料金体系をもう少し詳しく見ていきましょう。

ご覧のとおり、Core Residentialプランは購入量によって単価が変わりませんが、その他のプランは月間トラフィックが増えるほど単価が下がります。つまり、必要トラフィックが多いほど、1GBあたりのコストは安くなります。なお、Coreプランのこの価格は高度な設定を有効にしない場合に適用される点が重要です。高度な設定が必要になると、トラフィック消費に倍率がかかり、状況によってはCore Residentialより他プランの方が割安になる場合があります。

上の表はローテーション型レジデンシャルプロキシのみを扱っていますが、Evomiは固定のISPプロキシも販売しています。価格は以下のスクリーンショットで確認できます。

プロトコルとセッション設定

Evomiは、各プロキシ製品でHTTP、HTTPS、SOCKS5をサポートしています。特にCore Residentialでは、UDPとQUICをオプションの切り替えで利用できます。これは本当に珍しい仕様です。多くのレジデンシャルプロキシプロバイダーはHTTPとSOCKS5のみ対応なので、QUIC対応によってHTTP/3へ移行したモダンなWebアプリのテストなどの用途が広がります（公式HTTP/3設定ガイド参照）。QUICはHTTP/3の基盤となるトランスポートプロトコルで、TCPのハンドシェイクによるオーバーヘッドを回避できるため、不安定な回線でも高速にリクエストを送れるのが特徴です。UDP対応についても、Evomiのエキスパート設定ガイドで説明されています。Webスクレイピング用途ではブラウザ自動化ほど重要ではありませんが、選択肢として持てるのは便利です。

スティッキーセッションは、標準のエンドポイント形式で1分から120分まで設定できます。より長い固定が必要な場合は、_lifetime-1440パラメータにより最大1,440分、つまり24時間まで延長できます。さらにハードセッションモードもあり、基盤となるデバイスが接続されている限り同じIPを維持します。ハードセッションはデバイス所有者の接続状況に左右されるため持続時間は読みづらい一方、時間指定ではなく本当の意味での継続性が必要な場合に有効です。IPの多様性を最大化したい用途向けには、リクエストごとに新しいIPを割り当てるローテーションセッションもサポートされています。タスクに応じて長期固定と継続ローテーションを柔軟に選べるわけです。なお、注意点として、現時点ではIPホワイトリスト認証は利用できません。認証はユーザー名とパスワードのみです。多くの環境では問題ありませんが、インフラ側でホワイトリスト方式の認可を前提にしているチームは、この点を考慮する必要があります。

無料トライアル

Core Residential、Datacenter、Mobileの各プロキシは、事前決済なしで無料トライアルを利用できます。チェックアウトの合計は$0.00と表示されますが、トライアルを有効化するには請求情報の入力が必要で、登録プロセスの中でサブスクリプションも作成されます。これは多くのプロキシ事業者が採用している一般的な方式で、摩擦ゼロの無料アクセスは悪用を呼び込みやすいため、その抑止のために設けられています。正当な開発者がサービス評価を行う場合、請求情報の入力はちょっとした手間であり、大きな障壁ではありません。なお、トライアル期間終了後はサブスクリプションが自動更新され、事前にキャンセルしない限り該当プランの料金が請求される点には注意が必要です。無料トライアルは実質的にリスクゼロで始められる入口であり、インフラ製品の提供方法として理にかなっています。

ダッシュボードとプロキシ設定

Evomiのダッシュボードは整理されており、主に次のセクションに分かれています。

• ホーム
• 購入済みプロキシ（統計、プロキシ設定、サブスクリプション管理、ドキュメント、サポート）
• サブスクリプションを購入できる料金プラン
• プロフィール設定とサブスクリプション管理
• 一般情報とドキュメント

どのページも直感的で操作しやすいため、ここでは深入りしません。代わりに、Core Residentialプランを例に、ローテーションプロキシの設定を詳しく見ていきます。

購入が完了すると、購入済みプロキシのタブが表示されます。そこをクリックすると統計ページに移動します。プロキシ設定を開始するには、以下のスクリーンショットのように"Proxy Generator"タブをクリックします。

これでEvomiプロキシの設定を開始できます。基本的にほぼすべての設定項目にはドキュメントが紐付いており、以下のスクリーンショットのように"?"アイコンをクリックすれば参照できます。

ただし、Evomiのドキュメントが技術寄りに感じられる場合や、読む時間がない場合に備えて、各セクションを簡単に説明しておきます。

• Format Settings。 生成されるエンドポイント（プロキシ）の出力形式を制御します。右側には、エンドポイントがリアルタイムで生成される欄があります。プロトコルやロケーション設定を変更すると、プレビューに即座に反映されます。これにより、自分のワークフローに合った形式を簡単に作れます。

• Location Settings。 国、市、地域レベルでターゲティングを設定できます。特定地域のユーザーとして見せたい場合、たとえばローカルSEOの検索結果を確認したい場合や、スクレイピング対象サイトが特定国からしかアクセスできない場合に役立ちます。なお、複数国を同時に選ぶと、より詳細な市や地域のターゲティングは選べなくなります。

• Session Settings。 生成されたエンドポイント内でIPアドレスがどの頻度で変わるかを決めます。リクエストごとにローテーション、指定時間後にローテーション、できるだけ長く同一IPを維持する、といった設定が可能です。興味深い点として、リクエストごとのローテーションを選ぶと生成できるエンドポイントは1つだけです。別のセッションタイプを選ぶ場合は最大1,000個のエンドポイントを生成でき、実質的に1,000個の別プロキシを得られます。

• Expert Settings。 明確にしておくと、高度な設定はおよそ90%の用途では不要で、なくてもすぐにプロキシを使い始められます。ただし、特定のタスク向けにプロキシを細かく調整できる柔軟性が得られます。各項目には短い説明と詳細ドキュメントへのリンクが用意されているため、ここでは個別の設定はすべて取り上げません。必要であればEvomiのサポートに連絡すれば、質問にも丁寧に対応してくれます。

以上です。生成されたエンドポイント（プロキシ）は右側パネルに表示され、すぐに利用できます。

パフォーマンス指標

テスト時点で、Evomiは非常に優れたパフォーマンス結果を示しました。テストは専用のproxy checkerを用いて実施しています。毎月更新している最新の測定値（プロキシの種類ごとの成功率・応答時間・速度）は、このページ冒頭の「私たちのテスト」セクションにあります。各プロキシ種別の結果は以下のスクリーンショットで確認できます。

Mobile Proxies

Premium Residential Proxies

Core Residential Proxies

Datacenter Proxies

テスト結果をよく見ると、データセンタープロキシは主に米国に集中している一方、レジデンシャルとモバイルはロケーションがかなり多様です。これは、レジデンシャルとモバイルのプールがデータセンターのプールより大きいこと、そしてデータセンターの多くが米国にあることが理由です。

また、レジデンシャルプロキシには家庭用ISPとモバイルキャリアのIPが混在する場合がありますが、モバイルプロキシを使う場合、割り当てられるIPはモバイル事業者由来のものだけになります。

テストではランダムなロケーション割り当てを使用しましたが、ロケーション判定はISPレベルまで正確でした。また、ISPターゲティングを使ってEvomiのレジデンシャルプロキシも検証し、以下のスクリーンショットのとおり結果は優秀でした。

設定: 国: ウクライナ、ISP: Lanet Network LTD

唯一気になった点は、非常に限定的なターゲティング条件を指定すると、条件に一致するプロキシがEvomi側に存在しない場合があることです。その場合、接続やテストを試みるとプロキシが動作していないように見えることがありますが、実際にはプロキシジェネレーターで選んだ条件に合致する利用可能なIPがないだけです。本来は、該当IPが存在しない設定を選べないようシステム側で自動的に制御できるのが理想です。

テスト期間中の稼働率は100%でした。ただし、公式ステータスページのstatus.evomi.comを見ると稼働率は99.95%と報告されており、それでも十分に優秀な数値です。

動作するコード例

以下は、requestsライブラリを使い、リトライロジック、適切なタイムアウト処理、Evomiレジデンシャルプロキシ向けのセッション設定を含むPythonの例です。requestsはPythonの標準的なHTTPクライアントで、プロキシ経由のルーティングを辞書で簡単に扱えます。urllib3.util.retry.Retryクラスが自動的にリトライを管理するため、リトライ処理を手書きする必要がありません。

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

EVOMI_USER = "your_username"
EVOMI_PASS = "your_password"
# _country-us_session-mysession123_lifetime-30 形式を使用
# lifetime-30 はスティッキーセッションを30分維持するという意味。
# 24時間の最大値にするには _lifetime-1440 に変更。
PROXY_HOST = "rp.evomi.com"
PROXY_PORT = 1000 # レジデンシャル用のHTTPポート。SOCKS5なら1001を使用

proxy_url = (
 f"http://{EVOMI_USER}_country-us_session-mysession123_lifetime-30"
 f":{EVOMI_PASS}@{PROXY_HOST}:{PROXY_PORT}"
)

proxies = {
 "http": proxy_url,
 "https": proxy_url,
}

# 429（レート制限）、500、502、503、504でリトライ。
# total=3 は例外を投げる前に3回試行するという意味。
retry_strategy = Retry(
 total=3,
 backoff_factor=1.5,
 status_forcelist=[429, 500, 502, 503, 504],
 allowed_methods=["GET", "POST"],
)

adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)

headers = {
 "User-Agent": (
 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
 "AppleWebKit/537.36 (KHTML, like Gecko) "
 "Chrome/124.0.0.0 Safari/537.36"
 ),
 "Accept-Language": "en-US,en;q=0.9",
}

try:
 response = session.get(
 "https://httpbin.org/ip",
 proxies=proxies,
 headers=headers,
 timeout=(5, 30), # （接続タイムアウト, 読み取りタイムアウト）秒
 )
 response.raise_for_status()
 print(f"Exit IP: {response.json()}")
except requests.exceptions.ProxyError as e:
 print(f"Proxy connection failed: {e}")
except requests.exceptions.Timeout:
 print("Request timed out. Check session lifetime or proxy availability.")
except requests.exceptions.HTTPError as e:
 print(f"HTTP error from target: {e.response.status_code}")

ここでのtimeoutタプル(5, 30)は意図的な設定です。1つ目の値は接続タイムアウト（プロキシが接続を受け付けるまで待つ時間）、2つ目は読み取りタイムアウト（接続確立後にターゲットサーバーの応答を待つ時間）です。レジデンシャルプロキシは実デバイスを経由するため、最初のハンドシェイクで接続が遅くなることがあり、開発者がよく使うデフォルトの1秒から2秒よりも、接続タイムアウト5秒の方が現実的です。読み取りタイムアウトを無制限のままにするのはよくある失敗で、遅いターゲットに対してスクレイピングジョブが永遠に停止してしまう原因になります。

Evomiはどんな人に向いているか？

Evomiは、使いやすいUIを維持しつつ、競争力のあるGB単価で利用したい個人開発者、小規模チーム、さらに大企業にも適しています。$0.49/GBのCore Residentialは、倫理的に調達されたレジデンシャルプロキシとして本当に最安級で、無料トライアルがあるため、未検証のプロバイダーに予算を投じる際に生じがちな摩擦も軽減されます。スイス拠点で、倫理的調達を重視している点は、プロキシトラフィックの取得方法に関してコンプライアンス要件を持つチームにとって、規模を問わず重要です。

プロダクトラインは分かりやすく、価格設定も明瞭で、無料トライアルもあるため、本格導入前に自分のターゲットに対して検証しない理由はあまりありません。どのプロキシプロバイダーでもそれが妥当な評価方法ですが、Evomiはそれを簡単に実行できるようにしています。