n8n Cloud：Send Email (SMTP) 節點掛起並無聲失敗 — Cloud 上的出站 SMTP (465/587) 是否被阻止？

問題
,
1

你能回答以下問題嗎：

  1. n8n Cloud 是否會從其基礎設施中阻止、限制或速率限制埠 465 或 587 上的出站 SMTP 連線？
  2. 如果存在限制，是特定於我的方案層級，還是適用於所有 n8n Cloud 帳戶？
  3. 是否有建議的解決方法可以透過 n8n Cloud 特別是（與自託管 n8n 相對）傳送電子郵件？
2

Hi @Kalon 歡迎！
由於 n8n Cloud 對外出流量使用動態 IP，如果您的外部 SMTP 提供商正在封鎖連線，您可以嘗試將 n8n Cloud 的出站 IP 範圍加入白名單。

我認為這是最有可能的原因。

4

沒錯，這在 n8n Cloud 上是預期的行為，而不是你那邊出了問題。Cloud 在所有套餐層級上都會封鎖埠 25、465 和 587 上的原始出站 SMTP，所以傳送電子郵件節點就會卡著直到連線逾時，這就是為什麼你會看到卡住但日誌中沒有任何有用的資訊。其他回覆說得對，修正方法是停止使用原始 SMTP，改為透過 API 傳送。Gmail 或 Microsoft Outlook 節點之所以有效，是因為它們透過提供者 API 走 https，而不是 SMTP，對於任何交易性郵件，透過 HTTP Request 節點（或它們的專用節點）使用 Resend、SendGrid 或 Mailgun 這類提供者是最乾淨的做法。如果你真的需要原始 SMTP，自行託管是唯一能讓你控制出站埠的地方。

有一件事值得在你做這些改變時順便解決，既然你已經注意到它會無聲地失敗：即使你切換後，電子郵件仍然會無聲失敗。API 呼叫可能回傳已接受，節點變綠，但訊息仍然無法到達，因為寄件網域未驗證、被歸檔為垃圾郵件，或供應商停用了該位址。所以接好線路後，傳送一封真實訊息到你控制的收件匣，並查看供應商的傳遞日誌，不要只看節點完成後是否變綠。你是在傳送重設和收據之類的交易性郵件，還是更像是發送通知給自己？這會影響哪條路線最不麻煩。

5

@Kalon 我們不應該封鎖出站 SMTP 連接埠，我懷疑是郵件服務在阻止連接，而不是雲端那邊的問題。可能是 SSL/TLS 設定的問題。

6

歡迎，Kalon :waving_hand:

關於你的三個問題：

  1. n8n Cloud 沒有公開文件說明是否在 465/587 埠上阻止或限速出站 SMTP，而且它對許多 Cloud 用戶來說運作良好——所以真正的埠阻止不太可能。無聲掛起幾乎總是埠/SSL 不匹配（465 需要開啟 SSL/TLS；587 需要關閉以用於 STARTTLS——如果不匹配，連線就會一直卡著直到逾時）或提供商拒絕你（Gmail/Outlook 通常需要應用程式密碼，而且它們會阻止陌生的發送 IP）。不過我無法評論 n8n 的內部基礎設施限制——如果你懷疑存在實際阻止，支援團隊可以確認。

  2. 不了解有任何分層特定的 SMTP 限制——據我所知，Cloud 帳戶間的行為是相同的。

  3. Cloud 上可靠的解決方案：跳過原始 SMTP，改用交易型電子郵件 API 透過 HTTPS 發送——SendGrid、Brevo、Postmark、Resend 或 Mailgun（他們的節點或 HTTP Request 節點）。這完全避免了埠/TLS 的麻煩，提供更好的送達率，而且在 Cloud 上就是能用。如果你想繼續使用 SMTP：試試 587 並關閉 SSL、使用應用程式密碼，然後查看失敗的執行——即使看起來無聲，實際的錯誤（認證 vs TLS vs 逾時）通常也在裡面。