सामग्री पर जाएंAPI क्लाइंट को रेज़िडेंशियल प्रॉक्सी से डेडिकेटेड IP पर ले जाने से API प्रोवाइडर को दिखने वाला IP पता बदल जाता है। इसका असर allowlist, अनुरोधों के हस्ताक्षर, रेट लिमिट और रीट्राई पर भी पड़ सकता है। सबसे सुरक्षित तरीका है कि एक बार में सिर्फ़ एक क्लाइंट का नेटवर्क रूट बदलें और उसके क्रेडेंशियल व अनुरोध भेजने का तरीका पहले जैसा रखें।
अगर आप API एक्सेस के लिए रेज़िडेंशियल प्रॉक्सी से डेडिकेटेड IP पर माइग्रेट करने की योजना बना रहे हैं, तो इसे सिर्फ़ प्रॉक्सी सेटिंग का अपडेट नहीं, बल्कि नेटवर्क रिलीज़ मानें। इस गाइड में बताया गया है कि API के लिए डेडिकेटेड IP पर कैसे माइग्रेट करें और बदलाव को नियंत्रित तरीके से कैसे टेस्ट करें। पहले पता करें कि अनुरोध कौन-सा क्लाइंट भेजता है। इसके बाद प्रोवाइडर के नियमों की पुष्टि करें और पुराना रूट हटाने से पहले नए रूट को टेस्ट करें।
1. API क्लाइंट का आउटबाउंड रूट पता करें
सबसे पहले, API को कॉल करने वाले क्लाइंट और उनके चलने की जगहों की सूची बनाएँ। प्रोडक्शन वर्कर, स्टेजिंग जॉब और डेवलपर की लोकल स्क्रिप्ट में अलग-अलग प्रॉक्सी सेटिंग हो सकती हैं, भले ही वे एक ही API अकाउंट का इस्तेमाल करते हों। बदलाव करने से पहले हर क्लाइंट का एनवायरनमेंट, डिप्लॉयमेंट लोकेशन और मौजूदा आउटबाउंड रूट दर्ज करें।
इसके बाद, एप्लिकेशन से प्रोवाइडर तक एक अनुरोध का पूरा रास्ता देखें। क्लाइंट लाइब्रेरी, एनवायरनमेंट वेरिएबल, प्रॉक्सी कॉन्फ़िगरेशन, कंटेनर या होस्ट की नेटवर्क सेटिंग और किसी भी आउटबाउंड गेटवे की जाँच करें। अहम सेटिंग वह है जो API को दिखने वाला सोर्स पता तय करती है—ज़रूरी नहीं कि वह एप्लिकेशन की मुख्य कॉन्फ़िगरेशन फ़ाइल में दी गई प्रॉक्सी सेटिंग ही हो।
इस बदलाव के दायरे से असंबंधित ट्रैफ़िक को बाहर रखें। अगर कोई होस्ट कई सेवाओं को अनुरोध भेजता है, तो पूरे होस्ट की प्रॉक्सी बदलने के बजाय सिर्फ़ API क्लाइंट को डेडिकेटेड IP से रूट करें। इससे गलती का असर सीमित रहेगा: API अनुरोध विफल होने पर मॉनिटरिंग एजेंट या कोई असंबंधित इंटीग्रेशन भी बाधित नहीं होगा।
कॉन्फ़िगरेशन में बदलाव करने से पहले मौजूदा सेटिंग दर्ज कर लें। इसमें क्लाइंट का नाम, एनवायरनमेंट, डेस्टिनेशन होस्ट और आउटबाउंड रूट नियंत्रित करने वाली सेटिंग शामिल करें। अनुरोध विफल होने पर यह छोटा-सा रिकॉर्ड पुराने और नए रूट की तुलना करने में मदद करेगा।
2. API प्रोवाइडर की IP allowlist से जुड़ी शर्तें जानें
API अकाउंट के दस्तावेज़ देखें या प्रोवाइडर के सपोर्ट चैनल से allowlist के नियमों की पुष्टि करें। प्रोडक्शन अनुरोधों को रूट करने से पहले लागू होने वाले पते के फ़ॉर्मैट, मंज़ूरी की प्रक्रिया और बदलाव के प्रभावी होने के समय की जानकारी लें।
पुष्टि करें कि प्रोवाइडर अकाउंट और इस्तेमाल की जा रही API keys पर allowlist के नियम कैसे लागू करता है। अगर अकाउंट में कई API keys हैं, तो जाँचें कि संबंधित पता हर key के लिए अलग से कॉन्फ़िगर करना ज़रूरी है या नहीं।
पूछें कि टेस्टिंग के दौरान प्रोवाइडर मौजूदा रेज़िडेंशियल-प्रॉक्सी पते को allowlist में बनाए रखने की अनुमति देता है या नहीं। दोनों सोर्स को अनुमति मिलने से नया रूट जाँचते समय तुरंत बदलाव करने की मजबूरी नहीं होगी। अगर प्रोवाइडर को मंज़ूरी के लिए टिकट या मेंटेनेंस विंडो चाहिए, तो डिप्लॉयमेंट के दौरान इसका पता चलने का इंतज़ार करने के बजाय उसी हिसाब से योजना बनाएँ।
अगर API अकाउंट पर सख़्त एक्सेस कंट्रोल लागू हैं, तो प्रोवाइडर के अपेक्षित पते की तुलना डेडिकेटेड IP को दिए गए पते से करें। अगर उपलब्ध हो, तो प्रोवाइडर के बताए तरीके या किसी सुरक्षित टेस्ट एंडपॉइंट से पते की पुष्टि करें।
3. मौजूदा सोर्स के साथ डेडिकेटेड IP भी जोड़ें
प्रोवाइडर से फ़ॉर्मैट और मंज़ूरी की प्रक्रिया की पुष्टि हो जाने के बाद, मौजूदा सोर्स को बनाए रखते हुए डेडिकेटेड IP को अकाउंट की allowlist में जोड़ें। API IP allowlist कैसे सेट करें, यह तय करते समय संबंधित अकाउंट, key और प्रोवाइडर की मंज़ूरी की शर्तों को ध्यान में रखें। इससे टेस्टिंग के दौरान दोनों में से किसी भी रूट का इस्तेमाल किया जा सकेगा। बदलाव का रिकॉर्ड रखें, जिसमें जोड़ा गया पता, उससे जुड़ा API अकाउंट या key और मंज़ूरी की स्थिति शामिल हो।
अपडेट सबमिट करने से पहले फ़ॉर्मैट की ग़लतियों की जाँच करें। टाइपो, अनचाही IP रेंज या गलत अकाउंट से जुड़ी एंट्री के कारण उलझन हो सकती है: allowlist में बदलाव दिखने के बावजूद नए क्लाइंट को authorization error मिल सकता है। अगर प्रोवाइडर की प्रक्रिया इसकी अनुमति देती है, तो किसी दूसरे ऑपरेटर से भी पते की जाँच करवाएँ।
अगर API प्रोवाइडर अलग-अलग टेस्ट और प्रोडक्शन अकाउंट देता है, तो उस अकाउंट में नई एंट्री की पुष्टि करें जिसका क्लाइंट वास्तव में इस्तेमाल करता है। सैंडबॉक्स में सफल टेस्ट से यह साबित नहीं होता कि प्रोडक्शन allowlist अपडेट हो गई है। बदलाव के नोट्स में इन अकाउंट के नाम साफ़ तौर पर दर्ज रखें।
प्रॉक्सी कनेक्शन के लिए प्रोवाइडर का बताया हुआ authentication तरीका इस्तेमाल करें और क्रेडेंशियल को सोर्स कोड में न रखें। प्रॉक्सी authentication के बेहतरीन तरीकों की गाइड से यह जाँचने में मदद मिल सकती है कि क्लाइंट प्रॉक्सी क्रेडेंशियल कैसे भेजता है, ताकि वे API क्रेडेंशियल के साथ न मिलें।
4. एक API क्लाइंट को डेडिकेटेड IP से रूट करें
पहले टेस्ट के लिए कम जोखिम वाला एक क्लाइंट चुनें, जैसे स्टेजिंग वर्कर जो प्रतिनिधि अनुरोध भेजता हो, लेकिन ग्राहकों को दिखने वाले बदलाव न करता हो। रेज़िडेंशियल प्रॉक्सी से डेडिकेटेड IP पर जाने का तरीका यह है कि पहले सिर्फ़ उसी क्लाइंट की आउटबाउंड सेटिंग अपडेट करें। उसकी API key, अनुरोध हेडर, पेलोड बनाने का तरीका और टाइमआउट सेटिंग जस की तस रखें, ताकि मुख्य बदलाव सिर्फ़ नेटवर्क रूट में हो।
कॉन्फ़िगरेशन में नए रूट को साफ़ तौर पर पहचानने योग्य बनाएँ। उदाहरण के लिए, कई एप्लिकेशन द्वारा इस्तेमाल की जाने वाली साझा प्रॉक्सी सेटिंग को बदलने के बजाय स्पष्ट नाम वाला एनवायरनमेंट वेरिएबल या अलग क्लाइंट कॉन्फ़िगरेशन ब्लॉक इस्तेमाल करें। सही सेटिंग रनटाइम और क्लाइंट लाइब्रेरी पर निर्भर करती है; डिप्लॉय करने से पहले जाँचें कि लाइब्रेरी प्रॉक्सी और सीधे कनेक्शन को कैसे संभालती है।
इस टेस्ट के दौरान पुराना रूट उपलब्ध रखें। रोलबैक का मतलब क्लाइंट की पिछली आउटबाउंड सेटिंग बहाल करना होना चाहिए, न कि उसके क्रेडेंशियल फिर से बनाना या API अनुरोध का कोड बदलना। क्रेडेंशियल न बदलें।
अगर क्लाइंट डेडिकेटेड IP तक पहुँचने के लिए HTTP या SOCKS5 प्रॉक्सी इस्तेमाल करता है, तो प्रॉक्सी प्रोवाइडर के निर्देशों के अनुसार प्रोटोकॉल और पोर्ट की पुष्टि करें। इस SOCKS5 proxy vs HTTP proxy वाली गाइड में बताए गए अंतर तब काम आ सकते हैं, जब क्लाइंट लाइब्रेरी एक प्रोटोकॉल को सपोर्ट करती हो, लेकिन दूसरे को नहीं। चुनाव करने से पहले लाइब्रेरी की वास्तविक ज़रूरतों की पुष्टि करें।
5. API authentication और अनुरोध के हस्ताक्षर जाँचें
डेडिकेटेड IP से कुछ प्रतिनिधि अनुरोध भेजें। इसमें एक read अनुरोध और, जहाँ API सुरक्षित टेस्टिंग की अनुमति देता हो, ऐसा अनुरोध शामिल करें जो प्रोडक्शन क्लाइंट वाला authentication और signing पाथ इस्तेमाल करता हो। पहली जाँच के लिए ऐसा एंडपॉइंट चुनें जिससे कोई बदलाव न हो; असली ऑर्डर बनाकर या रद्द करके टेस्ट न करें।
जवाब का कोड और प्रोवाइडर का error body दर्ज करें। 401 या 403 का मतलब क्रेडेंशियल, अनुमतियों या IP नियमों से जुड़ी समस्या हो सकता है, लेकिन कारण का अंतिम संकेत प्रोवाइडर का जवाब ही देगा। अगर API signed requests का इस्तेमाल करता है, तो पुराने और नए रूट के बीच सही method, path, timestamp, body और signed headers की तुलना करें। नेटवर्क रूट बदलने के लिए नए हस्ताक्षर की ज़रूरत नहीं होनी चाहिए, लेकिन क्लाइंट कॉन्फ़िगरेशन में बदलाव से अनुरोध बनाने का तरीका अनजाने में बदल सकता है।
अगर रेज़िडेंशियल प्रॉक्सी से अनुरोध सफल होता है, लेकिन डेडिकेटेड IP से विफल, तो अकाउंट की allowlist और key-स्तर की अनुमतियाँ जाँचें। IP-आधारित एक्सेस नियमों के लिए प्रोवाइडर के दस्तावेज़ों में दिए निर्देशों का पालन करें।
प्रॉक्सी authentication और API authentication को अलग रखें। प्रॉक्सी क्रेडेंशियल क्लाइंट को प्रॉक्सी इस्तेमाल करने की अनुमति देते हैं; API क्रेडेंशियल सेवा को अनुरोध भेजने की अनुमति देते हैं। अगर लॉग दोनों तरह की विफलताओं को सिर्फ़ “authentication failed” कहता है, तो समस्या ढूँढ़ने में समय बर्बाद हो सकता है। इतना विवरण दर्ज करें कि पता चल सके कि कनेक्शन या अनुरोध के किस चरण में गड़बड़ी आई।
6. वास्तविक वर्कलोड के तहत API का व्यवहार जाँचें
एक सफल अनुरोध से सिर्फ़ बुनियादी कनेक्टिविटी साबित होती है, प्रोडक्शन के लिए तैयारी नहीं। चुने गए क्लाइंट को उसके सामान्य अनुरोध पैटर्न के साथ चलाएँ और जवाब के कोड, लेटेंसी, टाइमआउट और रीट्राई व्यवहार की जाँच करें। अगर क्लाइंट read और write—दोनों तरह के अनुरोध भेजता है, तो सुरक्षित रिकॉर्ड या प्रोवाइडर के मंज़ूर किए टेस्ट एनवायरनमेंट में हर तरह के ऑपरेशन को टेस्ट करें।
रेट-लिमिट वाले जवाबों पर ध्यान दें। लागू लिमिट और उसके दायरे की पुष्टि करें; यह न मानें कि डेडिकेटेड IP को अलग कोटा मिलेगा। रेट-लिमिट जवाब को संभालने के क्लाइंट के तरीके की तुलना प्रोवाइडर के निर्देशों से करें। इसमें ज़रूरी प्रतीक्षा अवधि या response header भी शामिल हैं।
ट्रैफ़िक बढ़ाने से पहले रीट्राई और idempotency की समीक्षा करें। अगर प्रोवाइडर तक पहुँचने के बाद किसी अनुरोध का टाइमआउट हो जाता है, तो अपने-आप होने वाला रीट्राई किसी write को दोहरा सकता है—जब तक API idempotency key या डुप्लिकेट रोकने का कोई दूसरा तरीका सपोर्ट न करे। सामान्य तौर पर इस्तेमाल होने वाले अनुरोध पैटर्न के साथ इस व्यवहार को टेस्ट करें और पुष्टि करें कि दोहराए गए अनुरोध पर API क्या जवाब देता है।
कनेक्शन टाइमआउट और कनेक्शन के दोबारा इस्तेमाल पर भी नज़र डालें। हर अनुरोध के लिए नया कनेक्शन खोलने वाला क्लाइंट, कनेक्शन चालू रखने वाले क्लाइंट से अलग व्यवहार कर सकता है—खासकर तब, जब रास्ते में प्रॉक्सी या गेटवे हो। API के अपने error responses को DNS, कनेक्शन और प्रॉक्सी की गड़बड़ियों से अलग दर्ज करें, ताकि टीम पहचान सके कि किस लेयर पर ध्यान देना है।
7. बाकी क्लाइंट स्विच करें और पुराना रूट हटाएँ
पहला क्लाइंट सभी जाँचों में सफल हो जाए, तो बाकी क्लाइंट को एक-एक करके माइग्रेट करें। एक बार में सिर्फ़ एक एनवायरनमेंट या सर्विस अपडेट करें। फिर पुष्टि करें कि उसके अनुरोध डेडिकेटेड IP से जा रहे हैं और API से जुड़ी उसकी error rate टीम की सामान्य परिचालन सीमा में है। एक साथ सभी जगह बदलाव न करें; इससे समस्या का कारण ढूँढ़ना मुश्किल हो जाता है।
एक आसान बदलाव लॉग रखें, जिसमें हर क्लाइंट का नाम, डिप्लॉयमेंट का समय, रूट और टेस्ट का नतीजा दर्ज हो। अगर किसी एक क्लाइंट में गड़बड़ी आती है, तो इस रिकॉर्ड से यह पता लगाने में मदद मिलेगी कि समस्या क्लाइंट-विशिष्ट कॉन्फ़िगरेशन की है या प्रोवाइडर की allowlist से जुड़ी है। कारण स्पष्ट होने तक रोलआउट रोकें; वही बदलाव और एनवायरनमेंट में लागू करने की जल्दबाज़ी न करें।
रेज़िडेंशियल-प्रॉक्सी सोर्स को allowlist से तभी हटाएँ, जब हर इच्छित क्लाइंट के डेडिकेटेड IP पर चलने की पुष्टि हो जाए और रोलबैक अवधि समाप्त हो जाए। API प्रोवाइडर से पूछें कि एंट्री हटाने के लिए मंज़ूरी चाहिए या यह बदलाव तुरंत प्रभावी होता है। पुरानी एंट्री हटाने के बाद हर माइग्रेट किए गए एनवायरनमेंट से एक अनुरोध टेस्ट करें।
पुराने रूट का कॉन्फ़िगरेशन नियंत्रित रोलबैक रिकॉर्ड में रखें, लेकिन बिना वजह इस्तेमाल में न होने वाली एक्सेस चालू न छोड़ें। अगर बाद के किसी डिप्लॉयमेंट में रेज़िडेंशियल प्रॉक्सी की फिर से ज़रूरत पड़े, तो किसी बिना दस्तावेज़ वाले अपवाद पर निर्भर रहने के बजाय प्रोवाइडर की सामान्य मंज़ूरी प्रक्रिया से एक्सेस बहाल करें।