[خانه](https://servghost.com/fa) /
[راهنماهای میزبانی با حریم خصوصی](https://servghost.com/fa/guides) /
محافظت DDoS از VPS: جایی که هاست تمام می‌شود و لایه 7 آغاز می‌شود






عملیات


# جان سالم به‌در بردن از یک حمله DDoS روی VPS شما



هر پلن هاستینگ می‌گوید «محافظت DDoS شامل می‌شود» و همه آن‌ها یک چیز محدود را می‌گویند: شبکه سیل‌هایی را جذب می‌کند که با گیگابیت سنجیده می‌شوند. حمله‌هایی که واقعاً سایت‌های کوچک را از پا درمی‌آورند با درخواست در ثانیه سنجیده می‌شوند، تقریباً هیچ هزینه‌ای برای مهاجم ندارند و کاملاً مشروع به‌نظر می‌رسند. این راهنما مرز میان این دو را مشخص می‌کند، نشان می‌دهد چطور در کمتر از یک دقیقه بفهمید در کدام سمت آن هستید، و آنچه واقعاً در سمتی از مرز که به خودتان مربوط است دوام می‌آورد را پوشش می‌دهد.


[بیشتر بخوانید](#guide-body)
[سؤالات متداول](#guide-faq)






## در این صفحه




- [راهنما](#guide-body)

- [سؤالات متداول](#guide-faq)

- [راهنماهای مرتبط](#guide-related)

- [صفحات پیشنهادی](#guide-cta)






بدون KYC
فقط ارز دیجیتال
بدون لاگ
DMCA نادیده گرفته می‌شود
دسترسی کامل Root
NVMe SSD





22 دقیقه مطالعه
به‌روزرسانی Sep 2026

در این صفحه

[01دو حمله متفاوت که یک اسم را به اشتراک می‌گذارند](#دو-حمله-متفاوت-که-یک-اسم-را-به-اشتراک-میگذارند)
[02«محافظت DDoS شامل می‌شود» واقعاً چه چیزی به شما می‌دهد](#محافظت-ddos-شامل-میشود-واقعا-چه-چیزی-به-شما-میدهد)
[03اول مشخص کنید که آیا اصلاً این یک حمله است](#اول-مشخص-کنید-که-آیا-اصلا-این-یک-حمله-است)
[04خواندن حمله از خود سرور](#خواندن-حمله-از-خود-سرور)
[05ده دقیقه اول](#ده-دقیقه-اول)
[06محدودیت‌های نرخی که دوام می‌آورند، و اشتباهی که همه مرتکب می‌شوند](#محدودیتهای-نرخی-که-دوام-میآورند-و-اشتباهی-که-همه-مرتکب-میشون)
[07کش‌گذاری ارزان‌ترین اقدام مقابله‌ای است که تا به حال پیاده می‌کنید](#کشگذاری-ارزانترین-اقدام-مقابلهای-است-که-تا-به-حال-پیاده-میکن)
[08سقف‌هایی که تعیین می‌کنند آیا از پا می‌افتید یا نه](#سقفهایی-که-تعیین-میکنند-آیا-از-پا-میافتید-یا-نه)
[09قراردادن چیزی جلوی سرور اصلی](#قراردادن-چیزی-جلوی-سرور-اصلی)
[10یک سرور اصلی پنهان بیش از هر فیلتری ارزش دارد](#یک-سرور-اصلی-پنهان-بیش-از-هر-فیلتری-ارزش-دارد)
[11انتخاب سخت‌افزار و لوکیشن، طوری که حمله‌ها کسل‌کننده بمانند](#انتخاب-سختافزار-و-لوکیشن-طوری-که-حملهها-کسلکننده-بمانند)
[12پنج کاری که نباید انجام دهید](#پنج-کاری-که-نباید-انجام-دهید)
[13نسخه کوتاه](#نسخه-کوتاه)
[FAQسؤالات رایج](#guide-faq)
[→صفحات پیشنهادی](#guide-cta)







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

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

## دو حمله متفاوت که یک اسم را به اشتراک می‌گذارند

«DDoS» یک کلمه است که دو مشکل را پوشش می‌دهد که تقریباً هیچ‌چیز مشترکی جز نتیجه‌شان ندارند. این دو در جاهای متفاوت، توسط افراد متفاوت، با ابزارهای متفاوت متوقف می‌شوند، و اشتباه‌گرفتن آن‌ها با هم دلیل اصلی این است که چرا این‌همه تلاش برای مقابله در لایه اشتباه هدر می‌رود.

| | حجمی — لایه‌های 3 و 4 | اپلیکیشن — لایه 7 |
| --- | --- | --- |
| چه چیزی می‌رسد | سیل SYN، تقویت UDP از طریق بازتابنده‌های DNS، NTP یا memcached باز، سیل ACK، بسته‌های آشغال ساده | درخواست‌های عادی HTTP: سیل GET، سیل POST، slow-loris، رشته‌های کوئری دورزننده کش |
| واحد اندازه‌گیری | گیگابیت و میلیون‌ها بسته در ثانیه | درخواست در ثانیه — اغلب فقط چند هزار تا |
| پهنای باند لازم برای آسیب‌زدن | عظیم. این یک رقابت ظرفیتی است | تقریباً هیچ. اگر اندپوینت به‌اندازه کافی پرهزینه باشد، یک لپ‌تاپ تنها هم کافی است |
| کجا باید متوقف شود | **در بالادست، توسط ارائه‌دهنده‌تان.** تا زمانی که بسته‌ها به پورت شما برسند، خسارت وارد شده است | **روی سرور خودتان، توسط خودتان**، یا روی پراکسی‌ای که جلوی آن کنترل می‌کنید |
| روی خود دستگاه چه شکلی دارد | اینترفیس اشباع، شمارنده‌های بسته پوچ و عجیب، CPU ممکن است بیکار باشد | پهنای باند متوسط، اما هر کارگر مشغول، بار در حال بالارفتن، صف پایگاه‌داده در حال رشد |
| چه کسی درستش می‌کند | پالایش هاست شما، به‌صورت خودکار، معمولاً ظرف چند ثانیه | پیکربندی خودتان — محدودیت نرخ، کش‌گذاری، سقف اتصال |

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

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

## «محافظت DDoS شامل می‌شود» واقعاً چه چیزی به شما می‌دهد

محافظت در لایه شبکه واقعی، باارزش، و تقریباً همیشه بد فهمیده‌شده است. وقتی ارائه‌دهنده‌ای فیلترینگ L3/L4 را تبلیغ می‌کند، منظورش این است که شبکه‌اش ترافیک مقصدش آدرس شما را زیر نظر دارد، و وقتی سیلی شناسایی شود، ترافیک از میان سخت‌افزار پالایش عبور داده می‌شود که بخش مخرب را حذف می‌کند و آنچه را مشروع به‌نظر می‌رسد پیش می‌فرستد. این کار بدون هیچ تیکت پشتیبانی‌ای انجام می‌شود و معمولاً بدون اینکه شما چیزی بیش از یک پرش کوتاه متوجه شوید.

این یک جمله کار زیادی روی دوش خودش دارد، پس ارزش دارد باز کنیم که چه چیزی را شامل می‌شود و چه چیزی را نه:

- **حمله‌هایی را پوشش می‌دهد که به‌تنهایی نمی‌توانید از پسشان بربیایید.** یک سیل تقویتی 200 Gbps علیه سروری با پورت 1 Gbps مشکل پیکربندی نیست. حساب و کتاب ساده است. پالایش بالادستی تنها پاسخی است که وجود دارد.

- **نسبت به اپلیکیشن شما بی‌حالت (stateless) است.** فیلتر نمی‌داند کدام URLهای شما پرهزینه‌اند، کدام بازدیدکننده‌ها لاگین‌کرده‌اند، یا اینکه یک درخواست به اندپوینت جست‌وجوی شما چهارصد برابر یک درخواست به لوگویتان هزینه دارد.

- **به یک آستانه واکنش نشان می‌دهد، نه به رنج شما.** شناسایی بر اساس حجم ترافیک فعال می‌شود. حمله‌ای که هیچ‌وقت از آن آستانه رد نشود، هیچ‌وقت آن را فعال نمی‌کند، مهم نیست چقدر کامل سایت شما را از کار انداخته باشد.

- **در موارد شدید ممکن است موقتاً بلک‌هول کند.** هر شبکه‌ای یک سقف دارد. اگر حمله‌ای زیرساخت مشترک را تهدید کند، ممکن است آدرس برای مدتی کنار گذاشته شود — این یک رویه استاندارد و همه‌جایی است و بهتر است پیش از رخ‌دادنش بدانیدش تا حین آن.

**نسخه یک‌خطی:** هاست شما شبکه خودش را محافظت می‌کند و شما از آن بهره می‌برید. اما اپلیکیشن شما را محافظت نمی‌کند، و راهی هم برای این کار ندارد. لایه 7 یک آپسل نیست که از شما دریغ شده باشد — لایه‌ای است که ارائه‌دهنده شما بدون خاتمه‌دادن به TLS شما نمی‌تواند داخل آن را ببیند، کاری که برای هرکسی که آفشور هاست می‌کند هزینه‌های جدی خودش را دارد.

## اول مشخص کنید که آیا اصلاً این یک حمله است

سهم قابل‌توجهی از رویدادهایی که به‌عنوان DDoS مشکوک می‌شوند، در واقع چیز دیگری‌اند که لباس آن را پوشیده‌اند، و راه‌حل‌ها قابل‌تعویض با هم نیستند. پیش از اینکه هرچیزی را محدودیت نرخ بزنید، دو دقیقه وقت بگذارید و بدلی‌ها را کنار بگذارید — تشخیص اشتباه این‌جا یک ساعت، و گاهی کاربران واقعی‌تان، برایتان هزینه دارد.

- **پرطرفدار شده‌اید.** یک لینک روی یک تجمیع‌کننده بزرگ، شکلی از ترافیک تولید می‌کند که دقیقاً شبیه یک سیل لایه 7 است، با این تفاوت که رفررها واقعی‌اند و درخواست‌ها برای صفحاتی هستند که یک انسان می‌خواهدشان. این یک مشکل ظرفیت با یک دلیل خوشحال‌کننده است؛ محدودیت‌نرخ‌زدنش به خودتان آسیب می‌زند.

- **یک خزنده رفتار مؤدبانه‌اش را از دست داد.** اسکرِیپرهای تهاجمی و بات‌های آموزش هوش مصنوعی به‌راحتی می‌توانند از پس یک سرور کوچک بربیایند. معمولاً user-agent لو می‌دهد، و راه‌حل robots.txt به‌همراه یک محدودیت هدفمند است، نه یک محدودیت عمومی.

- **خودتان چیزی را خراب کرده‌اید.** دیپلویی که کش را غیرفعال کرده، یک کرون‌جاب سرکش، پایگاه‌داده‌ای که یک ایندکس را از دست داده — همه این‌ها به شکل «بار ناگهانی، بدون دلیل مشخص» ظاهر می‌شوند. اگر زمان‌بندی با تغییری که خودتان دادید هم‌خوانی دارد، همان تغییر را باور کنید.

- **مانیتورینگ خودتان همان سیل است.** نادر، خجالت‌آور، و خیلی رایج‌تر از چیزی که کسی اعتراف کند. یک حلقه health-check که بدون backoff دوباره تلاش می‌کند می‌تواند نرخ درخواستی واقعاً چشمگیر تولید کند.

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

## خواندن حمله از خود سرور

برای دسته‌بندی اینکه چه اتفاقی دارد می‌افتد نیازی به داشبورد ندارید. چهار دستور، که به ترتیب اجرا شوند، در کمتر از یک دقیقه به شما می‌گویند در کدام لایه دارید می‌جنگید — و دانستن آن تعیین می‌کند در ادامه چه‌کاری انجام دهید.

**آیا لوله پر است؟** شمارنده‌های اینترفیس را نگاه کنید. اگر توان عملیاتی نزدیک به سقف پورت چسبیده، در یک حمله حجمی هستید و کار شما زدن یک تیکت پشتیبانی است، نه تغییر کانفیگ:

- vnstat -tr 10 — میانگین توان عملیاتی طی ده ثانیه، سریع‌ترین قرائت صادقانه از اشباع.

- cat /proc/net/dev دو بار، با فاصله یک‌ثانیه‌ای — تفاضل بسته و بایت به ازای هر اینترفیس، بدون نیاز به ابزار خاصی.

**آیا یک سیل SYN است؟** اتصالات نیمه‌باز در وضعیت SYN-RECV روی هم انباشته می‌شوند. چند تا عادی است؛ هزاران تا عادی نیست:

- ss -s — خط خلاصه، شمار اتصالات به تفکیک وضعیت در یک نگاه.

- ss -tn state syn-recv | wc -l — همان عدد مشخصی که اهمیت دارد.

**آیا لایه 7 است؟** اگر پهنای باند چیز خاصی نیست اما همه‌چیز کند است، درخواست‌ها به ازای هر کلاینت را در access log خودتان بشمارید. یک آدرس تنها با ده‌ها هزار بازدید کار یک آماتور است؛ صد هزار آدرس که هرکدام فقط سه بازدید دارند، همان چیز واقعی است:

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

- $1 را با $7 عوض کنید تا به‌جایش مسیرهای درخواستی را رتبه‌بندی کنید. اگر یک اندپوینت پرهزینه غالب است، هم هدف را پیدا کرده‌اید و هم نیمی از راه‌حل را.

**واقعاً چه چیزی ته کشیده؟** میانگین بار به‌تنهایی چیز زیادی به شما نمی‌گوید. دنبال سقف مشخصی باشید که به آن خورده‌اید: همه فرزندان PHP-FPM مشغول، اتصالات پایگاه‌داده در سقف خودشان، توصیف‌گرهای فایل ته‌کشیده، یا کارگرهایی که در وضعیت D منتظر دیسک گیر کرده‌اند. آن سقف — نه ترافیک — چیزی است که سایت را از کار انداخته، و بالابردنش اغلب سریع‌تر از فیلترکردن هرچیزی است.

**این را در ذهن نگه دارید وقتی دارید بررسی می‌کنید:** اگر یک سرویس با تمرکز بر حریم خصوصی اجرا می‌کنید، یک حمله دقیقاً همان لحظه‌ای است که بیشترین وسوسه را دارید تا لاگ‌گیری را بالا ببرید و همان‌جا نگهش دارید. اگر لازم شد بالایش ببرید، اما بعد دوباره پایینش بیاورید و فایل‌ها را بعد از آن به‌شدت بچرخانید. رویدادی که یک ماه لاگ کامل بازدیدکننده‌ها را روی دیسک باقی می‌گذارد، یک مشکل را با مشکلی بدتر و ماندگارتر معاوضه کرده است. [راهنمای OpSec سرور](https://servghost.com/fa/guides/server-opsec-staying-anonymous) ما همین نظم و انضباط را پوشش می‌دهد.

## ده دقیقه اول

زیر فشار، آدم‌ها دست به بزرگ‌ترین اهرم در دسترس می‌برند، و بزرگ‌ترین اهرم معمولاً اشتباه است. این ترتیبی است که خسارت را محدود می‌کند، تقریباً از سریع‌ترین و امن‌ترین شروع می‌شود:

- **پیش از اقدام، دسته‌بندی کنید.** اینترفیس اشباع یعنی حجمی؛ اینترفیس آرام با کارگرهای مشغول یعنی لایه 7. سی ثانیه که این‌جا صرف کنید، از یک ساعت رفع‌کردن لایه اشتباه نجاتتان می‌دهد.

- **اگر حجمی است، فوراً یک تیکت باز کنید** و آدرس مقصد، زمان شروع و شمارنده‌های اینترفیس خودتان را در آن بگنجانید. بعد دست از تایپ‌کردن در سرور بردارید — این را نمی‌توانید از داخل خودش حل کنید.

- **اگر لایه 7 است، اول کش کنید.** روشن‌کردن کش‌گذاری تهاجمی کل صفحه برای بازدیدکنندگان ناشناس، تک‌تنها سریع‌ترین راه برای تبدیل یک قطعی به یک شانه‌بالاانداختن است، و تنها اقدامی است که علیه ترافیک واقعی هم کمک می‌کند.

- **سپس محدودیت نرخ بگذارید** — اول اندپوینت هدف، بعد بقیه چیزها. محتاطانه شروع کنید. محدودیتی که کاربران خودتان را هم از پا درمی‌آورد، ادامه‌ای خودخواسته از همان حمله است.

- **فقط چیزی را مسدود کنید که بدون ابهام است.** ده‌دوازده آدرس که هرکدام صد هزار درخواست دارند، یک user-agent که آشکارا جعلی است، یک کشور که هیچ کاربری در آن ندارید. در برابر وسوسه نوشتن قوانین پیچیده وقتی زیر آتش هستید مقاومت کنید؛ ماه بعد آن‌ها را به یاد نخواهید آورد.

- **اگر لازم شد، عمداً بخشی از بار را کنار بگذارید.** نمایش یک صفحه ایستای «در حال تعمیر» به بازدیدکنندگانی که لاگین نکرده‌اند، دستگاه را زنده نگه می‌دارد، API شما را بالا نگه می‌دارد، و برایتان وقت فکرکردن می‌خرد. خودتان تصمیم بگیرید چه چیزی را قربانی کنید بهتر از این است که این تصمیم به‌جای شما گرفته شود.

- **هرچه انجام دادید را یادداشت کنید.** هر قانون موقتی که اضافه کردید، یک مین زمینی برای «خودِ آینده‌تان» است. قوانینی که کمک کردند دائمی می‌شوند؛ بقیه فردا برداشته می‌شوند.

## محدودیت‌های نرخی که دوام می‌آورند، و اشتباهی که همه مرتکب می‌شوند

محدودیت نرخ ابزار اصلی برای لایه 7 است، و nginx این کار را خوب انجام می‌دهد با دو دایرکتیو که دو مشکل واقعاً متفاوت را حل می‌کنند. limit_req سقف *نرخ* درخواست را تعیین می‌کند — یعنی هر کلاینت چقدر می‌تواند تقاضا کند. limit_conn سقف *همزمانی* را تعیین می‌کند — یعنی هر کلاینت چند اتصال می‌تواند هم‌زمان باز نگه دارد. سیل‌ها به اولی نیاز دارند؛ حمله‌های slow-loris، که هزاران اتصال نزدیک‌به‌بیکار را باز نگه می‌دارند تا استخر کارگرهای شما را خالی کنند، به دومی نیاز دارند. اگر فقط یکی را پیاده کنید، فقط نیمی از مشکل پوشش داده می‌شود.

سه جزئیات، محدودیتی که واقعاً کار می‌کند را از محدودیتی که فقط تزئینی است جدا می‌کنند:

- **از burst استفاده کنید، و از nodelay هم.** مرورگرهای واقعی پرشی (bursty) عمل می‌کنند — یک بازدید تک از یک صفحه، ده‌دوازده درخواست منبع تقریباً هم‌زمان شلیک می‌کند. محدودیتی بدون فضای اضافه، بازدیدکنندگان واقعی را خفه می‌کند در حالی که مهاجمی که سرعتش را درست زیر آستانه نگه داشته، بدون مشکل عبور می‌کند.

- **اندپوینت‌های پرهزینه را جداگانه محدود کنید.** صفحه جست‌وجو، فرم لاگین، بازنشانی رمز عبور و هر اندپوینتی که در پایگاه‌داده می‌نویسد، سزاوار بودجه‌ای بسیار تنگ‌تر از منابع ایستای شما هستند. مهاجمان این‌ها را بدون تلاش پیدا می‌کنند، چون همین‌ها هستند که آسیب می‌زنند.

- **429 برگردانید، نه 503.** این کد وضعیت، سیگنالی است به کلاینت‌های خوش‌رفتار و موتورهای جست‌وجو که این محدودسازی نرخ است نه خرابی — و از تبدیل‌شدن یک بعدازظهر بد به یک مشکل رتبه‌بندی جلوگیری می‌کند.

**اشتباهی که بی‌سروصدا همه این‌ها را بی‌اثر می‌کند:** اگر هرچیزی جلوی سرور شما نشسته باشد — یک CDN، یک لود بالانسر، ریورس پراکسی خودتان — آن‌وقت هر درخواست از آدرس *آن* می‌رسد، نه آدرس بازدیدکننده. در این حالت یک محدودیت نرخ به‌ازای هر کلاینت، کل اینترنت را یک کلاینت واحد حساب می‌کند، و یا اصلاً هیچ‌کاری نمی‌کند یا کل مخاطبان شما را یک‌جا مسدود می‌کند. باید منبع real-IP خودتان را (در nginx، set_real_ip_from برای بازه‌های آی‌پی پراکسی به‌همراه real_ip_header برای هدری که ارسال می‌کند) *پیش از* اینکه محدودیت‌ها اصلاً معنایی پیدا کنند، پیکربندی کنید. آن را هم فقط به بازه‌های خود پراکسی محدود کنید: اگر به یک هدر ارسالی از سمت کلاینت از اینترنت باز اعتماد کنید، مهاجم می‌تواند در هر درخواست یک هویت تازه جعل کند و مستقیم از هر محدودیتی که دارید عبور کند.

## کش‌گذاری ارزان‌ترین اقدام مقابله‌ای است که تا به حال پیاده می‌کنید

یک محدودیت نرخ، کار را رد می‌کند. یک کش کاری می‌کند که آن کار اصلاً وجود نداشته باشد. برای هرچیزی که یک بازدیدکننده ناشناس می‌بیند، کش‌گذاری کل صفحه اقتصاد کل حمله را تغییر می‌دهد: درخواستی که قرار بود یک رفت‌وبرگشت به پایگاه‌داده، رندر یک قالب و یک کارگر PHP هزینه داشته باشد، تبدیل می‌شود به خواندن یک فایل که با میکروثانیه سنجیده می‌شود. همان سروری که در چهارصد درخواست پویا در ثانیه فروریخت، ده‌ها هزار درخواست کش‌شده را بدون اینکه حتی متوجه شود، سرویس می‌دهد.

چیزهایی که وقتی از سر ناچاری روشنش می‌کنید، اهمیت دارند:

- **فقط برای بازدیدکنندگان ناشناس کش کنید.** با یک کوکی نشست، کش را دور بزنید. نمایش صفحه یک کاربر لاگین‌کرده به کاربر دیگر، رویدادی به‌مراتب بدتر از همان قطعی‌ای است که داشتید رفعش می‌کردید.

- **عمداً محتوای قدیمی تحویل دهید.** proxy_cache_use_stale در nginx به‌همراه updating error timeout یعنی وقتی بک‌اند شما در حال دست‌وپنجه نرم‌کردن است، بازدیدکننده‌ها به‌جای خطا، صفحه‌ای کمی قدیمی می‌گیرند. در طول یک حمله، این تفاوت میان سایتی است که خوب به‌نظر می‌رسد و سایتی که مرده به‌نظر می‌رسد.

- **میس‌های تکراری را ادغام کنید.** proxy_cache_lock تضمین می‌کند که هزار درخواست هم‌زمان برای یک صفحه کش‌نشده، فقط یک درخواست به بک‌اند تولید کند، نه هزار تا. بدون آن، یک حمله دورزننده کش مستقیم از کش عبور می‌کند و با تمام قدرت روی پایگاه‌داده شما فرود می‌آید.

- **رشته‌های کوئری دورزننده کش را خنثی کنید.** ترفند استاندارد این است که یک ? و یک مقدار تصادفی اضافه شود تا هر درخواست یک کلید یکتا باشد و برای همیشه میس بخورد. کلید کش خودتان را طوری نرمال کنید که پارامترهای کوئری‌ای را که اپلیکیشن شما واقعاً استفاده نمی‌کند، نادیده بگیرد.

این‌جا یک عدم‌تقارن خوشایند وجود دارد که ارزش دارد در ذهن بنشانید: هر ساعتی که صرف کش‌گذاری می‌کنید، سایت را در بهترین روزش هم سریع‌تر، ارزان‌تر برای اجرا، و بهتر در دوام‌آوردن در برابر موفقیت می‌کند. تقریباً هیچ خط دفاعی دیگری، وقتی هیچ مشکلی نیست، سودی به شما برنمی‌گرداند.

## سقف‌هایی که تعیین می‌کنند آیا از پا می‌افتید یا نه

بیشتر سرورها به این دلیل نمی‌میرند که CPU‌شان تمام شده. آن‌ها به این دلیل می‌میرند که به یک سقف نامرئی می‌خورند که هیچ‌کس عمداً تنظیمش نکرده — یک پیش‌فرض از یک دهه پیش که روی سخت‌افزاری منطقی بود که دیگر هیچ‌کس از آن استفاده نمی‌کند. زیر حمله، این‌ها چیزهایی هستند که واقعاً اول از همه می‌شکنند:

- **کارگرهای اپلیکیشن.** pm.max_children در PHP-FPM، شمار کارگرهای Python شما، اندازه کلاستر Node شما. این سقف واقعی همزمانی سایت شماست. وقتی همه‌شان مشغول‌اند، هر بازدیدکننده اضافی در صف می‌ماند، و سایت از کار می‌افتد، مهم نیست CPU چقدر بیکار به‌نظر برسد. آن را فقط تا جایی بالا ببرید که حافظه اجازه می‌دهد — سواپ‌کردن بدتر از صف‌کشیدن است.

- **صف پذیرش.** net.core.somaxconn و backlog مربوط به listen شما تعیین می‌کنند چند اتصال می‌توانند منتظر پذیرفته‌شدن بمانند. یک backlog کوچک، یک هجوم قابل‌تحمل را به اتصالات ردشده تبدیل می‌کند.

- **کوکی‌های SYN.** net.ipv4.tcp_syncookies به کرنل اجازه می‌دهد به یک سیل SYN پاسخ دهد بدون اینکه برای اتصالاتی که هیچ‌وقت کامل نمی‌شوند حالتی تخصیص دهد. کرنل‌های مدرن آن را به‌صورت پیش‌فرض فعال می‌کنند؛ به‌جای فرض‌کردن، بررسی کنید، چون هیچ هزینه‌ای ندارد و شما را از رایج‌ترین سیلی که وجود دارد نجات می‌دهد.

- **توصیف‌گرهای فایل.** هر اتصال یک توصیف‌گر است. سقف پیش‌فرض nofile اغلب پایین‌تر از تعداد اتصالاتی است که سعی می‌کنید سرویس دهید، و حالت شکستش — accept هایی که شکست می‌خورند در حالی که همه‌چیز سالم به‌نظر می‌رسد — واقعاً ساعت سه بامداد گیج‌کننده است.

- **اتصالات پایگاه‌داده.** بالابردن شمار کارگرها بدون بالابردن استخر اتصال، فقط صف را به جایی می‌برد که دیدنش سخت‌تر است. این دو عدد باید با هم تنظیم شوند.

این‌ها را در یک روز آرام تنظیم کنید، نه حین یک رویداد. فایده دانستنشان این است که وقتی سایت از پا می‌افتد، می‌توانید به‌جای حدس‌زدن، دقیقاً نام سقفی را که به آن خورده بگویید — و سقفی که نامش را می‌دانید، سقفی است که رفع‌شدنی است.

## قراردادن چیزی جلوی سرور اصلی

هرچه تا این‌جا گفته شد، روی خود سرور اتفاق می‌افتد. قدم بعدی این است که تصمیم بگیرید آیا اصلاً باید خود سرور چیزی باشد که ترافیک را مستقیم دریافت می‌کند یا نه. سه گزینه صادقانه وجود دارد، و پاسخ درست خیلی بیشتر به چیزی بستگی دارد که هاست می‌کنید تا به چیزی که از پسِ هزینه‌اش برمی‌آیید.

| رویکرد | چه چیزی به شما می‌دهد | چه چیزی از شما می‌گیرد |
| --- | --- | --- |
| سرور اصلی مستقیم در معرض، اما سخت‌شده | سادگی، بدون شخص ثالث، بدون خاتمه TLS‌ای که کنترلش دست شما نیست | آدرس شما عمومی و دائمی است. لایه 7 کاملاً بر عهده خودتان است |
| یک CDN تجاری یا سرویس پالایش | ظرفیت جذب عظیم، یک صفحه چالش با یک کلیک، کش‌گذاری سراسری | یک ابیوز دسک با نظر خودش درباره محتوای شما، و شرکتی که می‌تواند ترافیک شما را ببیند. برای پروژه‌های آفشور یا حساس به DMCA، این می‌تواند ضعیف‌ترین حلقه در یک چیدمان در باقی موارد دقیق باشد |
| نود جلویی خودتان — یک VPS کوچک که nginx را اجرا می‌کند و به یک سرور اصلی محافظت‌شده با فایروال پراکسی می‌شود | کنترل کامل، بدون شخص ثالث در مسیر درخواست، آدرسی که می‌توانید بسوزانید و جایگزینش کنید، و یک آدرس واقعی که پنهان می‌ماند | سقف ظرفیت خودش، و یک دستگاه دیگر برای اجرا. دو یا سه نود جلویی در شبکه‌های مختلف، از‌کار‌انداختنش را به‌طرز معناداری سخت‌تر می‌کند |

نود جلویی خودمیزبان بیشتر از آن چیزی که معمولاً می‌گیرد توجه شایسته است، به‌خصوص برای هرکسی که هاستینگ آفشور را به دلایلی انتخاب کرده که یک CDN بزرگ ممکن است با آن‌ها همدلی نداشته باشد. الگو چندان جذاب نیست: نودهای پراکسی ارزان در جلو، سرور اصلی‌ای که با فایروال طوری تنظیم شده که فقط از آن نودها اتصال بپذیرد، و DNS‌ای که به سمت نودهای جلویی اشاره می‌کند. اگر یک نود جلویی مورد حمله قرار گیرد، آن را ظرف چند دقیقه با آدرسی تازه جایگزین می‌کنید و سرور اصلی اصلاً متوجه نمی‌شود. نسخه کامل این معماری — از‌جمله شش راهی که آدرس سرور اصلی در هر صورت لو می‌رود — موضوع راهنمای ما درباره [پنهان‌کردن IP سرور اصلی](https://servghost.com/fa/guides/hiding-your-origin-server-ip) است.

## یک سرور اصلی پنهان بیش از هر فیلتری ارزش دارد

ارزش دارد این را رک بگوییم، چون اولویت معمول را وارونه می‌کند: ارزان‌ترین اقدام مقابله با DDoS که در دسترس شماست، آدرسی است که مهاجم آن را ندارد. فیلترکردن کاری است که وقتی این یکی از قبل شکست خورده انجام می‌دهید.

این بیشتر از آن چیزی که به‌نظر می‌رسد اهمیت دارد، چون آدرس‌های سرور اصلی دائماً و بی‌سروصدا لو می‌روند. رکوردهای تاریخی DNS از قبل از اینکه یک پراکسی جلویش بگذارید، سال‌ها بعد از آن تغییر هم باقی می‌مانند. ایمیلی که مستقیم از اپلیکیشن ارسال می‌شود، آدرس را در هدرهای خودش حمل می‌کند. یک گواهی TLS که روی آدرس خام صادر شده، برای همیشه در لاگ‌های شفافیت گواهی منتشر می‌شود. یک صفحه خطا، یک ریدایرکت، یا یک زیردامنه گمنام که هیچ‌وقت پشت پراکسی نبوده، همگی لورفتنش را رقم می‌زنند. اگر یک CDN را جلوی سروری گذاشته‌اید که قبلاً در معرض بوده، فرض کنید آدرس قدیمی شناخته‌شده است تا وقتی که خودتان تغییرش داده باشید.

**نتیجه منطقی‌اش یک قانون فایروال است، و همین باارزش‌ترین خط تک در کل این راهنماست:** به‌محض اینکه چیزی جلو نشست، سرور اصلی باید اتصالات روی پورت‌های 80 و 443 را از هر چیزی به‌جز آدرس‌های همان نود جلویی رد کند. بدون این، پراکسی فقط یک پیشنهاد است — هرکسی که آدرس واقعی را کشف کند به‌سادگی از کنارش رد می‌شود و مستقیم به شما حمله می‌کند، و هرچه در جلو پیکربندی کرده‌اید تزئینی می‌شود.

## انتخاب سخت‌افزار و لوکیشن، طوری که حمله‌ها کسل‌کننده بمانند

بخشی از این ماجرا پیش از آنکه اصلاً حمله‌ای رخ دهد تصمیم‌گیری می‌شود، همان لحظه‌ای که یک پلن را انتخاب می‌کنید. سه ویژگی خیلی بیشتر از آنچه برگه مشخصات نشان می‌دهد اهمیت دارند:

- **پهنای باند نامحدود.** در یک پلن سهمیه‌ای، یک حمله فقط یک قطعی نیست — یک صورت‌حساب هم هست. ترافیکی که هیچ‌وقت نخواستید و نمی‌توانستید ردش کنید، باز هم از سهمیه شما کم می‌شود. انتقال نامحدود یک ریسک مالی را به یک ریسک کاملاً فنی تبدیل می‌کند، که رده بسیار بهتری از مشکل است.

- **اینکه آیا پورت مال خودتان است یا نه.** روی یک هاست مجازی‌سازی‌شده مشترک، همسایه‌ای که مورد حمله است می‌تواند شما را هم تحت‌تأثیر قرار دهد، و سقف محافظتی خودتان هم مشترک است. [سخت‌افزار اختصاصی](https://servghost.com/fa/dedicated) با پورت مخصوص به خودش، هر دو اثر را از بین می‌برد. برای پروژه‌ای که انتظار توجه خصمانه دارد، این روشن‌ترین دلیل برای ارتقا از یک [VPS](https://servghost.com/fa/vps) است — بیشتر از هسته یا RAM.

- **شبکه کجا نشسته است.** یک شبکه اروپایی با اتصال خوب و ظرفیت ترانزیت واقعی، سیلی را جذب می‌کند که یک شبکه با پیرینگ ضعیف جذبش نمی‌کند، و حوزه قضایی‌ای که به دلایل حقوقی انتخاب کرده‌اید هم ویژگی‌های شبکه‌ای خودش را دارد. ارزش دارد هنگام انتخاب از میان [لوکیشن‌های](https://servghost.com/fa/locations) موجود، هر دو را بررسی کنید.

یک استدلال مقیاسی هم هست که بی‌سروصدا به نفع سادگی است. یک سایت ایستا پشت یک کش روی یک سرور معمولی، به‌طرز خارق‌العاده‌ای از‌کار‌انداختنش سخت است؛ همان محتوا روی یک CMS سنگین با یک اندپوینت جست‌وجوی کش‌نشده، می‌تواند با یک اسکریپت به دست یک فرد مصمم شکسته شود. کم‌کردن چیزهای پویا خودش یک اقدام مقابله‌ای است، و رایگان هم هست. اگر پروژه شما واقعاً زیر بار پیوسته زندگی می‌کند، یادداشت‌های ما درباره [هاستینگ با ترافیک بالا](https://servghost.com/fa/use-cases/high-traffic-hosting) جنبه اندازه‌گیری همین پرسش را پوشش می‌دهند.

## پنج کاری که نباید انجام دهید

الگوهای شکست این‌جا آن‌قدر ثابت‌اند که بشود فهرستشان کرد، و هرکدام برای یک نفر یک آخر هفته هزینه داشته‌اند:

- **خودتان را بلک‌هول نکنید.** بلک‌هول‌کردن آدرس خودتان، به معنای واقعی کلمه به حمله پایان می‌دهد — هیچ‌کس نمی‌تواند به شما برسد، حتی کاربران خودتان. این ابزاری برای آخرین چاره در دست ارائه‌دهنده شماست، نه اقدامی که خودتان داوطلبانه انجام می‌دهید.

- **fail2ban را محافظت DDoS تلقی نکنید.** این ابزار خوبی است در برابر تلاش‌های brute-force از چند آدرس معدود. اما در برابر یک سیل توزیع‌شده، ظرف چند دقیقه به چیزی واکنش نشان می‌دهد که در چند ثانیه می‌رسد، و قانونی که هزاران آدرس را مسدود می‌کند می‌تواند در پردازش فایروال هزینه‌ای بیشتر از خود حمله رویتان بگذارد.

- **باج ندهید.** اکثریت قریب‌به‌اتفاق ایمیل‌های اخاذی که تهدید به یک حمله فاجعه‌بار می‌کنند، از افرادی می‌آیند که هیچ توانایی‌ای ندارند و هزاران پیام یکسان می‌فرستند. آن اقلیت کوچکی هم که می‌توانند عملی‌اش کنند، دوباره برمی‌گردند، چون ثابت کرده‌اید که پرداخت می‌کنید.

- **تلافی نکنید.** جدا از اینکه تقریباً همه‌جا غیرقانونی است، منابع حمله اشخاص ثالث نفوذشده‌اند. در واقع دارید به قربانی‌ها حمله می‌کنید، آن‌هم از آدرسی که بدون ابهام مال خودتان است.

- **در وحشت مهاجرت نکنید.** جابه‌جاکردن هاست وسط یک حمله یعنی آدرس جدید ظرف چند دقیقه عمومی می‌شود و شما هیچ پیکربندی کارآمدی ندارید. اول ثبات پیدا کنید، بعد با تأمل جابه‌جا شوید — و اگر واقعاً جابه‌جا می‌شوید، راهنمای ما درباره [مهاجرت بدون قطعی](https://servghost.com/fa/guides/migrate-website-to-offshore-hosting) دقیقاً برای همین وجود دارد تا خود جابه‌جایی به یک رویداد دوم تبدیل نشود.

## نسخه کوتاه

بدون استدلال‌هایش، مدل کاری در هشت خط جا می‌شود:

- **اول دسته‌بندی کنید.** اینترفیس اشباع یعنی حجمی و مال هاست شماست. اینترفیس آرام با کارگرهای ته‌کشیده یعنی لایه 7 و مال خودتان است.

- **برای حجمی، یک تیکت ثبت کنید** با آدرس، برچسب زمانی و شمارنده‌های خودتان — بعد دست از دست‌زدن به سرور بردارید.

- **برای بازدیدکنندگان ناشناس تهاجمی کش کنید،** زیر فشار محتوای قدیمی تحویل دهید، و میس‌های تکراری را ادغام کنید. این پراهرم‌ترین تغییری است که می‌توانید انجام دهید.

- **هم بر اساس نرخ درخواست و هم بر اساس همزمانی محدودیت نرخ بگذارید،** تنگ‌ترین آن روی اندپوینت‌هایی که بیشترین هزینه را دارند، و 429 برگردانید.

- **پیش از هر چیز دیگری پیکربندی real-IP خودتان را درست کنید،** وگرنه هر محدودیت به‌ازای هر کلاینت پشت یک پراکسی، یا بی‌فایده است یا فاجعه‌بار.

- **سقف‌های خودتان را بشناسید** — کارگرها، backlog، توصیف‌گرها، اتصالات پایگاه‌داده — و آن‌ها را در یک روز آرام و با تأمل بالا ببرید.

- **آدرس سرور اصلی را مخفی و با فایروال محدود به نودهای جلویی خودتان نگه دارید.** این بیش از تمام فیلترها روی هم ارزش دارد.

- **پهنای باند نامحدود بخرید** تا ترافیکی که نخواسته‌اید هیچ‌وقت یک صورت‌حساب هم نباشد.

هیچ‌کدام از این‌ها شما را مصون نمی‌کند، و هرکسی که مصونیت می‌فروشد دارد چیز دیگری می‌فروشد. کاری که این‌ها می‌کنند این است که شما را از جمعیتی که با یک نوجوان بی‌حوصله از مدار خارج می‌شود بیرون می‌آورند و به جمعیتی می‌برند که برای مختل‌کردنش به منابع واقعی و قصد واقعی نیاز است — که برای اکثریت قریب‌به‌اتفاق پروژه‌ها، عملاً از امن‌بودن قابل‌تشخیص نیست. بقیه‌اش همان کار بی‌زرق‌وبرقی است که سرور را در همه‌چیز دیگر هم خوب می‌کند: [در همان روز اول سخت‌شده](https://servghost.com/fa/guides/first-hour-vps-hardening-checklist)، [در بدترین روز قابل‌بازیابی](https://servghost.com/fa/guides/vps-backup-strategy)، و جایی در حال اجرا که با ترافیک شما مثل کسب‌وکار خودتان رفتار می‌کند.





سؤالات متداول

## DDoS روی یک سرور کوچک — پرسش‌های رایج





### 01
آیا «محافظت DDoS شامل می‌شود» یعنی در برابر همه‌چیز امن هستم؟



خیر، و این شکاف مبهم نیست بلکه دقیق است. محافظت شامل‌شده، فیلترینگ در لایه شبکه است: سیل‌های حجمی — سیل SYN، تقویت UDP، طوفان‌های بسته خام — را در بالادست، پیش از رسیدن به پورت شما، حذف می‌کند. این همان دسته‌ای است که واقعاً به‌تنهایی از پسش برنمی‌آیید، پس شامل‌کردنش کار درستی است. اما این محافظت اپلیکیشن شما را بازرسی نمی‌کند، پس یک سیل HTTP با چند هزار درخواست در ثانیه علیه یک اندپوینت پرهزینه، دست‌نخورده از آن عبور می‌کند و سایت شما را از کار می‌اندازد در حالی که همه نمودارهای شبکه عادی به‌نظر می‌رسند. لایه 7 پیکربندی‌ای است که خودتان مالکش هستید: کش‌گذاری، محدودیت نرخ و سقف اتصال.





### 02
چطور یک حمله DDoS را از یک جهش ترافیکی تشخیص دهم؟



از خودتان بپرسید آیا این ترافیک چیزی می‌خواهد. بازدیدکننده‌های واقعی، حتی سیل ناگهانی‌شان از یک لینک پرطرفدار، صفحاتی را درخواست می‌کنند که وجود دارند، منابع همان صفحات را بارگذاری می‌کنند، با رفررهای قابل‌قبول می‌رسند و در الگویی طبیعی روی شبکه‌های زیادی پخش می‌شوند. یک حمله معمولاً روی یک مسیر می‌کوبد، منابع را نادیده می‌گیرد، user-agent های نامحتمل یا خالی می‌فرستد، و توزیعی نشان می‌دهد که مصنوعی به‌نظر می‌رسد. access log خودتان را برای درخواست به ازای هر آدرس کلاینت و هر مسیر بررسی کنید: اگر یک اندپوینت غالب است و هیچ‌چیز دیگری بارگذاری نمی‌شود، این یک حمله است. اگر همان صفحاتی که یک انسان می‌خواهد سرویس داده می‌شوند و رفررهایتان واقعی‌اند، شما یک مشکل ظرفیت با یک دلیل خوشحال‌کننده دارید.





### 03
مؤثرترین کاری که می‌توانم حین حمله انجام دهم چیست؟



کش‌گذاری کامل صفحه را برای بازدیدکنندگان ناشناس روشن کنید و آن را طوری پیکربندی کنید که وقتی بک‌اند در حال دست‌وپنجه نرم‌کردن است، محتوای قدیمی تحویل دهد. یک محدودیت نرخ کار را رد می‌کند؛ یک کش کاری می‌کند که آن کار اصلاً وجود نداشته باشد. درخواستی که یک کوئری پایگاه‌داده، رندر یک قالب و یک کارگر اپلیکیشن هزینه داشت، تبدیل به خواندن یک فایل می‌شود، و همان سخت‌افزاری که در چند صد درخواست پویا در ثانیه فروریخت، ده‌ها هزار درخواست کش‌شده را سرویس می‌دهد. این تنها اقدام در این فهرست هم هست که دقیقاً به همان اندازه علیه ترافیک واقعی هم کمک می‌کند، پس برخلاف یک محدودیت نرخ، نمی‌تواند به کاربران خودتان آسیب برگرداند.





### 04
چرا محدودیت نرخ nginx من بعد از قراردادن یک CDN جلوی سرور، از کار افتاد؟



چون حالا هر درخواست از آدرس CDN می‌رسد، نه آدرس بازدیدکننده، پس یک محدودیت به‌ازای هر کلاینت دارد کل اینترنت را یک کلاینت واحد حساب می‌کند. بسته به آستانه، یا هیچ‌وقت فعال نمی‌شود یا کل ترافیک شما را یک‌جا مسدود می‌کند. منبع real-IP خودتان را پیکربندی کنید — در nginx، بازه‌های پراکسی مورد اعتماد به‌همراه هدری که پراکسی ارسال می‌کند — تا محدودیت دوباره بر اساس بازدیدکننده واقعی کلید بخورد. آن اعتماد را فقط به بازه‌های خود پراکسی محدود کنید: اگر یک هدر ارسالی از سمت کلاینت را از اینترنت باز بپذیرید، مهاجم می‌تواند در هر درخواست یک هویت تازه جعل کند و از هر محدودیتی که دارید عبور کند.





### 05
آیا fail2ban برای متوقف‌کردن یک حمله DDoS کافی است؟



خیر. fail2ban لاگ‌ها را با یک بازه زمانی می‌خواند و آدرس‌های خاطی را بعد از یک آستانه مسدود می‌کند، که برای تلاش‌های brute-force از چند منبع معدود مناسب است. یک حمله توزیع‌شده ظرف چند ثانیه از هزاران آدرس می‌رسد که هرکدام فقط چند درخواست می‌فرستند، پس آن آستانه هیچ‌وقت لمس نمی‌شود و زمان واکنش هم در هر صورت خیلی کند است. بدتر اینکه، مجموعه‌قوانینی که تا ده‌ها هزار ورودی رشد کند، می‌تواند منابع بیشتری از خود حمله مصرف کند. آن را برای SSH و اندپوینت‌های لاگین نگه دارید، و سیل‌ها را با کش‌گذاری، محدودیت نرخ و یک فیلتر بالادستی مدیریت کنید.





### 06
باید از یک CDN استفاده کنم یا ریورس پراکسی خودم را جلوی سرور اجرا کنم؟



این بیشتر به چیزی که هاست می‌کنید بستگی دارد تا به بودجه‌تان. یک CDN تجاری ظرفیت جذبی می‌آورد که نمی‌توانید با آن برابری کنید و یک صفحه چالش را یک کلیک آن‌طرف‌تر می‌گذارد، اما ابیوز دسک آن را هم به ارث می‌برید و می‌تواند ترافیک شما را ببیند — که برای پروژه‌های آفشور یا حساس به DMCA، اغلب ضعیف‌ترین حلقه در یک چیدمان در باقی موارد دقیق است. نودهای جلویی خودتان کار بیشتری می‌برند و سقف ظرفیت واقعی دارند، اما هیچ شخص ثالثی در مسیر درخواست نیست و نودی که مورد حمله قرار می‌گیرد را می‌توانید ظرف چند دقیقه با آدرسی تازه جایگزین کنید. در هر دو حالت، سرور اصلی باید با فایروال طوری تنظیم شود که ترافیک وب را فقط از نود جلویی بپذیرد، وگرنه کل چیدمان تزئینی است.





### 07
آیا یک حمله علاوه بر آپ‌تایم، برایم هزینه مالی هم دارد؟



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





### 08
آیا انتقال به یک هاست آفشور یا بدون KYC، احتمال حمله را بیشتر می‌کند؟



انتخاب هاست خودش خنثی است؛ چیزی که اجرا می‌کنید همان چیزی است که توجه جلب می‌کند. سرورهای بازی، فروم‌ها، استریمینگ، بازارها و هرچیزی که رقیب یا کینه‌ای دارد، صرف‌نظر از حوزه قضایی، حمله جذب می‌کند. چیزی که واقعاً آفشور تغییر می‌کند، راه‌چاره شماست: احتمال کمتری دارد که به‌خاطر «مزاحم‌بودن» کنار گذاشته شوید، که این خودش دو لبه دارد — محافظت فنی است نه قراردادی. لوکیشنی با ظرفیت ترانزیت واقعی انتخاب کنید، پهنای باند نامحدود بگیرید، آدرس سرور اصلی را پنهان نگه دارید، و لایه 7 را از همان روز اول مسئولیت خودتان بدانید، نه از اولین رویداد.




راهنماهای مرتبط

## ادامه مطلب


[### چطور در سال 2026 یک حوزه قضایی آفشور برای میزبانی انتخاب کنید

خرید


یک چارچوب تصمیم‌گیری عملی برای انتخاب حوزه قضایی آفشور: قانون نگهداری داده، قرارداد MLAT، موضع درباره DMCA، سرعت رسیدگی دادگاه و اجرای واقعی — کشور به کشور.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/choosing-an-offshore-jurisdiction)
[### VPS در مقابل سرور اختصاصی برای بارهای کاری حساس به حریم خصوصی

خرید


چه زمانی VPS کافی است، چه زمانی اشتراک در منابع یک خطر امنیتی است، و چه زمانی bare-metal تنها پاسخ صادقانه است. ایزولاسیون سخت‌افزاری، ریسک هایپروایزر، و هزینه در برابر مدل تهدید.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/vps-vs-dedicated-for-privacy)
[### VPN خودمیزبان روی VPS بدون KYC: WireGuard در مقابل OpenVPN

عملیات


چرا VPN خودمیزبان از ارائه‌دهندگان تجاری بهتر است، و WireGuard و OpenVPN واقعاً از نظر حریم خصوصی، عملکرد و ریسک عملیاتی در سال 2026 چگونه مقایسه می‌شوند.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 در مقابل H100 SXM5 برای استنتاج هوش مصنوعی (و جایگاه RTX 5090)

خرید


راهنمای خرید: کدام GPU از NVIDIA برای بارهای کاری LLM سلف‌هاست، تصویر، ویدیو، صدا و تنظیم دقیق در ۲۰۲۶. RTX 4090 در مقابل RTX 5090 در مقابل H100 SXM5 در مقابل دو H100 — VRAM، توان عملیاتی، $/توکن، و برتری هر کدام.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP ویندوز آفشور برای معاملات Forex با MT4 / MT5 / cTrader

عملیات


راهنمای کامل: چرا به Windows RDP برای معاملات Forex نیاز دارید، چگونه یک حوزه قضایی آفشور با تأخیر کم انتخاب کنید، راه‌اندازی MT4 / MT5 / cTrader / Expert Advisor، تأخیر تا سرورهای کارگزار، و مسیر پرداخت بدون KYC.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/offshore-windows-rdp-for-forex-trading)
[### میزبانی DMCA-Ignored توضیح داده شد: معنای واقعی آن در 2026

خرید


میزبانی «DMCA ignored» واقعاً چه چیزی به شما می‌دهد، کدام حوزه‌های قضایی واقعاً از آن پشتیبانی می‌کنند، چه بارهای کاری به آن نیاز دارند، و دام‌های حق مؤلفی که این اصطلاح پوشش نمی‌دهد.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/dmca-ignored-hosting-explained)
[### ثبت دامنه ناشناس با ارز دیجیتال: حریم خصوصی WHOIS در 2026

حریم خصوصی


راهنمای عملی 2026 برای ثبت دامنه بدون افشای هویت: رژیم‌های WHOIS بر اساس TLD، انتخاب رجیسترار، گزینه‌های پرداخت با ارز دیجیتال، و اشتباهات عملیاتی که هویت شما را لو می‌دهند.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/anonymous-domain-registration-with-crypto)
[### پرداخت‌های کریپتو برای هاستینگ: Monero در مقابل Bitcoin در مقابل USDT

حریم خصوصی


چگونه انتخاب ارز پرداخت تأثیر می‌گذارد که هاست شما چه چیزی درباره‌تان می‌داند. حریم خصوصی، کارمزدها، قطعیت تراکنش و میزان افشاگری در تحلیل زنجیره برای XMR، BTC و USDT — با یک توصیه صریح.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### آیا هاستینگ آفشور واقعاً ناشناس است؟ یک پاسخ صادقانه

حریم خصوصی


هاستینگ آفشور و بدون KYC هویتی را که یک هاست معمولی جمع‌آوری می‌کند حذف می‌کند — اما «ناشناس‌بودن» به پرداخت، لاگ‌گیری ارائه‌دهنده و امنیت عملیاتی (opsec) خودتان بستگی دارد. در ادامه می‌بینید واقعاً چه چیزی قابل ردیابی است.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/is-offshore-hosting-truly-anonymous)
[### ساعت اول سخت‌سازی VPS: یک چک‌لیست

عملیات


یک چک‌لیست مشخص و مرحله‌به‌مرحله برای ایمن‌سازی یک VPS تازه در کمتر از یک ساعت: کلیدهای SSH، یک فایروال، fail2ban، به‌روزرسانی‌های خودکار، و کاهش سطح حمله که جلوی بیشتر حملات فرصت‌طلبانه را می‌گیرد.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/first-hour-vps-hardening-checklist)
[### What Is No-KYC Hosting? Definition, Legality & How It Works

حریم خصوصی


No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/what-is-no-kyc-hosting)
[### Is Offshore Hosting Legal? The Honest 2026 Answer

خرید


Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/is-offshore-hosting-legal)
[### How to Pay for Hosting with Monero (XMR) — Step by Step

حریم خصوصی


A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/how-to-pay-for-hosting-with-monero)
[### How to Host a Website Anonymously — A Practical 2026 Guide

حریم خصوصی


A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/how-to-host-a-website-anonymously)
[### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide

عملیات


Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### How to Self-Host an LLM on a GPU Server — 2026 Guide

عملیات


Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — What Is the Difference?

خرید


Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/bulletproof-vs-offshore-hosting)
[### How to Buy a VPS with Bitcoin — Step-by-Step (2026)

خرید


A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/how-to-buy-a-vps-with-bitcoin)
[### Best Countries for DMCA-Ignored Hosting in 2026

خرید


Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/best-countries-for-dmca-ignored-hosting)
[### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide

عملیات


Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/how-to-host-a-tor-hidden-service)
[### Offshore Mail Server Setup — Self-Host Private Email in 2026

عملیات


Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/offshore-mail-server-setup)
[### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS

عملیات


How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/crypto-node-hosting-guide)
[### GPU Hosting for Stable Diffusion — Run Your Own Image Server

عملیات


Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Staying Anonymous When You Run a Server

حریم خصوصی


Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/server-opsec-staying-anonymous)
[### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026

عملیات


How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/seedbox-setup-guide)
[### How to Bypass DPI Censorship with Your Own VPS (2026 Guide)

حریم خصوصی


Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough.


سؤالات متداول 6‌گانه](https://servghost.com/fa/guides/bypass-dpi-censorship-with-your-own-vps)
[### رمزگذاری کامل دیسک روی VPS: راه‌اندازی LUKS و محافظت واقعی آن

عملیات


چگونه یک VPS را با LUKS رمزگذاری کنید: حجم‌های داده‌ی رمزشده، رمزگذاری کامل روت با بازکردن قفل از راه دور روی SSH، تنظیماتی که روی سرور کوچک اهمیت دارند، و توضیحی صادقانه از آنچه رمزگذاری دیسک واقعاً متوقف می‌کند.


سؤالات متداول 8‌گانه](https://servghost.com/fa/guides/full-disk-encryption-on-a-vps)
[### پنهان‌کردن IP سرور مبدأ: CDN، پراکسی معکوس و آنچه هنوز لو می‌رود

حریم خصوصی


اینکه آیا باید CDN را جلوی یک سرور آفشور گذاشت: چه چیزی را پنهان می‌کند، چه دفتر شکایاتی به ارث می‌رسد، شش راهی که IP مبدأ باز هم لو می‌رود، و چگونه IP خودتان را بررسی کنید.


سؤالات متداول 8‌گانه](https://servghost.com/fa/guides/hiding-your-origin-server-ip)
[### استراتژی بکاپ VPS: رمزنگاری‌شده، آفشور و واقعاً قابل بازیابی

عملیات


هاست شما بکاپی نگه نمی‌دارد. چه چیزی واقعاً سرورها را نابود می‌کند، چرا بکاپ پوش با سرور از بین می‌رود، مقایسه restic و Borg، کلیدهای فراموش‌شده، و روش تست بازیابی.


سؤالات متداول 8‌گانه](https://servghost.com/fa/guides/vps-backup-strategy)
[### راه‌اندازی سرور Matrix: فدراسیون، متادیتا و آنچه رمزگذاری پنهان نمی‌کند

عملیات


هوم‌سرور Matrix شخصی واقعاً چه می‌دهد: Synapse در برابر Conduit، server_name‌ای که هرگز تغییر نمی‌کند، رسانه‌ای که دیسک را پر می‌کند، و آنچه فدراسیون هنوز آشکار می‌کند.


سؤالات متداول 8‌گانه](https://servghost.com/fa/guides/self-host-a-matrix-server)
[### چطور یک وب‌سایت را بدون قطعی به هاست آفشور مهاجرت دهیم

عملیات


ترتیبی که مهاجرت هاست را کسل‌کننده می‌کند: کاهش TTL رکورد DNS چند روز پیش از موعد، اجرای هم‌زمان هر دو سرور، توقف نوشتن برای چند دقیقه به‌جای چند ساعت — و پاک‌سازی ردی که این جابه‌جایی در Passive DNS، لاگ‌های Certificate Transparency و WHOIS از خود به‌جا می‌گذارد.


سؤالات متداول 8‌گانه](https://servghost.com/fa/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‌گانه](https://servghost.com/fa/guides/self-host-a-crypto-payment-gateway)




## آن را جایی بگذارید که سیل‌ها را فیلتر می‌کند



سرورهای KVM آفشور در هفت حوزه قضایی با فیلترینگ DDoS در لایه L3/L4، پهنای باند نامحدود، روت کامل و ذخیره‌سازی NVMe. بدون KYC، پرداخت با ارز دیجیتال، چند دقیقه پس از تأیید تراکنش راه‌اندازی می‌شود.


[مشاهده پلن‌های VPS](https://servghost.com/fa/vps)
[سرورهای اختصاصی](https://servghost.com/fa/dedicated)
[Offshore Hosting](https://servghost.com/fa/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": "VPS آفشور و سرورهای اختصاصی در 7 حوزه قضایی آفشور. بدون 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": "محافظت DDoS از VPS: جایی که هاست تمام می‌شود و لایه 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": "fa",
    "keywords": "محافظت DDoS از VPS, جلوگیری از حمله DDoS روی سرور, مقابله با حمله لایه 7, محدودسازی نرخ nginx در برابر DDoS, هاستینگ آفشور با محافظت DDoS, فیلترینگ DDoS در لایه L3 L4, جلوگیری از سیل SYN, پنهان‌کردن IP سرور اصلی",
    "articleSection": "عملیات",
    "wordCount": 4278
}
```

```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": "از خودتان بپرسید آیا این ترافیک چیزی می‌خواهد. بازدیدکننده‌های واقعی، حتی سیل ناگهانی‌شان از یک لینک پرطرفدار، صفحاتی را درخواست می‌کنند که وجود دارند، منابع همان صفحات را بارگذاری می‌کنند، با رفررهای قابل‌قبول می‌رسند و در الگویی طبیعی روی شبکه‌های زیادی پخش می‌شوند. یک حمله معمولاً روی یک مسیر می‌کوبد، منابع را نادیده می‌گیرد، user-agent های نامحتمل یا خالی می‌فرستد، و توزیعی نشان می‌دهد که مصنوعی به‌نظر می‌رسد. access log خودتان را برای درخواست به ازای هر آدرس کلاینت و هر مسیر بررسی کنید: اگر یک اندپوینت غالب است و هیچ‌چیز دیگری بارگذاری نمی‌شود، این یک حمله است. اگر همان صفحاتی که یک انسان می‌خواهد سرویس داده می‌شوند و رفررهایتان واقعی‌اند، شما یک مشکل ظرفیت با یک دلیل خوشحال‌کننده دارید."
            }
        },
        {
            "@type": "Question",
            "name": "مؤثرترین کاری که می‌توانم حین حمله انجام دهم چیست؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "کش‌گذاری کامل صفحه را برای بازدیدکنندگان ناشناس روشن کنید و آن را طوری پیکربندی کنید که وقتی بک‌اند در حال دست‌وپنجه نرم‌کردن است، محتوای قدیمی تحویل دهد. یک محدودیت نرخ کار را رد می‌کند؛ یک کش کاری می‌کند که آن کار اصلاً وجود نداشته باشد. درخواستی که یک کوئری پایگاه‌داده، رندر یک قالب و یک کارگر اپلیکیشن هزینه داشت، تبدیل به خواندن یک فایل می‌شود، و همان سخت‌افزاری که در چند صد درخواست پویا در ثانیه فروریخت، ده‌ها هزار درخواست کش‌شده را سرویس می‌دهد. این تنها اقدام در این فهرست هم هست که دقیقاً به همان اندازه علیه ترافیک واقعی هم کمک می‌کند، پس برخلاف یک محدودیت نرخ، نمی‌تواند به کاربران خودتان آسیب برگرداند."
            }
        },
        {
            "@type": "Question",
            "name": "چرا محدودیت نرخ nginx من بعد از قراردادن یک CDN جلوی سرور، از کار افتاد؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "چون حالا هر درخواست از آدرس CDN می‌رسد، نه آدرس بازدیدکننده، پس یک محدودیت به‌ازای هر کلاینت دارد کل اینترنت را یک کلاینت واحد حساب می‌کند. بسته به آستانه، یا هیچ‌وقت فعال نمی‌شود یا کل ترافیک شما را یک‌جا مسدود می‌کند. منبع real-IP خودتان را پیکربندی کنید — در nginx، بازه‌های پراکسی مورد اعتماد به‌همراه هدری که پراکسی ارسال می‌کند — تا محدودیت دوباره بر اساس بازدیدکننده واقعی کلید بخورد. آن اعتماد را فقط به بازه‌های خود پراکسی محدود کنید: اگر یک هدر ارسالی از سمت کلاینت را از اینترنت باز بپذیرید، مهاجم می‌تواند در هر درخواست یک هویت تازه جعل کند و از هر محدودیتی که دارید عبور کند."
            }
        },
        {
            "@type": "Question",
            "name": "آیا fail2ban برای متوقف‌کردن یک حمله DDoS کافی است؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "خیر. fail2ban لاگ‌ها را با یک بازه زمانی می‌خواند و آدرس‌های خاطی را بعد از یک آستانه مسدود می‌کند، که برای تلاش‌های brute-force از چند منبع معدود مناسب است. یک حمله توزیع‌شده ظرف چند ثانیه از هزاران آدرس می‌رسد که هرکدام فقط چند درخواست می‌فرستند، پس آن آستانه هیچ‌وقت لمس نمی‌شود و زمان واکنش هم در هر صورت خیلی کند است. بدتر اینکه، مجموعه‌قوانینی که تا ده‌ها هزار ورودی رشد کند، می‌تواند منابع بیشتری از خود حمله مصرف کند. آن را برای 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/fa/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "راهنماهای میزبانی با حریم خصوصی",
            "item": "https://servghost.com/fa/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "محافظت DDoS از VPS: جایی که هاست تمام می‌شود و لایه 7 آغاز می‌شود",
            "item": "https://servghost.com/fa/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```