HTTP 請求返回 401 "No valid key"，但相同請求在 Postman 中可正常執行

問題
1

描述問題/錯誤/疑問

大家好，
我在使用 n8n HTTP Request 時遇到了一個奇怪的問題。
環境
n8n Self Hosted 2.20.11
HTTP Request node v4.4
外部 API 使用 JWT Bearer 認證
發生什麼事
我從 n8n 呼叫 API 授權端點。
API 傳回有效的 JWT 令牌。
我在第二個 HTTP Request node 中使用該確切的令牌。
API 回應：
{
“result”: “error”,
“description”: “No valid key”
}
HTTP 狀態：401
重要
從 n8n 手動複製的同一令牌在 Postman 中正常運作。
API 提供者已驗證端點和認證。
Postman 匯出的確切 cURL 被匯入到全新的 HTTP Request node 中，但在 n8n 中仍然失敗。
已測試 Lowercase Headers 選項。
已測試 Gzip/壓縮設定。
已測試 Accept-Encoding: identity。
Authorization header 以以下方式傳送：
Authorization: Bearer
API 供應商以相同令牌從 Postman 測試同一請求，並收到：
{
“result”: “ok”,
“idlead”: “5”
}
有人見過 n8n 傳送的內容與 Postman 不同的情況嗎，即使匯入了確切的 cURL 也是如此？
有什麼想法可以檢查來自 n8n 的原始傳出請求嗎？
謝謝。

錯誤訊息是什麼（如果有的話）？

請分享您的工作流程

分享最後一個 node 傳回的輸出

有關您的 n8n 設定的資訊

  • n8n 版本：
  • 資料庫（預設值：SQLite）：
  • n8n EXECUTIONS_PROCESS 設定（預設值：own、main）：
  • 透過以下方式執行 n8n（Docker、npm、n8n cloud、桌面應用程式）：
  • 作業系統：
2

@Hector_AnVa 最快的方式查看 n8n 實際發送的內容（正好是你要求的）：將兩個都指向請求檢查器。拿一個 webhook.site 的 URL，把 n8n 節點和你的 Postman 請求都設定指向它，兩個都執行，比較擷取到的標頭。這樣總能暴露出區別。

你已經排除了大小寫/gzip，所以剩下兩個常見的元兇：

  • 重複的 Authorization。如果節點的 Authentication 設定了認證資料 AND 還有一個手動的 Authorization 標頭（cURL 匯入通常會新增一個），n8n 會發送兩個，API 就會 401，保持只有一個。
  • n8n 的預設標頭，它會新增一個 User-Agent 和有時候 Accept-Encoding，Postman 沒有這些，嚴格的閘道會據此拒絕。

既然連匯入的 cURL 都失敗了，我賭一下是重複的 Authorization，webhook.site 的比較 30 秒內就能確認。

3

要查看 n8n 確實在傳送什麼，請使用請求檢查服務。這是比較 n8n 請求與 Postman 請求最可靠的方式。

  • 使用 Webhook.site：
    1. 前往 Webhook.site 並複製提供的唯一 URL。
    2. 將你的第二個 HTTP Request 節點的 URL 改為這個 Webhook.site URL。
    3. 執行該節點。
    4. 在 Webhook.site 介面中檢查標頭和本文。

要查看的項目： 檢查 Authorization 是否被雙重編碼、是否存在多餘的空白字符，或 Content-Type 是否與你的 API 期望的不同。

n8n 的「Authentication: Predefined Credential Type」有時會新增與你手動新增的 Authorization 標頭衝突的標頭。確保你沒有意外傳送兩個 Authorization 標頭。

  • 測試： 將 Authentication 下拉式選單設為「None」，並嚴格使用名為 Authorization 的 Header 參數，其值為 Bearer <TOKEN>。

如果你透過表達式傳遞令牌（例如 {{ $json.token }}），請確保沒有從前一個節點捕捉到尾端換行符或隱藏的空白字符。試著進行修剪：{{ $json.token.trim() }}。

某些 API 會根據預設的 axios User-Agent 標頭（通常是 axios/x.x.x）來封鎖請求。試著新增自訂 User-Agent 標頭（例如 Mozilla/5.0...）以模擬瀏覽器。

確保 Accept 標頭已明確設定（例如 application/json），因為某些 API 在傳送預設的 */* 時行為會有所不同。

4

補充 @kjooleng 的 Webhook.site 提示：對於這個特定模式（Token 在 Postman 中有效，但在 n8n 中相同的 Token 失敗）來說，一個非常常見的原因是在從第一個 HTTP Response 複製到 n8n 時，Token 末尾被插入了不可見的空格或換行符。

具體檢查方法：在返回 JWT 的第一個 HTTP Request Node 中，仔細查看輸出，最好通過 Code Node 使用 JSON.stringify($json.token) 而不是正常視圖。如果末尾出現 "\n" 或額外的空格，那就是問題所在。Postman 在手動粘貼時經常會自動修剪，但 n8n 不會。

解決方法是在將 Token 傳遞給第二個 Request 之前，對 Token 字段使用 .trim()，可以通過 Code Node 或直接在 Expression 字段中進行：{{ $json.token.trim() }}。

5

@Hector_AnVa 你可以試試 Webhook.site，將 n8n 和 Postman 指向同一個 URL，比較實際發送的內容。

最可能的原因：重複的 Authorization 標頭。匯入 cURL 時，n8n 有時會在上面再加上一個。

修正方法：將 Authentication 設為「None」，只使用手動的 Authorization: Bearer 標頭。

另外檢查：

修剪你的 token：{{ $json.token.trim() }} 隱藏的空格會破壞驗證

新增自訂 User-Agent n8n 的預設值 (axios/x.x.x) 會被某些 API 拒絕