[ホーム](https://servghost.com/ja) / [プライバシーホスティングガイド](https://servghost.com/ja/guides) / VPSのDDoS対策：ホストの防御が止まりレイヤー7が始まる場所 運用 # VPSへのDDoS攻撃を乗り切る どのホスティングプランも「DDoS対策込み」と謳っているが、そのすべてが指しているのは同じ狭い範囲のことだ——ネットワークがギガビット単位のフラッドを吸収する、という一点に限られる。実際に小規模なサイトを落とす攻撃は毎秒リクエスト数で測られ、攻撃者側のコストはほぼゼロで、見た目はまったく正当なアクセスとして届く。本ガイドはこの二つの境界線を引き、自分がどちら側にいるのかを1分で見分ける方法を示したうえで、あなたの側の防御として本当に機能するものを扱う。 [ガイドを読む](#guide-body) [FAQ](#guide-faq) ## このページの内容 - [ガイド](#guide-body) - [FAQ](#guide-faq) - [Related ガイドs](#guide-related) - [推奨 pages](#guide-cta) KYC不要 暗号資産決済のみ ログなし DMCA無視 フルroot NVMe SSD 27 min 読み込み Sep 2026更新 このページの内容 [01同じ名前を共有する二つの異なる攻撃](#同じ名前を共有する二つの異なる攻撃) [02「DDoS対策込み」が実際に買っているもの](#ddos対策込みが実際に買っているもの) [03まず、そもそも攻撃かどうかを見極める](#まずそもそも攻撃かどうかを見極める) [04サーバー自身から攻撃を読み取る](#サーバー自身から攻撃を読み取る) [05最初の10分間](#最初の10分間) [06効くレート制限と、誰もがやってしまう間違い](#効くレート制限と誰もがやってしまう間違い) [07キャッシュは、あなたが導入する中で最も安上がりな対策だ](#キャッシュはあなたが導入する中で最も安上がりな対策だ) [08倒れるかどうかを決める上限値](#倒れるかどうかを決める上限値) [09オリジンの手前に何かを置く](#オリジンの手前に何かを置く) [10隠されたオリジンは、どんなフィルタよりも価値がある](#隠されたオリジンはどんなフィルタよりも価値がある) [11攻撃を退屈なものにとどめるためのハードウェアとロケーションの選び方](#攻撃を退屈なものにとどめるためのハードウェアとロケーションの選び方) [12やってはいけない五つのこと](#やってはいけない五つのこと) [13要約版](#要約版) [FAQよくある質問](#guide-faq) [→推奨 pages](#guide-cta) DDoS対策が実際にどう機能するかを人が知る瞬間は二つある。一つ目は穏やかだ——購入時に「DDoS対策込み」という機能一覧を読み、その一文がすべてをカバーしていると何となく思い込む瞬間。二つ目は朝の三時、サイトがダウンし、グラフの様子がわけもわからず狂っていて、その「込み」だったはずの対策が——正しくも、そして設計通りに——まったく何もしていない瞬間だ。 どちらの瞬間も同じ製品と同じ真実にかかわっている。ホスティングプロバイダーは生のボリュームとして届く攻撃をフィルタリングできる。なぜならそのパケットが通る回線を所有しているのはプロバイダーであって、あなたではないからだ。一方で、通常に見えるリクエストとして届く攻撃はフィルタリングできない。ネットワークの視点からすれば、それは通常に見えるリクエストそのものだからだ。この境界線——ホストが吸収するフラッドと、自分自身で生き延びなければならないフラッドの間の境界線——こそが本ガイド全体の主題である。以下すべては、自分がその境界線のどちら側にいるかを見極め、それぞれの側で何をすべきかについて述べる。 ## 同じ名前を共有する二つの異なる攻撃 「DDoS」は一語でありながら、結果以外にほとんど共通点のない二つの問題を覆っている。それぞれ違う場所で、違う人間が、違う道具を使って止めるものであり、この二つを混同することこそ、対策の労力の大半が間違った層に注ぎ込まれる理由だ。 | | ボリューム型——レイヤー3・4 | アプリケーション型——レイヤー7 | | --- | --- | --- | | 届くもの | SYNフラッド、オープンDNS・NTP・memcachedリフレクターを経由したUDP増幅、ACKフラッド、ただのゴミパケット | 通常のHTTPリクエスト：GETフラッド、POSTフラッド、slow-loris、キャッシュを無効化するクエリ文字列 | | 単位 | ギガビットおよび毎秒数百万パケット | 毎秒リクエスト数——多くの場合わずか数千 | | 打撃を与えるのに必要な帯域 | 膨大。これは容量の勝負だ | ほぼゼロ。エンドポイントが十分に高コストならノートPC1台でも足りる | | 止めなければならない場所 | **上流、あなたのプロバイダーによって。**パケットがあなたのポートに届いた時点で、被害はすでに発生している | **あなたのサーバー上で、あなた自身が**、あるいはその手前にあなたが管理するプロキシで | | ボックス上での見え方 | インターフェースが飽和し、パケットカウンターが異常な値になる。CPUはアイドルのこともある | 帯域はほどほどだが、すべてのワーカーがビジーになり、負荷が上昇し、データベースのキューが伸びていく | | 誰が直すか | ホストのスクラビングが、自動的に、たいてい数秒以内に | あなたの設定——レート制限、キャッシュ、接続上限 | 最後の二行をもう一度読んでほしい。ここに実務上の要点が詰まっている。インターフェースが飽和しているなら、サーバーに何を打ち込んでも助けにはならない——パケットはすでにポートを消費してしまっており、それを落とせるのは上流のルーターを所有する当事者だけだ。逆にインターフェースは静かなのにサイトが落ちたままなら、話は逆になる。ホストの層では何も*おかしくない*ため、ホストには異常が見えておらず、直すのは完全にあなたの仕事だ。 ボリューム型フラッドは、容量のある上流でフィルタリングされる。そのフィルタをすり抜けてくるのは普通に見えるトラフィックであり、それを止めるのはホストではなくあなたの仕事だ。 ## 「DDoS対策込み」が実際に買っているもの ネットワーク層の対策は本物であり、価値があり、そしてほぼ常に誤解されている。プロバイダーがL3/L4フィルタリングを謳うとき、それが意味しているのは、あなたのアドレス宛のトラフィックをネットワークが監視し、フラッドを検知するとトラフィックをスクラビング用のハードウェアへ迂回させ、悪意のある部分を落として正当に見えるものだけを転送する、ということだ。これはサポートチケットなしに行われ、たいていは一瞬の乱れ以上には気づかれない。 この一文は多くのことを語っているので、何を含み何を含まないのかを分解しておく価値がある。 - **自分一人では生き延びられない攻撃をカバーする。**1Gbpsのポートを持つサーバーに対する200Gbpsの増幅フラッドは設定の問題ではない。単なる算数だ。上流でのスクラビングだけが唯一存在する答えである。 - **あなたのアプリケーションについては無頓着だ。**このフィルタは、どのURLが高コストか、どの訪問者がログイン済みか、検索エンドポイントへのリクエストがロゴ画像へのリクエストの400倍のコストだということを知らない。 - **反応するのはしきい値であって、あなたの苦しみではない。**検知はトラフィック量をトリガーにする。しきい値を一度も超えない攻撃は、どれほど徹底的にサイトを落としていようと、一切トリガーされない。 - **極端な場合には一時的にヌルルーティングされることがある。**どのネットワークにも上限がある。攻撃が共有インフラを脅かすなら、そのアドレスは一定期間切り離されることがある——これは標準的かつ普遍的な措置であり、事が起きている最中ではなく起きる前に知っておく価値がある。 **一行でまとめると。**あなたのホストは自らのネットワークを守り、あなたはその恩恵を受ける。だがあなたのアプリケーションは守らないし、守る手段もない。レイヤー7は出し惜しみされたアップセルではなく、プロバイダーがTLSを終端しない限り中身を覗けない層なのであり、オフショアでホスティングする者にとって、それは重大な代償を伴う取引にほかならない。 ## まず、そもそも攻撃かどうかを見極める DDoSだと疑われるインシデントのかなりの割合は、実は別の何かがその皮を被っているにすぎず、対処法は互換性がない。何かにレート制限をかける前に、まず2分かけて偽物を除外しておくこと——ここでの誤診は1時間を無駄にし、時には本物のユーザーまで失わせる。 - **人気が出ただけ。**大手アグリゲーターに載ったリンクは、レイヤー7フラッドとまったく同じ形のトラフィックを生み出す。違うのはリファラーが本物で、リクエストされているのが人間が見たがるページだという点だけだ。これは原因が幸福な容量の問題であり、レート制限をかけるのは自傷行為に等しい。 - **クローラーが行儀を忘れた。**強引なスクレイパーやAI学習用ボットは、小規模サーバーを軽々と圧倒しうる。たいていはユーザーエージェントが正体を白状しており、対処は一般的な制限ではなくrobots.txtと的を絞った制限だ。 - **自分で何かを壊した。**キャッシュを無効化してしまったデプロイ、暴走したcronジョブ、インデックスを失ったデータベース——どれも「突然の負荷、明白な原因なし」という形で現れる。タイミングが自分が行った変更と一致するなら、その変更を疑うべきだ。 - **自分自身の監視こそがフラッドだった。**まれで、間が悪く、そして誰もが認める以上によくある話だ。バックオフなしにリトライするヘルスチェックのループは、本当に見事なリクエストレートを生み出しうる。 見分けるための問いはシンプルだ。*そのトラフィックは何かを求めているか?*本物の負荷は——たとえ敵意があるように見える本物の負荷であっても——形を持つ。実在するページを叩き、リンクをたどり、アセットを読み込み、もっともらしく分散したネットワークからやってくる。攻撃はたいてい、そこまで律儀にやらない。 ## サーバー自身から攻撃を読み取る 何が起きているかを分類するのにダッシュボードは要らない。順番に実行する四つのコマンドが、自分がどの層と戦っているのかを1分足らずで教えてくれる——それが分かれば、次にすべきことはすべて決まる。 **回線は埋まっているか。**インターフェースのカウンターを見る。スループットがポートの上限に張り付いているなら、ボリューム型攻撃の最中であり、やるべきことは設定変更ではなくサポートチケットだ。 - vnstat -tr 10——10秒間の平均スループット。飽和状況を最速かつ正直に読み取れる。 - cat /proc/net/devを1秒間隔で2回——インターフェースごとのパケット数・バイト数の差分を、ツールなしで得られる。 **SYNフラッドか。**半開状態の接続がSYN-RECVに積み上がる。数個なら正常だが、数千となれば話は別だ。 - ss -s——サマリー行。状態別の接続数がひと目で分かる。 - ss -tn state syn-recv | wc -l——本当に重要な、その具体的な数値。 **レイヤー7か。**帯域はごく普通なのに何もかもが遅いなら、アクセスログでクライアントごとのリクエスト数を数える。1つのアドレスから数万ヒットが来ているなら素人の仕業であり、10万個のアドレスからそれぞれ3ヒットずつ来ているなら本物だ。 - tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30 - $1を$7に置き換えれば、代わりにリクエストされたパスをランキングできる。1つの高コストなエンドポイントが突出しているなら、標的を見つけたことになり、対処法も半分見つかったことになる。 **実際に何が枯渇しているのか。**ロードアベレージ単体ではほとんど何も分からない。自分がぶつかった具体的な上限を探すこと——PHP-FPMの子プロセスが全部ビジー、データベース接続が上限に達している、ファイルディスクリプタが枯渇している、あるいはワーカーがディスク待ちでD状態のまま固まっている、など。サイトを落としたのはトラフィックそのものではなくその上限であり、それを引き上げる方が何かをフィルタリングするより速いことが多い。 **調べている間、これを頭に置いておくこと。**プライバシー重視のサービスを運用しているなら、攻撃の最中こそロギングを強化してそのままにしておきたい誘惑に最も駆られる瞬間だ。必要なら強化してよいが、その後は必ず元に戻し、ログファイルを積極的にローテーションすること。1か月分の詳細な訪問者ログをディスクに残したままのインシデントは、一つの問題をより悪くより長く続く問題と交換しただけだ。この規律については当社の[サーバーOpSecガイド](https://servghost.com/ja/guides/server-opsec-staying-anonymous)で扱っている。 ## 最初の10分間 プレッシャーの下では、人は手近にある最大のレバーに手を伸ばしがちだが、その最大のレバーはたいてい間違っている。以下は被害を抑える順序であり、おおむね最速かつ最も安全なものから並べてある。 - **行動する前に分類する。**インターフェースが飽和していればボリューム型、静かなインターフェースでワーカーがビジーならレイヤー7。ここに30秒かけることで、間違った層を1時間かけて直す羽目にならずに済む。 - **ボリューム型なら、直ちにチケットを開く。**宛先アドレス、開始時刻、インターフェースのカウンターを添えること。そのあとはサーバーに手を出すのをやめる——これは中からは直せない。 - **レイヤー7なら、まずキャッシュ。**匿名訪問者向けに積極的なフルページキャッシュを有効にすることは、障害を肩をすくめるだけの出来事に変える最速の手段であり、本物のトラフィックに対しても等しく役立つ唯一の対策でもある。 - **次にレート制限をかける。**まず狙われているエンドポイント、それから他のすべて。控えめに始めること。自分のユーザーまで巻き添えにする制限は、攻撃の続きを自分の手で行っているようなものだ。 - **疑いようのないものだけをブロックする。**それぞれ10万リクエストを送ってくる十数個のアドレス、明らかに偽のユーザーエージェント、自分のユーザーが一人もいない国、など。攻撃を受けている最中に凝ったルールを書きたい衝動は抑えること——来月には覚えていない。 - **必要なら意図的に負荷を切り捨てる。**未認証の訪問者には静的な「メンテナンス中」ページを出すことで、ボックスを生かし続け、APIを稼働させ続け、考える時間を稼げる。何を犠牲にするかは自分で決める方が、勝手に決められるよりましだ。 - **やったことを書き残す。**追加した一時的なルールはすべて、未来の自分にとっての地雷になる。役に立ったルールは恒久化し、残りは翌日には外す。 ## 効くレート制限と、誰もがやってしまう間違い レイヤー7に対する主要な道具はレート制限であり、nginxは本当に異なる二つの問題を解決する二つのディレクティブでそれをうまくこなす。limit_reqはリクエストの*頻度*を制限する——クライアントがどれだけの頻度で要求できるか。limit_connは*同時接続数*を制限する——1クライアントが同時に開いておける接続がいくつか。フラッドを防ぐには前者が要り、ワーカープールを枯渇させるためにほぼアイドル状態の接続を数千も保持するslow-loris攻撃を防ぐには後者が要る。どちらか一方しか導入していなければ、問題の半分にしか対応できていない。 効く制限と、見せかけだけの制限を分ける細部が三つある。 - **バーストを使い、nodelayも使う。**本物のブラウザはバースト的だ——1回のページ閲覧が、ほぼ同時に十数件のアセットリクエストを発生させる。余裕のない制限は本物の訪問者を締め付ける一方で、しきい値のすぐ下でペースを合わせる攻撃者はすり抜けてしまう。 - **高コストなエンドポイントは個別に制限する。**検索ページ、ログインフォーム、パスワードリセット、データベースに書き込むあらゆるエンドポイントには、静的アセットよりはるかに厳しい予算を割り当てるべきだ。攻撃者は苦労せずこれらを見つけ出す。痛手になるのがまさにそこだからだ。 - **503ではなく429を返す。**このステータスコードは、行儀の良いクライアントや検索エンジンに対して、これが失敗ではなくスロットリングであるという合図になる——そしてひどい午後がランキングの問題に発展するのを防いでくれる。 **それをすべて静かに無効化してしまう間違い。**サーバーの手前に何か——CDN、ロードバランサー、自前のリバースプロキシ——が挟まっていると、すべてのリクエストは訪問者のアドレスではなく*その何か*のアドレスから届くことになる。すると、クライアント単位のレート制限はインターネット全体を1クライアントとして数えてしまい、まったく発動しないか、あるいはユーザー全員を一度に締め出すかのどちらかになる。制限が意味を持つよりも*前に*、real-IPの取得元を設定しなければならない（nginxでは、プロキシのアドレス範囲に対するset_real_ip_fromと、プロキシが送るヘッダーに対するreal_ip_header）。これもプロキシ自身のアドレス範囲だけに限定すること——オープンなインターネットからクライアントが提示したヘッダーを信用してしまうと、攻撃者はリクエストごとに新しい身元を偽装でき、あなたが持つすべての制限をまっすぐすり抜けてしまう。 ## キャッシュは、あなたが導入する中で最も安上がりな対策だ レート制限は仕事を拒否する。キャッシュは仕事そのものを存在しないことにする。匿名訪問者が見るものである限り、フルページキャッシュは攻撃全体の経済性を変えてしまう——データベースへの往復、テンプレートのレンダリング、PHPワーカーを1つ消費するはずだったリクエストが、マイクロ秒単位のファイル読み込みになる。毎秒400件の動的リクエストで潰れていたのと同じサーバーが、キャッシュされたリクエストなら数万件を涼しい顔でさばく。 本番でこれを有効にする際に重要なことは以下の通りだ。 - **キャッシュするのは匿名訪問者向けのものだけ。**セッションクッキーがあればバイパスする。ログイン中のあるユーザーのページを別のユーザーに出してしまうのは、直そうとしていた障害よりはるかに深刻な事態だ。 - **意図的にstaleを返す。**nginxのproxy_cache_use_staleをupdating error timeoutとともに使えば、バックエンドが苦しんでいるときに訪問者はエラーの代わりに少し古いページを受け取れる。攻撃の最中、これは「無事に見えるサイト」と「死んでいるように見えるサイト」を分ける違いになる。 - **重複したミスを一つにまとめる。**proxy_cache_lockは、キャッシュされていない同一ページへの1000件の同時リクエストが、1000件ではなく1件のバックエンドリクエストになることを保証する。これがないと、キャッシュを無効化する攻撃はキャッシュをすり抜けてそのままデータベースに全力で着弾する。 - **キャッシュを無効化するクエリ文字列を無力化する。**定番の手口は?とランダムな値を付け加え、すべてのリクエストを一意のキーにして永遠にミスさせることだ。アプリケーションが実際には使っていないクエリパラメータを無視するよう、キャッシュキーを正規化しておくこと。 ここには心に留めておく価値のある心地よい非対称性がある。キャッシュに費やす時間はどれも、サイトが最も調子の良い日にもサイトを速くし、運用コストを下げ、成功に耐える力を高めてくれる。何も問題が起きていないときに配当を払ってくれる防御策は、他にはほとんどない。 ## 倒れるかどうかを決める上限値 ほとんどのサーバーはCPUが尽きて死ぬわけではない。誰も意図的に設定した覚えのない見えない上限にぶつかって死ぬ——もう誰も使っていないハードウェアの上でなら理にかなっていた、十年前のデフォルト値だ。攻撃を受けたとき、実際に最初に壊れるのは次のものだ。 - **アプリケーションワーカー。**PHP-FPMのpm.max_children、Pythonのワーカー数、Nodeのクラスターサイズ。これがサイトの実質的な同時実行数の上限だ。全部ビジーになると、追加の訪問者はすべてキューに入り、CPUがどれほど暇そうに見えていようとサイトはダウンする。引き上げるのはメモリが許す範囲までにとどめること——スワップが起きるくらいならキューイングの方がましだ。 - **acceptキュー。**net.core.somaxconnとlistenのバックログが、acceptを待てる接続数を決める。バックログが小さいと、本来は乗り切れるはずのバーストが接続拒否に変わってしまう。 - **SYNクッキー。**net.ipv4.tcp_syncookiesは、決して完了しない接続のために状態を確保することなく、カーネルがSYNフラッドに応答できるようにする。最近のカーネルはデフォルトで有効になっているが、思い込まず確認すること。コストはゼロで、最も一般的なフラッドから身を守れる。 - **ファイルディスクリプタ。**すべての接続はディスクリプタを1つ消費する。デフォルトのnofile上限は、さばこうとしている接続数より低いことが多く、その障害の現れ方——他はすべて健全に見えるのにacceptだけが失敗する——は、朝の3時には本当に頭を悩ませる。 - **データベース接続。**コネクションプールを増やさずにワーカー数だけ増やしても、キューが見えにくい場所に移動するだけだ。この二つの数値は必ず一緒に調整すること。 これらはインシデントの最中ではなく、平穏な日に調整しておくこと。これらを知っておく意味は、サイトが倒れたときに、当て推量ではなくぶつかった上限をその場で名指しできる点にある——そして名指しできる上限は、直せる上限だ。 ## オリジンの手前に何かを置く ここまではすべてサーバー上で起きることだった。次に決めるべきは、そもそもサーバー自身がトラフィックを直接受け取るべきかどうかだ。正直な選択肢は三つあり、正解を決めるのは予算よりも、あなたが何をホストしているかの方だ。 | 方式 | 得られるもの | 代償 | | --- | --- | --- | | オリジンを直接公開し、固める | シンプルさ、第三者不在、自分の管理下にないTLS終端がないこと | アドレスが公開・恒久的になる。レイヤー7の対応は完全に自分の仕事 | | 商用CDNまたはスクラビングサービス | 圧倒的な吸収容量、ワンクリックのチャレンジページ、グローバルなキャッシュ | あなたのコンテンツについて意見を持つ苦情処理窓口と、あなたのトラフィックを見ることができる企業。オフショアやDMCAに敏感なプロジェクトにとっては、他をどれほど注意深く構成していても、これが最も弱い環になりうる | | 自前のフロントノード——nginxを動かす小さなVPSが、ファイアウォールで守られたオリジンへプロキシする | 完全な制御、リクエスト経路に第三者がいないこと、焼き捨てて交換できるアドレス、そして隠されたままの本物のアドレス | それ自体の容量制限と、運用するマシンが1台増えること。異なるネットワークに2、3個のフロントを置けば、落とすのを意味のある程度まで難しくできる | 自前でホストするフロントノードは、通常与えられる以上の注目に値する。特に、大手CDNが必ずしも同情してくれるとは限らない理由でオフショアホスティングを選んだ人にとってはそうだ。そのパターンは地味そのものだ——手前に安価なプロキシノードを置き、オリジンはファイアウォールでそれらのノードからの接続だけを受け付けるようにし、DNSはフロント群を指す。フロントが攻撃されたら、数分で新しいアドレスに交換すればよく、オリジンは何も気づかない。このアーキテクチャの全貌——それでもオリジンアドレスが漏れてしまう六つの経路も含めて——は、当社の[オリジンサーバーIPを隠す](https://servghost.com/ja/guides/hiding-your-origin-server-ip)ガイドで扱っている。 ## 隠されたオリジンは、どんなフィルタよりも価値がある これは率直に述べておく価値がある。通常の優先順位をひっくり返す話だからだ——あなたが利用できる最も安上がりなDDoS対策は、攻撃者が持っていないアドレスである。フィルタリングは、それがすでに失敗したときに行うことにすぎない。 これは聞こえる以上に重要だ。オリジンアドレスは絶えず、しかも静かに漏れ続けるからだ。プロキシを手前に置く前の過去のDNSレコードは、その変更よりも何年も長生きする。アプリケーションから直接送られるメールは、そのアドレスをヘッダーに載せている。生のアドレスに対して発行されたTLS証明書は、Certificate Transparencyログに恒久的に公開される。エラーページ、リダイレクト、あるいは一度もプロキシされたことのないマイナーなサブドメインも、すべて正体を明かしてしまう。かつて公開されていたサーバーの手前にCDNを置いたのであれば、アドレスを変更するまでは、古いアドレスは知られていると考えておくべきだ。 **その帰結はファイアウォールルールであり、本ガイド中で最も価値のある一行だ。**何かが手前に置かれた時点で、オリジンはフロントのアドレス以外からの80番・443番への接続をすべて拒否すべきである。これがなければ、プロキシは単なる提案にすぎない——本物のアドレスを知った者は誰でもそれを迂回して直接攻撃でき、フロント側で設定したことはすべて見せかけになってしまう。 ## 攻撃を退屈なものにとどめるためのハードウェアとロケーションの選び方 この一部は、攻撃が起きるよりずっと前、プランを選ぶ瞬間にすでに決まっている。スペック表が示唆する以上に重要な性質が三つある。 - **帯域無制限課金。**従量課金プランでは、攻撃は障害であるだけでなく請求書でもある。頼んでもいないし断ることもできなかったトラフィックが、それでも割り当てに計上されてしまう。無制限課金の転送量は、金銭的リスクを純粋に技術的なリスクへと変えてくれる。これははるかにましな部類の問題だ。 - **ポートが自分専用かどうか。**共有型の仮想化ホストでは、攻撃を受けている隣人があなたの性能まで劣化させることがあり、対策の上限も他人と共有することになる。専用ポートを持つ[専用ハードウェア](https://servghost.com/ja/dedicated)は、この両方の影響を取り除く。敵意ある注目を予期するプロジェクトにとって、コア数やRAM以上に、これこそが[VPS](https://servghost.com/ja/vps)から一段上へ移行する最も明確な理由だ。 - **ネットワークがどこにあるか。**実際のトランジット容量を持つ、接続性の良いヨーロッパのネットワークは、ピアリングの乏しいネットワークでは吸収できないフラッドを吸収できる。そして法的な理由で選んだ法域には、ネットワーク上の特性もある。利用可能な[ロケーション](https://servghost.com/ja/locations)から選ぶ際には、この両方を確認する価値がある。 また、静かにシンプルさを後押しする規模の議論もある。控えめなサーバー上でキャッシュの背後にある静的サイトは、驚くほど落としにくい。同じコンテンツを、キャッシュされない検索エンドポイントを持つ重量級CMSで動かせば、スクリプトを書く気になった一人の人間に壊されうる。動的な部分を減らすこと自体が対策であり、しかも無料だ。プロジェクトが本当に持続的な負荷にさらされているなら、当社の[高トラフィック向けホスティング](https://servghost.com/ja/use-cases/high-traffic-hosting)の記事が、同じ問題のサイジング面を扱っている。 ## やってはいけない五つのこと ここでの失敗パターンは一覧にできるほど一貫しており、そのどれもが誰かの週末を犠牲にしてきた。 - **自分自身をヌルルーティングしない。**自分のアドレスをブラックホール化することは、最も文字通りの意味で攻撃を終わらせる——ユーザーを含め、誰もあなたに到達できなくなる。これはプロバイダーにとっての最終手段であり、自分から進んで行う行動ではない。 - **fail2banをDDoS対策だと思わない。**少数のアドレスからのブルートフォースには良い道具だ。分散フラッドに対しては、数秒で届くものに数分かけて反応することになり、しかも数千のアドレスをBANするルールは、攻撃そのものよりファイアウォール処理に多くのコストをかけてしまうことがある。 - **身代金を払わない。**壊滅的な攻撃をちらつかせる恐喝メールの圧倒的多数は、能力のない人間が同一のメッセージを何千通も送っているだけのものだ。実際にやり遂げられるごく少数は、あなたが払うと証明してしまったがゆえに、また戻ってくる。 - **報復しない。**ほぼどこでも違法であることに加えて、送信元は乗っ取られた第三者だ。あなたは被害者を攻撃することになり、しかも紛れもなく自分のものだと分かるアドレスからそれを行うことになる。 - **パニックで移行しない。**攻撃の最中にホストを移すと、新しいアドレスは数分で公開され、しかも動作する設定が手元にない状態になる。まず安定させ、移行は後で計画的に行うこと——実際に移行するなら、当社の[ダウンタイムなしの移行](https://servghost.com/ja/guides/migrate-website-to-offshore-hosting)ガイドは、まさにその移行が第二のインシデントにならないようにするために存在している。 ## 要約版 理屈をそぎ落とせば、実用モデルは8行に収まる。 - **まず分類する。**インターフェースが飽和していればボリューム型であり、ホストの領分。静かなインターフェースでワーカーが枯渇していればレイヤー7であり、自分の領分。 - **ボリューム型なら、**アドレス、タイムスタンプ、カウンターを添えてチケットを出す——そのあとサーバーに触るのをやめる。 - **匿名訪問者向けに積極的にキャッシュし、**負荷が高いときはstaleを返し、重複したミスを一つにまとめる。これが打てる中で最もレバレッジの高い変更だ。 - **リクエスト頻度と同時接続数の両方でレート制限をかけ、**最もコストのかかるエンドポイントほど厳しくし、429を返す。 - **何よりも先にreal-IPの設定を直す。**そうでなければ、プロキシの背後にあるクライアント単位の制限はすべて、無意味であるか破滅的であるかのどちらかになる。 - **自分の上限を知っておく**——ワーカー、バックログ、ディスクリプタ、データベース接続——そして平穏な日に計画的に引き上げておく。 - **オリジンアドレスを秘密にし、**フロントノードだけにファイアウォールで限定する。これはどんなフィルタを全部合わせたものより価値がある。 - **帯域無制限課金を選ぶ。**頼んでもいないトラフィックが、そのまま請求書になることのないように。 これで無敵になるわけではなく、無敵を売る者は何か別のものを売っている。実際に起きるのは、暇な10代の若者にオフラインへ追いやられる側の集団から抜け出し、本物のリソースと本物の意図を必要とする側の集団へ移ることだ——そしてこれは、圧倒的多数のプロジェクトにとって、安全と区別がつかない。残りは、サーバーを他のあらゆる面でも優れたものにするのと同じ地味な作業だ——[初日に固めておくこと](https://servghost.com/ja/guides/first-hour-vps-hardening-checklist)、[最悪の日に復元できること](https://servghost.com/ja/guides/vps-backup-strategy)、そしてあなたのトラフィックを自分自身のビジネスとして扱ってくれる場所で動かすこと。 FAQ ## 小規模サーバーへのDDoS——よくある質問 ### 01 「DDoS対策込み」なら、すべてから安全ということですか。 いいえ、そしてその隙間は曖昧なものではなく明確なものです。標準で含まれる対策はネットワーク層のフィルタリングであり、SYNフラッド、UDP増幅、生のパケット洪水といったボリューム型のフラッドを、ポートに届く前に上流で落とします。これは自分ひとりでは本当に対処できない種類の攻撃であり、標準で含まれるべき正しいものです。ただしアプリケーションの中身は検査しないため、高コストなエンドポイントに対する毎秒数千リクエスト程度のHTTPフラッドはそのまま素通りし、すべてのネットワークグラフが正常に見えたままサイトを落とします。レイヤー7はあなた自身が持つ設定の領分です——キャッシュ、レート制限、接続上限です。 ### 02 DDoS攻撃と通常のアクセス急増をどう見分ければよいですか。 そのトラフィックが何かを求めているかを問うことです。人気リンクからの急激な流入であっても、本物の訪問者は実在するページをリクエストし、そのページ上のアセットも読み込み、もっともらしいリファラーを伴い、多くのネットワークに自然な形で分散します。攻撃はたいてい一つのパスばかりを叩き、アセットを無視し、不自然あるいは存在しないユーザーエージェントを送り、分布が人工的に見えます。アクセスログでクライアントアドレスごと、パスごとのリクエスト数を確認してください。一つのエンドポイントが突出していて他は何も読み込まれていないなら攻撃です。人間が見たがるのと同じページが配信されていて、リファラーも本物なら、原因が幸福な容量の問題です。 ### 03 攻撃を受けている最中に打てる、最も効果的な一手は何ですか。 匿名訪問者向けにフルページキャッシュを有効にし、バックエンドが苦しんでいるときはstaleなコンテンツを返すよう設定することです。レート制限は仕事を拒否しますが、キャッシュは仕事そのものを存在しないことにします。データベースへの問い合わせ、テンプレートのレンダリング、アプリケーションワーカーを消費していたリクエストがファイル読み込みになり、毎秒数百件の動的リクエストで潰れていたのと同じハードウェアが、キャッシュされたリクエストなら数万件をさばけます。これはまた、本物のトラフィックに対しても等しく役立つ唯一の対策でもあり、レート制限と違って自分のユーザーに跳ね返ることがありません。 ### 04 CDNを前段に置いたら、なぜnginxのレート制限が効かなくなったのですか。 すべてのリクエストが、訪問者のアドレスではなくCDNのアドレスから届くようになったためです。クライアント単位の制限がインターネット全体を1クライアントとして数えてしまっています。しきい値次第で、まったく発動しないか、あるいはトラフィック全体を一度に締め出すかのどちらかになります。real-IPの取得元——nginxであれば信頼するプロキシのアドレス範囲と、プロキシが送るヘッダー——を設定し、制限が再び実際の訪問者を基準にするようにしてください。その信頼はプロキシ自身のアドレス範囲だけに限定してください。オープンなインターネットからクライアントが提示したヘッダーを受け入れてしまうと、攻撃者はリクエストごとに新しい身元を偽装でき、あなたのすべての制限をすり抜けられてしまいます。 ### 05 fail2banだけでDDoS攻撃を止めるのに十分ですか。 いいえ。fail2banは一定間隔でログを読み、しきい値を超えた問題のあるアドレスをBANするもので、少数の送信元からのブルートフォース攻撃には向いています。分散攻撃は、それぞれがわずか数件のリクエストしか送らない数千のアドレスから数秒のうちに届くため、しきい値には到達せず、いずれにせよ反応速度もはるかに遅すぎます。さらに悪いことに、エントリ数が数万に膨れ上がったルールセットは、攻撃そのものより多くのリソースを消費しかねません。fail2banはSSHやログインエンドポイント用にとどめ、フラッドにはキャッシュ、レート制限、上流のフィルタで対処してください。 ### 06 CDNを使うべきですか、それとも自前のリバースプロキシを前段に置くべきですか。 これは予算よりも、何をホストしているかによって決まります。商用CDNは自分では太刀打ちできない吸収容量とワンクリックのチャレンジページをもたらしますが、その苦情処理窓口を引き継ぐことになり、CDN側にはトラフィックが見えてしまいます——オフショアやDMCAに敏感なプロジェクトにとっては、他をどれほど注意深く構成していても、これが最も弱い環になりがちです。自前のフロントノードはより多くの手間がかかり、実際の容量にも限界がありますが、リクエスト経路に第三者が存在せず、攻撃されたフロントは数分で新しいアドレスに交換できます。どちらの方式でも、オリジンはフロントからのWebトラフィックだけを受け付けるようファイアウォールで固めなければならず、そうしなければ構成全体が見せかけに終わります。 ### 07 攻撃は稼働時間だけでなく、金銭的な損失にもつながりますか。 従量課金プランであれば、はい。頼んでもいないし断ることもできなかったトラフィックが、それでも転送量の割り当てに計上され、持続的なフラッドは1年分のホスティング費用を超える超過料金の請求書を生むこともあります。これが、無制限課金の帯域がスペック表に見える以上に重要である実務上の理由です——金銭的リスクを純粋に技術的なリスクへと変えてくれるのです。また、攻撃が共有インフラを脅かす場合、プロバイダーが一時的にそのアドレスをヌルルーティングすることがあると、あらかじめ知っておく価値もあります。これはどこでも行われる標準的な対応であり、特定のホストの落ち度ではありません。 ### 08 オフショアやノーKYCのホストに移ると、攻撃を受けやすくなりますか。 ホスティングの選択自体は中立であり、注目を集めるのは何を運用しているかの方です。ゲームサーバー、フォーラム、配信、マーケットプレイス、そして競合や恨みを買うようなものは、法域を問わず攻撃を引き寄せます。オフショアで変わるのは対処の余地です——不都合な存在だからという理由で切り捨てられにくくなりますが、これは両刃の剣でもあります。保護は契約上のものではなく技術的なものになるのです。実際のトランジット容量を持つロケーションを選び、無制限課金の帯域を選び、オリジンアドレスを隠したままにし、レイヤー7は最初のインシデントからではなく最初の日から自分の責任として扱ってください。 Related ガイドs ## 続けて読む [### 2026年にオフショアホスティング法域を選ぶ方法 購入 オフショア法域を選ぶための実践的な意思決定フレームワーク: データ保持法、MLATの露出、DMCA対応姿勢、裁判所のスピード、実際の執行状況を国ごとに解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/choosing-an-offshore-jurisdiction) [### プライバシーが重要なワークロード向けのVPS vs 専用サーバー 購入 VPSで十分な場合、共有テナンシーが弱点になる場合、そしてベアメタルだけが誠実な答えになる場合を解説します。ハードウェア分離、ハイパーバイザーのリスク、コストと脅威モデルの比較について。 6の質問からなるFAQ](https://servghost.com/ja/guides/vps-vs-dedicated-for-privacy) [### No-KYC VPS上のセルフホストVPN: WireGuard vs OpenVPN 運用 セルフホストVPNが商用プロバイダーより優れている理由、そして2026年時点でWireGuardとOpenVPNがプライバシー、性能、運用リスクの面で実際にどう比較されるかを解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/self-hosted-vpn-wireguard-vs-openvpn) [### AI推論向けRTX 4090 vs H100 SXM5比較（RTX 5090はどこに位置するか） 購入 購入ガイド：2026年、セルフホストのLLM、画像、動画、音声、ファインチューニングのワークロードにはどのNVIDIA GPUを選ぶべきか。RTX 4090 vs RTX 5090 vs H100 SXM5 vs デュアルH100——VRAM、スループット、$/トークン、それぞれが優位になる場面を比較します。 6の質問からなるFAQ](https://servghost.com/ja/guides/rtx-4090-vs-h100-for-ai-inference) [### MT4 / MT5 / cTrader Forexトレード向けのオフショアWindows RDP 運用 完全ガイド：Forex取引にWindows RDPを使う理由、低遅延なオフショア法域の選び方、MT4 / MT5 / cTrader / Expert Advisorのセットアップ方法、ブローカーサーバーへの遅延、そしてKYC不要の決済フローまで解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/offshore-windows-rdp-for-forex-trading) [### DMCA無視ホスティング解説：2026年における本当の意味 購入 「DMCA無視」ホスティングが実際に何をもたらすのか、どの法域が本当に支持しているのか、それを必要とするワークロードとは何か、そしてその言葉がカバーしない著作権の落とし穴とは何か。 6の質問からなるFAQ](https://servghost.com/ja/guides/dmca-ignored-hosting-explained) [### 暗号通貨による匿名ドメイン登録：2026年のWHOISプライバシー プライバシー 身元を明かさずにドメインを登録するための2026年実践ガイド：TLD別WHOISの仕組み、レジストラの選択、暗号支払いオプション、そしてそれでも身元が漏れる運用上のミス。 6の質問からなるFAQ](https://servghost.com/ja/guides/anonymous-domain-registration-with-crypto) [### 暗号資産決済向けホスティング: Monero vs Bitcoin vs USDT プライバシー 支払いに使うコインによって、ホストに知られる情報がどう変わるかを解説します。XMR、BTC、USDTそれぞれのプライバシー、手数料、ファイナリティ、チェーン分析への露出を比較し、明確な結論を提示します。 6の質問からなるFAQ](https://servghost.com/ja/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### オフショアホスティングは本当に匿名なのか?正直な答え プライバシー オフショアのKYC不要ホスティングは、通常のホスティング業者が収集する身元情報を排除します——しかし「匿名」かどうかは、支払い方法、業者側のログ、そしてあなた自身のOPSEC次第です。実際に何が追跡可能なのかを解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/is-offshore-hosting-truly-anonymous) [### VPSハードニングの最初の1時間:チェックリスト 運用 新しいVPSを1時間以内に守るための、具体的で順序立ったチェックリスト。SSHキー、ファイアウォール、fail2ban、自動アップデート、そして無差別攻撃の大半を食い止める攻撃対象領域の削減。 6の質問からなるFAQ](https://servghost.com/ja/guides/first-hour-vps-hardening-checklist) [### No-KYCホスティングとは？定義・合法性・仕組みを解説 プライバシー No-KYCホスティングは、氏名・メールアドレス・身分証明書など一切の本人確認なしでサーバーを借りられるサービスです。その意味、技術的な仕組み、合法性、そして本物のプロバイダーの見分け方を詳しく解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/what-is-no-kyc-hosting) [### オフショアホスティングは合法か？2026年版・正直な回答 購入 オフショアホスティングは合法です――利用者にとっても、プロバイダーにとっても。この記事では、その用語の本当の意味、法的境界線の実態、払拭すべき誤解、そして責任ある活用方法を解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/is-offshore-hosting-legal) [### Monero（XMR）でホスティングを支払う方法 — ステップバイステップ プライバシー Monero（XMR）でVPSや専用サーバーの料金を支払うためのステップバイステップガイド：XMRがプライバシー保護の観点から最も優れた選択肢である理由、入手方法、そしてチェックアウトから数分でサーバーが稼働するまでの流れを解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/how-to-pay-for-hosting-with-monero) [### ウェブサイトを匿名でホスティングする方法 — 2026年版実践ガイド プライバシー アカウント、支払い、ドメイン、管轄地域、接続、コンテンツ — 身元を一切残さずウェブサイトをホスティングするための、層ごとに解説した実践的ガイド。 6の質問からなるFAQ](https://servghost.com/ja/guides/how-to-host-a-website-anonymously) [### VPSにWireGuard VPNを構築する — ステップバイステップガイド 運用 WireGuardを使ってVPS上に自分専用のプライベートVPNを構築する方法：セルフホスト型VPNが商用VPNより優れている理由から、インストールからクライアント接続まで完全なセットアップ手順、そして堅牢化の方法まで解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### GPUサーバーでLLMをセルフホストする方法 — 2026年版ガイド 運用 レンタルGPUサーバーで独自の大規模言語モデルを稼働させる：APIより自己ホスティングが優れている理由、GPUとモデルの選び方、OllamaまたはvLLMを使ったセットアップ、そしてコストについて。 6の質問からなるFAQ](https://servghost.com/ja/guides/self-host-an-llm-on-a-gpu-server) [### バレットプルーフホスティングとオフショアホスティング — その違いとは？ 購入 バレットプルーフホスティングとオフショアホスティングは混同されがちですが、まったく別物です。両者の本質的な違い、その重要性、そして実際にどちらを選ぶべきかを解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/bulletproof-vs-offshore-hosting) [### BitcoinでVPSを購入する方法――ステップバイステップ完全ガイド（2026年版） 購入 BitcoinでVPSを購入するための初心者向けガイド。BTCの入手方法、プランの選び方、請求書の支払い方、そして手に入るものが何か――カードも氏名も不要なサーバーを手順を追って解説します。 6の質問からなるFAQ](https://servghost.com/ja/guides/how-to-buy-a-vps-with-bitcoin) [### DMCAを無視できるホスティングに最適な国（2026年版） 購入 米国式の削除申請が届かないサーバーをどこに置くか——機能する法域、「DMCA無視」が本当に意味すること、そして選び方。 6の質問からなるFAQ](https://servghost.com/ja/guides/best-countries-for-dmca-ignored-hosting) [### Torの隠しサービス（.onionサイト）のホスティング方法 — 2026年版ガイド 運用 VPS上にTor onionサービスを構築する：隠しサービスとは何か、それが最も強力な匿名ホスティング形態である理由、完全な設定手順、そして真の匿名性を維持する方法。 6の質問からなるFAQ](https://servghost.com/ja/guides/how-to-host-a-tor-hidden-service) [### オフショアメールサーバーの構築 — 2026年版・プライベートメールを自己ホスト 運用 オフショアVPS上でプライベートメールサーバーを自己ホストする方法：なぜ自己ホストするのか、何が必要か、オールインワンメールスタックによる現実的な構築手順、そして配信可能性を正しく確保する方法。 6の質問からなるFAQ](https://servghost.com/ja/guides/offshore-mail-server-setup) [### 暗号ノードホスティングガイド — VPS でブロックチェーンノードを運用する 運用 ブロックチェーンノードをサーバー上でホストする方法：自前のノードを運用する理由、Bitcoin・Ethereum・Monero などに適したサーバー構成、セットアップ手順、そしてプライバシーを守りながら運用する方法。 6の質問からなるFAQ](https://servghost.com/ja/guides/crypto-node-hosting-guide) [### Stable Diffusion 向け GPU ホスティング — 自分だけの画像生成サーバーを運用する 運用 GPU サーバーで Stable Diffusion を自己ホストする方法：セルフホスティングの理由、最適な GPU の選び方、Web UI のセットアップ、そしてホスト型サービスとのコスト比較。 6の質問からなるFAQ](https://servghost.com/ja/guides/gpu-hosting-for-stable-diffusion) [### サーバーOpSec — サーバー運用時に匿名性を維持する方法 プライバシー 匿名サーバーを運用するすべての人のための運用セキュリティ：身元が特定されてしまう失敗のパターン、それを防ぐ習慣、そして真に独立したアイデンティティを保ち続ける方法。 6の質問からなるFAQ](https://servghost.com/ja/guides/server-opsec-staying-anonymous) [### シードボックス設定ガイド — 2026年版プライベートシードボックスの自己構築 運用 サーバー上に自分だけのシードボックスを構築する方法：シードボックスとは何か、サイジングの考え方、WebUI付きトレントクライアントのインストール、そしてプライベートかつ安全に保つための手順。 6の質問からなるFAQ](https://servghost.com/ja/guides/seedbox-setup-guide) [### 自前のVPSでDPI検閲を回避する方法(2026年版ガイド) プライバシー VPNが突然つながらなくなった?自前のVPSでDPI検閲を回避する方法を解説する。ディープパケットインスペクション(DPI)が実際に何を検知しているのか、2026年時点で有効な5つのプロトコルがそれぞれどのブロック手法に強いのか、そしてVLESS+REALITYの導入手順をひと通り示す。 6の質問からなるFAQ](https://servghost.com/ja/guides/bypass-dpi-censorship-with-your-own-vps) [### VPSのフルディスク暗号化：LUKS導入と本当に守れるもの 運用 VPSをLUKSで暗号化する方法を解説します。暗号化データボリューム、dropbearによるSSH経由リモートロック解除を伴うフルルート暗号化、インストール時に暗号化するベアメタルという3つの構成、小規模サーバーで本当に重要になる設定、そしてディスク暗号化が実際に何を防ぎ、何を防がないのかを正直に説明します。 8の質問からなるFAQ](https://servghost.com/ja/guides/full-disk-encryption-on-a-vps) [### オリジンサーバーIPを隠す：CDN・リバースプロキシと漏れる経路 プライバシー オフショアサーバーの前にCDNやリバースプロキシを置くべきかどうかを解説します。CDNが実際に何を隠してくれるのか、その代わりに背負うことになる苦情処理の窓口、そして設定を誤るとオリジンサーバーのIPアドレスが漏れてしまう6つの経路と、自分のIPアドレスを10分で監査する具体的な手順までを正直に述べます。 8の質問からなるFAQ](https://servghost.com/ja/guides/hiding-your-origin-server-ip) [### VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証 運用 ホスティング業者はバックアップを保持しません。サーバーを壊す本当の原因、restic対BorgBackupの選び方、忘れがちな鍵、復元テストの手順まで解説します。 8の質問からなるFAQ](https://servghost.com/ja/guides/vps-backup-strategy) [### Matrixサーバーのセルフホスト:Synapseと連合の実態 運用 Matrixホームサーバーで本当に変わることとは。Synapse・Conduitの違い、変更不可能なserver_name、肥大化するメディア保存、連合が明かす情報を解説します。 8の質問からなるFAQ](https://servghost.com/ja/guides/self-host-a-matrix-server) [### サイトをオフショアホスティングへダウンタイムゼロで移行する方法 運用 ホスト移行を退屈な作業に変える順序をご紹介します。DNSのTTLを数日前に下げ、2台のサーバーを並行稼働させて書き込みフリーズを時間ではなく分に抑え、さらに移行が残すパッシブDNSやCertificate Transparency、WHOISの痕跡を消す方法まで解説します。 8の質問からなるFAQ](https://servghost.com/ja/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server 運用 Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8の質問からなるFAQ](https://servghost.com/ja/guides/self-host-a-crypto-payment-gateway) ## フラッドをフィルタリングしてくれる場所に置く 7つの法域から選べるオフショアKVMサーバーに、L3/L4のDDoSフィルタリング、無制限課金の帯域、フルルート権限、NVMeストレージが付属します。KYCは不要、暗号資産での決済に対応し、取引確認から数分でデプロイされます。 [VPSプランを見る](https://servghost.com/ja/vps) [専用サーバー](https://servghost.com/ja/dedicated) [オフショアホスティング](https://servghost.com/ja/offshore-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servghost.com/#organization", "name": "ServGhost", "url": "https://servghost.com", "description": "7つのオフショア法域で提供するVPSと専用サーバー。KYC不要、ログなし、暗号資産決済のみ。設計段階からプライバシーを重視しています。", "logo": { "@type": "ImageObject", "url": "https://servghost.com/ServGhost.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servghost.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servghost.com/canary", "https://servghost.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servghost.com/#website", "url": "https://servghost.com", "name": "ServGhost", "publisher": { "@id": "https://servghost.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPSのDDoS対策：ホストの防御が止まりレイヤー7が始まる場所", "description": "パケットの洪水はホストが濾過しますが、リクエストの洪水を防ぐのはあなたの仕事です。L3/L4スクラビングの仕組み、レイヤー7攻撃がすり抜ける理由、そして攻撃を受けている間も小さなオフショアサーバーを稼働させ続けるキャッシュ、レート制限、接続上限を解説します。", "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011", "author": { "@type": "Organization", "@id": "https://servghost.com/#editorial", "name": "ServGhost Editorial", "url": "https://servghost.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servghost.com/#organization" } }, "publisher": { "@id": "https://servghost.com/#organization" }, "datePublished": "2026-09-07T00:00:00+00:00", "dateModified": "2026-09-07T00:00:00+00:00", "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps", "inLanguage": "ja", "keywords": "VPS DDoS対策, サーバー DDoS攻撃 対処法, レイヤー7 DDoS対策, nginx レート制限 DDoS, オフショア DDoS対策 ホスティング, SYNフラッド 対策, オリジンIP 隠す 方法, L3 L4 DDoSフィルタリング", "articleSection": "運用", "wordCount": 5359 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "「DDoS対策込み」なら、すべてから安全ということですか。", "acceptedAnswer": { "@type": "Answer", "text": "いいえ、そしてその隙間は曖昧なものではなく明確なものです。標準で含まれる対策はネットワーク層のフィルタリングであり、SYNフラッド、UDP増幅、生のパケット洪水といったボリューム型のフラッドを、ポートに届く前に上流で落とします。これは自分ひとりでは本当に対処できない種類の攻撃であり、標準で含まれるべき正しいものです。ただしアプリケーションの中身は検査しないため、高コストなエンドポイントに対する毎秒数千リクエスト程度のHTTPフラッドはそのまま素通りし、すべてのネットワークグラフが正常に見えたままサイトを落とします。レイヤー7はあなた自身が持つ設定の領分です——キャッシュ、レート制限、接続上限です。" } }, { "@type": "Question", "name": "DDoS攻撃と通常のアクセス急増をどう見分ければよいですか。", "acceptedAnswer": { "@type": "Answer", "text": "そのトラフィックが何かを求めているかを問うことです。人気リンクからの急激な流入であっても、本物の訪問者は実在するページをリクエストし、そのページ上のアセットも読み込み、もっともらしいリファラーを伴い、多くのネットワークに自然な形で分散します。攻撃はたいてい一つのパスばかりを叩き、アセットを無視し、不自然あるいは存在しないユーザーエージェントを送り、分布が人工的に見えます。アクセスログでクライアントアドレスごと、パスごとのリクエスト数を確認してください。一つのエンドポイントが突出していて他は何も読み込まれていないなら攻撃です。人間が見たがるのと同じページが配信されていて、リファラーも本物なら、原因が幸福な容量の問題です。" } }, { "@type": "Question", "name": "攻撃を受けている最中に打てる、最も効果的な一手は何ですか。", "acceptedAnswer": { "@type": "Answer", "text": "匿名訪問者向けにフルページキャッシュを有効にし、バックエンドが苦しんでいるときはstaleなコンテンツを返すよう設定することです。レート制限は仕事を拒否しますが、キャッシュは仕事そのものを存在しないことにします。データベースへの問い合わせ、テンプレートのレンダリング、アプリケーションワーカーを消費していたリクエストがファイル読み込みになり、毎秒数百件の動的リクエストで潰れていたのと同じハードウェアが、キャッシュされたリクエストなら数万件をさばけます。これはまた、本物のトラフィックに対しても等しく役立つ唯一の対策でもあり、レート制限と違って自分のユーザーに跳ね返ることがありません。" } }, { "@type": "Question", "name": "CDNを前段に置いたら、なぜnginxのレート制限が効かなくなったのですか。", "acceptedAnswer": { "@type": "Answer", "text": "すべてのリクエストが、訪問者のアドレスではなくCDNのアドレスから届くようになったためです。クライアント単位の制限がインターネット全体を1クライアントとして数えてしまっています。しきい値次第で、まったく発動しないか、あるいはトラフィック全体を一度に締め出すかのどちらかになります。real-IPの取得元——nginxであれば信頼するプロキシのアドレス範囲と、プロキシが送るヘッダー——を設定し、制限が再び実際の訪問者を基準にするようにしてください。その信頼はプロキシ自身のアドレス範囲だけに限定してください。オープンなインターネットからクライアントが提示したヘッダーを受け入れてしまうと、攻撃者はリクエストごとに新しい身元を偽装でき、あなたのすべての制限をすり抜けられてしまいます。" } }, { "@type": "Question", "name": "fail2banだけでDDoS攻撃を止めるのに十分ですか。", "acceptedAnswer": { "@type": "Answer", "text": "いいえ。fail2banは一定間隔でログを読み、しきい値を超えた問題のあるアドレスをBANするもので、少数の送信元からのブルートフォース攻撃には向いています。分散攻撃は、それぞれがわずか数件のリクエストしか送らない数千のアドレスから数秒のうちに届くため、しきい値には到達せず、いずれにせよ反応速度もはるかに遅すぎます。さらに悪いことに、エントリ数が数万に膨れ上がったルールセットは、攻撃そのものより多くのリソースを消費しかねません。fail2banはSSHやログインエンドポイント用にとどめ、フラッドにはキャッシュ、レート制限、上流のフィルタで対処してください。" } }, { "@type": "Question", "name": "CDNを使うべきですか、それとも自前のリバースプロキシを前段に置くべきですか。", "acceptedAnswer": { "@type": "Answer", "text": "これは予算よりも、何をホストしているかによって決まります。商用CDNは自分では太刀打ちできない吸収容量とワンクリックのチャレンジページをもたらしますが、その苦情処理窓口を引き継ぐことになり、CDN側にはトラフィックが見えてしまいます——オフショアやDMCAに敏感なプロジェクトにとっては、他をどれほど注意深く構成していても、これが最も弱い環になりがちです。自前のフロントノードはより多くの手間がかかり、実際の容量にも限界がありますが、リクエスト経路に第三者が存在せず、攻撃されたフロントは数分で新しいアドレスに交換できます。どちらの方式でも、オリジンはフロントからのWebトラフィックだけを受け付けるようファイアウォールで固めなければならず、そうしなければ構成全体が見せかけに終わります。" } }, { "@type": "Question", "name": "攻撃は稼働時間だけでなく、金銭的な損失にもつながりますか。", "acceptedAnswer": { "@type": "Answer", "text": "従量課金プランであれば、はい。頼んでもいないし断ることもできなかったトラフィックが、それでも転送量の割り当てに計上され、持続的なフラッドは1年分のホスティング費用を超える超過料金の請求書を生むこともあります。これが、無制限課金の帯域がスペック表に見える以上に重要である実務上の理由です——金銭的リスクを純粋に技術的なリスクへと変えてくれるのです。また、攻撃が共有インフラを脅かす場合、プロバイダーが一時的にそのアドレスをヌルルーティングすることがあると、あらかじめ知っておく価値もあります。これはどこでも行われる標準的な対応であり、特定のホストの落ち度ではありません。" } }, { "@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/ja/" }, { "@type": "ListItem", "position": 2, "name": "プライバシーホスティングガイド", "item": "https://servghost.com/ja/guides" }, { "@type": "ListItem", "position": 3, "name": "VPSのDDoS対策：ホストの防御が止まりレイヤー7が始まる場所", "item": "https://servghost.com/ja/guides/surviving-a-ddos-attack-on-your-vps" } ] } ```