پروکسی برای n8n: چگونه درخواست HTTP را تنظیم کنیم و از خطای ۴۰۳ جلوگیری کنیم

```html

شما یک workflow در n8n جمع‌آوری کرده‌اید، او دو هفته کار کرده و سپس به طور مداوم با 403 Forbidden سقوط کرده است. اولین فکر — «سایت خراب شده» یا «اعتبارنامه‌ها منقضی شده‌اند». بیشتر اوقات مشکل چیز دیگری است: سرور هدف متوجه شده است که درخواست از مرورگر نیامده، بلکه از اتوماسیونی است که با IP مرکز داده VPS شما کار می‌کند. n8n دارای یک مکانیزم داخلی پروکسی است — فقط به طور پیش‌فرض فعال نیست و بخشی از تنظیمات در جایی زندگی می‌کند که آنها را جستجو می‌کنند.

بیایید به صورت مرحله‌ای بررسی کنیم: کجا دقیقاً پروکسی در n8n تنظیم می‌شود، چه تفاوتی بین self-hosted و Cloud وجود دارد و چه سه تله‌ای بیشترین زمان را می‌بلعند.

چرا n8n بیشتر از مرورگر شما مسدود می‌شود

n8n — بزرگترین پلتفرم اتوماسیون open-source: تقریباً 198 هزار ستاره و 59.6 هزار fork در GitHub، نسخه فعلی در زمان انتشار — [email protected] (24 ژوئیه 2026). محبوبیت یک طرف منفی دارد: سیستم‌های ضد ربات به خوبی خط‌خطی شبکه‌ای آن را می‌شناسند.

سه عامل در اینجا وجود دارد:

• User-Agent شما را به سرعت شناسایی می‌کند. این یک حدس نیست، بلکه یک رفتار مستند شده است. در n8n یک متغیر N8N_ENFORCE_GLOBAL_USER_AGENT وجود دارد (به طور پیش‌فرض false) و مستندات به وضوح هدف آن را توصیف می‌کند: جایگزینی رشته «عریان» User-Agent n8n با Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/) برای جلوگیری از مسدود شدن درخواست‌ها توسط فایروال‌های وب‌اپلیکیشن. مشکل به گزارش‌های باگ رسید: در issue #28280 (باز شده در 10 آوریل 2026، بسته شده) توصیف شده است که چگونه نودهای بومی UA عریان n8n را برمی‌گرداند و سایت‌ها با دلیل «Bad User-Agent» 403 پاسخ می‌دهند. خود نود HTTP Request در زیر کاپوت از axios استفاده می‌کند و بدون هدر دستی به راحتی شناسایی می‌شود.
• IP سرور شما — از مرکز داده است. n8n تقریباً همیشه بر روی VPS یا در ابر زندگی می‌کند. این دامنه‌ها به طور عمومی شناخته شده و به عنوان «غیر کاربر» علامت‌گذاری شده‌اند: برخی از سایت‌ها آنها را به شدت محدود می‌کنند، حتی تا حدی که محدودیت‌های درخواست‌ها به مراتب پایین‌تر از اتصال‌های خانگی است.
• سرعت درخواست‌ها غیر انسانی است. نود در یک حلقه ده‌ها درخواست در ثانیه از یک آدرس ارسال می‌کند — این یک تریگر کلاسیک برای محدودیت نرخ و مسدود شدن IP بعدی است.

مرحله 1. پروکسی در خود نود (در Cloud نیز کار می‌کند)

سریع‌ترین راه — تنظیم پروکسی به صورت نقطه‌ای برای یک HTTP Request:

1. نود HTTP Request را باز کنید.
2. در پایین روی Add Option کلیک کنید و Proxy را انتخاب کنید — این یک فیلد متنی برای URL پروکسی سرور است.
3. رشته را در فرمت استاندارد با احراز هویت وارد کنید: http://لگین:رمزعبور@host:port.
4. همچنین گزینه هدرها را اضافه کنید: Send Headers را فعال کنید و User-Agent مرورگر واقعی را تعیین کنید — به صورت دستی رشته فعلی را از DevTools Chrome خود کپی کنید.

این روش — تنها گزینه موجود در n8n Cloud است: در آنجا شما بر محیط اجرای کنترل ندارید، بنابراین متغیرهای محیطی سیستم برای شما در دسترس نیستند و IP خروجی ثابت نیست و از یک اجرا به اجرای دیگر تغییر می‌کند. مزیت این رویکرد — جزئیات: نودهای مختلف یک workflow می‌توانند از پروکسی‌های مختلف و جغرافیای متفاوت استفاده کنند. معایب — اگر بیست نود وجود داشته باشد، باید بیست مکان را اصلاح کنید.

مرحله 2. پروکسی جهانی از طریق متغیرهای محیطی (self-hosted)

در سرور خود منطقی‌تر است که تمام ترافیک خروجی را یکجا بپیچید. n8n متغیرهای استاندارد را می‌خواند:

• HTTP_PROXY — URL پروکسی برای ترافیک HTTP غیر رمزگذاری شده نودها؛
• HTTPS_PROXY — همین برای درخواست‌های TLS/SSL (در عمل این پارامتر اصلی شماست)؛
• ALL_PROXY — زمانی استفاده می‌شود که HTTP_PROXY/HTTPS_PROXY خاص‌تر تعیین نشده باشد؛
• NO_PROXY — لیست میزبان‌ها به صورت کاما، که n8n به طور مستقیم به آنها می‌رود و از پروکسی دور می‌زند.

در docker-compose.yml اینگونه به نظر می‌رسد:

• HTTPS_PROXY=http://لگین:رمزعبور@gate.provider.com:8080
• NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
• N8N_ENFORCE_GLOBAL_USER_AGENT=true

حتماً NO_PROXY را پر کنید. در غیر این صورت، از طریق پروکسی خارجی، درخواست‌های داخلی نیز ارسال می‌شوند — به پایگاه داده Postgres شما، به کانتینرهای همسایه، به دامنه وب‌هوک خودتان. علامت این است که «همه چیز بعد از فعال‌سازی پروکسی خراب شده است»، در حالی که سایت‌های هدف به تازگی باز شده‌اند.

اگر می‌خواهید نسخه n8n را به بیرون افشا نکنید، به جای رشته RFC، رشته خود را از طریق N8N_GLOBAL_USER_AGENT_VALUE تعیین کنید — این مقدار پیش‌فرض را نادیده می‌گیرد. منطق کلی تنظیم ترافیک کانتینری همانند سایر سناریوها است: تجزیه و تحلیل فرمت‌ها و زیرآب‌ها در راهنمای پروکسی کردن کانتینرهای Docker وجود دارد.

مرحله 3. سه تله که شب را می‌بلعند

تله 1: ثبت متغیرها تصمیم می‌گیرد

این موضوع غیر واضح است و تقریباً در هیچ‌کدام از آموزش‌ها دیده نمی‌شود. n8n متغیرهایی که با _PROXY پایان می‌یابند را از طریق بسته npm proxy-from-env پردازش می‌کند و آن اولویت خود را تحمیل می‌کند: نسخه‌های کوچک (http_proxy) بر نسخه‌های بزرگ (HTTP_PROXY) اولویت دارند، اگر هر دو تعیین شده باشند. سناریوی کلاسیک درد: در سیستم یک https_proxy فراموش شده وجود دارد، شما به دقت HTTPS_PROXY را در compose تعیین می‌کنید — و ترافیک به طور سرسختانه به آدرس قدیمی می‌رود. هر دو ثبت را بررسی کنید.

جزئیات جداگانه برای Enterprise: متغیر پروکسی برای درخواست‌ها به سرور مجوز https_proxy_license_server باید فقط کوچک باشد، فرمت — https://user:pass@proxy:port.

تله 2: نود کد نمی‌تواند آنچه را که شما در نظر دارید انجام دهد

یک توصیه رایج از فروم‌ها — «در نود کد درخواست خود را از طریق axios با پروکسی‌اجنت بنویسید». به طور پیش‌فرض این کار نخواهد کرد: n8n واردات ماژول‌ها را در نود کد غیرفعال می‌کند. باید به طور واضح آنها را مجاز کنید — NODE_FUNCTION_ALLOW_BUILTIN برای داخلی‌ها و NODE_FUNCTION_ALLOW_EXTERNAL برای خارجی‌ها (از n8n/node_modules). نکته اضافی: اگر شما task runners در حالت external دارید، این متغیرها در محیط کانتینر تعیین نمی‌شوند، بلکه در پیکربندی رنرها /etc/n8n-task-runners.json به عنوان env-override قرار می‌گیرند. بهتر و ایمن‌تر است که بر روی گزینه پروکسی در نود بمانید.

تله 3: پروکسی وجود دارد، اما سرعت همان است

پروکسی آدرس را تغییر می‌کند، اما رفتار را نه. اگر workflow هنوز هم درخواست‌ها را به صورت انبوه ارسال می‌کند، شما فقط IP‌های جدید را می‌سوزانید. در همان نود، ترمزهای داخلی وجود دارد:

• Batching — Items per Batch (چند عنصر در هر بسته) و Batch Interval به میلی‌ثانیه (0 = بدون وقفه). بسته را 1–5 قرار دهید و فاصله را در 1000–3000 میلی‌ثانیه تنظیم کنید.
• Timeout — به میلی‌ثانیه؛ کانال‌های مقیم کندتر از کانال‌های مرکز داده هستند، مقدار پیش‌فرض باید افزایش یابد.
• Response → Never Error — کل workflow را در اولین 403 نمی‌اندازد، اجازه می‌دهد کد پاسخ را با انشعاب پردازش کند.
• Pagination — حالت‌های Update a Parameter و Response Contains Next URL به جای حلقه‌های دست‌ساز.

در سطح نمونه، سرعت با N8N_CONCURRENCY_PRODUCTION_LIMIT محدود می‌شود (به طور پیش‌فرض -1، یعنی بدون محدودیت) — مقدار معقولی می‌تواند هم پروکسی‌پول و هم خود سرور را حفظ کند. برای اطلاعات بیشتر در مورد اینکه چگونه سایت‌ها درخواست‌های شما را محاسبه می‌کنند و چه کار باید با محدودیت‌ها انجام دهید، در تجزیه و تحلیل دور زدن محدودیت نرخ از طریق پروکسی مراجعه کنید.

کدام پروکسی‌ها برای n8n مناسب هستند

انتخاب به «خوب بودن» بستگی ندارد، بلکه به اینکه چه کسی در طرف دیگر است.

• پروکسی‌های مرکز داده. ارزان و سریع. برای API‌های رسمی، خدمات داخلی، سایت‌های دوستانه با ربات‌ها و هر وظیفه‌ای که به سادگی به یک آدرس ثابت و پایدار نیاز دارد مناسب است — به عنوان مثال، تا IP شما در لیست سفید شریک قرار گیرد. در سایت‌های محافظت شده، همان 403 را می‌دهند که VPS عریان: دامنه‌های آنها شناخته شده‌اند. این پایه‌ای برای وظایف بسته‌ای بدون ضد ربات است.
• پروکسی‌های مقیم. آدرس‌های ارائه‌دهندگان واقعی خانگی — چیزی که برای جمع‌آوری داده‌ها از سایت‌های با حفاظت جدی، برای محتوای وابسته به جغرافیا و نظارت بر قیمت‌ها نیاز است. برای workflow‌هایی که به سایت‌های عمومی می‌روند، پروکسی‌های مقیم — پیش‌فرض کارآمد: روتیشن بر اساس درخواست برای پارسینگ انبوه و جلسات چسبنده، زمانی که نیاز به حفظ یک جلسه در زنجیره نودها دارید، بگیرید.
• پروکسی‌های موبایلی. بالاترین سطح اعتماد: هزاران مشترک زنده پشت یک اپراتور نشسته‌اند، مسدود کردن چنین IP برای سایت هزینه‌بر است. در جاهایی که سخت‌تر محدود می‌کنند — کار با شبکه‌های اجتماعی و پیام‌رسان‌ها — توجیه‌پذیر است. برای این هزینه و سرعت را پرداخت می‌کنید.

یک طرح عملی در workflow مختلط: API‌های رسمی — به طور مستقیم یا از طریق پروکسی‌های مرکز داده، سایت‌های عمومی — از طریق پروکسی‌های مقیم، شبکه‌های اجتماعی — از طریق پروکسی‌های موبایلی. گزینه پروکسی در هر نود به طور جداگانه تنظیم می‌شود، بنابراین می‌توان همه اینها را در یک سناریو بدون مشکل ترکیب کرد.

چک‌لیست قبل از راه‌اندازی

1. پروکسی تعیین شده است — یا به عنوان گزینه Proxy در نود، یا از طریق HTTPS_PROXY; در Cloud فقط گزینه اول در دسترس است.
2. هر دو ثبت متغیرها بررسی شده‌اند — کوچک‌ها بزرگ‌ها را نادیده می‌گیرند.
3. NO_PROXY localhost، پایگاه داده و میزبان‌های داخلی را می‌بندد.
4. User-Agent جایگزین شده است: N8N_ENFORCE_GLOBAL_USER_AGENT=true یا هدر شخصی در نود. همچنین سایر هدرها را بررسی کنید — مجموعه غیر همسان هدرها اتوماسیون را به خوبی خود User-Agent نشان می‌دهد.
5. Batching با فاصله غیر صفر فعال شده است.
6. یک آزمایش بر روی 3–5 عنصر انجام شده است، نه بر روی کل لیست.

نتیجه‌گیری

403 در n8n تقریباً همیشه نه یک دلیل، بلکه مجموع سه دلیل است: User-Agent قابل شناسایی، IP مرکز داده و سرعت بسیار یکنواخت درخواست‌ها. این نیز با مجموعه‌ای از اقدامات قابل درمان است، نه فقط یک علامت: UA را جایگزین کنید، ترافیک را از طریق پروکسی نوع مناسب هدایت کنید و نود را از طریق Batching کند کنید. هر سه اهرم به طور پیش‌فرض در پلتفرم گنجانده شده‌اند — کافی است آنها را پیدا کرده و فعال کنید.

آغاز کار با یک کانال مقیم در نودهای مشکل‌دار و مرکز داده در سایر نودها ساده‌ترین راه است: پرداخت در ProxyCove بر اساس ترافیک است، بنابراین می‌توانید حداقل حجم را برای آزمایش‌ها بگیرید و ببینید workflow خاص شما چگونه عمل می‌کند. پروکسی مناسب برای وظیفه را انتخاب کنید و رشته را در فیلد پروکسی قرار دهید — این کار چند دقیقه زمان می‌برد.