---
title: "邊緣層如何讓 Alchemy 上的 RPC 更快"
description: "深入 Alchemy Edge Proxy：自建 bare-metal ingress 層如何讓 100 多個網路的區塊鏈 RPC 最高提速 7.5 倍，且客戶無需遷移。"
---

# 邊緣層如何讓 Alchemy 上的 RPC 更快

<ImageBlock
  src="https://media.alchemy.com/blog/edge-proxy-hero-2026-05.png"
  alt="Alchemy Edge Proxy:讓 blockchain RPC 更快的裸機邊緣層"
  width={5760}
  height={2700}
  priority
/>

每年有數兆美元的價值透過區塊鏈基礎設施流動。Solana 上的一筆 DeFi 兌換、Ethereum 上的一筆穩定幣轉帳、Polygon 上的一筆預測市場結算：這些交易都仰賴 RPC 呼叫在抵達節點前經過多層網路傳輸。當金融活動搬到鏈上執行時，這條路徑上的每一毫秒都關係到資金風險。

對於一個服務超過 [100+ 條區塊鏈網路](https://www.alchemy.com/rpc)、每年處理數兆次請求的基礎設施供應商來說，使用者與資料中心之間的那一層，正是效能勝負的關鍵所在。那一層就是邊緣層（edge）。2025 年底，Alchemy 將其徹底重建。

## RPC 延遲對鏈上金融為何重要？

區塊鏈的使用者與應用程式分布在全球各地。新加坡的交易機器人、法蘭克福的錢包應用、維吉尼亞州的 DeFi 協議後端：它們都會發出 [RPC 呼叫](https://www.alchemy.com/overviews/rpc-node)來讀取區塊鏈狀態並提交交易。這些呼叫解析得越快，體驗就越好。

在 DeFi 中，延遲會直接轉化為執行品質。較慢的 `eth_call` 意味著過時的價格資料。延遲的交易提交意味著較差的成交或交易失敗。對錢包應用而言，每多出 100 毫秒的載入時間，都會削弱留住使用者在鏈上活動的體驗。

但延遲只是問題的一半。可靠性同樣重要。如果你的 RPC 供應商將所有流量都導向單一第三方 CDN，這個 CDN 就成為單點故障。一旦它故障，每個網路、每個客戶、每個請求都會一同中斷。

## 什麼是 Alchemy Edge Proxy？

可以把 Edge Proxy 想成 [Alchemy RPC 基礎設施](https://www.alchemy.com/rpc-api)的大門。無論是讀取 Ethereum 狀態、查詢 Solana 帳戶，還是在 Base 上提交交易，每一個 API 請求都會先經過這個入口層，才會抵達後端的服務基礎設施。

多年來，Alchemy 一直使用一家主要的 CDN 作為這道大門。CDN 之所以成為業界普遍的選擇是有原因的：它們開箱即用地提供 DDoS 防護、地理路由、WAF 規則以及 SSL 終止。對大多數網頁應用來說，這套組合已經足夠。CDN 已經有二十年的時間，從電子商務到串流媒體，都是預設的入口層選擇，這個地位是它們應得的。

鏈上金融的需求不同。RPC 流量突發、對延遲敏感、地理上遍及全球，且在安全性上的要求也是一般網頁流量所沒有的。一個平行讀取三條鏈狀態的交易機器人，不在乎 CDN 能不能在 50 個城市快取一個行銷頁面。它在乎的是從發出 `eth_call` 到收到回應之間的時間。一個同步餘額的錢包，不需要針對 SQL injection 的 WAF 規則。它需要的是最近的邊緣節點，以及能在個位數毫秒內完成的 TLS 交握。一個在衍生品交易所結算部位的協議，無法容忍以第三方 CDN 的事故處理時間，作為自身正常運行時間的上限。

為了滿足這些需求，我們在裸機（bare metal）上建構了自訂的邊緣代理（edge proxy）：一個從頭開始、專為高吞吐量、低延遲的區塊鏈 RPC 流量設計的入口層。它運行在 Alchemy 自行掌控、遍布全球多個地區的基礎設施上，以我們可以依網路個別調校的等效或更強的防護，取代每一層 CDN 防護，並徹底移除關鍵服務路徑上對第三方的依賴。

結果就是目前正式上線中，速度最快的區塊鏈 RPC 入口層。

## Alchemy Edge Proxy 如何運作？

Edge Proxy 架構由兩個核心元件組成，運行在分布於全球多個地區（美國東部、美國西部、歐洲中部、東南亞等）的專用裸機伺服器上。

### Istio Ingress Gateway

第一個元件是以 Envoy 作為資料平面的 [Istio](https://istio.io/) Ingress Gateway。它負責 TLS 終止、連線管理與請求代理。Envoy 正是在 Lyft、Google Cloud 與 AWS App Mesh 負載下運作的同一套代理。它的非同步非阻塞 C++ 核心、HTTP/2 多工，以及預先建立的上游連線池，使其非常適合高吞吐量、低延遲的入口場景。

### Edge Proxy Control Plane（EPCP）

第二個元件是一個自訂的控制平面，以 [ext_authz filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter) 的形式與 Envoy 並行運作。對於每一個傳入的請求，EPCP 都會評估：

- 根據 URL、標頭以及目標區塊鏈網路，決定請求要路由到哪裡
- 針對該請求，哪些後端叢集可用（例如：archive node 叢集、AWS 託管服務、特定地區端點）
- 該請求是否因安全或合規原因而應被封鎖
- 本地地區中哪些網路是健康的（透過健康檢查判斷）

接著 EPCP 會注入路由標頭，告訴 Envoy 該將請求轉發到哪裡。這樣的設計讓熱路徑（hot path）維持快速（由 Envoy 處理代理），同時讓路由邏輯保持彈性且可動態設定。

### 請求生命週期

以下是一個典型成功請求在系統中的流程：

<ImageBlock
  src="https://media.alchemy.com/blog/edge-proxy-request-lifecycle.png"
  alt="Alchemy Edge Proxy 請求生命週期：client 到 Geo DNS 到 Istio Ingress Gateway 到 EPCP，再回到 Istio 到目標 cluster"
  width={1705}
  height={167}
/>

1. 客戶端向 `*.g.alchemy.com` 發送 RPC 請求。
2. 基於地理位置的 DNS 將請求解析至最近的 Edge Proxy 地區。
3. Istio Ingress Gateway 接收請求，並透過 ext_authz 傳遞給 EPCP。
4. EPCP 驗證請求（OFAC 檢查、安全規則），判斷目標叢集，並回傳路由標頭。
5. Istio 將請求轉發至對應的後端。
6. 回應直接回傳給客戶端。

### 基於地理位置的 DNS 路由

Edge Proxy 採用基於地理鄰近性的 DNS 解析。這代表 DNS 層與鏈、網路無關：無論是針對 Ethereum mainnet 還是 Solana mainnet 的請求，都會解析到同一個區域性的 Edge Proxy。Edge Proxy 本身則在內部處理具網路感知能力的路由。

<ImageBlock
  src="https://media.alchemy.com/blog/edge-proxy-geo-dns-routing.png"
  alt="Geo-based DNS 路由示意圖：請求會解析到最近的 Alchemy Edge Proxy 區域，與目標 chain 無關"
  width={1200}
  height={627}
/>

這樣的設計有幾項優勢：

- 無論最終需要哪條區塊鏈網路，DNS 解析與 TLS 交握都會在最近的邊緣位置完成。
- 新增區塊鏈網路無需任何 DNS 變更。
- 地區性健康檢查在 Edge Proxy 層級執行。若某個 Edge Proxy 地區變得不健康，DNS 會自動容錯移轉至次近的地區。

### 動態設定

Edge Proxy 會從我們內部的設定平台拉取路由設定。這使得執行期變更無需重新部署即可生效：

<CodeSnippet
  language="yaml"
  code={`regions:
  us-east:
    enabled: true
    routes:
      "/v2":
        verbs: ["POST"]
        destination: archive-cluster
    fallbackRegions:
      - us-west
      - eu-central
      - apac-southeast
security:
  ipsBanned: ["..."]
  pathsBanned: ["..."]`}
/>

若某個地區需要排空流量、某個網路需要重新路由，或需要套用新的安全規則，設定更新會直接生效，無需碰觸正在運行的代理。

## 沒有 CDN 的情況下，安全模型如何運作？

移除對 CDN 的依賴，意味著需要從頭重建每一項安全防護。Edge Proxy 以分層方式取代 CDN 原有的防護：

<EmbeddedTable
  table={{
    columns: [
      { key: "layer", width: 240, title: "Security layer", dataType: "object" },
      { key: "cdn", width: 240, title: "Previous (CDN)", dataType: "object" },
      { key: "edge", width: 360, title: "Edge Proxy", dataType: "object" },
    ],
    data: [
      {
        layer: { title: "OFAC / locality compliance", tooltip: "", icon: "" },
        cdn: { title: "CDN WAF rules", tooltip: "", icon: "" },
        edge: { title: "Maxmind geolocation with application-level enforcement", tooltip: "", icon: "" },
        id: 0,
      },
      {
        layer: { title: "DNS DDoS", tooltip: "", icon: "" },
        cdn: { title: "CDN", tooltip: "", icon: "" },
        edge: { title: "DNS provider (standard protection)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        layer: { title: "Volumetric DDoS (UDP / ICMP floods)", tooltip: "", icon: "" },
        cdn: { title: "CDN", tooltip: "", icon: "" },
        edge: { title: "Infrastructure provider with built-in anti-DDoS protection", tooltip: "", icon: "" },
        id: 2,
      },
      {
        layer: { title: "Protocol DDoS (SYN floods, IP fragmentation)", tooltip: "", icon: "" },
        cdn: { title: "CDN", tooltip: "", icon: "" },
        edge: { title: "Infrastructure provider for IP fragmentation; Envoy for SYN floods (connection limits, timeouts)", tooltip: "", icon: "" },
        id: 3,
      },
      {
        layer: { title: "L7 DDoS (application-layer attacks)", tooltip: "", icon: "" },
        cdn: { title: "CDN WAF", tooltip: "", icon: "" },
        edge: { title: "Envoy configuration with path allowlisting, IP-based rate limiting, max request time limits", tooltip: "", icon: "" },
        id: 4,
      },
    ],
  }}
/>

關鍵在於：這些防護並不比 CDN 的防護來得弱，只是更具針對性。Alchemy 掌控每一層，可以依網路個別調整閾值，出問題時也不需要仰賴第三方的事故應變時程。

## Alchemy Edge Proxy 帶來了什麼成果？

Edge Proxy 於 2025 年 10 月間，在三週內推廣至 100+ 條區塊鏈網路，且完全不需要客戶進行遷移。成效立即顯現。

### 延遲

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 200, title: "Metric", dataType: "object" },
      { key: "before", width: 200, title: "Before (CDN)", dataType: "object" },
      { key: "after", width: 220, title: "After (Edge Proxy)", dataType: "object" },
      { key: "improvement", width: 200, title: "Improvement", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "P99 (APAC)", tooltip: "", icon: "" },
        before: { title: "150ms", tooltip: "", icon: "" },
        after: { title: "20ms", tooltip: "", icon: "" },
        improvement: { title: "7.5x faster", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "P50 (median)", tooltip: "", icon: "" },
        before: { title: "~35ms", tooltip: "", icon: "" },
        after: { title: "~5ms", tooltip: "", icon: "" },
        improvement: { title: "7x faster", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "P95 (all networks)", tooltip: "", icon: "" },
        before: { title: "~200ms", tooltip: "", icon: "" },
        after: { title: "~100ms", tooltip: "", icon: "" },
        improvement: { title: "~100ms reduction", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

客戶端的遙測資料在各種不同工作負載下，也顯示出相近幅度的改善，其中對延遲最敏感的工作負載獲益最大。

若需目前公開的供應商數據，可比較各鏈、各地區與常用方法的 [RPC 延遲基準測試](https://www.alchemy.com/benchmarks)。

### 可靠性

在同一段時間窗口內，若仍使用先前以 CDN 為前端的架構，本應會受到上游事故的影響，而 Alchemy 的基礎設施則完全未受波及。

## 這與其他基礎設施方案相比如何？

處理區塊鏈 API 基礎設施入口流量，常見有三種做法：

<EmbeddedTable
  table={{
    columns: [
      { key: "dimension", width: 220, title: "", dataType: "object" },
      { key: "cdn", width: 220, title: "CDN-proxied", dataType: "object" },
      { key: "direct", width: 220, title: "Direct connection", dataType: "object" },
      { key: "edge", width: 260, title: "Custom edge proxy (Alchemy)", dataType: "object" },
    ],
    data: [
      {
        dimension: { title: "Latency", tooltip: "", icon: "" },
        cdn: { title: "100+ms overhead at p95", tooltip: "", icon: "" },
        direct: { title: "Lowest possible", tooltip: "", icon: "" },
        edge: { title: "Matches direct connection", tooltip: "", icon: "" },
        id: 0,
      },
      {
        dimension: { title: "Traffic types supported", tooltip: "", icon: "" },
        cdn: { title: "All (HTTP, WSS, frontend, backend)", tooltip: "", icon: "" },
        direct: { title: "RPC / WSS backend only", tooltip: "", icon: "" },
        edge: { title: "All (HTTP, WSS, frontend, backend)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        dimension: { title: "DDoS protection", tooltip: "", icon: "" },
        cdn: { title: "Built-in", tooltip: "", icon: "" },
        direct: { title: "None", tooltip: "", icon: "" },
        edge: { title: "Built-in (infrastructure provider + Envoy)", tooltip: "", icon: "" },
        id: 2,
      },
      {
        dimension: { title: "OFAC compliance", tooltip: "", icon: "" },
        cdn: { title: "CDN WAF rules", tooltip: "", icon: "" },
        direct: { title: "Not compliant", tooltip: "", icon: "" },
        edge: { title: "Application-level enforcement", tooltip: "", icon: "" },
        id: 3,
      },
      {
        dimension: { title: "Customer migration required", tooltip: "", icon: "" },
        cdn: { title: "No", tooltip: "", icon: "" },
        direct: { title: "Yes", tooltip: "", icon: "" },
        edge: { title: "No", tooltip: "", icon: "" },
        id: 4,
      },
      {
        dimension: { title: "Vendor dependency", tooltip: "", icon: "" },
        cdn: { title: "CDN vendor", tooltip: "", icon: "" },
        direct: { title: "None", tooltip: "", icon: "" },
        edge: { title: "Own infrastructure", tooltip: "", icon: "" },
        id: 5,
      },
      {
        dimension: { title: "Cost scaling", tooltip: "", icon: "" },
        cdn: { title: "Scales with traffic", tooltip: "", icon: "" },
        direct: { title: "Minimal", tooltip: "", icon: "" },
        edge: { title: "Fixed infrastructure cost", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

這種自訂邊緣代理，結合了直連的延遲優勢與 CDN 的防護與流量彈性，同時避免了兩者各自的供應商依賴與成本隨流量增加的問題。

部分 RPC 供應商已推出不依賴 CDN 的邊緣方案，但這類上線通常要求客戶在停用期限前遷移至新的端點。Alchemy Edge Proxy 則在不需要客戶採取任何行動的情況下，帶來了同等或更高的效能提升。

## 在最快的區塊鏈基礎設施上構建

Alchemy 的 Edge Proxy 只是為全球金融活動需求打造的平台中的一環。尾端延遲最高提升 7.5 倍、支援 100+ 條網路、跨多個大洲的多地區佈局，以及無需任何操作的效能升級：這一切都是 [Alchemy RPC 端點](https://www.alchemy.com/rpc-api)開箱即有的能力。

無論你在構建的是 DeFi 協議、錢包、支付應用，還是面向金融機構的鏈上基礎設施，效能與可靠性都是最基本的要求。歡迎查看[完整支援鏈列表](https://www.alchemy.com/rpc)、深入閱讀 [Alchemy 開發者文件](https://www.alchemy.com/docs)，或是[建立免費帳號](https://dashboard.alchemy.com/signup)開始構建。