FineProxy

プロキシタイプ

利用可能な国々

インターフェース言語

支払い方法

統合

仕様書

IPアドレスローテーション

無料お試し

都市別ターゲティング

価格設定

のトップ9の代替案 FineProxy

DataImpulse

⭐ 4.9

💰 から $0.45

🌍 195 国

📡 モバイルプロキシ, レジデンシャルプロキシ, データセンタープロキシ

詳細情報

Webshare

⭐ 4.9

💰 から $0.0224

🌍 195 国

📡 レジデンシャルプロキシ, ISP プロキシ, データセンタープロキシ

詳細情報

Geonix

⭐ 4.88

💰 から $0.07

🌍 200+ 国

📡 モバイルプロキシ, レジデンシャルプロキシ, 個別 IPv6 プロキシ, ISP プロキシ, データセンタープロキシ

詳細情報

ProxyLine

⭐ 4.7

💰 から $0.48

🌍 100+ 国

📡 個別 IPv6 プロキシ, データセンタープロキシ

詳細情報

Froxy

⭐ 4.85

💰 から $0.6

🌍 200+ 国

📡 モバイルプロキシ, レジデンシャルプロキシ, データセンタープロキシ

詳細情報

Proxy Seller

⭐ 4.99

💰 から $0.05

🌍 220 国

📡 モバイルプロキシ, レジデンシャルプロキシ, 個別 IPv6 プロキシ, ISP プロキシ, データセンタープロキシ

詳細情報

ProxyEmpire

⭐ 4.85

💰 から $0.35

🌍 170+ 国

📡 モバイルプロキシ, レジデンシャルプロキシ, ISP プロキシ, データセンタープロキシ

詳細情報

NinjasProxy

⭐ 4.8

💰 から $0.9

🌍 国

📡 モバイルプロキシ, レジデンシャルプロキシ, ISP プロキシ, データセンタープロキシ

詳細情報

Netnut

⭐ 4.75

💰 から $0.5

🌍 195+ 国

📡 モバイルプロキシ, レジデンシャルプロキシ, ISP プロキシ, データセンタープロキシ, アンブロッカー

詳細情報

私たちのレビュー

著者 Caproxy Team

公開日： 2026-01-11
最終更新： 2026-05-15

61

Fineproxyは2011年からサービスを提供しており、プロキシ業界の年数換算で言えばほとんど「古参」です。この間に多くのことが変わりました。アンチボットの仕組みは賢くなり、レジデンシャルプールは巨大化し、市場全体はGB課金へと大きく舵を切りました。Fineproxyは基本的にその流れに乗っていません。今でもトラフィック上限なしの定額、IP単位課金を続けています。これは、何を作っているか次第で強みになることもあれば、警戒すべき点にもなり得ます。本レビューでは、彼らが実際にどんな事業者なのか、プロダクトが現場でどう見えるのか、そしてどこで有効で（あるいは有効でない）かを掘り下げます。

Fineproxyとは

端的に言うと、彼らは自社ハードウェアを運用するデータセンターおよびISPプロキシのプロバイダーです。自社でIPv4アドレス空間とASNを保有し、Tier IIIおよびTier IVのデータセンターにまたがる500台超のサーバーを運用しています。さらに、100,000個以上の専用IPv4アドレスプールを持っています。この「ASNを自前で持っている」という点は、多くのレビューが十分に評価していない重要ポイントです。プロバイダーがブローカーからIPブロックを大量に買い付けて再販している場合、rDNSレコードやBGPアナウンスの履歴、ASNの評判は、以前の所有者からそのまま引き継がれてしまいます。Fineproxyのアドレスは自社ASNでアナウンスされるため、ASNレベルの評判が一貫して予測しやすいという利点があります。もっとも、狙うターゲットによっては、それが良くも悪くも働きます。

同社は69カ国で22,000社以上のクライアントにサービスを提供し、月間の総トラフィックは1,500TB超に達します。アップリンクはホストあたり10〜40Gbit/sで、単一エンドポイントあたり理論上の最大値は500Mbit/sです。実際には単一のスクレイピングスレッドで500Mbit/sに到達することはまずありませんが、余裕があることで、ピーク時に共有インフラがポートレベルでボトルネックになりにくくなります。

2011年から続けてきた歴史がプロダクトにも表れています。UIは少し古めで、プラン構成も融通が利きません。ただし基礎部分、つまりクリーンなIP、安定したプール、定額課金は堅実で、更新し続ける顧客層がいることからも、その強さがうかがえます。

プロキシの種類とプラン

Fineproxyが販売しているのは、データセンター（固定）、ISP（固定レジデンシャル）、そしてローテーション型データセンターの3カテゴリです。それぞれ用途が異なり、最新のアンチボット基盤に対する「失敗の仕方」も変わります。

固定データセンタープロキシ

これが同社の主力です。専用IPv4アドレスのブロックを購入すると、契約期間中はそのIPがあなたのものとして固定され、HTTP/HTTPSとSOCKS4/5が標準で利用でき、トラフィック制限もありません。プランは地域とIP数で販売されています。現行カタログから代表例をいくつか挙げると以下の通りです。

「World Mix」プランは特定の国ではなく、同社のグローバル拠点全体からアドレスを抽出します。厳密なジオ指定が不要で、リクエストを分散してASNの多様性を確保したい運用には便利です。一方、国単位で確実に狙い撃ちしたい場合はあまり向きません。事前にリストをテストしない限り、特定のIPがどの国に紐づくかを常にコントロールできるわけではないからです。

注目すべき機能として、8日ごとの無料スワップがあります。データセンターのIPは時間とともにブロックリストに載ることがあり、あなたのブロック内のIPがそうなった場合でも、新しいプランを買わずに交換できます。加えて、更新時には20%割引が適用されます。どちらも、固定データセンタープロキシを大規模に運用する際に面倒になりがちな保守コストを下げてくれます。

ISPプロキシ

Europe 1,500 IPプランはISP（固定レジデンシャル）として掲載されており、これらのIPはFineproxyのデータセンターASNではなく、実在のISPのASN配下でアナウンスされます。これは大きな違いです。Cloudflare Bot Management、Akamai Bot Manager、DataDomeはいずれも、リスクモデルの要素としてASNの評判を組み込んでいます。そのため、Comcast、Vodafone、OrangeのようなISPに登録されたIPは、たとえ両方が同じラックに物理的に置かれていたとしても、データセンターASNのIPとは根本的に異なるリスクスコアになります。ISPプロキシは市場の中間に位置します。中程度のアンチボット対象では純データセンターより通過率が上がる一方で、固定でローテーションしないため、行動ベースのフラグが立つような長時間セッションを続けると、そのIPは交換するまで実質的に焼かれた状態になります。

ローテーション型データセンタープロキシ

Fineproxyは、IP単位ではなくAPIクレジットで課金されるローテーションプロキシも提供しています。最小プランは500万APIクレジットで、最大は1億まで。リクエストごとに新しいIPが割り当てられ、プールはグローバル、同時接続数の制限もありません。仕組みはシンプルで、ゲートウェイエンドポイントがアウトバウンド接続のたびにプール内の別の出口ノードを割り当て、各HTTPリクエストは異なる送信元IPを持ちます。問題になりやすいのは、TLSフィンガープリントをセッション間で相関させるターゲットです。JA3やJA4のハッシュが送信元IPが変わっても一定のままだと、Cloudflare EnterpriseやKasadaはそれらのリクエストを結びつけ、累積的なリスクスコアを適用できます。IPだけを回してもTLS ClientHelloの特性が固定のままでは、IPの多様性は得られてもセッションの多様性は得られません。

プロトコルと認証

HTTP、HTTPS、SOCKS5は全プランに含まれます。SOCKS4も対応。UDP/QUICは要望に応じて提供されており、UDP World Mix 100 IPプランは基本価格に対して50%上乗せで掲載されています。コネクションレスなプロトコルをSOCKS5層でプロキシするにはルーティングが複雑になるため、このプレミアムは妥当です。認証方式は2つで、ユーザー名/パスワードまたはIPホワイトリストです。IPホワイトリスト方式（IP認可）は、送信元IPが固定のサーバー間パイプラインでは扱いやすく、リクエストヘッダーから認証情報を完全に排除できるため、漏えい経路を1つ減らせます。ユーザー名/パスワード認証は、クライアントIPが変動する分散構成で便利です。どちらも、下の接続例でより詳しく触れます。

REST/OpenAPIインターフェースは全プランで利用可能で、プロキシリストをプログラムから管理できます。稼働中IPの入れ替え、使用状況の確認、ダッシュボードにログインせずにスワップをトリガーする、といった運用が可能です。大規模運用では必須の機能であり、エンタープライズ専用としてロックされていないのは良い点です。

パフォーマンスとインフラ

スペック上の数字は、ホストあたり10〜40Gbit/sのアップリンク、IPエンドポイントあたり最大500Mbit/sです。これはインフラレベルの指標であり、スクレイピングの1スレッドでそのまま観測できる値ではありません。ヨーロッパのデータセンタープロキシがヨーロッパのターゲットへアクセスする場合、プロキシホップ自体の実測p50レイテンシはおおむね30〜60ms程度になり、その上にDNS解決、ターゲット側の処理、TCPハンドシェイク時間が加わります。高同時実行のスクレイピングでは、この数値よりも接続確立レートとエラー復旧の速さの方が重要です。一方、レイテンシに敏感な用途、例えば広告検証や短いポーリング間隔でのSERP監視では、World MixよりもヨーロッパやUSAの地域指定プールを選ぶのが適切です。出口ノードとターゲットの地理的距離を縮められるからです。

月間総転送量1,500TBという数字は、インフラにかかっている実際の負荷の目安になります。22,000クライアントと100,000超のIPに分散していると考えると、比率としては無理がありません。プールを過度に売りすぎているプロバイダーは、ピーク時のp95やp99レイテンシのスパイクにそれが表れますが、Fineproxyのユーザーレビューには、そうしたパターンが一貫して報告されているわけではありません。つまり、プールが極端に圧迫されていない可能性が高いと言えます。

何と組み合わせて使えるか

Fineproxyの固定プロキシは、エコシステム内のほぼすべてのツールと互換性があります。caproxy.comの互換リストにはSelenium、Puppeteer、Playwright、Scrapy、ZennoPoster、Multilogin、A-Parser、Key Collector、ScrapeBox、PhantomBuster、Python requests、wget、さらに多くのソーシャル自動化ツールが並びます。驚く話ではありません。SOCKS5とHTTP CONNECTを話せるプロキシであれば、これらのツールで使えるのが普通です。違いが出るのは互換性そのものではなく、保護されたターゲットに対する実際の通りやすさです。

Pythonのrequestsライブラリで、適切なリトライロジックとエラーハンドリングを備えた現実的な接続例は次のようになります。

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

PROXY_HOST = "your.fineproxy.endpoint"
PROXY_PORT = 8080
PROXY_USER = "your_username"
PROXY_PASS = "your_password"

proxies = {
    "http":  f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
    "https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
}

# 429と503ではリトライするが、403ではしない。403はIPがフラグ済みの合図で、
# 同じ出口ノードに即座に投げ直しても無駄になる。
# 403でリトライする前に、プールから新しいIPに切り替えること。
retry_strategy = Retry(
    total=3,
    backoff_factor=1.5,
    status_forcelist=[429, 500, 502, 503, 504],
    allowed_methods=["GET", "POST"],
    raise_on_status=False,
)

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",
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
}

def fetch(url, retries_on_403=2):
    for attempt in range(retries_on_403):
        try:
            resp = session.get(
                url,
                proxies=proxies,
                headers=headers,
                timeout=(5, 30),  # (connect_timeout, read_timeout)
            )
            if resp.status_code == 403:
                # IPがフラグ済み。ローテーション前にバックオフ
                time.sleep(2 ** attempt)
                continue
            if resp.status_code == 1015:
                # Cloudflareのレート制限。429と同様に扱う
                time.sleep(5)
                continue
            resp.raise_for_status()
            return resp
        except requests.exceptions.ProxyError as e:
            print(f"試行 {attempt + 1} 回目でプロキシエラー: {e}")
            time.sleep(1)
    return None

Cookieの引き継ぎが必要で、ボットのセッションリセットに見えるTLSハンドシェイクの繰り返しを避けたい場合は、永続ブラウザコンテキストを使うPlaywrightの方が適します。その場合、設定は少し変わります。

from playwright.sync_api import sync_playwright
import time

PROXY_CONFIG = {
    "server": "http://your.fineproxy.endpoint:8080",
    "username": "your_username",
    "password": "your_password",
}

def scrape_with_playwright(url: str, user_data_dir: str = "/tmp/pw_profile"):
    with sync_playwright() as p:
        # persistent_context は起動間でcookieやlocalStorageを再利用するため、
        # KasadaやPerimeterXが「新規ボットセッション」を特定するために使う
        # フィンガープリント差分を小さくできる。
        context = p.chromium.launch_persistent_context(
            user_data_dir=user_data_dir,
            proxy=PROXY_CONFIG,
            headless=True,
            args=["--disable-blink-features=AutomationControlled"],
            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"
            ),
        )
        page = context.new_page()
        page.set_extra_http_headers({
            "Accept-Language": "en-US,en;q=0.9",
        })
        try:
            resp = page.goto(url, timeout=30000, wait_until="domcontentloaded")
            if resp and resp.status in (403, 429):
                print(f"ブロック: HTTP {resp.status}")
                return None
            time.sleep(2)  # コンテンツを返す前にJSチャレンジの解決を待つ
            return page.content()
        finally:
            context.close()

Fineproxyが得意なこと

2026年時点で、定額かつトラフィック上限なしの価格体系は本当に珍しくなりました。市場の多くは、利用量に応じて売上が伸びるGB課金へ移行しています。Fineproxyのモデルはその逆で、IPに対して料金を支払い、そのIPに好きなだけトラフィックを流せます。Cloudflare Bot ManagementやAkamai Bot Managerを本格的に導入していないターゲットに対して、大量かつ単純なスクレイピングを行うなら、これは大きなコスト面の優位性になります。固定IPブロックで月に数百GBを引き出し、ターゲットの防御が軽い場合、1GBあたり3〜4ドルを請求するGB課金レジデンシャルより、はるかに安く済むでしょう。

24時間返金ポリシーと、8日ごとの無料スワップも実用的です。多くのプロバイダーはIPローテーションに追加料金を課すか、フラグ済みIPが「ユーザーのせい」かどうかをサポートと揉める構図になりがちです。定期スワップがあることで、その摩擦を減らせます。

互換性の幅も広いです。Fineproxyのプロキシは主要な自動化フレームワーク、アンチディテクトブラウザ（Multilogin、Dolphin Antyなど）、そして市場にある主要なスクレイピングツールのほぼすべてで動作します。SOCKS5対応も完全で、SOCKS5上での認証にも対応しています。安価なプロバイダーの中には、認証なしのSOCKS5しか提供せず、分散構成でも不便なIPホワイトリスト認証を強いられる場合がありますが、Fineproxyはその点で問題になりません。

レビューサイト全体のユーザー評価は、速度、信頼性、サポートの返信速度に関して概ね安定して高評価です。不満の多くはプランの粒度に関するもので、最小プールサイズが一部ユーザーには大きすぎること、例えば50 IPだけ買うといった選択肢がないことが挙げられます。これは確かに制約です。

Fineproxyが苦戦するところ

率直に言えば、データセンタープロキシには本格的なアンチボット相手に越えられない天井があり、インフラが良くてもそれは覆りません。Cloudflare Enterprise、Akamai Bot Manager、PerimeterXはいずれもASN評判リストを維持しており、Fineproxyのようにクリーンで私有のデータセンターASNであっても、データセンターASNには明確なリスクペナルティが課されます。このペナルティは毎回403になるという意味ではありませんが、チャレンジの閾値を引き上げます。その結果、CAPTCHAやJSチャレンジ（Cloudflareのマネージドチャレンジで1015が返るケース）が増え、同じターゲットに対してレジデンシャルやISPプロキシを使う場合よりも、初回成功率が下がります。スニーカーサイトや旅行運賃アグリゲーター、Kasadaのセンサーデータ収集を走らせているサイトをスクレイピングする場合、8日スワップの補充速度を上回るペースでIPを消費してしまうでしょう。

ローテーションプロキシはAPIクレジット課金で、モデルとしては妥当ですが、ゲートウェイ側に一貫ハッシュによるセッション固定（セッションピニング）がありません。ターゲットがログインしてから閲覧し、最後に抽出するような多段フローを使う場合、各ステップが別々の出口ノード、別IPに当たると、セッションに紐づくワークフローは失敗します。このローテーション製品が最も向くのは、状態を持たない単発リクエストの仕事です。URLを1つ投げてレスポンスを1つ返す、セッション継続が不要な用途です。

IPv6対応は最小限です。製品カタログはほぼIPv4で構成されています。IPv6でアクセスでき、低コストで膨大なアドレス多様性が必要なターゲット、例えば/22や/20のIPv6サブネットが上流からほぼ無料同然で手に入るようなケースでは、Fineproxyは適した選択肢ではありません。

管理画面は使えるものの古さがあります。リアルタイムのIPヘルスダッシュボードや、IP別の成功率レポート、特定IPが特定ターゲットから403を返される理由を診断できるビルトインのリクエストログはありません。診断はmitmproxyやWiresharkなどを使って自前で行う必要があります。環境が整っていれば問題ありませんが、Fineproxyは一部のエンタープライズ志向プロバイダーのような「マネージド」サービスではありません。

価格を文脈の中で見る

広告上のレンジの下限では、月$0.07/IPから始まり、ボリュームが増えるほど単価は下がります。USAの1,000 IPパッケージはおよそ$89/月で、$0.089/IPです。USAの3,000 IPパッケージはおよそ$230/月で、$0.077/IPに近づきます。World Mixの5,000 IPブロックは$380/月。いずれもトラフィック料金を含まない定額なので、経済性は流すデータ量に完全に依存します。1,000 IPで月1TB流すなら$0.089/GBで、レジデンシャル課金と競争できます。同じブロックで月10TB流すなら$0.0089/GBとなり、これに近い価格をレジデンシャルで実現できるプロバイダーはほぼありません。

更新には20%割引が付くため、長期運用では効いてきます。クーポンコードもさまざまに出回っており（10%オフ、25%オフ、特定パッケージで30%オフなど）、決済前にアグリゲーターサイトを確認する価値はあります。

結局、Fineproxyを使うべき人は誰か

Fineproxyに向いているのは、中程度に保護されたターゲットに対して、高ボリュームかつ高スループットでスクレイピングする人です。例えばECマーケットプレイス、不動産アグリゲーター、求人ボードなど、基本的なレート制限があり、Cloudflare Free/ProのWAF程度は使っているかもしれないが、Cloudflare Bot Management Enterpriseまでは入れていない層が該当します。このレベルなら、評判の良いASNに紐づくクリーンなデータセンターIPで十分に仕事になり、定額課金のおかげで作業中にトラフィックメーターを気にせずに済みます。

また、スクレイピング以外の目的で、大きく安定したIPブロックが必要なインフラにも適しています。SOCKS5トンネリング、分散テスト、アンチディテクトブラウザでの複数アカウント運用、あるいはUDPベースのトラフィック（要望に応じてUDP対応）などです。エンドポイントあたり500Mbit/sの上限と40Gbit/sのアップリンクがあるため、現実的な自動化シナリオで帯域の壁に当たることはまずありません。

主なターゲットがCloudflare Bot Management、Akamai Bot Manager、DataDome、Kasadaの場合は不向きです。これらには、実際の一般消費者向けASN由来のレジデンシャルまたはISPプロキシが必要です。しかしFineproxyのISP提供は、ヨーロッパの1,500 IPという単一プランに限られており、保護されたターゲット相手に高ボリュームで回すには足りません。その用途では、レジデンシャルプールに特化したプロバイダー（3,000万以上のアドレス、都市単位ターゲティング、スティッキーセッション対応）を選び、GB課金を受け入れる方が適切です。

その実態が、無駄のないデータセンタープロキシ運用であり、15年分のインフラの蓄積と、誠実なIP単位の価格設定、そしてクリーンなIPをめぐって過度に他テナントと競合しないだけの十分な規模のプールを備えているという点を踏まえると、Fineproxyは堅実な選択肢です。ただし、データセンタープロキシの限界がどこにあるかは、冷静に見極める必要があります。