n8n के लिए प्रॉक्सी: HTTP अनुरोध को कैसे सेट करें और 403 त्रुटि से बचें

```html

आपने n8n में वर्कफ़्लो बनाया, वह दो हफ्ते तक काम करता रहा, और फिर 403 Forbidden के साथ स्थिरता से गिरने लगा। पहला विचार - "साइट टूट गई" या "क्रेडेंशियल्स खराब हो गए।" अक्सर मामला कुछ और होता है: लक्षित सर्वर ने जान लिया कि अनुरोध ब्राउज़र से नहीं, बल्कि आपके VPS के डेटा सेंटर के IP से काम कर रही स्वचालन से आया है। n8n में एक अंतर्निहित प्रॉक्सी तंत्र है - बस यह डिफ़ॉल्ट रूप से चालू नहीं है, और कुछ सेटिंग्स वहां नहीं हैं जहां उन्हें खोजा जाता है।

चरण-दर-चरण समझते हैं: n8n में प्रॉक्सी कहाँ निर्धारित की जाती है, self-hosted और Cloud में क्या अंतर है, और कौन सी तीन जाल अधिकतर समय खा जाती हैं।

n8n को आपके ब्राउज़र की तुलना में अधिक बार क्यों ब्लॉक किया जाता है

n8n - सबसे बड़ा ओपन-सोर्स स्वचालन प्लेटफ़ॉर्म: GitHub पर लगभग 198 हजार सितारे और 59.6 हजार फोर्क्स, प्रकाशन के समय वर्तमान रिलीज - [email protected] (24 जुलाई 2026)। लोकप्रियता का एक उल्टा पक्ष है: एंटी-बॉट सिस्टम इसे अच्छी तरह से पहचानते हैं।

तीन कारक मिलकर काम करते हैं:

• User-Agent आपको तुरंत उजागर करता है। यह एक अनुमान नहीं है, बल्कि आधिकारिक रूप से दस्तावेजीकृत व्यवहार है। n8n में एक चर N8N_ENFORCE_GLOBAL_USER_AGENT है (डिफ़ॉल्ट रूप से false), और दस्तावेज़ इसका उद्देश्य सीधे वर्णित करता है: "नग्न" User-Agent स्ट्रिंग n8n को RFC-संगत Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/) में बदलना, ताकि वेब एप्लिकेशन फ़ायरवॉल द्वारा अनुरोधों के ब्लॉक को रोकने में मदद मिले। समस्या बग रिपोर्ट तक पहुँच गई: समस्या #28280 (10 अप्रैल 2026 को खोला गया, बंद) में वर्णित है कि कैसे मूल नोड्स ने bare-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 निर्धारित करें - अपने Chrome के DevTools से वर्तमान स्ट्रिंग को मैन्युअल रूप से कॉपी करें।

यह तरीका n8n Cloud पर एकमात्र उपलब्ध है: वहां आप रनटाइम वातावरण का प्रबंधन नहीं करते, इसलिए सिस्टम पर्यावरण चर आपके लिए उपलब्ध नहीं हैं, और आउटगोइंग IP निश्चित नहीं है और हर बार बदलता है। इस दृष्टिकोण का लाभ - ग्रेन्युलैरिटी: एक ही वर्कफ़्लो के विभिन्न नोड्स विभिन्न प्रॉक्सियों और विभिन्न स्थानों के माध्यम से जा सकते हैं। नुकसान - यदि नोड्स बीस हैं, तो बीस स्थानों को संपादित करना होगा।

चरण 2. पर्यावरण चर के माध्यम से वैश्विक प्रॉक्सी (self-hosted)

अपने सर्वर पर, सभी आउटगोइंग ट्रैफ़िक को एक साथ लपेटना अधिक तार्किक है। n8n मानक चर पढ़ता है:

• HTTP_PROXY - नोड्स के लिए अनएन्क्रिप्टेड HTTP ट्रैफ़िक के लिए प्रॉक्सी URL;
• 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 पर समाप्त होने वाले को proxy-from-env npm पैकेज के माध्यम से संसाधित करता है, और यह अपनी प्राथमिकता का क्रम थोपता है: छोटे संस्करण (http_proxy) बड़े (HTTP_PROXY) पर प्राथमिकता रखते हैं, यदि दोनों निर्धारित हैं। दर्द का एक क्लासिक परिदृश्य: सिस्टम में एक पुराना https_proxy लंबे समय से पड़ा है, आप HTTPS_PROXY को compose में सावधानी से लिखते हैं - और ट्रैफ़िक जिद्दी रूप से पुराने पते पर जाता है। दोनों पंजीकरण की जांच करें।

Enterprise के लिए एक अलग विवरण: लाइसेंस सर्वर के लिए अनुरोधों के लिए प्रॉक्सी चर https_proxy_license_server को केवल छोटे अक्षरों में होना चाहिए, प्रारूप - https://user:pass@proxy:port.

जाल 2: Code node वह नहीं कर सकता जो आप सोचते हैं

फोरम से अक्सर सलाह - "Code node में अपने अनुरोध को axios के साथ प्रॉक्सी-एजेंट के माध्यम से लिखें।" डिफ़ॉल्ट रूप से यह काम नहीं करेगा: n8n Code node में मॉड्यूल का आयात बंद कर देता है। उन्हें स्पष्ट रूप से अनुमति देनी पड़ती है - NODE_FUNCTION_ALLOW_BUILTIN अंतर्निहित के लिए और NODE_FUNCTION_ALLOW_EXTERNAL बाहरी के लिए (जो n8n/node_modules से हैं)। एक अतिरिक्त बिंदु: यदि आपके पास बाहरी मोड में कार्य रunners हैं, तो ये चर कंटेनर के वातावरण में नहीं, बल्कि रन्नर्स के कॉन्फ़िग में /etc/n8n-task-runners.json में env-override के रूप में निर्धारित होते हैं। प्रॉक्सी के स्टैंडर्ड विकल्प पर रहना आसान और सुरक्षित है।

जाल 3: प्रॉक्सी है, लेकिन गति वही है

प्रॉक्सी पता बदलता है, लेकिन व्यवहार नहीं। यदि वर्कफ़्लो अभी भी अनुरोधों की बौछार कर रहा है, तो आप बस नए IP को जला देंगे। उसी नोड में अंतर्निहित ब्रेक हैं:

• Batching - Items per Batch (एक बैच में कितने आइटम) और Batch Interval मिलीसेकंड में (0 = बिना विराम)। बैच 1-5 और 1000-3000 मिलीसेकंड का अंतराल रखें।
• Timeout - मिलीसेकंड में; निवासी चैनल डेटा सेंटर के चैनलों की तुलना में धीमे होते हैं, डिफ़ॉल्ट को बढ़ाना चाहिए।
• Response → Never Error - पहले 403 पर पूरे वर्कफ़्लो को नहीं गिराता, प्रतिक्रिया को शाखाबद्ध करके कोड को संसाधित करने की अनुमति देता है।
• Pagination - Update a Parameter और Response Contains Next URL मोड स्वनिर्मित लूप के बजाय।

इंस्टेंस स्तर पर गति N8N_CONCURRENCY_PRODUCTION_LIMIT द्वारा सीमित होती है (डिफ़ॉल्ट रूप से -1, यानी बिना सीमा) - एक उचित मान प्रॉक्सी पूल और स्वयं सर्वर को सुरक्षित रखेगा। आपकी अनुरोधों की गणना कैसे की जाती है और सीमाओं के साथ क्या करना है, इस पर अधिक जानकारी प्रॉक्सी के माध्यम से रेट लिमिटिंग को बायपास करने के विश्लेषण में है।

n8n के लिए कौन सी प्रॉक्सी लें

चुनाव "कूलनेस" पर निर्भर नहीं करता, बल्कि इस पर निर्भर करता है कि दूसरी तरफ कौन है।

• डेटा सेंटर की। सस्ता और तेज़। आधिकारिक API, आंतरिक सेवाओं, बॉट-फ्रेंडली साइटों और किसी भी कार्यों के लिए उपयुक्त जहां बस एक स्थिर स्थिर पता चाहिए - उदाहरण के लिए, ताकि आपका IP साझेदार की श्वेत सूची में डाला जा सके। सुरक्षित साइटों पर वही 403 मिलता है जो नग्न VPS पर मिलता है: उनके रेंज ज्ञात हैं। यह एंटी-बॉट के बिना बैच कार्यों के लिए आधार है।
• रेसिडेंशियल। वास्तविक घरेलू प्रदाताओं के पते - यह उन साइटों से डेटा एकत्र करने के लिए आवश्यक है जिनकी सुरक्षा गंभीर है, भू-निर्भर सामग्री और मूल्य निगरानी के लिए। वर्कफ़्लो के लिए जो सार्वजनिक साइटों पर जाते हैं, रेसिडेंशियल प्रॉक्सी कार्यशील डिफ़ॉल्ट हैं: बड़े पैमाने पर पार्सिंग के लिए अनुरोध पर रोटेशन लें और स्टिकी सत्र जब एक सत्र को नोड्स की श्रृंखला पर बनाए रखना हो।
• मोबाइल। सबसे उच्च स्तर की विश्वसनीयता: एक ऑपरेटर के पीछे हजारों जीवित ग्राहक होते हैं, ऐसे IP को साइट पर प्रतिबंधित करना महंगा होता है। जहां सबसे अधिक कठोरता से काटा जाता है - सोशल मीडिया और मैसेंजर के साथ काम करने के लिए उचित हैं। इसके लिए आप गति और कीमत चुकाते हैं।

मिश्रित वर्कफ़्लो पर व्यावहारिक योजना: आधिकारिक 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 आइटम पर परीक्षण रन किया गया, न कि पूरे सूची पर।

निष्कर्ष

n8n में 403 लगभग हमेशा एक कारण नहीं होता, बल्कि तीन का योग होता है: पहचानने योग्य User-Agent, डेटा सेंटर का IP और अनुरोधों की बहुत समान गति। इसे भी एक सेट के साथ ठीक किया जाता है, न कि केवल एक चेकमार्क के साथ: UA को बदलना, ट्रैफ़िक को आवश्यक प्रकार की प्रॉक्सी के माध्यम से ले जाना और नोड को Batching के माध्यम से धीमा करना। ये तीनों लीवर पहले से ही प्लेटफ़ॉर्म में अंतर्निहित हैं - उन्हें बस खोजने और चालू करने की आवश्यकता है।

शुरू करना सबसे आसान है सबसे समस्याग्रस्त नोड्स पर रेसिडेंशियल चैनल के साथ और अन्य पर डेटा सेंटर के साथ: ProxyCove पर भुगतान ट्रैफ़िक के लिए होता है, इसलिए परीक्षणों के लिए आप न्यूनतम मात्रा ले सकते हैं और देख सकते हैं कि आपका विशिष्ट वर्कफ़्लो कैसे व्यवहार करता है। कार्य के लिए प्रॉक्सी चुनें और प्रॉक्सी फ़ील्ड में स्ट्रिंग डालना कुछ मिनटों का काम है।