[होम](https://servghost.com/hi) /
[गोपनीयता होस्टिंग Guides](https://servghost.com/hi/guides) /
VPS पर DDoS प्रोटेक्शन: होस्ट कहाँ रुकता है, लेयर 7 कहाँ शुरू होती है






परिचालन


# अपने VPS पर DDoS हमले से बचना



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


[गाइड पढ़ें](#guide-body)
[FAQ](#guide-faq)






## इस पेज पर




- [गाइड](#guide-body)

- [FAQ](#guide-faq)

- [संबंधित गाइड्स](#guide-related)

- [सुझाए गए पेज](#guide-cta)






KYC नहीं
केवल क्रिप्टो
लॉग नहीं
DMCA अनदेखा
पूर्ण रूट
NVMe SSD





22 मिनट पढ़ें
Sep 2026 को अपडेट किया

इस पेज पर

[01एक ही नाम वाले दो अलग हमले](#एक-ह-नम-वल-द-अलग-हमल)
[02"DDoS प्रोटेक्शन शामिल है" असल में क्या देता है](#ddos-परटकशन-शमल-ह-असल-म-कय-दत-ह)
[03पहले तय करें कि यह हमला है भी या नहीं](#पहल-तय-कर-क-यह-हमल-ह-भ-य-नह)
[04सर्वर से ख़ुद हमले को पढ़ना](#सरवर-स-खद-हमल-क-पढन)
[05पहले दस मिनट](#पहल-दस-मनट)
[06टिकने वाली रेट लिमिट, और वह ग़लती जो हर कोई करता है](#टकन-वल-रट-लमट-और-वह-गलत-ज-हर-कई-करत-ह)
[07कैशिंग सबसे सस्ती मिटिगेशन है जो आप कभी तैनात करेंगे](#कशग-सबस-ससत-मटगशन-ह-ज-आप-कभ-तनत-करग)
[08वे सीमाएँ जो तय करती हैं कि आप गिरेंगे या नहीं](#व-समए-ज-तय-करत-ह-क-आप-गरग-य-नह)
[09ओरिजिन के आगे कुछ रखना](#ओरजन-क-आग-कछ-रखन)
[10छुपा हुआ ओरिजिन किसी भी फ़िल्टर से ज़्यादा क़ीमती है](#छप-हआ-ओरजन-कस-भ-फलटर-स-जयद-कमत-ह)
[11हार्डवेयर और लोकेशन ऐसे चुनना कि हमले उबाऊ बने रहें](#हरडवयर-और-लकशन-ऐस-चनन-क-हमल-उबऊ-बन-रह)
[12पाँच चीज़ें जो नहीं करनी चाहिए](#पच-चज-ज-नह-करन-चहए)
[13संक्षिप्त वर्शन](#सकषपत-वरशन)
[FAQCommon प्रश्न](#guide-faq)
[→सुझाए गए पेज](#guide-cta)







दो पल होते हैं जब लोगों को पता चलता है कि DDoS मिटिगेशन असल में कैसे काम करता है। पहला पल शांत होता है, ख़रीदते वक़्त, जब कोई एक फ़ीचर लिस्ट पढ़ता है जिसमें लिखा है "DDoS प्रोटेक्शन शामिल है" और चुपचाप मान लेता है कि यह वाक्य हर चीज़ को कवर करता है। दूसरा पल रात के तीन बजे आता है, जब साइट डाउन हो, ग्राफ़ ऐसे ग़लत दिखें जिनका कोई मतलब न बने, और वह शामिल प्रोटेक्शन — सही तरीक़े से, और डिज़ाइन के मुताबिक़ — बिल्कुल कुछ न कर रहा हो।

दोनों पल एक ही प्रोडक्ट और एक ही सच्चाई से जुड़े होते हैं: एक होस्टिंग प्रोवाइडर उन हमलों को फ़िल्टर करता है जो कच्चे वॉल्यूम के तौर पर आते हैं, क्योंकि वह उस पाइप का मालिक है जिससे वे पैकेट गुज़रते हैं, आप नहीं। यह उन हमलों को फ़िल्टर नहीं कर सकता जो सामान्य दिखने वाले रिक्वेस्ट के तौर पर आते हैं, क्योंकि नेटवर्क की नज़र से वे सामान्य दिखने वाले रिक्वेस्ट ही हैं। वह रेखा — जो फ्लड आपका होस्ट सोख लेता है और जो फ्लड आपको ख़ुद झेलना पड़ता है, इन दोनों के बीच — ही पूरा विषय है। आगे जो कुछ भी है, वह यह पता लगाने के बारे में है कि आप इस रेखा के किस तरफ़ हैं, और हर तरफ़ क्या करना है।

## एक ही नाम वाले दो अलग हमले

"DDoS" एक ऐसा शब्द है जो दो समस्याओं को ढँकता है, और नतीजे के अलावा इन दोनों में लगभग कुछ भी साझा नहीं है। इन्हें अलग-अलग जगहों पर, अलग-अलग लोगों द्वारा, अलग-अलग औज़ारों से रोका जाता है, और इन्हें गड्डमड्ड कर देना ही वजह है कि इतनी सारी मिटिगेशन कोशिशें ग़लत लेयर पर जाकर ख़त्म होती हैं।

| | वॉल्यूमेट्रिक — लेयर 3 और 4 | एप्लिकेशन — लेयर 7 |
| --- | --- | --- |
| क्या आता है | SYN फ्लड, खुले DNS, NTP या memcached रिफ्लेक्टर के ज़रिए UDP एम्प्लिफ़िकेशन, ACK फ्लड, सीधी कचरा पैकेट बाढ़ | सामान्य HTTP रिक्वेस्ट: GET फ्लड, POST फ्लड, slow-loris, कैश-बस्टिंग क्वेरी स्ट्रिंग |
| किसमें मापा जाता है | गीगाबिट और लाखों पैकेट प्रति सेकंड | रिक्वेस्ट प्रति सेकंड — अक्सर बस कुछ हज़ार |
| आपको नुक़सान पहुँचाने के लिए ज़रूरी बैंडविड्थ | बहुत ज़्यादा। यह एक क्षमता की होड़ है | लगभग कुछ नहीं। अगर एंडपॉइंट काफ़ी महँगा हो तो एक अकेला लैपटॉप भी यह कर सकता है |
| इसे कहाँ रोकना ज़रूरी है | **अपस्ट्रीम, आपके प्रोवाइडर द्वारा।** जब तक पैकेट आपके पोर्ट तक पहुँचते हैं, नुक़सान हो चुका होता है | **आपके सर्वर पर, आपके द्वारा**, या उसके आगे आपके नियंत्रण वाली किसी प्रॉक्सी पर |
| बॉक्स पर यह कैसा दिखता है | इंटरफ़ेस भरा हुआ, पैकेट काउंटर बेतुके, CPU शायद ख़ाली भी हो | मामूली बैंडविड्थ, पर हर वर्कर व्यस्त, लोड बढ़ता हुआ, डेटाबेस क्यू बढ़ती हुई |
| इसे कौन ठीक करता है | आपके होस्ट की स्क्रबिंग, अपने-आप, आमतौर पर सेकंडों में | आपका कॉन्फ़िगरेशन — रेट लिमिट, कैशिंग, कनेक्शन सीमाएँ |

आख़िरी दो पंक्तियाँ फिर से पढ़ें, क्योंकि इनमें व्यावहारिक बात छुपी है। अगर इंटरफ़ेस भर चुका है, तो सर्वर में आप जो भी टाइप करें उससे कोई फ़र्क़ नहीं पड़ेगा: पैकेट पहले ही पोर्ट को खा चुके हैं, और इन्हें गिराने वाला अकेला पक्ष वह है जो अपस्ट्रीम राउटर का मालिक है। अगर इंटरफ़ेस शांत है पर साइट फिर भी डाउन है, तो उल्टा सच है — आपके होस्ट को कुछ भी ग़लत नहीं दिखता क्योंकि उनकी लेयर पर सच में कुछ भी ग़लत *नहीं* है, और यह ठीक करना पूरी तरह आपका काम है।

वॉल्यूमेट्रिक फ्लड अपस्ट्रीम फ़िल्टर होते हैं, जहाँ क्षमता मौजूद है। जो इस फ़िल्टर से बचकर निकलता है वह सामान्य दिखने वाला ट्रैफ़िक है — और उसे रोकना आपका काम है, आपके होस्ट का नहीं।

## "DDoS प्रोटेक्शन शामिल है" असल में क्या देता है

नेटवर्क-लेयर प्रोटेक्शन असली है, क़ीमती है, और लगभग हमेशा ग़लत समझा जाता है। जब कोई प्रोवाइडर L3/L4 फ़िल्टरिंग का विज्ञापन करता है, तो उसका मतलब है कि उनका नेटवर्क आपके पते के लिए आने वाले ट्रैफ़िक पर नज़र रखता है, और जब कोई फ्लड पकड़ में आता है तो ट्रैफ़िक को स्क्रबिंग हार्डवेयर से गुज़ारा जाता है जो नुक़सानदेह हिस्सा गिरा देता है और जो वैध दिखे उसे आगे भेज देता है। यह बिना किसी सपोर्ट टिकट के होता है, और आमतौर पर आपको एक छोटी-सी झलक के अलावा कुछ पता भी नहीं चलता।

यह एक वाक्य बहुत सारा काम कर रहा है, इसलिए यह समझना ज़रूरी है कि इसमें क्या शामिल है और क्या नहीं:

- **यह उन हमलों को कवर करता है जिन्हें आप अकेले नहीं झेल सकते।** 1 Gbps पोर्ट वाले सर्वर के ख़िलाफ़ 200 Gbps का एम्प्लिफ़िकेशन फ्लड कोई कॉन्फ़िगरेशन समस्या नहीं है। यह सीधा हिसाब-किताब है। अपस्ट्रीम स्क्रबिंग ही अकेला जवाब है जो मौजूद है।

- **यह आपके एप्लिकेशन के बारे में कुछ नहीं जानता।** फ़िल्टर को नहीं पता कि आपके कौन-से URL महँगे हैं, कौन-से विज़िटर लॉग-इन हैं, या यह कि आपके सर्च एंडपॉइंट पर एक रिक्वेस्ट की क़ीमत आपके लोगो पर एक रिक्वेस्ट से चार सौ गुना ज़्यादा है।

- **यह एक थ्रेशोल्ड पर प्रतिक्रिया देता है, आपकी तकलीफ़ पर नहीं।** डिटेक्शन ट्रैफ़िक वॉल्यूम पर ट्रिगर होता है। जो हमला कभी थ्रेशोल्ड पार नहीं करता, वह इसे कभी ट्रिगर नहीं करता — चाहे उसने आपकी साइट को कितनी ही बुरी तरह क्यों न गिरा दिया हो।

- **बेहद असाधारण मामलों में यह कुछ देर के लिए नल-रूट भी कर सकता है।** हर नेटवर्क की एक सीमा होती है। अगर कोई हमला साझा इन्फ्रास्ट्रक्चर के लिए ख़तरा बन जाए, तो पता कुछ समय के लिए गिराया जा सकता है — यह मानक और सार्वभौमिक बात है, और इसके होने से पहले ही इसके बारे में जान लेना बेहतर है, बीच में नहीं।

**एक पंक्ति में:** आपका होस्ट अपने नेटवर्क की रक्षा करता है, और इसका फ़ायदा आपको मिलता है। यह आपके एप्लिकेशन की रक्षा नहीं करता, और इसका कोई तरीक़ा भी नहीं है। लेयर 7 कोई अपसेल नहीं है जो आपसे रोक ली गई हो — यह एक ऐसी लेयर है जिसके अंदर आपका प्रोवाइडर बिना आपका TLS टर्मिनेट किए झाँक ही नहीं सकता, और यह किसी के लिए भी जो ऑफ़शोर होस्ट कर रहा हो, अपनी ही गंभीर क़ीमत वाला एक सौदा है।

## पहले तय करें कि यह हमला है भी या नहीं

DDoS का शक होने वाली घटनाओं में एक बड़ा हिस्सा असल में कुछ और होता है, बस उसका कोट पहने हुए, और इनके इलाज एक-दूसरे की जगह काम नहीं करते। कुछ भी रेट-लिमिट करने से पहले, नक़ली मामलों को ख़ारिज करने में दो मिनट लगाएँ — यहाँ ग़लत पहचान आपको एक घंटा, और कभी-कभी आपके असली यूज़र, ख़र्च करवा देती है।

- **आप मशहूर हो गए।** किसी बड़े एग्रीगेटर पर एक लिंक बिल्कुल एक L7 फ्लड जैसा दिखने वाला ट्रैफ़िक शेप पैदा करता है, बस फ़र्क़ इतना है कि रेफ़रर असली होते हैं और रिक्वेस्ट उन पेजों के लिए होते हैं जिन्हें कोई इंसान देखना चाहेगा। यह एक ख़ुशनुमा वजह वाली क्षमता समस्या है; इसे रेट-लिमिट करना ख़ुद को नुक़सान पहुँचाना है।

- **किसी क्रॉलर के तौर-तरीक़े बिगड़ गए।** आक्रामक स्क्रैपर और AI ट्रेनिंग बॉट किसी छोटे सर्वर को आसानी से पछाड़ सकते हैं। यूज़र-एजेंट आमतौर पर ख़ुद बता देता है, और इलाज है robots.txt प्लस एक लक्षित लिमिट, न कि एक सामान्य लिमिट।

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

- **आपकी अपनी मॉनिटरिंग ही फ्लड है।** दुर्लभ, शर्मनाक, और जितना कोई मानता है उससे कहीं ज़्यादा आम। बिना बैकऑफ़ के दोबारा कोशिश करने वाला एक हेल्थ-चेक लूप सच में एक प्रभावशाली रिक्वेस्ट रेट पैदा कर सकता है।

फ़र्क़ करने वाला सवाल आसान है: *क्या ट्रैफ़िक को कुछ चाहिए?* असली लोड — यहाँ तक कि दुश्मनी जैसे दिखने वाले असली लोड को भी — एक शेप होती है। यह उन पेजों पर जाता है जो मौजूद हैं, लिंक फ़ॉलो करता है, ऐसेट लोड करता है, और नेटवर्क के एक विश्वसनीय फैलाव से आता है। हमला आमतौर पर इतनी परवाह नहीं करता।

## सर्वर से ख़ुद हमले को पढ़ना

क्या हो रहा है यह पहचानने के लिए आपको किसी डैशबोर्ड की ज़रूरत नहीं। सही क्रम में चलाए गए चार कमांड आपको एक मिनट से भी कम में बता देंगे कि आप किस लेयर में लड़ रहे हैं — और यह जानना ही तय करता है कि आगे आप क्या करेंगे।

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

- vnstat -tr 10 — दस सेकंड में औसत थ्रूपुट, सैचुरेशन का सबसे तेज़ ईमानदार आँकड़ा।

- cat /proc/net/dev को एक सेकंड के फ़ासले पर दो बार — हर इंटरफ़ेस के पैकेट और बाइट का अंतर, बिना किसी टूल के।

**क्या यह SYN फ्लड है?** हाफ़-ओपन कनेक्शन SYN-RECV में जमा होते जाते हैं। मुट्ठी भर सामान्य है; हज़ारों नहीं:

- ss -s — सारांश पंक्ति, एक नज़र में स्टेट के हिसाब से कनेक्शन गिनती।

- ss -tn state syn-recv | wc -l — वह ख़ास संख्या जो मायने रखती है।

**क्या यह लेयर 7 है?** अगर बैंडविड्थ सामान्य है पर सब कुछ धीमा है, तो अपने एक्सेस लॉग में हर क्लाइंट के रिक्वेस्ट गिनें। दसियों हज़ार हिट वाला एक अकेला पता एक शौक़िया है; तीन-तीन हिट वाले एक लाख पते असली माल हैं:

- tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

- इसके बजाय माँगे गए पाथ को रैंक करने के लिए $1 की जगह $7 रखें। अगर एक महँगा एंडपॉइंट हावी है, तो आपको निशाना भी मिल गया और आधा इलाज भी।

**असल में ख़त्म क्या हुआ है?** लोड एवरेज अकेले बहुत कम बताता है। उस ख़ास सीमा को खोजें जो आपने छू ली है: PHP-FPM के सारे चाइल्ड व्यस्त, डेटाबेस कनेक्शन अपनी सीमा पर, फ़ाइल डिस्क्रिप्टर ख़त्म, या डिस्क का इंतज़ार करते D स्टेट में फँसे वर्कर। वह सीमा — ट्रैफ़िक नहीं — है जिसने साइट को गिराया, और अक्सर इसे बढ़ाना किसी भी चीज़ को फ़िल्टर करने से तेज़ होता है।

**देखते वक़्त यह ध्यान रखें:** अगर आप प्राइवेसी-केंद्रित सेवा चलाते हैं, तो हमला ठीक वही पल है जब लॉगिंग बढ़ाकर वैसी ही छोड़ देने का सबसे ज़्यादा मन करता है। अगर ज़रूरी हो तो बढ़ाएँ, फिर बाद में इसे वापस घटाएँ और फ़ाइलों को आक्रामक तरीक़े से रोटेट करें। ऐसी घटना जो पूरे महीने के पूरी-तफ़सील वाले विज़िटर लॉग डिस्क पर छोड़ जाए, एक समस्या को उससे बदतर और लंबे समय तक टिकने वाली दूसरी समस्या से बदल देती है। हमारी [Server OpSec गाइड](https://servghost.com/hi/guides/server-opsec-staying-anonymous) इस अनुशासन को कवर करती है।

## पहले दस मिनट

दबाव में, लोग सबसे बड़ा उपलब्ध लीवर पकड़ लेते हैं, और सबसे बड़ा लीवर आमतौर पर ग़लत होता है। यह वह क्रम है जो नुक़सान सीमित करता है, मोटे तौर पर सबसे तेज़-और-सबसे-सुरक्षित पहले:

- **कार्रवाई से पहले पहचानें।** भरा हुआ इंटरफ़ेस माने वॉल्यूमेट्रिक; व्यस्त वर्कर वाला शांत इंटरफ़ेस माने लेयर 7। यहाँ ख़र्च किए तीस सेकंड आपको एक घंटे तक ग़लत लेयर ठीक करने से बचा लेते हैं।

- **अगर यह वॉल्यूमेट्रिक है, तो फ़ौरन एक टिकट खोलें** और उसमें डेस्टिनेशन पता, शुरू होने का समय, और अपने इंटरफ़ेस काउंटर शामिल करें। फिर सर्वर में टाइप करना बंद कर दें — आप इसे अंदर से ठीक नहीं कर सकते।

- **अगर यह लेयर 7 है, तो पहले कैश करें।** अनाम विज़िटर के लिए आक्रामक फ़ुल-पेज कैशिंग चालू करना, किसी आउटेज को महज़ एक कंधा उचकाने में बदलने का अकेला सबसे तेज़ तरीक़ा है, और यह अकेला उपाय है जो असली ट्रैफ़िक के ख़िलाफ़ भी मदद करता है।

- **फिर रेट-लिमिट करें** — पहले निशाना बना एंडपॉइंट, बाक़ी सब बाद में। शुरुआत सतर्क रखें। ऐसी लिमिट जो आपके अपने यूज़र को बाहर कर दे, हमले की ख़ुद-लगाई गई अगली कड़ी है।

- **सिर्फ़ वही ब्लॉक करें जो बिल्कुल साफ़ हो।** एक दर्जन पते जिनमें से हर एक पर एक लाख रिक्वेस्ट, कोई साफ़ नक़ली यूज़र-एजेंट, कोई एक देश जहाँ आपका कोई यूज़र नहीं। हमले के बीच पेचीदा नियम लिखने की इच्छा पर काबू रखें; अगले महीने आपको वे याद ही नहीं रहेंगे।

- **अगर ज़रूरी हो तो जान-बूझकर लोड कम करें।** बिना लॉग-इन वाले विज़िटर को एक स्टैटिक "अंडर मेंटेनेंस" पेज परोसना बॉक्स को ज़िंदा रखता है, आपका API चालू रखता है, और सोचने का वक़्त ख़रीदता है। क्या क़ुर्बान करना है यह ख़ुद तय करना, इससे बेहतर है कि यह आपके लिए तय हो जाए।

- **जो किया उसे लिख लें।** हर अस्थायी नियम जो आपने जोड़ा, आने वाले कल के आपके लिए एक बारूदी सुरंग है। जिन नियमों ने मदद की वे स्थायी बन जाते हैं; बाक़ी कल हटा दिए जाते हैं।

## टिकने वाली रेट लिमिट, और वह ग़लती जो हर कोई करता है

रेट लिमिटिंग लेयर 7 के लिए मुख्य औज़ार है, और nginx इसे दो डायरेक्टिव के साथ बख़ूबी करता है जो दो सच में अलग-अलग समस्याएँ हल करते हैं। limit_req रिक्वेस्ट की *रेट* सीमित करता है — यानी एक क्लाइंट कितनी बार पूछ सकता है। limit_conn *समवर्ती कनेक्शन* सीमित करता है — यानी एक क्लाइंट एक साथ कितने कनेक्शन खुले रख सकता है। फ्लड को पहले वाले की ज़रूरत होती है; slow-loris हमलों को, जो आपके वर्कर पूल को थकाने के लिए हज़ारों लगभग-निष्क्रिय कनेक्शन थामे रहते हैं, दूसरे वाले की। सिर्फ़ एक तैनात करें और आप आधी समस्या के ख़िलाफ़ ही सुरक्षित हैं।

तीन बारीकियाँ एक काम करने वाली लिमिट को एक दिखावटी लिमिट से अलग करती हैं:

- **बर्स्ट इस्तेमाल करें, और nodelay इस्तेमाल करें।** असली ब्राउज़र बर्स्ट में चलते हैं — एक अकेला पेज व्यू एक दर्जन लगभग-एक-साथ ऐसेट रिक्वेस्ट दाग़ता है। बिना गुंजाइश वाली लिमिट असली विज़िटर को रोक देती है जबकि थ्रेशोल्ड से बस नीचे अपनी रफ़्तार रखने वाला हमलावर आराम से निकल जाता है।

- **महँगे एंडपॉइंट को अलग से सीमित करें।** आपका सर्च पेज, लॉगिन फ़ॉर्म, पासवर्ड रीसेट और डेटाबेस में लिखने वाला कोई भी एंडपॉइंट, आपके स्टैटिक ऐसेट से कहीं ज़्यादा तंग बजट का हक़दार है। हमलावर इन्हें बिना कोशिश किए ढूँढ लेते हैं, क्योंकि यही वे हैं जो चोट पहुँचाते हैं।

- **429 लौटाएँ, 503 नहीं।** यह स्टेटस कोड सही-व्यवहार वाले क्लाइंट और सर्च इंजन को यह संकेत देता है कि यह थ्रॉटलिंग है, नाकामी नहीं — और यह एक बुरी दोपहर को रैंकिंग समस्या बनने से रोकता है।

**वह ग़लती जो चुपचाप यह सब बेकार कर देती है:** अगर आपके सर्वर के आगे कुछ भी बैठा है — एक CDN, एक लोड बैलेंसर, आपकी अपनी रिवर्स प्रॉक्सी — तो हर रिक्वेस्ट *उसके* पते से आता है, विज़िटर के पते से नहीं। तब एक प्रति-क्लाइंट रेट लिमिट पूरे इंटरनेट को एक क्लाइंट मानकर गिनती करती है, और यह या तो बिल्कुल कुछ नहीं करेगी या आपकी पूरी ऑडियंस को एक साथ बैन कर देगी। आपको अपना रियल-IP सोर्स कॉन्फ़िगर करना ही होगा (nginx में, प्रॉक्सी की रेंज के लिए set_real_ip_from प्लस वह हेडर जो प्रॉक्सी भेजता है उसके लिए real_ip_header) — और यह लिमिट के कोई मतलब रखने से *पहले* करना होगा। इसे भी प्रॉक्सी की अपनी रेंज तक सीमित रखें: खुले इंटरनेट से आया क्लाइंट-दिया हेडर भरोसा करने पर एक हमलावर हर रिक्वेस्ट पर एक नई पहचान गढ़ सकता है और आपकी हर लिमिट से सीधा निकल सकता है।

## कैशिंग सबसे सस्ती मिटिगेशन है जो आप कभी तैनात करेंगे

एक रेट लिमिट काम को नकारती है। एक कैश काम को मौजूद ही नहीं रहने देता। अनाम विज़िटर को दिखने वाली किसी भी चीज़ के लिए, फ़ुल-पेज कैशिंग पूरे हमले का हिसाब-किताब बदल देती है: जो रिक्वेस्ट पहले एक डेटाबेस राउंड-ट्रिप, एक टेम्पलेट रेंडर और एक PHP वर्कर की क़ीमत लेता था, वह अब माइक्रोसेकंड में मापी जाने वाली एक फ़ाइल रीड बन जाता है। जो सर्वर चार सौ डायनेमिक रिक्वेस्ट प्रति सेकंड पर ढह गया था, वही अब दसियों हज़ार कैश्ड रिक्वेस्ट बिना अटके परोस देगा।

जब आप इसे ग़ुस्से में चालू करते हैं तो ये बातें मायने रखती हैं:

- **सिर्फ़ अनाम विज़िटर के लिए कैश करें।** सेशन कुकी पर बायपास रखें। एक लॉग-इन यूज़र का पेज किसी दूसरे को परोस देना, जिस आउटेज को आप ठीक कर रहे थे उससे कहीं बुरी घटना है।

- **जान-बूझकर बासी कंटेंट परोसें।** nginx का proxy_cache_use_stale, updating error timeout के साथ, इसका मतलब है कि जब आपका बैकएंड जूझ रहा हो, तो विज़िटर को एरर की बजाय थोड़ा पुराना पेज मिलता है। हमले के दौरान यही फ़र्क़ है एक ठीक-ठाक दिखती साइट और एक मरी हुई दिखती साइट के बीच।

- **दोहरे मिस को इकट्ठा करें।** proxy_cache_lock यह पक्का करता है कि एक ही अनकैश्ड पेज के लिए हज़ार एक साथ आए रिक्वेस्ट, हज़ार नहीं बल्कि एक बैकएंड रिक्वेस्ट पैदा करें। इसके बिना, एक कैश-बस्टिंग हमला कैश से सीधा गुज़रकर पूरी ताक़त से आपके डेटाबेस पर जा गिरता है।

- **कैश-बस्टिंग क्वेरी स्ट्रिंग को बेअसर करें।** आम तरकीब है ? और एक रैंडम वैल्यू जोड़ना ताकि हर रिक्वेस्ट एक यूनीक की बन जाए और हमेशा मिस हो। अपनी कैश की को नॉर्मलाइज़ करें ताकि वे क्वेरी पैरामीटर नज़रअंदाज़ हों जिन्हें आपका एप्लिकेशन असल में इस्तेमाल ही नहीं करता।

यहाँ एक सुखद असमानता है जिसे समझ लेना अच्छा है: कैशिंग पर लगाया हर घंटा, साइट को उसके सबसे अच्छे दिन भी तेज़, चलाने में सस्ता, और कामयाबी झेलने में बेहतर बना देता है। मुश्किल से कोई और सुरक्षा-पंक्ति ऐसी है जो तब भी मुनाफ़ा दे जब सब कुछ ठीक-ठाक चल रहा हो।

## वे सीमाएँ जो तय करती हैं कि आप गिरेंगे या नहीं

ज़्यादातर सर्वर इसलिए नहीं मरते कि उनका CPU ख़त्म हो गया। वे इसलिए मरते हैं क्योंकि वे एक अदृश्य सीमा से टकरा जाते हैं जिसे किसी ने जान-बूझकर सेट नहीं किया था — एक दशक पुराना डिफ़ॉल्ट जो उस हार्डवेयर पर मायने रखता था जिसे अब कोई इस्तेमाल नहीं करता। हमले के दौरान, असल में सबसे पहले यही टूटते हैं:

- **एप्लिकेशन वर्कर।** PHP-FPM का pm.max_children, आपकी Python वर्कर गिनती, आपके Node क्लस्टर का साइज़। यही आपकी साइट की असली कंकरन्सी सीमा है। जब ये सब व्यस्त हों, तो हर अतिरिक्त विज़िटर क्यू में लग जाता है, और साइट डाउन रहती है चाहे CPU कितना भी ख़ाली क्यों न दिखे। इसे सिर्फ़ उतना ही बढ़ाएँ जितनी मेमोरी इजाज़त दे — स्वैपिंग, क्यूइंग से बदतर है।

- **एक्सेप्ट क्यू।** net.core.somaxconn और आपका लिसन बैकलॉग तय करते हैं कि कितने कनेक्शन स्वीकार होने का इंतज़ार कर सकते हैं। एक छोटा बैकलॉग एक झेली जा सकने वाली बर्स्ट को ठुकराए गए कनेक्शन में बदल देता है।

- **SYN कुकीज़।** net.ipv4.tcp_syncookies कर्नेल को उन कनेक्शन के लिए स्टेट बनाए बिना एक SYN फ्लड का जवाब देने देता है जो कभी पूरे होने वाले ही नहीं। आधुनिक कर्नेल इसे डिफ़ॉल्ट रूप से चालू रखते हैं; मान लेने की बजाय जाँच लें, क्योंकि इसकी कोई क़ीमत नहीं है और यह आपको सबसे आम फ्लड से बचाता है जो मौजूद है।

- **फ़ाइल डिस्क्रिप्टर।** हर कनेक्शन एक डिस्क्रिप्टर है। डिफ़ॉल्ट nofile लिमिट अक्सर उन कनेक्शन की संख्या से कम होती है जिन्हें आप परोसने की कोशिश कर रहे हैं, और नाकामी का तरीक़ा — जब सब कुछ सेहतमंद दिखते हुए भी accept फेल हो रहा हो — रात तीन बजे सच में उलझन भरा होता है।

- **डेटाबेस कनेक्शन।** कनेक्शन पूल बढ़ाए बिना वर्कर गिनती बढ़ाना क्यू को बस किसी ऐसी जगह खिसका देता है जहाँ देखना मुश्किल हो। इन दोनों संख्याओं को साथ में एडजस्ट करना ज़रूरी है।

इन्हें किसी शांत दिन पर ट्यून करें, किसी घटना के दौरान नहीं। इन्हें जानने का मतलब यह है कि जब साइट गिरे, तो आप अंदाज़ा लगाने की बजाय उस सीमा का नाम ले सकें जिससे वह टकराई — और नाम ली गई सीमा ही ठीक की जा सकने वाली सीमा है।

## ओरिजिन के आगे कुछ रखना

ऊपर बताई गई हर चीज़ सर्वर पर होती है। अगला क़दम यह तय करना है कि क्या सर्वर को सीधे ट्रैफ़िक पाने वाली चीज़ होना भी चाहिए। तीन ईमानदार विकल्प हैं, और सही जवाब इस बात पर आप जो अफ़ोर्ड कर सकते हैं उससे कहीं ज़्यादा इस बात पर निर्भर करता है कि आप होस्ट क्या कर रहे हैं।

| तरीक़ा | आपको क्या मिलता है | आपको क्या क़ीमत चुकानी पड़ती है |
| --- | --- | --- |
| ओरिजिन सीधे एक्सपोज़्ड, हार्डन किया हुआ | सादगी, कोई थर्ड पार्टी नहीं, कोई ऐसा TLS टर्मिनेशन नहीं जो आपके नियंत्रण में न हो | आपका पता पब्लिक और स्थायी है। लेयर 7 पूरी तरह आपकी ज़िम्मेदारी है |
| कमर्शियल CDN या स्क्रबिंग सेवा | बेहद बड़ी सोखने की क्षमता, एक क्लिक में एक चैलेंज पेज, ग्लोबल कैशिंग | आपके कंटेंट पर राय रखने वाला एक एब्यूज़ डेस्क, और एक कंपनी जो आपका ट्रैफ़िक देख सकती है। ऑफ़शोर या DMCA-संवेदनशील प्रोजेक्ट के लिए यह अक्सर एक वरना सतर्क सेटअप की सबसे कमज़ोर कड़ी बन सकता है |
| आपका अपना फ़्रंट नोड — nginx चलाने वाला एक छोटा VPS, जो एक फ़ायरवॉल में बंद ओरिजिन तक प्रॉक्सी करता है | पूरा नियंत्रण, रिक्वेस्ट के रास्ते में कोई थर्ड पार्टी नहीं, एक ऐसा पता जिसे आप जला और बदल सकते हैं, और एक असली पता जो छुपा रहता है | उसकी अपनी क्षमता सीमाएँ, और चलाने के लिए एक और मशीन। अलग-अलग नेटवर्क में दो-तीन फ़्रंट इसे गिराना काफ़ी मुश्किल बना देते हैं |

सेल्फ़-होस्टेड फ़्रंट नोड को आमतौर पर मिलने से ज़्यादा ध्यान मिलना चाहिए, ख़ासकर उन लोगों के लिए जिन्होंने ऐसी वजहों से ऑफ़शोर होस्टिंग चुनी जिनसे कोई बड़ा CDN शायद हमदर्दी न रखे। तरीक़ा बिना किसी चमक-दमक का है: आगे सस्ते प्रॉक्सी नोड, ओरिजिन एक फ़ायरवॉल में बंद कि सिर्फ़ उन्हीं नोड से कनेक्शन स्वीकार करे, DNS फ़्रंट की ओर इशारा करता हुआ। अगर किसी फ़्रंट पर हमला हो, तो आप उसे मिनटों में एक नए पते से बदल देते हैं और ओरिजिन को पता भी नहीं चलता। इस आर्किटेक्चर का पूरा वर्शन — साथ में वे छह तरीक़े जिनसे एक ओरिजिन पता फिर भी लीक हो जाता है — हमारी गाइड [ओरिजिन सर्वर IP छुपाना](https://servghost.com/hi/guides/hiding-your-origin-server-ip) का विषय है।

## छुपा हुआ ओरिजिन किसी भी फ़िल्टर से ज़्यादा क़ीमती है

यह साफ़-साफ़ कह देना ज़रूरी है, क्योंकि यह सामान्य प्राथमिकता को उलट देता है: आपको उपलब्ध सबसे सस्ती DDoS मिटिगेशन एक ऐसा पता है जो हमलावर के पास नहीं है। फ़िल्टरिंग वह है जो आप तब करते हैं जब यह पहले ही नाकाम हो चुका हो।

यह सुनने से कहीं ज़्यादा मायने रखता है, क्योंकि ओरिजिन पते लगातार और चुपचाप लीक होते हैं। प्रॉक्सी लगाने से पहले के पुराने DNS रिकॉर्ड, बदलाव के बरसों बाद तक बने रहते हैं। एप्लिकेशन से सीधे भेजी मेल अपने हेडर में पता ले जाती है। कच्चे पते पर जारी किया गया एक TLS सर्टिफ़िकेट सर्टिफ़िकेट ट्रांसपेरेंसी लॉग में स्थायी रूप से छप जाता है। एक एरर पेज, एक रीडायरेक्ट, या कोई गुमनाम सबडोमेन जिसे कभी प्रॉक्सी नहीं किया गया, सब इसे उजागर कर देते हैं। अगर आपने किसी ऐसे सर्वर के आगे CDN लगाया है जो पहले एक्सपोज़्ड था, तो मान लें कि पुराना पता तब तक जाना-पहचाना है जब तक आपने उसे बदल न दिया हो।

**इसका नतीजा एक फ़ायरवॉल नियम है, और यह इस गाइड की सबसे क़ीमती अकेली पंक्ति है:** एक बार जब कुछ आगे बैठ जाए, तो ओरिजिन को 80 और 443 पर उस फ़्रंट के पतों को छोड़कर बाक़ी सब से कनेक्शन ठुकरा देने चाहिए। इसके बिना, प्रॉक्सी बस एक सुझाव है — जो कोई भी असली पता जान लेता है, वह बस उसके इर्द-गिर्द से निकलकर आप पर सीधा हमला कर देता है, और आपने फ़्रंट पर जो कुछ भी कॉन्फ़िगर किया वह सिर्फ़ दिखावा बनकर रह जाता है।

## हार्डवेयर और लोकेशन ऐसे चुनना कि हमले उबाऊ बने रहें

इसमें से कुछ हिस्सा हमला होने से पहले ही तय हो जाता है, ठीक उस पल जब आप कोई प्लान चुनते हैं। तीन ख़ासियतें स्पेसिफ़िकेशन शीट के अंदाज़े से कहीं ज़्यादा मायने रखती हैं:

- **अनमीटर्ड बैंडविड्थ।** मीटर्ड प्लान पर, हमला सिर्फ़ एक आउटेज नहीं होता — यह एक इनवॉइस भी होता है। जो ट्रैफ़िक आपने कभी माँगा नहीं और ठुकरा भी नहीं सकते थे, वह भी आपके अलाउंस में गिना जाता है। अनमीटर्ड ट्रांसफ़र एक वित्तीय जोखिम को महज़ एक तकनीकी जोखिम में बदल देता है, जो एक कहीं बेहतर क़िस्म की समस्या है।

- **क्या पोर्ट सिर्फ़ आपका है।** किसी साझा वर्चुअलाइज़्ड होस्ट पर, हमले की चपेट में आया कोई पड़ोसी आपको भी नुक़सान पहुँचा सकता है, और आपकी अपनी प्रोटेक्शन सीमा भी साझा होती है। अपने पोर्ट वाला [डेडिकेटेड हार्डवेयर](https://servghost.com/hi/dedicated) दोनों असर हटा देता है। ऐसे प्रोजेक्ट के लिए जिसे दुश्मनी भरा ध्यान मिलने की उम्मीद हो, यही [VPS](https://servghost.com/hi/vps) से ऊपर जाने की सबसे साफ़ वजह है — कोर या RAM से भी ज़्यादा।

- **नेटवर्क कहाँ बैठा है।** असली ट्रांज़िट क्षमता वाला एक अच्छी तरह जुड़ा यूरोपीय नेटवर्क वह फ्लड सोख लेता है जो एक ख़राब-पीयर्ड नेटवर्क नहीं सोख पाएगा, और जो क्षेत्राधिकार आपने क़ानूनी वजहों से चुना, उसकी नेटवर्क ख़ासियतें भी होती हैं। उपलब्ध [लोकेशन](https://servghost.com/hi/locations) में से चुनते वक़्त दोनों जाँच लेना बेहतर है।

यहाँ एक स्केल वाली दलील भी है जो चुपचाप सादगी के पक्ष में जाती है। किसी मामूली सर्वर पर कैश के पीछे बैठी एक स्टैटिक साइट को गिराना असाधारण रूप से मुश्किल है; वही कंटेंट अगर एक भारी-भरकम CMS पर एक अनकैश्ड सर्च एंडपॉइंट के साथ हो, तो एक स्क्रिप्ट लिए एक ज़िद्दी इंसान उसे तोड़ सकता है। जो डायनेमिक है उसे घटाना भी एक मिटिगेशन है, और यह मुफ़्त है। अगर आपका प्रोजेक्ट सच में लगातार लोड के तहत जीता है, तो हमारी [हाई-ट्रैफ़िक होस्टिंग](https://servghost.com/hi/use-cases/high-traffic-hosting) नोट्स इसी सवाल के साइज़िंग वाले पहलू को कवर करते हैं।

## पाँच चीज़ें जो नहीं करनी चाहिए

यहाँ नाकामी के तरीक़े इतने एक-जैसे हैं कि उन्हें सूचीबद्ध किया जा सके, और हर एक ने किसी न किसी का पूरा वीकेंड ख़र्च करवाया है:

- **ख़ुद को नल-रूट मत करें।** अपने ही पते को ब्लैकहोल करना हमले को सबसे शाब्दिक तरीक़े से ख़त्म करता है — आपके यूज़र समेत कोई भी आप तक नहीं पहुँच पाता। यह आपके प्रोवाइडर के लिए आख़िरी उपाय वाला औज़ार है, कोई ऐसा क़दम नहीं जो आप ख़ुद अपनी मर्ज़ी से उठाएँ।

- **fail2ban को DDoS प्रोटेक्शन मत मानें।** यह कुछ पतों से आने वाली ब्रूट-फ़ोर्स कोशिशों के ख़िलाफ़ एक बढ़िया औज़ार है। एक डिस्ट्रिब्यूटेड फ्लड के ख़िलाफ़ यह सेकंडों में आने वाली किसी चीज़ पर मिनटों में प्रतिक्रिया देता है, और हज़ारों पतों को बैन करने वाला एक नियम, फ़ायरवॉल प्रोसेसिंग में हमले से भी ज़्यादा क़ीमत ले सकता है।

- **फ़िरौती मत दें।** तबाही मचाने वाले हमले की धमकी देने वाले जबरन-वसूली ईमेल की बहुत बड़ी बहुसंख्या ऐसे लोगों से आती है जिनके पास कोई क्षमता नहीं होती और जो हज़ारों एक-जैसे मैसेज भेजते हैं। जो छोटी-सी अल्पसंख्या सच में कर गुज़र सकती है, वह वापस आएगी, क्योंकि आपने साबित कर दिया कि आप भुगतान करते हैं।

- **जवाबी हमला मत करें।** लगभग हर जगह यह ग़ैर-क़ानूनी होने के अलावा, स्रोत ख़ुद समझौता किए गए थर्ड पार्टी होते हैं। आप पीड़ितों पर हमला कर रहे होंगे, और वह भी एक ऐसे पते से जो बेशक़ आपका ही है।

- **घबराकर माइग्रेट मत करें।** हमले के बीच होस्ट बदलने का मतलब है कि नया पता मिनटों में पब्लिक हो जाता है और आपके पास कोई काम करता कॉन्फ़िगरेशन नहीं होता। पहले स्थिर हों, बाद में सोच-समझकर आगे बढ़ें — और अगर आप बदलते ही हैं, तो [बिना डाउनटाइम माइग्रेट करने](https://servghost.com/hi/guides/migrate-website-to-offshore-hosting) पर हमारी गाइड ठीक इसीलिए मौजूद है ताकि यह बदलाव ख़ुद एक दूसरी घटना न बन जाए।

## संक्षिप्त वर्शन

तर्क को हटाकर, काम करने वाला मॉडल आठ पंक्तियों में समा जाता है:

- **पहले पहचानें।** भरा हुआ इंटरफ़ेस माने वॉल्यूमेट्रिक, और यह आपके होस्ट का काम है। थके हुए वर्कर वाला शांत इंटरफ़ेस माने लेयर 7, और यह आपका काम है।

- **वॉल्यूमेट्रिक के लिए, पता, टाइमस्टैंप और अपने काउंटर के साथ एक टिकट फ़ाइल करें** — फिर सर्वर को छूना बंद कर दें।

- **अनाम विज़िटर के लिए आक्रामक तरीक़े से कैश करें,** दबाव में बासी कंटेंट परोसें, और दोहरे मिस इकट्ठा करें। यह वह बदलाव है जिसका सबसे ज़्यादा असर होता है।

- **रिक्वेस्ट रेट और समवर्ती कनेक्शन, दोनों से रेट-लिमिट करें,** सबसे महँगे एंडपॉइंट पर सबसे तंग, और 429 लौटाएँ।

- **बाक़ी सब कुछ करने से पहले अपना रियल-IP कॉन्फ़िगरेशन ठीक करें,** वरना प्रॉक्सी के पीछे हर प्रति-क्लाइंट लिमिट या तो बेकार होगी या तबाही मचाने वाली।

- **अपनी सीमाएँ जानें** — वर्कर, बैकलॉग, डिस्क्रिप्टर, डेटाबेस कनेक्शन — और किसी शांत दिन जान-बूझकर इन्हें बढ़ाएँ।

- **ओरिजिन पता गुप्त रखें और उसे अपने फ़्रंट नोड तक फ़ायरवॉल में बंद रखें।** यह हर फ़िल्टर को मिलाकर भी उससे ज़्यादा क़ीमती है।

- **अनमीटर्ड बैंडविड्थ ख़रीदें** ताकि जो ट्रैफ़िक आपने माँगा ही नहीं वह कभी बिल भी न बने।

इनमें से कुछ भी आपको अभेद्य नहीं बनाता, और जो कोई भी अभेद्यता बेच रहा हो वह कुछ और ही बेच रहा है। यह जो करता है वह यह है कि आपको उस आबादी से बाहर निकाल देता है जिसे कोई ऊबा हुआ किशोर भी ऑफ़लाइन कर देता है, और उस आबादी में डाल देता है जिसे परेशान करने के लिए असली संसाधन और असली इरादे की ज़रूरत होती है — जो, ज़्यादातर प्रोजेक्ट के लिए, सुरक्षित होने से अलग पहचाना ही नहीं जा सकता। बाक़ी वही बिना चमक-दमक वाला काम है जो एक सर्वर को हर और चीज़ में भी अच्छा बनाता है: [पहले ही दिन हार्डन किया हुआ](https://servghost.com/hi/guides/first-hour-vps-hardening-checklist), [सबसे बुरे दिन रीस्टोर किया जा सकने वाला](https://servghost.com/hi/guides/vps-backup-strategy), और कहीं ऐसी जगह चलता हुआ जो आपके ट्रैफ़िक को आपका अपना कारोबार मानकर बरते।





FAQ

## छोटे सर्वर पर DDoS — आम सवाल





### 01
"DDoS प्रोटेक्शन शामिल है" का मतलब क्या मैं हर चीज़ से सुरक्षित हूँ?



नहीं, और यह कमी धुँधली नहीं बल्कि सटीक है। शामिल प्रोटेक्शन नेटवर्क-लेयर फ़िल्टरिंग है: यह वॉल्यूमेट्रिक फ्लड — SYN फ्लड, UDP एम्प्लिफ़िकेशन, कच्चे पैकेट तूफ़ान — को आपके पोर्ट तक पहुँचने से पहले, अपस्ट्रीम ही गिरा देती है। यही वह श्रेणी है जिसे आप सच में अकेले नहीं संभाल सकते, इसलिए इसे शामिल करना सही बात है। यह आपके एप्लिकेशन की जाँच नहीं करती, इसलिए किसी महँगे एंडपॉइंट के ख़िलाफ़ कुछ हज़ार रिक्वेस्ट प्रति सेकंड का एक HTTP फ्लड इससे बिना छुए गुज़र जाता है और हर नेटवर्क ग्राफ़ सामान्य दिखते हुए भी आपकी साइट गिरा देता है। लेयर 7 वह कॉन्फ़िगरेशन है जिसके मालिक आप ख़ुद हैं: कैशिंग, रेट लिमिट और कनेक्शन सीमाएँ।





### 02
मैं DDoS हमले और ट्रैफ़िक स्पाइक में फ़र्क़ कैसे करूँ?



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





### 03
हमले के दौरान मैं सबसे असरदार अकेला काम क्या कर सकता हूँ?



अनाम विज़िटर के लिए फ़ुल-पेज कैशिंग चालू करें, और इसे इस तरह कॉन्फ़िगर करें कि जब बैकएंड जूझ रहा हो तो यह बासी कंटेंट परोसे। एक रेट लिमिट काम को नकारती है; एक कैश काम को मौजूद ही नहीं रहने देता। जो रिक्वेस्ट पहले एक डेटाबेस क्वेरी, एक टेम्पलेट रेंडर और एक एप्लिकेशन वर्कर की क़ीमत लेता था, वह एक फ़ाइल रीड बन जाता है, और जो हार्डवेयर कुछ सौ डायनेमिक रिक्वेस्ट प्रति सेकंड पर ढह गया था, वही दसियों हज़ार कैश्ड रिक्वेस्ट परोस देगा। यह सूची का अकेला ऐसा उपाय भी है जो असली ट्रैफ़िक के ख़िलाफ़ भी वैसी ही मदद करता है, इसलिए रेट लिमिट के उलट, यह आपके अपने यूज़र पर उल्टा असर नहीं करता।





### 04
CDN लगाने के बाद मेरी nginx रेट लिमिट ने काम करना क्यों बंद कर दिया?



क्योंकि अब हर रिक्वेस्ट विज़िटर के पते की बजाय CDN के पते से आता है, इसलिए एक प्रति-क्लाइंट लिमिट पूरे इंटरनेट को एक ही क्लाइंट मानकर गिन रही है। थ्रेशोल्ड के हिसाब से, यह या तो कभी ट्रिगर ही नहीं होगी या आपके पूरे ट्रैफ़िक को एक साथ बैन कर देगी। अपना रियल-IP सोर्स कॉन्फ़िगर करें — nginx में, भरोसेमंद प्रॉक्सी रेंज प्लस वह हेडर जो प्रॉक्सी भेजता है — ताकि लिमिट फिर से असली विज़िटर पर आधारित हो। उस भरोसे को प्रॉक्सी की अपनी रेंज तक सीमित रखें: अगर आप खुले इंटरनेट से आया क्लाइंट-दिया हेडर स्वीकार करते हैं, तो एक हमलावर हर रिक्वेस्ट पर एक नई पहचान गढ़ सकता है और आपकी हर लिमिट से निकल सकता है।





### 05
क्या DDoS हमला रोकने के लिए fail2ban काफ़ी है?



नहीं। fail2ban एक अंतराल पर लॉग पढ़ता है और थ्रेशोल्ड पार करने पर दोषी पतों को बैन करता है, जो कुछ गिने-चुने स्रोतों से आई ब्रूट-फ़ोर्स कोशिशों के लिए ठीक है। एक डिस्ट्रिब्यूटेड हमला हज़ारों पतों से सेकंडों में आता है, जिनमें से हर एक बस मुट्ठी भर रिक्वेस्ट भेजता है, इसलिए थ्रेशोल्ड कभी पार ही नहीं होता, और वैसे भी प्रतिक्रिया का समय बहुत धीमा है। इससे भी बुरा यह कि दसियों हज़ार एंट्री तक बढ़ चुका एक रूलसेट, हमले से भी ज़्यादा संसाधन खा सकता है। इसे SSH और लॉगिन एंडपॉइंट के लिए रखें, और फ्लड को कैशिंग, रेट लिमिटिंग और एक अपस्ट्रीम फ़िल्टर से संभालें।





### 06
क्या मुझे CDN इस्तेमाल करना चाहिए, या आगे अपनी ख़ुद की रिवर्स प्रॉक्सी चलानी चाहिए?



यह आपके बजट से ज़्यादा इस पर निर्भर करता है कि आप होस्ट क्या कर रहे हैं। एक कमर्शियल CDN वह सोखने की क्षमता लाता है जिसकी आप बराबरी नहीं कर सकते, और एक क्लिक दूर एक चैलेंज पेज भी, पर साथ में आपको उसका एब्यूज़ डेस्क भी विरासत में मिलता है और वह आपका ट्रैफ़िक देख सकता है — जो ऑफ़शोर या DMCA-संवेदनशील प्रोजेक्ट के लिए अक्सर एक वरना सतर्क सेटअप की सबसे कमज़ोर कड़ी होती है। आपके अपने फ़्रंट नोड ज़्यादा मेहनत माँगते हैं और उनकी असली क्षमता सीमाएँ होती हैं, पर रिक्वेस्ट के रास्ते में कोई थर्ड पार्टी नहीं होती और हमले की चपेट में आया फ़्रंट मिनटों में एक नए पते से बदला जा सकता है। दोनों ही सूरत में, ओरिजिन को इस तरह फ़ायरवॉल में बंद होना चाहिए कि वह सिर्फ़ फ़्रंट से आया वेब ट्रैफ़िक स्वीकार करे, वरना पूरा इंतज़ाम सिर्फ़ दिखावा है।





### 07
क्या हमले से अपटाइम के साथ-साथ पैसे का भी नुक़सान होगा?



मीटर्ड प्लान पर, हाँ — जो ट्रैफ़िक आपने कभी माँगा नहीं और ठुकरा भी नहीं सकते थे, वह भी आपके ट्रांसफ़र अलाउंस में गिना जाता है, और एक लगातार चलने वाला फ्लड एक साल की होस्टिंग से भी बड़ा ओवरेज बिल बना सकता है। यही व्यावहारिक वजह है कि अनमीटर्ड बैंडविड्थ स्पेसिफ़िकेशन शीट पर दिखने से कहीं ज़्यादा मायने रखता है: यह एक वित्तीय जोखिम को महज़ एक तकनीकी जोखिम में बदल देता है। यह भी पहले से जान लेना अच्छा है कि अगर कोई हमला साझा इन्फ्रास्ट्रक्चर के लिए ख़तरा बन जाए, तो प्रोवाइडर कुछ समय के लिए पते को नल-रूट कर सकते हैं; यह हर जगह का मानक तरीक़ा है, आपके ख़ास होस्ट की कोई नाकामी नहीं।





### 08
क्या ऑफ़शोर या नो-KYC होस्ट पर जाने से हमलों की आशंका बढ़ जाती है?



होस्टिंग का चुनाव अपने-आप में तटस्थ है; आप जो चलाते हैं वही ध्यान खींचता है। गेम सर्वर, फ़ोरम, स्ट्रीमिंग, मार्केटप्लेस, और कोई भी ऐसी चीज़ जिसका कोई प्रतिस्पर्धी हो या जिससे किसी को रंजिश हो, क्षेत्राधिकार चाहे जो भी हो, हमले खींचती है। ऑफ़शोर होने पर जो बदलता है वह है आपका सहारा: आपको असुविधाजनक होने की वजह से हटाए जाने की आशंका कम होती है, और यह बात दोनों तरफ़ जाती है — सुरक्षा तकनीकी है, संविदात्मक नहीं। असली ट्रांज़िट क्षमता वाली लोकेशन चुनें, अनमीटर्ड बैंडविड्थ लें, ओरिजिन पता छुपा रखें, और लेयर 7 को पहली घटना से नहीं बल्कि पहले ही दिन से अपनी ज़िम्मेदारी मानें।




संबंधित गाइड्स

## पढ़ते रहें


[### How to चुनें an ऑफशोर होस्टिंग न्यायक्षेत्र in 2026

खरीदारी


ऑफशोर न्यायक्षेत्र चुनने के लिए एक व्यावहारिक decision framework: data-retention कानून, MLAT exposure, DMCA stance, अदालत की speed, और real-world प्रवर्तन — देश दर देश।


6-प्रश्न FAQ](https://servghost.com/hi/guides/choosing-an-offshore-jurisdiction)
[### Privacy-Critical Workloads के लिए VPS बनाम Dedicated सर्वर

खरीदारी


कब VPS पर्याप्त है, कब shared tenancy liability बन जाती है, और कब bare metal ही ईमानदार जवाब है। Hardware isolation, हाइपरवाइज़र risk, और cost बनाम जोखिम मॉडल।


6-प्रश्न FAQ](https://servghost.com/hi/guides/vps-vs-dedicated-for-privacy)
[### No-KYC VPS पर Self-Hosted VPN: WireGuard बनाम OpenVPN

परिचालन


स्व-होस्टेड VPN व्यावसायिक प्रदाताओं को क्यों मात देता है, और 2026 में WireGuard और OpenVPN गोपनीयता, प्रदर्शन और परिचालन जोखिम पर वास्तव में कैसे तुलना करते हैं।


6-प्रश्न FAQ](https://servghost.com/hi/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI Inference के लिए RTX 4090 बनाम H100 SXM5 (और RTX 5090 कहाँ फिट होता है)

खरीदारी


2026 में self-होस्टेड LLM, image, video, voice और finetuning वर्कलोड के लिए कौन सा NVIDIA GPU चुनें: RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token और कब कौन जीतता है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex Trading के लिए ऑफशोर Windows RDP

परिचालन


पूर्ण guide: forex trading के लिए Windows RDP क्यों, low-latency offshore क्षेत्राधिकार कैसे चुनें, MT4/MT5/cTrader/Expert Advisor सेटअप, broker servers पर latency, और no-KYC checkout path।


6-प्रश्न FAQ](https://servghost.com/hi/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA-Ignored Hosting समझाया गया: 2026 में इसका असली मतलब क्या है

खरीदारी


"DMCA ignored" hosting वास्तव में आपको क्या देती है, कौन-सी jurisdictions इसे सच में back करती हैं, किन workloads को इसकी ज़रूरत है, और कौन-से copyright जाल इस शब्द के दायरे में नहीं आते।


6-प्रश्न FAQ](https://servghost.com/hi/guides/dmca-ignored-hosting-explained)
[### Crypto से Anonymous Domain Registration: 2026 में WHOIS Privacy

गोपनीयता


2026 की practical guide: बिना identity reveal किए domains register करने का तरीका — TLD के अनुसार WHOIS regimes, registrar चुनाव, crypto payment options, और वे operational गलतियाँ जो आपको leak करती हैं।


6-प्रश्न FAQ](https://servghost.com/hi/guides/anonymous-domain-registration-with-crypto)
[### क्रिप्टो Payments for होस्टिंग: Monero vs Bitcoin vs USDT

गोपनीयता


भुगतान कॉइन आपके होस्ट को आपके बारे में क्या पता चलता है इसे कैसे प्रभावित करता है। XMR, BTC और USDT के लिए गोपनीयता, शुल्क, finality और चेन विश्लेषण जोखिम — स्पष्ट सिफारिश के साथ।


6-प्रश्न FAQ](https://servghost.com/hi/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### क्या Offshore Hosting सच में Anonymous है? एक ईमानदार जवाब

गोपनीयता


Offshore, no-KYC hosting वह identity हटा देती है जो एक normal host collect करता है — लेकिन "anonymous" होना payment, provider logging और आपकी अपनी opsec पर निर्भर करता है। यहाँ बताया गया है कि असल में क्या traceable है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/is-offshore-hosting-truly-anonymous)
[### VPS Hardening का पहला घंटा: एक Checklist

परिचालन


एक नए VPS को एक घंटे से कम में secure करने के लिए एक concrete, ordered checklist: SSH keys, एक firewall, fail2ban, automatic updates, और वह attack-surface reduction जो ज़्यादातर opportunistic attacks को रोकती है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/first-hour-vps-hardening-checklist)
[### No-KYC होस्टिंग क्या है? परिभाषा, वैधता और यह कैसे काम करती है

गोपनीयता


No-KYC होस्टिंग आपको बिना किसी पहचान सत्यापन के सर्वर किराये पर लेने देती है — न नाम, न ईमेल, न ID। यहाँ जानें इसका अर्थ, यह तकनीकी रूप से कैसे काम करता है, क्या यह कानूनी है, और असली प्रदाता को कैसे पहचानें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/what-is-no-kyc-hosting)
[### क्या ऑफशोर होस्टिंग कानूनी है? 2026 का स्पष्ट जवाब

खरीदारी


ऑफशोर होस्टिंग कानूनी है — आपके लिए भी और सेवा प्रदाता के लिए भी। यहाँ जानिए इस शब्द का वास्तविक अर्थ, कानूनी सीमा कहाँ है, कौन-सी भ्रांतियाँ छोड़ने योग्य हैं, और इसे जिम्मेदारी से कैसे उपयोग करें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/is-offshore-hosting-legal)
[### Monero (XMR) से होस्टिंग का भुगतान कैसे करें — चरण-दर-चरण मार्गदर्शिका

गोपनीयता


VPS या डेडिकेटेड सर्वर के लिए Monero (XMR) से भुगतान की चरण-दर-चरण मार्गदर्शिका: XMR सबसे निजी विकल्प क्यों है, इसे कैसे प्राप्त करें, और चेकआउट प्रक्रिया कैसे काम करती है — इनवॉइस से लेकर कुछ ही मिनटों में चालू सर्वर तक।


6-प्रश्न FAQ](https://servghost.com/hi/guides/how-to-pay-for-hosting-with-monero)
[### गुमनाम तरीके से वेबसाइट होस्ट कैसे करें — एक व्यावहारिक 2026 गाइड

गोपनीयता


एक व्यावहारिक, बहु-स्तरीय गाइड जो बताती है कि बिना किसी पहचान के वेबसाइट कैसे होस्ट की जाए — अकाउंट, भुगतान, डोमेन, अधिकार क्षेत्र, कनेक्शन और कंटेंट — हर परत को विस्तार से समझाया गया है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/how-to-host-a-website-anonymously)
[### VPS पर WireGuard VPN कैसे सेटअप करें — चरण-दर-चरण गाइड

परिचालन


WireGuard से अपना निजी VPN बनाएं एक VPS पर: यह जानें कि self-hosted VPN किसी व्यावसायिक VPN से बेहतर क्यों है, इंस्टॉलेशन से लेकर कनेक्टेड क्लाइंट तक का पूरा सेटअप, और इसे कैसे सुरक्षित करें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU सर्वर पर LLM को स्व-होस्ट कैसे करें — 2026 गाइड

परिचालन


किराये के GPU सर्वर पर अपना खुद का लार्ज लैंग्वेज मॉडल चलाएँ: API की तुलना में स्व-होस्टिंग क्यों बेहतर है, कौन-सा GPU और मॉडल चुनें, Ollama या vLLM के साथ सेटअप कैसे करें, और इसकी लागत क्या है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting बनाम Offshore Hosting — क्या है अंतर?

खरीदारी


Bulletproof hosting और offshore hosting को अक्सर एक-दूसरे का पर्याय मान लिया जाता है — लेकिन ये एक नहीं हैं। यहाँ जानें असली अंतर, यह क्यों मायने रखता है, और आपको वास्तव में किसकी जरूरत है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin से VPS कैसे खरीदें — चरण-दर-चरण गाइड (2026)

खरीदारी


Bitcoin से VPS खरीदने की शुरुआती-अनुकूल मार्गदर्शिका: BTC प्राप्त करना, प्लान चुनना, इनवॉइस का भुगतान करना और क्या मिलता है — बिना कार्ड और बिना नाम के एक चालू सर्वर।


6-प्रश्न FAQ](https://servghost.com/hi/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026 में DMCA-ignored होस्टिंग के लिए सर्वश्रेष्ठ देश

खरीदारी


जब आप ऐसे सर्वर चाहते हैं जो US-शैली के टेकडाउन से परे हों — तो कहाँ होस्ट करें: वे क्षेत्राधिकार जो काम करते हैं, DMCA-ignored का वास्तविक अर्थ, और सही चुनाव कैसे करें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/best-countries-for-dmca-ignored-hosting)
[### Tor हिडन सर्विस (.onion साइट) कैसे होस्ट करें — 2026 गाइड

परिचालन


VPS पर Tor onion सर्विस सेट करें: हिडन सर्विस क्या है, यह अनाम होस्टिंग का सबसे मज़बूत रूप क्यों है, पूरा सेटअप, और इसे वास्तव में अनाम कैसे रखें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/how-to-host-a-tor-hidden-service)
[### ऑफशोर मेल सर्वर सेटअप — 2026 में खुद का प्राइवेट ईमेल होस्ट करें

परिचालन


एक ऑफशोर VPS पर अपना खुद का प्राइवेट ईमेल सर्वर चलाएं: सेल्फ-होस्ट ईमेल क्यों करें, इसके लिए क्या चाहिए, ऑल-इन-वन मेल स्टैक के साथ व्यावहारिक सेटअप, और डिलीवरेबिलिटी कैसे सही रखें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/offshore-mail-server-setup)
[### क्रिप्टो नोड होस्टिंग गाइड — VPS पर ब्लॉकचेन नोड चलाएं

परिचालन


सर्वर पर ब्लॉकचेन नोड कैसे होस्ट करें: अपना नोड चलाने के फायदे, Bitcoin, Ethereum, Monero आदि के लिए सर्वर का आकार, सेटअप प्रक्रिया और इसे निजी रखने के तरीके।


6-प्रश्न FAQ](https://servghost.com/hi/guides/crypto-node-hosting-guide)
[### Stable Diffusion के लिए GPU होस्टिंग — अपना खुद का इमेज सर्वर चलाएं

परिचालन


अपने खुद के GPU सर्वर पर Stable Diffusion चलाएं: इमेज जनरेशन को सेल्फ-होस्ट क्यों करें, कौन सा GPU चुनें, वेब UI के साथ सेटअप कैसे करें, और होस्टेड सेवा की तुलना में इसकी लागत क्या है।


6-प्रश्न FAQ](https://servghost.com/hi/guides/gpu-hosting-for-stable-diffusion)
[### सर्वर OpSec — सर्वर चलाते समय गुमनाम कैसे रहें

गोपनीयता


गुमनाम सर्वर चलाने वाले किसी भी व्यक्ति के लिए परिचालन सुरक्षा: वे गलतियाँ जो पहचान उजागर करती हैं, वे आदतें जो उन्हें रोकती हैं, और पहचान को वास्तव में अलग कैसे रखें।


6-प्रश्न FAQ](https://servghost.com/hi/guides/server-opsec-staying-anonymous)
[### Seedbox सेटअप गाइड — 2026 में अपना निजी Seedbox बनाएँ

परिचालन


अपने सर्वर पर खुद का seedbox कैसे बनाएँ: seedbox क्या होता है, उसकी साइज़िंग, web UI के साथ torrent client की इंस्टॉलेशन, और उसे निजी व सुरक्षित रखना।


6-प्रश्न FAQ](https://servghost.com/hi/guides/seedbox-setup-guide)
[### अपने खुद के VPS से DPI सेंसरशिप को कैसे बायपास करें (2026 गाइड)

गोपनीयता


आपका VPN काम करना बंद कर चुका है? अपने खुद के VPS से DPI सेंसरशिप बायपास करने का तरीका: डीप पैकेट इंस्पेक्शन असल में क्या पहचानता है, 2026 के पांच प्रोटोकॉल में से कौन-सा किस ब्लॉक को मात देता है, और एक पूरा VLESS+REALITY वॉकथ्रू।


6-प्रश्न FAQ](https://servghost.com/hi/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS पर फुल-डिस्क एन्क्रिप्शन: LUKS सेटअप और यह असल में क्या सुरक्षित करता है

परिचालन


LUKS से VPS एन्क्रिप्ट करने का तरीका: एन्क्रिप्टेड डेटा वॉल्यूम, SSH पर रिमोट अनलॉक वाला फुल-रूट एन्क्रिप्शन, छोटे सर्वर पर मायने रखने वाली सेटिंग्स, और डिस्क एन्क्रिप्शन असल में क्या रोकता है इसका ईमानदार ब्योरा।


8-प्रश्न FAQ](https://servghost.com/hi/guides/full-disk-encryption-on-a-vps)
[### ओरिजिन सर्वर IP छुपाना: CDN, रिवर्स प्रॉक्सी और जो फिर भी लीक होता है

गोपनीयता


ऑफ़शोर सर्वर के आगे CDN लगाएँ या नहीं: यह क्या छुपाता है, साथ में कौन-सी शिकायत डेस्क मिलती है, वे छह तरीके जिनसे ओरिजिन IP फिर भी लीक होता है, और अपना ऑडिट कैसे करें।


8-प्रश्न FAQ](https://servghost.com/hi/guides/hiding-your-origin-server-ip)
[### VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore

परिचालन


आपका host कोई backup नहीं रखता। server को असल में क्या बर्बाद करता है, push backup साथ में क्यों मरता है, restic बनाम BorgBackup, और restore टेस्ट करने का तरीक़ा।


8-प्रश्न FAQ](https://servghost.com/hi/guides/vps-backup-strategy)
[### खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ

परिचालन


अपने खुद के Matrix homeserver से असल में क्या मिलता है: Synapse बनाम Conduit, वह server_name जिसे आप बदल नहीं सकते, डिस्क भरने वाला media, और federation का एक्सपोज़र।


8-प्रश्न FAQ](https://servghost.com/hi/guides/self-host-a-matrix-server)
[### Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें

परिचालन


host migration को उबाऊ बनाने वाला क्रम: DNS TTL दिनों पहले घटाएँ, दोनों servers साथ चलाएँ, writes को घंटों की बजाय मिनटों तक freeze करें — और migration के पीछे छूटी passive-DNS, Certificate Transparency और WHOIS trail को साफ़ करें।


8-प्रश्न FAQ](https://servghost.com/hi/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

परिचालन


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8-प्रश्न FAQ](https://servghost.com/hi/guides/self-host-a-crypto-payment-gateway)




## ऐसी जगह रखें जो फ्लड को फ़िल्टर करे



सात क्षेत्राधिकारों में ऑफ़शोर KVM सर्वर, साथ में L3/L4 DDoS फ़िल्टरिंग, अनमीटर्ड बैंडविड्थ, फ़ुल रूट और NVMe स्टोरेज। कोई KYC नहीं, क्रिप्टो पेमेंट, ट्रांज़ैक्शन कन्फ़र्म होने के मिनटों बाद डिप्लॉय।


[VPS प्लान देखें](https://servghost.com/hi/vps)
[डेडिकेटेड सर्वर](https://servghost.com/hi/dedicated)
[ऑफशोर होस्टिंग](https://servghost.com/hi/offshore-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servghost.com/#organization",
    "name": "ServGhost",
    "url": "https://servghost.com",
    "description": "7 ऑफशोर न्यायक्षेत्रों में ऑफशोर VPS और डेडिकेटेड सर्वर। KYC नहीं, लॉग नहीं, केवल क्रिप्टो। आर्किटेक्चर से ही गोपनीयता।",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servghost.com/ServGhost.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servghost.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servghost.com/canary",
        "https://servghost.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servghost.com/#website",
    "url": "https://servghost.com",
    "name": "ServGhost",
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "VPS पर DDoS प्रोटेक्शन: होस्ट कहाँ रुकता है, लेयर 7 कहाँ शुरू होती है",
    "description": "आपका होस्ट पैकेट फ्लड फ़िल्टर करता है; रिक्वेस्ट फ्लड आपकी ज़िम्मेदारी है। L3/L4 स्क्रबिंग कैसे काम करती है, लेयर-7 हमले इससे सीधे क्यों निकल जाते हैं, और वे कैशिंग, रेट लिमिट व कनेक्शन सीमाएँ जो हमले के दौरान भी एक छोटे ऑफ़शोर सर्वर को ऑनलाइन रखती हैं।",
    "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011",
    "author": {
        "@type": "Organization",
        "@id": "https://servghost.com/#editorial",
        "name": "ServGhost Editorial",
        "url": "https://servghost.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servghost.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "datePublished": "2026-09-07T00:00:00+00:00",
    "dateModified": "2026-09-07T00:00:00+00:00",
    "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps",
    "inLanguage": "hi",
    "keywords": "VPS पर DDoS प्रोटेक्शन, DDoS अटैक से सर्वर कैसे बचाएँ, लेयर 7 DDoS मिटिगेशन, nginx rate limiting DDoS, ऑफ़शोर DDoS प्रोटेक्टेड होस्टिंग, L3 L4 DDoS फ़िल्टरिंग, SYN flood से कैसे बचें, origin server IP छुपाना DDoS",
    "articleSection": "परिचालन",
    "wordCount": 4335
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "\"DDoS प्रोटेक्शन शामिल है\" का मतलब क्या मैं हर चीज़ से सुरक्षित हूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं, और यह कमी धुँधली नहीं बल्कि सटीक है। शामिल प्रोटेक्शन नेटवर्क-लेयर फ़िल्टरिंग है: यह वॉल्यूमेट्रिक फ्लड — SYN फ्लड, UDP एम्प्लिफ़िकेशन, कच्चे पैकेट तूफ़ान — को आपके पोर्ट तक पहुँचने से पहले, अपस्ट्रीम ही गिरा देती है। यही वह श्रेणी है जिसे आप सच में अकेले नहीं संभाल सकते, इसलिए इसे शामिल करना सही बात है। यह आपके एप्लिकेशन की जाँच नहीं करती, इसलिए किसी महँगे एंडपॉइंट के ख़िलाफ़ कुछ हज़ार रिक्वेस्ट प्रति सेकंड का एक HTTP फ्लड इससे बिना छुए गुज़र जाता है और हर नेटवर्क ग्राफ़ सामान्य दिखते हुए भी आपकी साइट गिरा देता है। लेयर 7 वह कॉन्फ़िगरेशन है जिसके मालिक आप ख़ुद हैं: कैशिंग, रेट लिमिट और कनेक्शन सीमाएँ।"
            }
        },
        {
            "@type": "Question",
            "name": "मैं DDoS हमले और ट्रैफ़िक स्पाइक में फ़र्क़ कैसे करूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "यह पूछें कि क्या ट्रैफ़िक को कुछ चाहिए। असली विज़िटर, चाहे वे किसी लोकप्रिय लिंक से अचानक आए फ्लड के तौर पर ही क्यों न हों, उन पेजों के लिए रिक्वेस्ट भेजते हैं जो मौजूद हैं, उन पेजों के ऐसेट लोड करते हैं, विश्वसनीय रेफ़रर के साथ आते हैं, और कई नेटवर्क में एक स्वाभाविक पैटर्न में फैले होते हैं। एक हमला आमतौर पर एक ही पाथ पर लगातार वार करता है, ऐसेट को नज़रअंदाज़ करता है, अविश्वसनीय या ग़ायब यूज़र-एजेंट भेजता है, और एक ऐसा वितरण दिखाता है जो कृत्रिम लगे। अपने एक्सेस लॉग में प्रति क्लाइंट पते और प्रति पाथ रिक्वेस्ट जाँचें: अगर एक एंडपॉइंट हावी है और कुछ और लोड ही नहीं हो रहा, तो यह एक हमला है। अगर वही पेज परोसे जा रहे हैं जिन्हें कोई इंसान देखना चाहेगा और आपके रेफ़रर असली हैं, तो आपकी समस्या एक ख़ुशनुमा वजह वाली क्षमता समस्या है।"
            }
        },
        {
            "@type": "Question",
            "name": "हमले के दौरान मैं सबसे असरदार अकेला काम क्या कर सकता हूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "अनाम विज़िटर के लिए फ़ुल-पेज कैशिंग चालू करें, और इसे इस तरह कॉन्फ़िगर करें कि जब बैकएंड जूझ रहा हो तो यह बासी कंटेंट परोसे। एक रेट लिमिट काम को नकारती है; एक कैश काम को मौजूद ही नहीं रहने देता। जो रिक्वेस्ट पहले एक डेटाबेस क्वेरी, एक टेम्पलेट रेंडर और एक एप्लिकेशन वर्कर की क़ीमत लेता था, वह एक फ़ाइल रीड बन जाता है, और जो हार्डवेयर कुछ सौ डायनेमिक रिक्वेस्ट प्रति सेकंड पर ढह गया था, वही दसियों हज़ार कैश्ड रिक्वेस्ट परोस देगा। यह सूची का अकेला ऐसा उपाय भी है जो असली ट्रैफ़िक के ख़िलाफ़ भी वैसी ही मदद करता है, इसलिए रेट लिमिट के उलट, यह आपके अपने यूज़र पर उल्टा असर नहीं करता।"
            }
        },
        {
            "@type": "Question",
            "name": "CDN लगाने के बाद मेरी nginx रेट लिमिट ने काम करना क्यों बंद कर दिया?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "क्योंकि अब हर रिक्वेस्ट विज़िटर के पते की बजाय CDN के पते से आता है, इसलिए एक प्रति-क्लाइंट लिमिट पूरे इंटरनेट को एक ही क्लाइंट मानकर गिन रही है। थ्रेशोल्ड के हिसाब से, यह या तो कभी ट्रिगर ही नहीं होगी या आपके पूरे ट्रैफ़िक को एक साथ बैन कर देगी। अपना रियल-IP सोर्स कॉन्फ़िगर करें — nginx में, भरोसेमंद प्रॉक्सी रेंज प्लस वह हेडर जो प्रॉक्सी भेजता है — ताकि लिमिट फिर से असली विज़िटर पर आधारित हो। उस भरोसे को प्रॉक्सी की अपनी रेंज तक सीमित रखें: अगर आप खुले इंटरनेट से आया क्लाइंट-दिया हेडर स्वीकार करते हैं, तो एक हमलावर हर रिक्वेस्ट पर एक नई पहचान गढ़ सकता है और आपकी हर लिमिट से निकल सकता है।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या DDoS हमला रोकने के लिए fail2ban काफ़ी है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं। fail2ban एक अंतराल पर लॉग पढ़ता है और थ्रेशोल्ड पार करने पर दोषी पतों को बैन करता है, जो कुछ गिने-चुने स्रोतों से आई ब्रूट-फ़ोर्स कोशिशों के लिए ठीक है। एक डिस्ट्रिब्यूटेड हमला हज़ारों पतों से सेकंडों में आता है, जिनमें से हर एक बस मुट्ठी भर रिक्वेस्ट भेजता है, इसलिए थ्रेशोल्ड कभी पार ही नहीं होता, और वैसे भी प्रतिक्रिया का समय बहुत धीमा है। इससे भी बुरा यह कि दसियों हज़ार एंट्री तक बढ़ चुका एक रूलसेट, हमले से भी ज़्यादा संसाधन खा सकता है। इसे SSH और लॉगिन एंडपॉइंट के लिए रखें, और फ्लड को कैशिंग, रेट लिमिटिंग और एक अपस्ट्रीम फ़िल्टर से संभालें।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मुझे CDN इस्तेमाल करना चाहिए, या आगे अपनी ख़ुद की रिवर्स प्रॉक्सी चलानी चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "यह आपके बजट से ज़्यादा इस पर निर्भर करता है कि आप होस्ट क्या कर रहे हैं। एक कमर्शियल CDN वह सोखने की क्षमता लाता है जिसकी आप बराबरी नहीं कर सकते, और एक क्लिक दूर एक चैलेंज पेज भी, पर साथ में आपको उसका एब्यूज़ डेस्क भी विरासत में मिलता है और वह आपका ट्रैफ़िक देख सकता है — जो ऑफ़शोर या DMCA-संवेदनशील प्रोजेक्ट के लिए अक्सर एक वरना सतर्क सेटअप की सबसे कमज़ोर कड़ी होती है। आपके अपने फ़्रंट नोड ज़्यादा मेहनत माँगते हैं और उनकी असली क्षमता सीमाएँ होती हैं, पर रिक्वेस्ट के रास्ते में कोई थर्ड पार्टी नहीं होती और हमले की चपेट में आया फ़्रंट मिनटों में एक नए पते से बदला जा सकता है। दोनों ही सूरत में, ओरिजिन को इस तरह फ़ायरवॉल में बंद होना चाहिए कि वह सिर्फ़ फ़्रंट से आया वेब ट्रैफ़िक स्वीकार करे, वरना पूरा इंतज़ाम सिर्फ़ दिखावा है।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या हमले से अपटाइम के साथ-साथ पैसे का भी नुक़सान होगा?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "मीटर्ड प्लान पर, हाँ — जो ट्रैफ़िक आपने कभी माँगा नहीं और ठुकरा भी नहीं सकते थे, वह भी आपके ट्रांसफ़र अलाउंस में गिना जाता है, और एक लगातार चलने वाला फ्लड एक साल की होस्टिंग से भी बड़ा ओवरेज बिल बना सकता है। यही व्यावहारिक वजह है कि अनमीटर्ड बैंडविड्थ स्पेसिफ़िकेशन शीट पर दिखने से कहीं ज़्यादा मायने रखता है: यह एक वित्तीय जोखिम को महज़ एक तकनीकी जोखिम में बदल देता है। यह भी पहले से जान लेना अच्छा है कि अगर कोई हमला साझा इन्फ्रास्ट्रक्चर के लिए ख़तरा बन जाए, तो प्रोवाइडर कुछ समय के लिए पते को नल-रूट कर सकते हैं; यह हर जगह का मानक तरीक़ा है, आपके ख़ास होस्ट की कोई नाकामी नहीं।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या ऑफ़शोर या नो-KYC होस्ट पर जाने से हमलों की आशंका बढ़ जाती है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "होस्टिंग का चुनाव अपने-आप में तटस्थ है; आप जो चलाते हैं वही ध्यान खींचता है। गेम सर्वर, फ़ोरम, स्ट्रीमिंग, मार्केटप्लेस, और कोई भी ऐसी चीज़ जिसका कोई प्रतिस्पर्धी हो या जिससे किसी को रंजिश हो, क्षेत्राधिकार चाहे जो भी हो, हमले खींचती है। ऑफ़शोर होने पर जो बदलता है वह है आपका सहारा: आपको असुविधाजनक होने की वजह से हटाए जाने की आशंका कम होती है, और यह बात दोनों तरफ़ जाती है — सुरक्षा तकनीकी है, संविदात्मक नहीं। असली ट्रांज़िट क्षमता वाली लोकेशन चुनें, अनमीटर्ड बैंडविड्थ लें, ओरिजिन पता छुपा रखें, और लेयर 7 को पहली घटना से नहीं बल्कि पहले ही दिन से अपनी ज़िम्मेदारी मानें।"
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "होम",
            "item": "https://servghost.com/hi/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "गोपनीयता होस्टिंग Guides",
            "item": "https://servghost.com/hi/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "VPS पर DDoS प्रोटेक्शन: होस्ट कहाँ रुकता है, लेयर 7 कहाँ शुरू होती है",
            "item": "https://servghost.com/hi/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```