[Beranda](https://servghost.com/id) /
[Privasi Hosting Guides](https://servghost.com/id/guides) /
Perlindungan DDoS VPS: Batas Host Anda, Awal Layer 7






Operasional


# Bertahan dari Serangan DDoS di VPS Anda



Setiap paket hosting mengklaim "perlindungan DDoS termasuk", dan semuanya berarti hal sempit yang sama: network menyerap banjir yang diukur dalam gigabit. Serangan yang sungguh-sungguh menjatuhkan situs kecil diukur dalam permintaan per detik, nyaris tidak berbiaya apa pun bagi penyerang, dan datang dengan tampilan yang sepenuhnya sah. Panduan ini menarik garis batas antara keduanya, menunjukkan cara mengenali dalam satu menit Anda berada di sisi yang mana, dan membahas apa yang sungguh-sungguh bertahan di sisi garis yang menjadi tanggung jawab Anda.


[Baca panduan](#guide-body)
[FAQ](#guide-faq)






## Di halaman ini




- [Panduan](#guide-body)

- [FAQ](#guide-faq)

- [Panduan terkait](#guide-related)

- [Halaman yang direkomendasikan](#guide-cta)






Tanpa KYC
Hanya Kripto
Tanpa Log
DMCA Diabaikan
Root penuh
NVMe SSD





25 mnt baca
Diperbarui Sep 2026

Di halaman ini

[01Dua serangan berbeda yang berbagi satu nama](#dua-serangan-berbeda-yang-berbagi-satu-nama)
[02Apa yang sebenarnya Anda dapatkan dari "perlindungan DDoS termasuk"](#apa-yang-sebenarnya-anda-dapatkan-dari-perlindungan-ddos-ter)
[03Pertama, pastikan dulu apakah ini benar-benar serangan](#pertama-pastikan-dulu-apakah-ini-benar-benar-serangan)
[04Membaca serangan langsung dari server](#membaca-serangan-langsung-dari-server)
[05Sepuluh menit pertama](#sepuluh-menit-pertama)
[06Rate limit yang benar-benar efektif, dan kesalahan yang dilakukan semua orang](#rate-limit-yang-benar-benar-efektif-dan-kesalahan-yang-dilak)
[07Caching adalah mitigasi termurah yang pernah bisa Anda terapkan](#caching-adalah-mitigasi-termurah-yang-pernah-bisa-anda-terap)
[08Batas atas yang menentukan apakah Anda akan tumbang](#batas-atas-yang-menentukan-apakah-anda-akan-tumbang)
[09Memasang sesuatu di depan origin](#memasang-sesuatu-di-depan-origin)
[10Origin yang tersembunyi lebih berharga daripada filter apa pun](#origin-yang-tersembunyi-lebih-berharga-daripada-filter-apa-p)
[11Memilih hardware dan lokasi agar serangan tetap membosankan](#memilih-hardware-dan-lokasi-agar-serangan-tetap-membosankan)
[12Lima hal yang jangan dilakukan](#lima-hal-yang-jangan-dilakukan)
[13Versi singkatnya](#versi-singkatnya)
[FAQPertanyaan umum](#guide-faq)
[→Halaman yang direkomendasikan](#guide-cta)







Ada dua momen ketika orang benar-benar memahami cara kerja mitigasi DDoS. Yang pertama terjadi dengan tenang, saat membeli, membaca daftar fitur yang bertuliskan "perlindungan DDoS termasuk" dan diam-diam beranggapan kalimat itu mencakup segalanya. Yang kedua terjadi pukul tiga pagi, ketika situsnya down, grafiknya terlihat salah dengan cara yang tidak masuk akal, dan perlindungan yang sudah termasuk itu — secara tepat, dan memang sesuai desainnya — sama sekali tidak melakukan apa-apa.

Kedua momen itu melibatkan produk yang sama dan kebenaran yang sama: sebuah hosting provider menyaring serangan yang datang sebagai volume mentah, karena merekalah yang memiliki pipa tempat paket-paket itu mengalir, bukan Anda. Ia tidak bisa menyaring serangan yang datang sebagai permintaan yang tampak biasa saja, karena dari sudut pandang network, itu memang permintaan yang tampak biasa saja. Garis itu — antara banjir yang diserap host Anda dan banjir yang harus Anda selamatkan sendiri — adalah keseluruhan inti pembahasan ini. Semua yang ada di bawah ini adalah soal mencari tahu di sisi mana Anda berada, dan apa yang harus dilakukan pada masing-masing sisi.

## Dua serangan berbeda yang berbagi satu nama

"DDoS" adalah satu kata yang mencakup dua masalah yang nyaris tidak punya kesamaan apa pun kecuali akibatnya. Keduanya dihentikan di tempat yang berbeda, oleh pihak yang berbeda, dengan alat yang berbeda, dan kerancuan antara keduanya adalah alasan mengapa begitu banyak upaya mitigasi salah sasaran ke lapisan yang keliru.

| | Volumetrik — layer 3 dan 4 | Aplikasi — layer 7 |
| --- | --- | --- |
| Apa yang datang | SYN flood, UDP amplification lewat reflector DNS, NTP atau memcached yang terbuka, ACK flood, paket sampah biasa | Permintaan HTTP biasa: GET flood, POST flood, slow-loris, query string cache-busting |
| Diukur dalam | Gigabit dan jutaan paket per detik | Permintaan per detik — sering kali hanya beberapa ribu |
| Bandwidth yang dibutuhkan untuk melukai Anda | Sangat besar. Ini adalah kontes kapasitas | Nyaris tidak ada. Satu laptop saja bisa melakukannya jika endpoint-nya cukup mahal |
| Di mana ia harus dihentikan | **Upstream, oleh provider Anda.** Begitu paket sampai ke port Anda, kerusakannya sudah terjadi | **Di server Anda, oleh Anda sendiri**, atau di proxy yang Anda kendalikan di depannya |
| Seperti apa tampilannya di server | Interface jenuh, penghitung paket tidak masuk akal, CPU bisa saja idle | Bandwidth biasa saja, tapi setiap worker sibuk, load naik, antrean database membesar |
| Siapa yang memperbaikinya | Scrubbing dari host Anda, otomatis, biasanya dalam hitungan detik | Konfigurasi Anda — rate limit, caching, batas koneksi |

Baca lagi dua baris terakhir itu, karena di situlah letak poin praktisnya. Jika interface-nya jenuh, apa pun yang Anda ketikkan di server tidak akan membantu: paket-paketnya sudah menghabiskan port itu, dan satu-satunya pihak yang bisa menjatuhkannya adalah pemilik router di upstream. Jika interface-nya tenang tapi situsnya tetap down, yang terjadi justru sebaliknya — host Anda tidak melihat ada yang salah karena, di lapisan mereka, *memang* tidak ada yang salah, dan perbaikannya sepenuhnya menjadi tanggung jawab Anda.

Banjir volumetrik disaring di upstream, tempat kapasitasnya berada. Yang lolos dari filter itu adalah lalu lintas yang tampak biasa saja — dan menghentikannya adalah tugas Anda, bukan tugas host Anda.

## Apa yang sebenarnya Anda dapatkan dari "perlindungan DDoS termasuk"

Perlindungan di network layer itu nyata, berharga, dan hampir selalu disalahpahami. Ketika sebuah provider mengiklankan filtering L3/L4, maksudnya adalah network mereka memantau lalu lintas yang menuju alamat Anda, dan ketika sebuah banjir terdeteksi, lalu lintas itu dialihkan lewat scrubbing hardware yang menjatuhkan bagian yang berbahaya dan meneruskan yang tampak sah. Ini terjadi tanpa perlu tiket dukungan dan biasanya tanpa Anda menyadari lebih dari sekadar gangguan sekilas.

Satu kalimat itu menanggung banyak makna, jadi ada baiknya diurai apa yang tercakup dan apa yang tidak:

- **Ia mencakup serangan yang tidak bisa Anda hadapi sendirian.** Banjir amplifikasi 200 Gbps ke server dengan port 1 Gbps bukan soal konfigurasi. Itu soal aritmatika. Scrubbing di upstream adalah satu-satunya jawaban yang ada.

- **Ia tidak mengenal keadaan aplikasi Anda.** Filter itu tidak tahu URL mana yang mahal, pengunjung mana yang sedang login, atau bahwa satu permintaan ke endpoint pencarian Anda berbiaya empat ratus kali lipat dibanding satu permintaan ke logo Anda.

- **Ia bereaksi terhadap ambang batas, bukan terhadap penderitaan Anda.** Deteksi terpicu oleh volume lalu lintas. Serangan yang tidak pernah melewati ambang batas itu tidak akan pernah memicunya, tidak peduli seberapa total ia sudah melumpuhkan situs Anda.

- **Ia bisa saja sesaat melakukan null-route dalam kasus ekstrem.** Setiap network punya batas atasnya sendiri. Jika sebuah serangan mengancam infrastruktur bersama, alamat itu bisa saja dijatuhkan untuk sementara waktu — ini adalah praktik standar, berlaku di mana saja, dan lebih baik diketahui sebelum terjadi daripada saat sedang terjadi.

**Versi satu baris:** host Anda melindungi network miliknya, dan Anda ikut diuntungkan olehnya. Ia tidak melindungi aplikasi Anda, dan memang tidak punya cara untuk melakukannya. Layer 7 bukan upsell yang sengaja tidak diberikan kepada Anda — itu adalah lapisan yang tidak bisa dilihat oleh provider Anda tanpa mengakhiri TLS Anda, yang bagi siapa pun yang hosting offshore adalah sebuah pertukaran dengan konsekuensi seriusnya sendiri.

## Pertama, pastikan dulu apakah ini benar-benar serangan

Sebagian besar insiden yang dicurigai sebagai DDoS sebenarnya adalah hal lain yang mengenakan mantel yang sama, dan cara mengatasinya tidak bisa saling dipertukarkan. Sebelum menerapkan rate limit pada apa pun, luangkan dua menit untuk menyingkirkan kemungkinan-kemungkinan palsu itu — salah diagnosis di sini bisa menghabiskan satu jam Anda, dan sesekali, pengguna sungguhan Anda.

- **Anda jadi populer.** Sebuah tautan di agregator besar menghasilkan bentuk lalu lintas yang persis seperti banjir L7, hanya saja referrer-nya sungguhan dan permintaannya menuju halaman yang memang diinginkan manusia. Ini adalah masalah kapasitas dengan penyebab yang menyenangkan; menerapkan rate limit padanya sama saja menyakiti diri sendiri.

- **Sebuah crawler kehilangan sopan santunnya.** Scraper yang agresif dan bot pelatihan AI bisa dengan mudah melampaui kemampuan server kecil. User-agent-nya biasanya mengaku sendiri, dan perbaikannya adalah robots.txt ditambah limit yang ditargetkan, bukan limit umum.

- **Anda merusak sesuatu.** Sebuah deployment yang menonaktifkan caching, cron job yang lepas kendali, database yang kehilangan index — semuanya tampil sebagai "load tiba-tiba, tanpa sebab yang jelas". Jika waktunya bertepatan dengan perubahan yang Anda buat, percayalah pada perubahan itu.

- **Monitoring Anda sendiri adalah banjirnya.** Jarang terjadi, memalukan, dan jauh lebih umum daripada yang mau diakui siapa pun. Sebuah loop health-check yang mencoba ulang tanpa backoff bisa menghasilkan laju permintaan yang benar-benar mengesankan.

Pertanyaan pembedanya sederhana: *apakah lalu lintas ini menginginkan sesuatu?* Load yang sungguhan — bahkan yang tampak bermusuhan sekalipun — punya bentuk. Ia menuju halaman yang memang ada, mengikuti tautan, memuat aset, dan datang dari sebaran network yang masuk akal. Serangan biasanya tidak repot-repot melakukan itu.

## Membaca serangan langsung dari server

Anda tidak perlu dashboard untuk mengklasifikasikan apa yang sedang terjadi. Empat perintah, dijalankan berurutan, akan memberi tahu Anda sedang melawan di lapisan mana dalam kurang dari satu menit — dan mengetahui itu menentukan segala yang Anda lakukan setelahnya.

**Apakah pipanya penuh?** Perhatikan penghitung interface. Jika throughput tertahan mendekati batas atas port, Anda sedang menghadapi serangan volumetrik dan tugas Anda adalah membuka tiket dukungan, bukan mengubah konfigurasi:

- vnstat -tr 10 — throughput rata-rata selama sepuluh detik, pembacaan tercepat dan paling jujur soal kejenuhan.

- cat /proc/net/dev dua kali, berjarak satu detik — delta paket dan byte per interface, tanpa perlu tooling tambahan.

**Apakah ini SYN flood?** Koneksi half-open menumpuk di status SYN-RECV. Segelintir itu wajar; ribuan itu tidak:

- ss -s — baris ringkasan, jumlah koneksi per status sekilas pandang.

- ss -tn state syn-recv | wc -l — angka spesifik yang benar-benar penting.

**Apakah ini layer 7?** Jika bandwidth-nya biasa saja tapi semuanya lambat, hitung permintaan per klien di access log Anda. Satu alamat dengan puluhan ribu hit adalah amatir; seratus ribu alamat dengan masing-masing tiga hit adalah serangan sungguhan:

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

- Ganti $1 dengan $7 untuk mengurutkan path yang diminta sebagai gantinya. Jika satu endpoint yang mahal mendominasi, Anda sudah menemukan targetnya sekaligus separuh dari solusinya.

**Apa yang sebenarnya habis?** Load average sendirian tidak banyak bercerita. Carilah batas atas spesifik yang sudah Anda tabrak: proses child PHP-FPM semuanya sibuk, koneksi database sudah di batasnya, file descriptor habis, atau worker yang tersangkut di status D menunggu disk. Batas atas itu — bukan lalu lintasnya — yang melumpuhkan situs Anda, dan menaikkannya sering kali lebih cepat daripada memfilter apa pun.

**Ingat ini selagi Anda menyelidiki:** jika Anda menjalankan layanan yang berfokus pada privasi, sebuah serangan justru adalah saat Anda paling tergoda untuk menaikkan level logging dan membiarkannya begitu. Naikkan jika memang perlu, lalu turunkan kembali dan rotasi filenya secara agresif setelahnya. Sebuah insiden yang meninggalkan satu bulan log pengunjung dengan detail lengkap di disk sudah menukar satu masalah dengan masalah lain yang lebih buruk dan lebih lama bertahan. [Panduan OpSec server](https://servghost.com/id/guides/server-opsec-staying-anonymous) kami membahas disiplin yang menjadi induk dari hal ini.

## Sepuluh menit pertama

Di bawah tekanan, orang cenderung meraih tuas terbesar yang tersedia, dan tuas terbesar biasanya keliru. Inilah urutan yang membatasi kerusakan, kurang lebih dari yang tercepat-dan-teraman lebih dulu:

- **Klasifikasikan dulu sebelum bertindak.** Interface yang jenuh berarti volumetrik; interface yang tenang dengan worker yang sibuk berarti layer 7. Tiga puluh detik yang dihabiskan di sini menyelamatkan Anda dari memperbaiki lapisan yang keliru selama satu jam penuh.

- **Jika ini volumetrik, segera buka tiket** dan sertakan alamat tujuan, waktu mulainya, dan penghitung interface Anda. Setelah itu berhenti mengetik apa pun ke server — Anda tidak bisa memperbaiki ini dari dalamnya.

- **Jika ini layer 7, lakukan caching dulu.** Menyalakan full-page caching yang agresif untuk pengunjung anonim adalah cara tercepat untuk mengubah outage menjadi sekadar gangguan kecil, dan ini satu-satunya langkah yang juga membantu terhadap lalu lintas sungguhan.

- **Baru kemudian terapkan rate limit** — endpoint yang menjadi target lebih dulu, sisanya kemudian. Mulai dengan konservatif. Limit yang justru menjatuhkan pengguna Anda sendiri adalah kelanjutan serangan yang Anda timbulkan sendiri.

- **Blokir hanya yang benar-benar jelas.** Selusin alamat dengan masing-masing seratus ribu permintaan, user-agent yang jelas-jelas palsu, satu negara yang tidak punya pengguna Anda. Tahan godaan untuk menulis aturan yang rumit saat sedang diserang; Anda tidak akan mengingatnya bulan depan.

- **Buang load secara sengaja jika memang perlu.** Menyajikan halaman statis "sedang dalam perawatan" kepada pengunjung yang belum terautentikasi menjaga server tetap hidup, menjaga API Anda tetap jalan, dan membeli waktu untuk berpikir. Memutuskan sendiri apa yang dikorbankan lebih baik daripada dibiarkan diputuskan begitu saja.

- **Catat apa yang sudah Anda lakukan.** Setiap aturan sementara yang Anda tambahkan adalah ranjau bagi diri Anda di masa depan. Aturan yang terbukti membantu jadikan permanen; sisanya cabut besok.

## Rate limit yang benar-benar efektif, dan kesalahan yang dilakukan semua orang

Rate limiting adalah instrumen utama untuk layer 7, dan nginx melakukannya dengan baik lewat dua directive yang menyelesaikan dua masalah yang sungguh-sungguh berbeda. limit_req membatasi *rate* permintaan — seberapa sering satu klien boleh meminta. limit_conn membatasi *concurrency* — berapa banyak koneksi yang boleh dibuka satu klien secara bersamaan. Banjir permintaan butuh yang pertama; serangan slow-loris, yang menahan ribuan koneksi nyaris-idle untuk menghabiskan worker pool Anda, butuh yang kedua. Terapkan hanya satu saja dan Anda hanya terlindungi dari separuh masalah.

Tiga detail yang membedakan limit yang benar-benar bekerja dari yang hanya hiasan:

- **Gunakan burst, dan gunakan nodelay.** Browser sungguhan itu bersifat bursty — satu kali membuka halaman memicu selusin permintaan aset yang nyaris bersamaan. Limit tanpa ruang gerak akan menahan pengunjung sungguhan sementara penyerang yang mengatur temponya tepat di bawah ambang batas melenggang lolos.

- **Batasi endpoint yang mahal secara terpisah.** Halaman pencarian, form login, reset password, dan endpoint mana pun yang menulis ke database layak mendapat jatah yang jauh lebih ketat dibanding aset statis Anda. Penyerang menemukan endpoint ini tanpa perlu berusaha, karena merekalah yang paling menyakitkan.

- **Kembalikan 429, bukan 503.** Kode status ini adalah sinyal kepada klien yang berperilaku baik dan kepada mesin pencari bahwa ini adalah throttling, bukan kegagalan — dan itu mencegah sore hari yang buruk berubah menjadi masalah ranking.

**Kesalahan yang diam-diam membatalkan semuanya:** jika ada apa pun di depan server Anda — CDN, load balancer, reverse proxy milik Anda sendiri — maka setiap permintaan tiba dari alamat *miliknya*, bukan alamat pengunjung. Rate limit per klien kemudian menghitung seluruh internet sebagai satu klien saja, dan hasilnya akan sama sekali tidak berfungsi atau justru memblokir seluruh audiens Anda sekaligus. Anda harus mengonfigurasi sumber real-IP Anda (di nginx, set_real_ip_from untuk rentang alamat proxy tersebut ditambah real_ip_header untuk header yang dikirimnya) *sebelum* limit apa pun jadi berarti. Batasi juga kepercayaan itu hanya pada rentang milik proxy itu sendiri: mempercayai header yang dipasok klien dari internet terbuka membuat penyerang bisa memalsukan identitas baru di setiap permintaan dan melenggang lolos dari setiap limit yang Anda miliki.

## Caching adalah mitigasi termurah yang pernah bisa Anda terapkan

Rate limit menolak pekerjaan. Cache membuat pekerjaan itu tidak perlu ada. Untuk apa pun yang dilihat pengunjung anonim, full-page caching mengubah ekonomi dari keseluruhan serangan: permintaan yang tadinya berbiaya satu round-trip database, satu render template, dan satu worker PHP berubah menjadi pembacaan file yang diukur dalam mikrodetik. Server yang sama yang tadinya kolaps di angka empat ratus permintaan dinamis per detik akan melayani puluhan ribu permintaan cache tanpa terasa.

Hal-hal yang penting saat Anda menyalakannya dalam kondisi genting:

- **Cache hanya untuk pengunjung anonim.** Lewati (bypass) jika ada session cookie. Menyajikan halaman satu pengguna yang sedang login kepada pengguna lain adalah insiden yang jauh lebih buruk dibanding outage yang sedang Anda perbaiki.

- **Sajikan stale dengan sengaja.** proxy_cache_use_stale milik nginx dengan updating error timeout membuat pengunjung mendapat halaman yang sedikit basi alih-alih error saat backend Anda kepayahan. Selama serangan, ini adalah perbedaan antara situs yang terlihat baik-baik saja dan situs yang terlihat mati.

- **Gabungkan cache miss yang berduplikasi.** proxy_cache_lock memastikan seribu permintaan simultan untuk halaman yang sama yang belum ter-cache hanya menghasilkan satu permintaan ke backend, bukan seribu. Tanpa ini, serangan cache-busting akan menembus cache begitu saja dan menghantam database Anda dengan kekuatan penuh.

- **Netralkan query string cache-busting.** Trik standarnya adalah menambahkan ? dan sebuah nilai acak sehingga setiap permintaan menjadi key yang unik dan selalu miss selamanya. Normalisasi cache key Anda supaya mengabaikan parameter query yang sebenarnya tidak dipakai aplikasi Anda.

Ada asimetri yang menyenangkan di sini dan layak untuk dihayati: setiap jam yang Anda habiskan untuk caching juga membuat situs lebih cepat pada hari terbaiknya, lebih murah dijalankan, dan lebih tangguh bertahan dari kesuksesan. Nyaris tidak ada lini pertahanan lain yang membayar dividen ketika tidak ada apa pun yang salah.

## Batas atas yang menentukan apakah Anda akan tumbang

Sebagian besar server tidak mati karena kehabisan CPU. Mereka mati karena menabrak batas atas yang tidak terlihat, yang tidak sengaja diatur siapa pun — sebuah default dari satu dekade lalu yang dulu masuk akal di hardware yang sekarang sudah tidak dipakai siapa pun lagi. Saat diserang, inilah yang sebenarnya paling dulu jebol:

- **Worker aplikasi.** pm.max_children milik PHP-FPM, jumlah worker Python Anda, ukuran cluster Node Anda. Inilah batas concurrency sesungguhnya dari situs Anda. Ketika semuanya sibuk, setiap pengunjung tambahan mengantre, dan situsnya down tidak peduli seberapa idle CPU-nya terlihat. Naikkan hanya sejauh yang diizinkan memori — swapping lebih buruk daripada mengantre.

- **Accept queue.** net.core.somaxconn dan listen backlog Anda menentukan berapa banyak koneksi yang boleh menunggu untuk diterima. Backlog yang kecil mengubah lonjakan yang seharusnya bisa selamat menjadi koneksi yang ditolak.

- **SYN cookies.** net.ipv4.tcp_syncookies membiarkan kernel menjawab SYN flood tanpa perlu mengalokasikan state untuk koneksi yang tidak akan pernah selesai. Kernel modern mengaktifkannya secara default; verifikasi, jangan hanya berasumsi, karena tidak ada biayanya sama sekali dan ini menyelamatkan Anda dari banjir paling umum yang ada.

- **File descriptor.** Setiap koneksi adalah sebuah descriptor. Limit nofile default sering kali lebih rendah dari jumlah koneksi yang sedang Anda coba layani, dan mode kegagalannya — accept yang gagal padahal semuanya tampak sehat — benar-benar membingungkan pada jam tiga pagi.

- **Koneksi database.** Menaikkan jumlah worker tanpa menaikkan connection pool hanya memindahkan antrean itu ke tempat yang lebih sulit terlihat. Kedua angka ini harus disesuaikan bersamaan.

Setel ini semua di hari yang tenang, bukan saat insiden berlangsung. Gunanya mengetahui angka-angka ini adalah supaya saat situsnya tumbang, Anda bisa menyebut nama batas atas yang ditabraknya, bukan sekadar menebak — dan batas atas yang sudah punya nama adalah batas atas yang bisa diperbaiki.

## Memasang sesuatu di depan origin

Semua yang di atas terjadi di server itu sendiri. Langkah berikutnya adalah memutuskan apakah server itu sebaiknya menjadi pihak yang menerima lalu lintas secara langsung sama sekali. Ada tiga opsi yang jujur, dan jawaban yang tepat jauh lebih bergantung pada apa yang Anda hosting dibanding apa yang bisa Anda bayar.

| Pendekatan | Apa yang Anda dapatkan | Apa yang harus Anda korbankan |
| --- | --- | --- |
| Origin terekspos langsung, sudah di-harden | Kesederhanaan, tanpa pihak ketiga, tanpa terminasi TLS yang tidak Anda kendalikan sendiri | Alamat Anda publik dan permanen. Layer 7 sepenuhnya menjadi urusan Anda |
| CDN komersial atau layanan scrubbing | Kapasitas penyerapan yang sangat besar, halaman challenge hanya dengan satu klik, caching global | Meja aduan yang punya opini soal konten Anda, dan sebuah perusahaan yang bisa melihat lalu lintas Anda. Untuk proyek offshore atau yang sensitif terhadap DMCA, ini bisa menjadi mata rantai paling lemah dalam susunan yang sebenarnya sudah hati-hati |
| Front node milik Anda sendiri — sebuah VPS kecil yang menjalankan nginx, memproksikan ke origin yang di-firewall | Kendali penuh, tanpa pihak ketiga di jalur permintaan, alamat yang bisa Anda bakar dan ganti, serta alamat sungguhan yang tetap tersembunyi | Batas kapasitasnya sendiri, dan satu mesin lagi yang harus dijalankan. Dua atau tiga front di network yang berbeda membuatnya jauh lebih sulit untuk dijatuhkan |

Front node yang dikelola sendiri layak mendapat perhatian lebih dibanding yang biasanya diberikan, terutama bagi siapa pun yang memilih hosting offshore karena alasan yang mungkin tidak akan disetujui oleh CDN besar. Polanya tidak muluk-muluk: node proxy murah di depan, origin di-firewall untuk hanya menerima koneksi dari node-node itu, DNS diarahkan ke front-front tersebut. Jika sebuah front diserang, Anda menggantinya dengan alamat baru dalam hitungan menit dan origin-nya sama sekali tidak menyadarinya. Versi lengkap dari arsitektur ini — termasuk enam cara alamat origin tetap bisa bocor — adalah pokok bahasan panduan kami soal [menyembunyikan IP origin server Anda](https://servghost.com/id/guides/hiding-your-origin-server-ip).

## Origin yang tersembunyi lebih berharga daripada filter apa pun

Ini layak dikatakan secara terus terang, karena ini membalik prioritas yang biasa dipegang orang: mitigasi DDoS termurah yang tersedia bagi Anda adalah sebuah alamat yang tidak dimiliki penyerang. Filtering adalah yang Anda lakukan ketika hal itu sudah gagal duluan.

Ini lebih penting daripada kedengarannya, karena alamat origin bocor terus-menerus dan diam-diam. Record DNS historis dari sebelum Anda memasang proxy di depan tetap ada bertahun-tahun setelah perubahan itu. Mail yang dikirim langsung dari aplikasi membawa alamat itu di headernya. Sertifikat TLS yang diterbitkan untuk alamat mentah dipublikasikan secara permanen di log certificate transparency. Halaman error, sebuah redirect, atau subdomain tersembunyi yang tidak pernah diproksikan semuanya membocorkannya. Jika Anda memasang CDN di depan server yang dulu pernah terekspos, anggap saja alamat lamanya sudah diketahui sampai Anda benar-benar menggantinya.

**Konsekuensinya adalah sebuah aturan firewall, dan ini adalah satu baris paling berharga di seluruh panduan ini:** begitu ada sesuatu yang dipasang di depan, origin harus menolak koneksi di port 80 dan 443 dari siapa pun kecuali alamat-alamat front itu. Tanpa ini, proxy hanyalah sebuah saran — siapa pun yang mengetahui alamat sungguhannya tinggal melangkah melewatinya dan menyerang Anda secara langsung, dan semua yang Anda konfigurasikan di front berubah menjadi sekadar hiasan.

## Memilih hardware dan lokasi agar serangan tetap membosankan

Sebagian dari ini sudah ditentukan sebelum serangan itu terjadi, yaitu pada saat Anda memilih paket. Tiga properti ini jauh lebih penting daripada yang tersirat di lembar spesifikasi:

- **Bandwidth unmetered.** Pada paket metered, sebuah serangan bukan hanya outage — itu juga tagihan. Lalu lintas yang tidak pernah Anda minta dan tidak bisa Anda tolak tetap dihitung terhadap kuota Anda. Transfer unmetered mengubah risiko finansial menjadi risiko yang murni teknis, yang merupakan kelas masalah yang jauh lebih baik.

- **Apakah port-nya milik Anda sendiri.** Di host virtualisasi yang dipakai bersama, tetangga yang sedang diserang bisa menurunkan performa Anda, dan batas atas perlindungan Anda sendiri juga dipakai bersama. [Dedicated hardware](https://servghost.com/id/dedicated) dengan port miliknya sendiri menghilangkan kedua efek itu. Untuk proyek yang memang mengantisipasi perhatian yang bermusuhan, inilah alasan paling jelas untuk naik kelas dari [VPS](https://servghost.com/id/vps) — lebih dari sekadar soal core atau RAM.

- **Di mana network itu berada.** Network Eropa yang tersambung baik dengan kapasitas transit sungguhan menyerap banjir yang tidak akan sanggup diserap oleh network dengan peering yang buruk, dan yurisdiksi yang Anda pilih karena alasan hukum juga punya karakteristik network-nya sendiri. Ini layak dicek keduanya saat memilih dari [lokasi-lokasi](https://servghost.com/id/locations) yang tersedia.

Ada juga argumen skala yang diam-diam berpihak pada kesederhanaan. Situs statis di balik cache pada server sederhana sangat sulit dijatuhkan; konten yang sama pada CMS berat dengan endpoint pencarian yang tidak ter-cache bisa dijatuhkan oleh satu orang yang cukup gigih dengan sebuah script. Mengurangi apa yang bersifat dinamis adalah mitigasi, dan itu gratis. Jika proyek Anda sungguh-sungguh hidup di bawah load yang berkelanjutan, catatan [hosting untuk lalu lintas tinggi](https://servghost.com/id/use-cases/high-traffic-hosting) kami membahas sisi sizing dari pertanyaan yang sama.

## Lima hal yang jangan dilakukan

Pola kegagalan di sini cukup konsisten untuk didaftar, dan masing-masing pernah menghabiskan akhir pekan seseorang:

- **Jangan null-route diri Anda sendiri.** Melakukan blackhole terhadap alamat Anda sendiri mengakhiri serangan itu dengan cara yang paling harfiah — tidak ada seorang pun yang bisa menjangkau Anda, termasuk pengguna Anda sendiri. Ini adalah alat pilihan terakhir milik provider Anda, bukan tindakan yang Anda ambil secara sukarela.

- **Jangan anggap fail2ban sebagai perlindungan DDoS.** Ini alat yang bagus untuk melawan percobaan brute-force dari segelintir alamat. Terhadap banjir yang terdistribusi, ia bereaksi dalam hitungan menit terhadap sesuatu yang datang dalam hitungan detik, dan sebuah rule yang memblokir ribuan alamat bisa menghabiskan lebih banyak resource pemrosesan firewall dibanding kerugian dari serangan itu sendiri.

- **Jangan bayar tebusan.** Sebagian besar email pemerasan yang mengancam serangan dahsyat datang dari orang-orang yang sama sekali tidak punya kemampuan dan hanya mengirim ribuan pesan yang identik. Sebagian kecil yang benar-benar sanggup menindaklanjuti akan kembali lagi, karena Anda sudah membuktikan bahwa Anda mau membayar.

- **Jangan membalas.** Selain ilegal di hampir semua tempat, sumber serangannya adalah pihak ketiga yang mesinnya sudah disusupi. Anda akan menyerang korban, dan melakukannya dari alamat yang jelas-jelas milik Anda sendiri.

- **Jangan migrasi dalam kepanikan.** Berpindah host di tengah serangan berarti alamat barunya akan publik dalam hitungan menit dan Anda belum punya konfigurasi yang berfungsi. Stabilkan dulu, baru berpindah dengan sengaja belakangan — dan jika Anda memang berpindah, panduan kami soal [migrasi tanpa downtime](https://servghost.com/id/guides/migrate-website-to-offshore-hosting) ada persis untuk memastikan kepindahan itu tidak menjadi insiden kedua.

## Versi singkatnya

Dilepas dari semua penalarannya, model kerjanya muat dalam delapan baris:

- **Klasifikasikan dulu.** Interface yang jenuh berarti volumetrik dan menjadi urusan host Anda. Interface yang tenang dengan worker yang habis berarti layer 7 dan menjadi urusan Anda.

- **Untuk volumetrik, ajukan tiket** dengan alamat, timestamp, dan penghitung Anda — lalu berhenti menyentuh server itu.

- **Lakukan caching secara agresif untuk pengunjung anonim,** sajikan stale saat tertekan, dan gabungkan cache miss yang berduplikasi. Ini adalah perubahan dengan daya ungkit tertinggi yang bisa Anda buat.

- **Terapkan rate limit berdasarkan laju permintaan maupun concurrency,** paling ketat pada endpoint yang paling mahal, dan kembalikan 429.

- **Perbaiki konfigurasi real-IP Anda sebelum semua yang lain,** atau setiap limit per klien di balik proxy akan sia-sia atau justru bencana.

- **Kenali batas atas Anda** — worker, backlog, descriptor, koneksi database — dan naikkan secara sengaja di hari yang tenang.

- **Jaga alamat origin tetap rahasia dan di-firewall** hanya untuk front node Anda. Ini lebih berharga daripada semua filter digabung jadi satu.

- **Beli bandwidth unmetered** supaya lalu lintas yang tidak Anda minta tidak pernah berubah menjadi tagihan juga.

Tidak satu pun dari ini membuat Anda kebal, dan siapa pun yang menjual kekebalan sedang menjual sesuatu yang lain. Yang benar-benar dilakukannya adalah memindahkan Anda keluar dari populasi yang bisa dijatuhkan oleh remaja iseng yang bosan, ke populasi yang membutuhkan resource sungguhan dan niat sungguhan untuk mengganggu — yang, bagi sebagian besar proyek, sudah nyaris tidak bisa dibedakan dari aman. Sisanya adalah pekerjaan tidak glamor yang sama, yang membuat sebuah server unggul dalam segala hal lainnya: [di-harden sejak hari pertama](https://servghost.com/id/guides/first-hour-vps-hardening-checklist), [bisa dipulihkan pada hari terburuknya](https://servghost.com/id/guides/vps-backup-strategy), dan berjalan di tempat yang memperlakukan lalu lintas Anda sebagai urusan Anda sendiri.





FAQ

## DDoS di server kecil — pertanyaan umum





### 01
Apakah "perlindungan DDoS termasuk" berarti saya aman dari segalanya?



Tidak, dan celahnya jelas, bukan samar-samar. Perlindungan yang sudah termasuk itu adalah filtering di network layer: ia menjatuhkan banjir volumetrik — SYN flood, UDP amplification, badai paket mentah — di upstream, sebelum sampai ke port Anda. Itu adalah kategori yang sungguh-sungguh tidak bisa Anda tangani sendiri, jadi memang tepat untuk disertakan. Ia tidak memeriksa aplikasi Anda, jadi banjir HTTP beberapa ribu permintaan per detik ke endpoint yang mahal akan lolos begitu saja dan menjatuhkan situs Anda sementara semua grafik network terlihat normal. Layer 7 adalah konfigurasi yang menjadi tanggung jawab Anda sendiri: caching, rate limit, dan batas koneksi.





### 02
Bagaimana cara membedakan serangan DDoS dari lonjakan lalu lintas biasa?



Tanyakan apakah lalu lintas itu menginginkan sesuatu. Pengunjung sungguhan, bahkan yang datang mendadak dan deras dari sebuah tautan populer, meminta halaman yang memang ada, memuat aset-aset di halaman itu, datang dengan referrer yang masuk akal, dan tersebar di banyak network dengan pola yang alami. Serangan biasanya menghantam satu path saja, mengabaikan aset, mengirim user-agent yang tidak masuk akal atau bahkan tidak ada sama sekali, dan menunjukkan distribusi yang terlihat sintetis. Periksa access log Anda untuk permintaan per alamat klien dan per path: jika satu endpoint mendominasi dan tidak ada yang lain dimuat, itu serangan. Jika halaman yang sama yang memang diinginkan manusia sedang disajikan dan referrer Anda sungguhan, Anda punya masalah kapasitas dengan penyebab yang menyenangkan.





### 03
Apa satu hal paling efektif yang bisa saya lakukan saat sedang diserang?



Nyalakan full-page caching untuk pengunjung anonim, dan konfigurasikan agar menyajikan konten stale saat backend sedang kepayahan. Rate limit menolak pekerjaan; cache membuat pekerjaan itu tidak perlu ada. Permintaan yang tadinya berbiaya satu query database, satu render template, dan satu worker aplikasi berubah menjadi pembacaan file, dan hardware yang sama yang tadinya kolaps di angka beberapa ratus permintaan dinamis per detik akan melayani puluhan ribu permintaan cache. Ini juga satu-satunya langkah dalam daftar ini yang sama efektifnya terhadap lalu lintas sungguhan, jadi tidak seperti rate limit, ini tidak bisa berbalik merugikan pengguna Anda sendiri.





### 04
Mengapa rate limit nginx saya berhenti bekerja setelah memasang CDN di depan?



Karena sekarang setiap permintaan tiba dari alamat CDN, bukan alamat pengunjung, sehingga limit per klien menghitung seluruh internet sebagai satu klien saja. Tergantung ambang batasnya, ini akan sama sekali tidak pernah terpicu atau justru memblokir seluruh lalu lintas Anda sekaligus. Konfigurasikan sumber real-IP Anda — di nginx, rentang proxy yang dipercaya ditambah header yang dikirim proxy tersebut — supaya limit itu kembali mengacu pada pengunjung sesungguhnya. Batasi kepercayaan itu hanya pada rentang milik proxy itu sendiri: jika Anda menerima header yang dipasok klien dari internet terbuka, penyerang bisa memalsukan identitas baru di setiap permintaan dan melenggang lolos dari setiap limit yang Anda miliki.





### 05
Apakah fail2ban cukup untuk menghentikan serangan DDoS?



Tidak. fail2ban membaca log secara berkala dan memblokir alamat yang melanggar setelah melewati ambang batas, yang cocok untuk percobaan brute-force dari segelintir sumber. Serangan terdistribusi datang dalam hitungan detik dari ribuan alamat yang masing-masing hanya mengirim segelintir permintaan, jadi ambang batasnya tidak akan pernah tercapai, dan waktu reaksinya tetap jauh terlalu lambat. Lebih buruk lagi, ruleset yang membengkak sampai puluhan ribu entri bisa menghabiskan lebih banyak resource dibanding serangannya sendiri. Simpan fail2ban untuk SSH dan endpoint login, dan tangani banjir dengan caching, rate limiting, dan filter di upstream.





### 06
Sebaiknya pakai CDN, atau menjalankan reverse proxy sendiri di depan?



Itu bergantung pada apa yang Anda hosting, bukan pada anggaran Anda. CDN komersial membawa kapasitas penyerapan yang tidak bisa Anda tandingi dan halaman challenge hanya sejauh satu klik, tapi Anda ikut mewarisi meja aduannya dan ia bisa melihat lalu lintas Anda — yang untuk proyek offshore atau yang sensitif terhadap DMCA sering menjadi mata rantai paling lemah dalam susunan yang sebenarnya sudah hati-hati. Front node milik Anda sendiri membutuhkan lebih banyak kerja dan punya batas kapasitas yang nyata, tapi tidak ada pihak ketiga di jalur permintaan dan front yang diserang bisa diganti dengan alamat baru dalam hitungan menit. Apa pun pilihannya, origin harus di-firewall untuk hanya menerima lalu lintas web dari front tersebut, atau seluruh susunan itu hanya jadi hiasan.





### 07
Apakah serangan akan merugikan saya secara finansial, bukan cuma uptime?



Pada paket metered, ya — lalu lintas yang tidak pernah Anda minta dan tidak bisa Anda tolak tetap dihitung terhadap kuota transfer Anda, dan banjir yang berkelanjutan bisa menghasilkan tagihan kelebihan pakai yang lebih besar dari biaya hosting satu tahun. Inilah alasan praktis mengapa bandwidth unmetered jauh lebih penting daripada yang terlihat di lembar spesifikasi: ini mengubah risiko finansial menjadi risiko yang murni teknis. Ada baiknya juga diketahui lebih dulu bahwa jika sebuah serangan mengancam infrastruktur bersama, provider bisa saja untuk sementara melakukan null-route pada alamat itu; itu praktik standar di mana saja, bukan kegagalan dari host Anda secara khusus.





### 08
Apakah pindah ke host offshore atau no-KYC membuat serangan lebih mungkin terjadi?



Pilihan hosting itu sendiri netral; apa yang Anda jalankan itulah yang menarik perhatian. Game server, forum, streaming, marketplace, dan apa pun yang punya kompetitor atau dendam akan menarik serangan tidak peduli yurisdiksinya. Yang memang berubah di offshore adalah upaya pemulihan Anda: kemungkinan Anda diputus layanannya karena dianggap merepotkan jadi lebih kecil, dan ini berlaku dua arah — perlindungannya bersifat teknis, bukan kontraktual. Pilih lokasi dengan kapasitas transit yang sungguhan, ambil bandwidth unmetered, jaga alamat origin tetap tersembunyi, dan perlakukan layer 7 sebagai tanggung jawab Anda sendiri sejak hari pertama, bukan sejak insiden pertama.




Panduan terkait

## Terus membaca


[### Cara Memilih Yurisdiksi Hosting Offshore pada 2026

Pembelian


Kerangka keputusan praktis untuk memilih yurisdiksi offshore: undang-undang retensi data, paparan MLAT, posisi DMCA, kecepatan pengadilan, dan penegakan di dunia nyata — negara demi negara.


FAQ 6-pertanyaan](https://servghost.com/id/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Server Dedicated for Privasi-Critical Workloads

Pembelian


Kapan VPS sudah cukup, kapan shared tenancy menjadi liabilitas, dan kapan bare metal adalah satu-satunya jawaban yang jujur. Isolasi hardware, risiko hypervisor, serta biaya dibanding model ancaman.


FAQ 6-pertanyaan](https://servghost.com/id/guides/vps-vs-dedicated-for-privacy)
[### VPN Self-Hosted di VPS Tanpa-KYC: WireGuard vs OpenVPN

Operasional


Mengapa VPN self-hosted mengalahkan provider komersial, dan bagaimana WireGuard serta OpenVPN benar-benar dibandingkan dari sisi privasi, performa, dan risiko operasional pada 2026.


FAQ 6-pertanyaan](https://servghost.com/id/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 untuk Inferensi AI (dan Di Mana RTX 5090 Cocok)

Pembelian


Buying-decision guide: NVIDIA GPU mana untuk self-hosted LLM, image, video, voice, dan finetuning workloads pada 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, dan kapan masing-masing menang.


FAQ 6-pertanyaan](https://servghost.com/id/guides/rtx-4090-vs-h100-for-ai-inference)
[### Windows RDP Offshore untuk Trading Forex MT4 / MT5 / cTrader

Operasional


Panduan lengkap: mengapa Windows RDP untuk trading forex, cara memilih yurisdiksi offshore berlatensi rendah, pengaturan MT4 / MT5 / cTrader / Expert Advisor, latensi ke server broker, dan jalur checkout no-KYC.


FAQ 6-pertanyaan](https://servghost.com/id/guides/offshore-windows-rdp-for-forex-trading)
[### Hosting DMCA-Ignored Dijelaskan: Apa Artinya Sebenarnya di 2026

Pembelian


Apa yang benar-benar didapat dari hosting "DMCA ignored", yurisdiksi mana yang sungguh-sungguh mendukungnya, beban kerja yang membutuhkannya, dan jebakan hak cipta yang tidak dicakup oleh istilah tersebut.


FAQ 6-pertanyaan](https://servghost.com/id/guides/dmca-ignored-hosting-explained)
[### Registrasi Domain Anonim dengan Kripto: Privasi WHOIS di 2026

Privasi


Panduan praktis 2026 untuk mendaftarkan domain tanpa mengungkap identitas Anda: rezim WHOIS per TLD, pilihan registrar, opsi pembayaran kripto, dan kesalahan operasional yang tetap membocorkan Anda.


FAQ 6-pertanyaan](https://servghost.com/id/guides/anonymous-domain-registration-with-crypto)
[### Kripto Payments for Hosting: Monero vs Bitcoin vs USDT

Privasi


Bagaimana coin pembayaran memengaruhi apa yang diketahui host tentang Anda. Privasi, biaya, finalitas, dan eksposur chain analysis untuk XMR, BTC, dan USDT, dengan rekomendasi jelas.


FAQ 6-pertanyaan](https://servghost.com/id/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Apakah Hosting Offshore Benar-Benar Anonim? Jawaban yang Jujur

Privasi


Hosting offshore tanpa KYC menghilangkan identitas yang biasanya dikumpulkan oleh hosting normal — tetapi status "anonim" bergantung pada metode pembayaran, logging provider, dan opsec Anda sendiri. Berikut ini yang sebenarnya masih bisa dilacak.


FAQ 6-pertanyaan](https://servghost.com/id/guides/is-offshore-hosting-truly-anonymous)
[### Jam Pertama Hardening VPS: Sebuah Checklist

Operasional


Checklist konkret dan berurutan untuk mengamankan VPS baru dalam waktu kurang dari satu jam: kunci SSH, firewall, fail2ban, update otomatis, dan pengurangan attack surface yang menghentikan sebagian besar serangan oportunistik.


FAQ 6-pertanyaan](https://servghost.com/id/guides/first-hour-vps-hardening-checklist)
[### Apa Itu Hosting Tanpa KYC? Definisi, Legalitas & Cara Kerjanya

Privasi


Hosting tanpa KYC memungkinkan Anda menyewa server tanpa verifikasi identitas apa pun — tanpa nama, email, maupun ID. Berikut penjelasan lengkapnya: apa artinya, cara kerjanya secara teknis, apakah legal, dan cara memilih penyedia yang benar-benar tanpa KYC.


FAQ 6-pertanyaan](https://servghost.com/id/guides/what-is-no-kyc-hosting)
[### Apakah Hosting Offshore Legal? Jawaban Jujur untuk 2026

Pembelian


Hosting offshore itu legal — baik untuk Anda maupun untuk penyedia layanan. Berikut penjelasan sesungguhnya tentang istilah ini, di mana garis hukum yang sebenarnya, mitos yang perlu dibuang, dan cara menggunakannya secara bertanggung jawab.


FAQ 6-pertanyaan](https://servghost.com/id/guides/is-offshore-hosting-legal)
[### Cara Membayar Hosting dengan Monero (XMR) — Panduan Langkah demi Langkah

Privasi


Panduan langkah demi langkah untuk membayar VPS atau server dedicated dengan Monero (XMR): mengapa XMR adalah pilihan paling privat, cara memperolehnya, dan cara kerja proses checkout — dari invoice hingga server yang berjalan dalam hitungan menit.


FAQ 6-pertanyaan](https://servghost.com/id/guides/how-to-pay-for-hosting-with-monero)
[### Cara Meng-host Website Secara Anonim — Panduan Praktis 2026

Privasi


Panduan berlapis yang praktis untuk meng-host website tanpa identitas yang terlampir: akun, pembayaran, domain, yurisdiksi, koneksi, dan konten — setiap lapisan dijelaskan secara rinci.


FAQ 6-pertanyaan](https://servghost.com/id/guides/how-to-host-a-website-anonymously)
[### Cara Menyiapkan WireGuard VPN di VPS — Panduan Langkah demi Langkah

Operasional


Bangun VPN pribadi di VPS menggunakan WireGuard: mengapa VPN yang di-host sendiri lebih unggul dari layanan komersial, panduan lengkap mulai dari instalasi hingga klien terhubung, dan cara memperkuat keamanannya.


FAQ 6-pertanyaan](https://servghost.com/id/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Cara Self-Host LLM di Server GPU — Panduan 2026

Operasional


Jalankan model bahasa besar milik Anda sendiri di server GPU sewaan: mengapa self-hosting lebih unggul dari API, cara memilih GPU dan model yang tepat, cara setup dengan Ollama atau vLLM, dan berapa biayanya.


FAQ 6-pertanyaan](https://servghost.com/id/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — Apa Perbedaannya?

Pembelian


Bulletproof hosting dan offshore hosting kerap tertukar — padahal keduanya tidak sama. Berikut perbedaan sesungguhnya, mengapa hal ini penting, dan mana yang sebenarnya Anda butuhkan.


FAQ 6-pertanyaan](https://servghost.com/id/guides/bulletproof-vs-offshore-hosting)
[### Cara Membeli VPS dengan Bitcoin — Panduan Lengkah demi Langkah (2026)

Pembelian


Panduan ramah pemula untuk membeli VPS dengan Bitcoin: mendapatkan BTC, memilih paket, membayar invoice, dan apa yang Anda peroleh — server yang berjalan tanpa kartu dan tanpa nama terlampir.


FAQ 6-pertanyaan](https://servghost.com/id/guides/how-to-buy-a-vps-with-bitcoin)
[### Negara Terbaik untuk Hosting yang Mengabaikan DMCA di 2026

Pembelian


Tempat menghosting konten agar jauh dari jangkauan proses penghapusan ala AS: yurisdiksi yang benar-benar efektif, apa arti sebenarnya hosting yang mengabaikan DMCA, dan cara memilihnya.


FAQ 6-pertanyaan](https://servghost.com/id/guides/best-countries-for-dmca-ignored-hosting)
[### Cara Meng-host Tor Hidden Service (Situs .onion) — Panduan 2026

Operasional


Siapkan onion service Tor di VPS: apa itu hidden service, mengapa ini adalah bentuk hosting anonim yang paling kuat, panduan setup lengkap, dan cara menjaganya tetap benar-benar anonim.


FAQ 6-pertanyaan](https://servghost.com/id/guides/how-to-host-a-tor-hidden-service)
[### Panduan Setup Mail Server Offshore — Self-Host Email Privat di 2026

Operasional


Jalankan server email privat Anda sendiri di VPS offshore: mengapa self-host email, apa yang dibutuhkan, setup realistis dengan stack mail all-in-one, dan cara memastikan deliverability yang tepat.


FAQ 6-pertanyaan](https://servghost.com/id/guides/offshore-mail-server-setup)
[### Panduan Hosting Node Kripto — Jalankan Node Blockchain di VPS

Operasional


Cara meng-host node blockchain di server: mengapa menjalankan node sendiri, menentukan spesifikasi server untuk Bitcoin, Ethereum, Monero dan lainnya, proses setup, dan cara menjaga privasi.


FAQ 6-pertanyaan](https://servghost.com/id/guides/crypto-node-hosting-guide)
[### Hosting GPU untuk Stable Diffusion — Jalankan Server Gambar Sendiri

Operasional


Jalankan Stable Diffusion di server GPU Anda sendiri: alasan self-hosting pembuatan gambar, cara memilih GPU, pengaturan dengan web UI, serta perbandingan biaya versus layanan hosted.


FAQ 6-pertanyaan](https://servghost.com/id/guides/gpu-hosting-for-stable-diffusion)
[### OpSec Server — Tetap Anonim Saat Menjalankan Server

Privasi


Keamanan operasional bagi siapa saja yang menjalankan server anonim: kesalahan-kesalahan yang membongkar identitas, kebiasaan yang mencegahnya, dan cara menjaga identitas tetap benar-benar terpisah.


FAQ 6-pertanyaan](https://servghost.com/id/guides/server-opsec-staying-anonymous)
[### Panduan Penyiapan Seedbox — Bangun Seedbox Privat Anda Sendiri di 2026

Operasional


Cara membangun seedbox Anda sendiri di server: apa itu seedbox, cara menentukannya, menginstal klien torrent dengan web UI, dan menjaganya tetap privat dan aman.


FAQ 6-pertanyaan](https://servghost.com/id/guides/seedbox-setup-guide)
[### Cara Melewati Sensor DPI dengan VPS Anda Sendiri (Panduan 2026)

Privasi


VPN Anda berhenti berfungsi? Cara melewati sensor DPI dengan VPS Anda sendiri: apa yang sebenarnya dideteksi oleh deep packet inspection, dari lima protokol 2026 mana yang mengalahkan pemblokiran mana, dan panduan lengkap VLESS+REALITY.


FAQ 6-pertanyaan](https://servghost.com/id/guides/bypass-dpi-censorship-with-your-own-vps)
[### Enkripsi Disk Penuh di VPS: Setup LUKS dan Perlindungan Sebenarnya

Operasional


Cara mengenkripsi VPS dengan LUKS: volume data terenkripsi, full-root dengan remote unlock lewat SSH, pengaturan penting di server kecil, dan penjelasan jujur soal apa yang dicegah enkripsi disk.


FAQ 8-pertanyaan](https://servghost.com/id/guides/full-disk-encryption-on-a-vps)
[### Menyembunyikan IP Origin Server: CDN, Reverse Proxy, dan Kebocorannya

Privasi


Apakah perlu memasang CDN di depan server offshore: apa yang disembunyikannya, meja aduan yang Anda warisi, enam cara IP origin tetap bocor, dan cara mengauditnya sendiri.


FAQ 8-pertanyaan](https://servghost.com/id/guides/hiding-your-origin-server-ip)
[### Strategi Backup VPS: Terenkripsi, Off-Site, dan Bisa Dipulihkan

Operasional


Host Anda tidak menyimpan backup. Apa yang benar-benar merusak server, kenapa backup push ikut mati, restic vs Borg, kunci yang sering dilupakan, dan cara menguji restore.


FAQ 8-pertanyaan](https://servghost.com/id/guides/vps-backup-strategy)
[### Self-Hosting Server Matrix Sendiri: Synapse, Federation, E2EE

Operasional


Yang sungguh Anda dapatkan dari homeserver Matrix: Synapse vs Conduit, server_name yang tak bisa diubah, media pemenuh disk, dan yang tetap terlihat oleh federation.


FAQ 8-pertanyaan](https://servghost.com/id/guides/self-host-a-matrix-server)
[### Cara Migrasi Website ke Hosting Offshore Tanpa Downtime

Operasional


Urutan yang membuat migrasi hosting jadi membosankan: turunkan DNS TTL beberapa hari sebelumnya, jalankan kedua server secara paralel, bekukan penulisan data hanya beberapa menit, bukan berjam-jam — lalu bersihkan jejak passive-DNS, Certificate Transparency, dan WHOIS yang ditinggalkan proses pindah ini.


FAQ 8-pertanyaan](https://servghost.com/id/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operasional


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.


FAQ 8-pertanyaan](https://servghost.com/id/guides/self-host-a-crypto-payment-gateway)




## Host di tempat yang menyaring banjirnya



Server KVM offshore di tujuh yurisdiksi dengan filtering DDoS L3/L4, bandwidth unmetered, full root, dan storage NVMe. Tanpa KYC, pembayaran kripto, aktif dalam hitungan menit setelah transaksi terkonfirmasi.


[Lihat Paket VPS](https://servghost.com/id/vps)
[Server Dedicated](https://servghost.com/id/dedicated)
[Hosting Offshore](https://servghost.com/id/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 offshore dan server dedicated di 7 yurisdiksi offshore. Tanpa KYC, tanpa log, hanya kripto. Privasi sejak arsitektur.",
    "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": "Perlindungan DDoS VPS: Batas Host Anda, Awal Layer 7",
    "description": "Host Anda menyaring banjir paket; banjir permintaan menjadi tanggung jawab Anda. Cara kerja scrubbing L3/L4, mengapa serangan layer 7 lolos begitu saja, dan caching, rate limit, batas koneksi yang menjaga server offshore tetap online saat diserang.",
    "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": "id",
    "keywords": "proteksi DDoS VPS, cara mengatasi serangan DDoS di server, mitigasi DDoS layer 7, rate limiting nginx untuk DDoS, hosting anti DDoS offshore, filtering DDoS L3 L4, mitigasi SYN flood, sembunyikan IP origin dari DDoS",
    "articleSection": "Operasional",
    "wordCount": 4991
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Apakah \"perlindungan DDoS termasuk\" berarti saya aman dari segalanya?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Tidak, dan celahnya jelas, bukan samar-samar. Perlindungan yang sudah termasuk itu adalah filtering di network layer: ia menjatuhkan banjir volumetrik — SYN flood, UDP amplification, badai paket mentah — di upstream, sebelum sampai ke port Anda. Itu adalah kategori yang sungguh-sungguh tidak bisa Anda tangani sendiri, jadi memang tepat untuk disertakan. Ia tidak memeriksa aplikasi Anda, jadi banjir HTTP beberapa ribu permintaan per detik ke endpoint yang mahal akan lolos begitu saja dan menjatuhkan situs Anda sementara semua grafik network terlihat normal. Layer 7 adalah konfigurasi yang menjadi tanggung jawab Anda sendiri: caching, rate limit, dan batas koneksi."
            }
        },
        {
            "@type": "Question",
            "name": "Bagaimana cara membedakan serangan DDoS dari lonjakan lalu lintas biasa?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Tanyakan apakah lalu lintas itu menginginkan sesuatu. Pengunjung sungguhan, bahkan yang datang mendadak dan deras dari sebuah tautan populer, meminta halaman yang memang ada, memuat aset-aset di halaman itu, datang dengan referrer yang masuk akal, dan tersebar di banyak network dengan pola yang alami. Serangan biasanya menghantam satu path saja, mengabaikan aset, mengirim user-agent yang tidak masuk akal atau bahkan tidak ada sama sekali, dan menunjukkan distribusi yang terlihat sintetis. Periksa access log Anda untuk permintaan per alamat klien dan per path: jika satu endpoint mendominasi dan tidak ada yang lain dimuat, itu serangan. Jika halaman yang sama yang memang diinginkan manusia sedang disajikan dan referrer Anda sungguhan, Anda punya masalah kapasitas dengan penyebab yang menyenangkan."
            }
        },
        {
            "@type": "Question",
            "name": "Apa satu hal paling efektif yang bisa saya lakukan saat sedang diserang?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Nyalakan full-page caching untuk pengunjung anonim, dan konfigurasikan agar menyajikan konten stale saat backend sedang kepayahan. Rate limit menolak pekerjaan; cache membuat pekerjaan itu tidak perlu ada. Permintaan yang tadinya berbiaya satu query database, satu render template, dan satu worker aplikasi berubah menjadi pembacaan file, dan hardware yang sama yang tadinya kolaps di angka beberapa ratus permintaan dinamis per detik akan melayani puluhan ribu permintaan cache. Ini juga satu-satunya langkah dalam daftar ini yang sama efektifnya terhadap lalu lintas sungguhan, jadi tidak seperti rate limit, ini tidak bisa berbalik merugikan pengguna Anda sendiri."
            }
        },
        {
            "@type": "Question",
            "name": "Mengapa rate limit nginx saya berhenti bekerja setelah memasang CDN di depan?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Karena sekarang setiap permintaan tiba dari alamat CDN, bukan alamat pengunjung, sehingga limit per klien menghitung seluruh internet sebagai satu klien saja. Tergantung ambang batasnya, ini akan sama sekali tidak pernah terpicu atau justru memblokir seluruh lalu lintas Anda sekaligus. Konfigurasikan sumber real-IP Anda — di nginx, rentang proxy yang dipercaya ditambah header yang dikirim proxy tersebut — supaya limit itu kembali mengacu pada pengunjung sesungguhnya. Batasi kepercayaan itu hanya pada rentang milik proxy itu sendiri: jika Anda menerima header yang dipasok klien dari internet terbuka, penyerang bisa memalsukan identitas baru di setiap permintaan dan melenggang lolos dari setiap limit yang Anda miliki."
            }
        },
        {
            "@type": "Question",
            "name": "Apakah fail2ban cukup untuk menghentikan serangan DDoS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Tidak. fail2ban membaca log secara berkala dan memblokir alamat yang melanggar setelah melewati ambang batas, yang cocok untuk percobaan brute-force dari segelintir sumber. Serangan terdistribusi datang dalam hitungan detik dari ribuan alamat yang masing-masing hanya mengirim segelintir permintaan, jadi ambang batasnya tidak akan pernah tercapai, dan waktu reaksinya tetap jauh terlalu lambat. Lebih buruk lagi, ruleset yang membengkak sampai puluhan ribu entri bisa menghabiskan lebih banyak resource dibanding serangannya sendiri. Simpan fail2ban untuk SSH dan endpoint login, dan tangani banjir dengan caching, rate limiting, dan filter di upstream."
            }
        },
        {
            "@type": "Question",
            "name": "Sebaiknya pakai CDN, atau menjalankan reverse proxy sendiri di depan?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Itu bergantung pada apa yang Anda hosting, bukan pada anggaran Anda. CDN komersial membawa kapasitas penyerapan yang tidak bisa Anda tandingi dan halaman challenge hanya sejauh satu klik, tapi Anda ikut mewarisi meja aduannya dan ia bisa melihat lalu lintas Anda — yang untuk proyek offshore atau yang sensitif terhadap DMCA sering menjadi mata rantai paling lemah dalam susunan yang sebenarnya sudah hati-hati. Front node milik Anda sendiri membutuhkan lebih banyak kerja dan punya batas kapasitas yang nyata, tapi tidak ada pihak ketiga di jalur permintaan dan front yang diserang bisa diganti dengan alamat baru dalam hitungan menit. Apa pun pilihannya, origin harus di-firewall untuk hanya menerima lalu lintas web dari front tersebut, atau seluruh susunan itu hanya jadi hiasan."
            }
        },
        {
            "@type": "Question",
            "name": "Apakah serangan akan merugikan saya secara finansial, bukan cuma uptime?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Pada paket metered, ya — lalu lintas yang tidak pernah Anda minta dan tidak bisa Anda tolak tetap dihitung terhadap kuota transfer Anda, dan banjir yang berkelanjutan bisa menghasilkan tagihan kelebihan pakai yang lebih besar dari biaya hosting satu tahun. Inilah alasan praktis mengapa bandwidth unmetered jauh lebih penting daripada yang terlihat di lembar spesifikasi: ini mengubah risiko finansial menjadi risiko yang murni teknis. Ada baiknya juga diketahui lebih dulu bahwa jika sebuah serangan mengancam infrastruktur bersama, provider bisa saja untuk sementara melakukan null-route pada alamat itu; itu praktik standar di mana saja, bukan kegagalan dari host Anda secara khusus."
            }
        },
        {
            "@type": "Question",
            "name": "Apakah pindah ke host offshore atau no-KYC membuat serangan lebih mungkin terjadi?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Pilihan hosting itu sendiri netral; apa yang Anda jalankan itulah yang menarik perhatian. Game server, forum, streaming, marketplace, dan apa pun yang punya kompetitor atau dendam akan menarik serangan tidak peduli yurisdiksinya. Yang memang berubah di offshore adalah upaya pemulihan Anda: kemungkinan Anda diputus layanannya karena dianggap merepotkan jadi lebih kecil, dan ini berlaku dua arah — perlindungannya bersifat teknis, bukan kontraktual. Pilih lokasi dengan kapasitas transit yang sungguhan, ambil bandwidth unmetered, jaga alamat origin tetap tersembunyi, dan perlakukan layer 7 sebagai tanggung jawab Anda sendiri sejak hari pertama, bukan sejak insiden pertama."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Beranda",
            "item": "https://servghost.com/id/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Privasi Hosting Guides",
            "item": "https://servghost.com/id/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Perlindungan DDoS VPS: Batas Host Anda, Awal Layer 7",
            "item": "https://servghost.com/id/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```