n8n 爬蟲 IP 被封鎖？一篇精通 Proxy 代理伺服器設定與輪換策略

恭喜你，你已經成功掌握了在 n8n 中偽裝 User-Agent 的技巧，繞過了網站的第一道反爬蟲防線。你的爬蟲可能順利地運行了數十、甚至上百次。但就在你以為可以高枕無憂時，新的災難降臨了：Connection timed out、ECONNRESET，或是更直接的 403 Forbidden 錯誤訊息再次出現。

你檢查了 User-Agent，一切正常。但無論你重試幾次，都無法再成功訪問目標網站。這時，你可能遇到了比 User-Agent 偵測更進階、也更難纏的第二道高牆——IP 封鎖 (IP Blocking)。

當一個網站的伺服器，在短時間內偵測到來自同一個 IP 位址的大量、快速、且模式規律的請求時，它會很自然地將這個 IP 視為惡意機器人，並將其加入「黑名單」，暫時或永久地拒絕其所有存取。

要突破這道高牆，我們需要學會使用爬蟲世界中的「隱身術」與「分身術」——代理伺服器 (Proxy Server)。這篇文章將是你的 n8n Proxy 實戰終極指南，我們將帶你從 Proxy 的基礎概念與選擇開始，手把手教你在 n8n 中設定代理，並深入探討最重要的「IP 輪換 (Rotation)」策略，讓你能夠打造出更強大、更難以被偵測的專業級爬蟲。

零基礎帶你完成屬於自己的n8n自動化流程

內容目錄

User-Agent 之後的第二道高牆：認識 IP Rate Limiting 與地理封鎖

在我們動手之前，先來理解為什麼你的 IP 會被「盯上」。

速率限制 (Rate Limiting): 這是最常見的原因。為了保護伺服器效能，網站會限制單一 IP 在單位時間內的請求次數。例如，「每分鐘最多 100 次請求」。當你的爬蟲超過這個頻率時，就會被暫時封鎖。
行為模式偵測： 即使你的請求頻率不高，但如果行為過於「規律」——例如，以完全固定的 2 秒間隔，依序訪問 /product/1、/product/2、/product/3…——這種不像真人的瀏覽行為，也很容易被進階的防火牆 (WAF) 偵測並封鎖。
地理位置封鎖 (Geo-blocking): 某些網站的內容，只對特定國家或地區的訪客開放。如果你的 n8n 伺服器位於美國，但你想爬取的內容僅限台灣地區用戶訪問，你同樣會被阻擋。

這些問題的共同點，都指向了你的請求來源——單一且固定的 IP 位址。而 Proxy 的核心作用，就是為你提供大量不同的 IP 位址作為「跳板」，讓你的請求看起來像是來自四面八方、不同的真實使用者。

你的數位分身：代理伺服器 (Proxy) 的種類與選擇

Proxy 服務五花八門，但主要可以分為兩大類，了解它們的差異，才能為你的任務選擇最適合的武器。

數據中心代理 (Datacenter Proxies):
- 來源： 這些 IP 來自於雲端服務供應商（如 AWS, Google Cloud）的機房。
- 優點： 速度極快、穩定性高、價格相對便宜。
- 缺點： 容易被識別。因為這些 IP 的來源很集中，許多大型網站都擁有數據中心 IP 的黑名單，對於防禦嚴密的網站，效果較差。
- 適用情境： 對反爬蟲機制較弱的網站進行大量、快速的資料抓取。
住宅代理 (Residential Proxies):
- 來源： 這些 IP 來自於真實的家庭寬頻網路（由使用者自願分享其閒置頻寬）。
- 優點： 極難被偵測。因為你的請求看起來就跟一個真實的家庭用戶完全一樣，匿名性最高。
- 缺點： 速度較慢、穩定性相對較差（畢竟是家用網路）、價格昂貴得多。
- 適用情境： 爬取對 IP 審核極度嚴格的網站，例如電商巨頭、社群媒體、航空公司票價等。

選擇建議： 永遠先從數據中心代理開始嘗試。只有當數據中心代理被證明無效時，再考慮升級到成本更高的住宅代理。

n8n Proxy 基礎設定：如何在 HTTP Request 節點中指定代理伺服器？

在 n8n 中設定一個固定的 Proxy 非常簡單。假設你從 Proxy 供應商那裡，得到了一組代理伺服器的資訊，格式通常是 http://username:password@proxy_host:proxy_port。

在 n8n 中，打開你的 HTTP Request 節點。
進入「Options」分頁。
找到「Proxy」欄位。
將你的完整代理伺服器連線字串，貼到這個欄位中。

完成後，這個 HTTP Request 節點發出的所有請求，都會透過你指定的代理伺服器來進行轉發。對於只需要一個固定跳板（例如，繞過地理封鎖）的簡單任務，這樣就足夠了。

進階戰術：在 n8n 中手動建立「Proxy 輪換 (Rotation)」機制

對於大規模的爬取任務，使用單一固定的 Proxy IP 很快就會被識破。我們需要讓 n8n 在每一次（或每幾次）請求時，都自動切換到一個新的 Proxy IP。這就是「IP 輪換」。

雖然 n8n 節點本身沒有內建輪換功能，但我們可以利用 Expressions，輕鬆地打造出自己的輪換機制。

目標： 我們有一個包含 5 個 Proxy IP 的列表，現在要對 100 個網址進行爬取，希望每次請求都使用不同的 Proxy。

準備 Proxy 列表 (Set 節點):
- 在流程的開頭，使用一個 Set 節點，建立一個名為 proxy_list 的陣列 (Array)，並將你所有的 Proxy 連線字串放進去。
  - Name: proxy_list
  - Value (Expression):JSON[ "http://user:pass@proxy1.com:8080", "http://user:pass@proxy2.com:8080", "http://user:pass@proxy3.com:8080", "http://user:pass@proxy4.com:8080", "http://user:pass@proxy5.com:8080" ]
建立迴圈 (Split In Batches 節點):
- 將你要爬取的 100 個網址，傳入 Split In Batches 節點。
- Batch Size: 1。這會將流程變成一個逐一執行的迴圈。
動態設定 Proxy (HTTP Request 節點):
- 在迴圈中，設定你的 HTTP Request 節點。
- URL (Expression): {{ $json.url_to_scrape }} (從迴圈傳入的當前網址)。
- Options > Proxy (Expression): 這裡就是魔法發生的地方！JavaScript{{ $node["Set"].json.proxy_list[$runIndex % $node["Set"].json.proxy_list.length] }}
  - 解說：
    - $runIndex: n8n 的一個內建變數，代表當前是迴圈的第幾次執行（從 0 開始）。
    - %: 這是「取餘數」的運算子。
    - $node["Set"].json.proxy_list.length: 取得我們 Proxy 列表的長度（在這個例子中是 5）。
    - $runIndex % 5 的結果，會是 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, ... 這樣一個循環的序列。
    - 這段 Expression 的作用，就是利用迴圈的執行次數，依序、循環地從我們的 Proxy 列表中，取出一個 Proxy IP 來使用。

實戰演練：打造一個能自動輪換 IP 的高匿名性爬蟲

讓我們將以上概念，應用到一個完整的流程中。

流程設計： Start -> Set (定義目標與 Proxy) -> Split In Batches -> HTTP Request -> ...

Set 節點:
- 建立 urls_to_scrape 陣列，包含所有目標網址。
- 建立 proxy_list 陣列，包含你所有的 Proxy IP。
Split In Batches 節點:
- Field to Split Out: {{ $json.urls_to_scrape }}
- Batch Size: 1
HTTP Request 節點:
- URL (Expression): {{ $json.value }} (Split In Batches 輸出的單一網址)。
- Headers > User-Agent: Mozilla/5.0 ... (記得也要偽裝 User-Agent)。
- Options > Proxy (Expression): {{ $node["Set"].json.proxy_list[$runIndex % $node["Set"].json.proxy_list.length] }}

啟用這個流程後，n8n 就會像一個擁有無數分身的忍者，用不同的 IP、不同的身分，去逐一訪問你的目標網站，大幅降低被封鎖的風險。

Proxy 使用的最佳實踐與道德準則

選擇可靠的供應商： 不要使用網路上來路不明的免費 Proxy，它們通常極不穩定且有安全風險。請選擇信譽良好的付費 Proxy 供應商。
處理失敗的 Proxy: 現實世界中，Proxy IP 隨時可能失效。你應該在 HTTP Request 節點上，啟用「錯誤處理」機制。當一個請求因為 Proxy 失效而失敗時，你可以記錄下這個失敗的 Proxy，並在下一次輪換時將其排除。
尊重與責任： 使用 Proxy 的目的是為了更穩定、更有效地獲取公開資訊，而不是為了進行惡意攻擊或癱瘓對方伺服器。請始終保持一個合理的請求頻率，並遵守目標網站的 robots.txt 規範。