Hyperliquid の Bot を置くVPSの選び方

この用途は「東京リージョンに置く意味がある」数少ないケースです。ただし判断材料に ping を使うと確実に間違えます。

当サイトは各VPS事業者のアフィリエイトプログラムに参加しており、リンク経由でのお申し込みにより報酬を受け取る場合があります。ただし掲載順位・評価・実測データは編集方針と計測結果のみに基づいており、報酬額による優遇は一切行いません。日本リージョンが無い事業者や、報酬が発生しない事業者も同じ基準で掲載しています。

結論

• 東京リージョンに置く理由がある用途です。 当サイトの実測では、api.hyperliquid.xyz のオリジンまでの往復は日本国内の観測点が最小で、韓国・シンガポール・米国・欧州は距離どおりに大きく出ました
• ただし ping で比較すると必ず間違えます。 このホストは CloudFront の後ろにあり、ping が返るのは手元のCDNエッジだからです
• 東京VPSから実際にAPIを叩いた往復時間（板情報の取得）は、下の表のとおり中央値で1桁msです。ただし p95 は日によって跳ねるので、平均だけ見ないでください
• 詰めるべきは平均値ではなく、ゆらぎ・切断・時刻ずれのほうです

なぜ ping で判断すると間違えるのか

api.hyperliquid.xyz を名前解決すると 3.x.x.x、つまり Amazon CloudFront のアドレスが返ります。当サイトの東京ノードから ping を打つと、返ってくるのは東京のCDNエッジです。

計測日時: 2026-09-15T21:28:37+02:00 / 計測地点: 当サイトの計測ノード（東京DC内） / ICMP ping ×20 / MTR ×5。この列の値はCloudFrontエッジまでの距離であり、取引APIの応答時間ではありません。計測方法の詳細

ホップ数も1桁で、いかにも「すぐそこにある」値が出ます。しかしこれは取引APIの応答時間ではありません。同じことを大阪でもシンガポールでもやれば、そこでも近傍のエッジが応答するので、同じように良い値が出ます。差が出ない指標で置き場所を決めることになります。

オリジンはどこにあるのか — 観測点別のTTFB

そこで、オリジンまで必ず往復するリクエストで測ります。GET /info はオリジンの nginx が 405 Method Not Allowed（allow: POST）を返すので、エッジで打ち返されません。応答ボディが空なので回線速度の影響も受けません。

Globalping の公開プローブから、世界の観測点で同じリクエストを投げた結果です。

単位はms。計測日時: 2026-09-15T21:28:37+02:00 / HTTPS GET /info（オリジンが405を返す＝オリジンまで往復する）×3回 / 観測点: Globalping (https://globalping.io)。TLSはどの観測点でも近傍のCDNエッジで終わるため距離に応じて増えません。差が出ているTTFBがオリジンまでの距離を表します。プローブ側の事情で1回の値は数十msぶれるため最小値で並べています。近接した観測点どうしの順位は読まないでください。観測点は日替わりのため同一観測点の時系列比較にも使えません。

読み方はこうです。

• TLSの列はどの観測点でも一桁ms台に収まります（距離に応じて増えません）。手前のCDNエッジで終端しているためで、「エッジはどこにでもある」ことの裏取りになります
• 差が出ているのはTTFBの列だけです。エッジから先、オリジンまで往復した時間がそのまま乗っています
• 日本国内の観測点が最小で、距離が離れるほど素直に増えます。オリジンは日本国内にあると読むのが自然です
• ただし東京と大阪の順位は計測のたびに入れ替わります（当サイトの計測でも1回目は大阪が小さく、2回目は東京が小さく出ました）。プローブ側の事情で1回の値は数十msぶれるので、近接した観測点どうしの順位は読まないでください

東京VPSから実際にAPIを叩いた往復時間

当サイトの計測ノード（東京DC内）から、接続を維持したまま POST /info を繰り返した実測です。毎回TLSを張り直すと測っているのはハンドシェイクになるので、Botと同じく接続を張りっぱなしにしています。

計測日時: 2026-09-15T21:28:37+02:00 / 対象: api.hyperliquid.xyz / HTTPS keep-alive で POST /info を×30（TLSは張り直さない） / 計測地点: 当サイトの計測ノード（東京DC内）。応答サイズとサーバ側の処理量が違うため、リクエスト種別をまたいで比較しないでください。

Botが最も高い頻度で叩くのは板情報（l2Book）です。ここが実運用の代表値になります。応答サイズの大きいリクエストやサーバ側の処理が重いリクエストは同じ回線でも桁が変わるので、種別をまたいで比較しないでください。

「AWS の中に置けば速いのか」— 東京の中で並べてみる

CloudFront が手前にあると分かると、次に浮かぶのは「では AWS のインスタンスに置けばエッジまで最短では？」という疑問です。測りました。有利にはなりませんでした。

東京の観測点を10台取り、同一のプローブ集合で ping（エッジまで）と TTFB（オリジンまで）を並べた結果です。

計測日時: 2026-09-15T21:28:37+02:00 / 同一プローブ集合で HTTPS GET /info（オリジンまで往復）と ICMP ping（CloudFrontエッジまで）を測定 / 観測点: Globalping (https://globalping.io)。同一のプローブ集合で両方を測っています（別々に測ると指標の差ではなく観測点の差になります）。pingはCloudFrontエッジまで、TTFBはオリジンまで往復した値です。

• ping は全観測点が数ms以内に収まります。同じ都市の中ではエッジまでの距離の差は小さく、しかも次の行のとおりその大小はTTFBの大小と対応しません
• TTFB は桁で開きます。 そして2つの順位は一致しません。当サイトの計測では、pingで最速だった観測点がTTFBでは最下位という並びも出ました
• Amazon (AS16509) の観測点も横並びです。CloudFront は anycast で最寄りのエッジに落ちるので、AWSの中にいること自体はエッジまでの距離を縮めません

構造で考えると当然の結果です。往復時間は「自分→エッジ」＋「エッジ→オリジン」で、後者は誰にも短縮できません。前者をいくら詰めても、支配的な区間は動かないということです。

WebSocket：Botが実際に張りっぱなしにする経路

ここまでは REST（POST /info）の話でした。しかし実運用の Bot は WebSocket を張りっぱなしにします。当サイトの東京ノードから wss://api.hyperliquid.xyz/ws を実測した値です。

計測日時: 2026-09-15T21:28:37+02:00 / 対象: wss://api.hyperliquid.xyz/ws（BTC） / l2Book を購読し 45 秒観測。ws post の往復も測定 / 計測地点: 当サイトの計測ノード（東京DC内）。板の配信間隔は購読の種類で大きく変わります（同じ接続で trades を購読すると桁が違います）。

この表で一番重要なのは、速さではなく配信間隔の行です。

再接続のたびに効くのは「購読 → 初回配信」の行です。WebSocket は必ず切れるので、切断が多い環境ほどこの値が積み上がります。回線の平均レイテンシより、切れにくさのほうが効くというのはここに現れます。

東京か、大阪か

Hyperliquid のAPI相手なら東京です。当サイトの実測では東京と大阪の間に往復6ms前後の差があり、この用途ではそれを埋め返す材料がありません。

計測日時: 2026-09-15T21:25:15+02:00 / 計測地点: 日本国内（東京） / ICMP ping x10 + MTR x5。計測方法の詳細

大阪を選ぶ理由があるとすれば、東京リージョンの障害から独立させたい場合の待機系としてです。詳しくは東京と大阪の比較にまとめています。

サービスの選び方

Vultr 東京 — 検証しながら決められる

時間単位課金なので、東京・大阪・シンガポールに同時に立てて自分のBotで実測し、負けたインスタンスを即座に破棄できます。数時間なら数十円です。この用途では「借りてから測る」が現実的な検証手段になります。

Linode 東京 — ゆらぎの小ささを取る

Akamaiのバックボーンに乗っており、経路が安定しています。平均値よりゆらぎ（mdev）を重視するなら候補です。東京は新世代の jp-tyo-3 を選んでください。

避けたほうがいい選択

自分の環境で測る手順

置き場所の判断は、自分のBotが叩くリクエストで測ってください。以下はそのまま実行できます。

# 1. pingは「エッジまで」しか測れないことを確認する（比較には使わない）
ping -c 20 api.hyperliquid.xyz
curl -sI https://api.hyperliquid.xyz/info | grep -i x-amz-cf-pop   # 受けたエッジ

# 2. オリジンまで往復させる（405が返るが、それでよい）
curl -o /dev/null -s -w 'tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' \
  https://api.hyperliquid.xyz/info

# 3. 実運用に近い形で測る（接続を維持したまま板情報を繰り返し取得）
python3 - <<'PY'
import http.client, json, time, statistics
c = http.client.HTTPSConnection("api.hyperliquid.xyz", timeout=10)
body = json.dumps({"type": "l2Book", "coin": "BTC"})
hdr = {"Content-Type": "application/json"}
ts = []
for _ in range(30):
    t = time.perf_counter()
    c.request("POST", "/info", body, hdr); r = c.getresponse(); r.read()
    ts.append((time.perf_counter() - t) * 1000)
s = sorted(ts)
print(f"min {s[0]:.1f}ms  median {statistics.median(s):.1f}ms  p95 {s[int(len(s)*0.95)-1]:.1f}ms")
PY

WebSocket を測る

# pip install websockets （当サイトの日次計測は依存を避けて標準ライブラリで書いていますが、
# 手元で1回測るだけならこちらが早いです）
import asyncio, json, time, statistics, websockets

async def main(coin="BTC", seconds=45):
    async with websockets.connect("wss://api.hyperliquid.xyz/ws") as ws:
        await ws.send(json.dumps({"method": "subscribe",
                                  "subscription": {"type": "l2Book", "coin": coin}}))
        t0, stamps = time.perf_counter(), []
        end = time.time() + seconds
        while time.time() < end:
            try:
                msg = await asyncio.wait_for(ws.recv(), timeout=max(0.1, end - time.time()))
            except asyncio.TimeoutError:
                break
            if json.loads(msg).get("channel") == "l2Book":
                stamps.append(time.perf_counter())
        if not stamps:
            print("配信が届きませんでした"); return
        print(f"購読→初回配信 {(stamps[0]-t0)*1000:.1f}ms / {len(stamps)}件")
        if len(stamps) > 1:
            gaps = [(b-a)*1000 for a, b in zip(stamps, stamps[1:])]
            print(f"配信間隔 中央値 {statistics.median(gaps):.0f}ms / 最大 {max(gaps):.0f}ms")

asyncio.run(main())

WebSocket の配信間隔は、購読してからしばらく放置して測ります。30秒では足りません（5秒間隔なら6件しか取れず、中央値が安定しません）。当サイトは45秒観測しています。自分のBotが使う購読内容で測ること。 l2Book と trades では桁が違います。

当サイトが上と同じことを毎回同じ手順で行うスクリプトは scripts/measure-hyperliquid.py です（WebSocketの計測は依存パッケージを使わず標準ライブラリだけで書いてあります）。計測方法のページに方針を書いています。

運用チェックリスト

時刻同期は特に見落とされます。VPSを立てた直後はNTPが有効でないイメージがあります。timedatectl で System clock synchronized: yes を確認してから本番に移してください。

よくある質問