Hytale サーバーを DDoS 攻撃から守る

夜のプレイ中に全接続を同時に失い、数分のあいだ到達不能になり、そのあと自然に戻る Hytale サーバーに、ハードウェアの問題があることはまずありません。多くの場合、攻撃が走っています。本記事では、Hytale サーバーを DDoS 攻撃から守る方法を示します。まず追加費用なしでご自身で設定できる範囲、次にその対策が技術的にどこで終わるのか、最後に、サーバーが到達可能なままであるためにサーバーの手前のネットワークで何が起きる必要があるかです。

本記事の記述はすべて、Hypixel Studios の公式の専用サーバー、つまり Java 25 上の HytaleServer.jar と Assets.zip を前提としており、動作環境は Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS です。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。Hytale はアーリーアクセスで、動きが速いです。そのため本記事ではゲームに関する記述のすべてに日付を添えてあり、公式に裏づけのないものは、見込みなのかコミュニティ由来なのかを明示しています。攻撃がいま進行中の場合は、さらに順番が決まっています。まず測定し、それから変更します。負荷がかかっているときの強制的な再起動は、ワールドが最後に保存された時点以降に起きたことをすべて捨て、しかもその事案の測定値もあわせて消えます。

Hytale サーバーが DDoS 攻撃で狙って止められる理由

Hytale サーバーは、固定したアドレスに集まった人の輪であり、その輪は取り替え可能です。夜に 3 回続けて常用のサーバーへ入れなければ、人は別のサーバーを探します。コミュニティサーバーへの攻撃の裏にある仕組みは、まさにそこです。狙いはデータでも脅迫でもなく、離れていくプレイヤーです。1 つのアドレスを月に数ユーロで撃つ booter のサービスは、依頼者に技術も手間も求めず、しかも損害は障害ごとに新しく生じます。

Hytale にはさらに固有の事情があります。サーバーのコードが公開されていることです。Hypixel Studios は 2026 年 6 月に Hytale Shared Source という取り組みを発表し、そこでサーバーのコード一式、ネットワークプロトコル、アセットを GitHub で提供しています。有効なゲームのライセンスを持つ人なら誰でも参照できます。サーバーの運用者には利点です。プラグインが本物のインターフェースに対して作れるからです。攻撃する側にとっては、プロトコルをもう推測しなくてよいという意味になります。接続確立のどこで計算時間がかかるのかを知りたければ、読めば分かります。こうした攻撃で技術的に何が起きるかは、記事 DDoS 攻撃とは何か で解説しています。

2026 年 9 月 27 日時点の Hytale の状況

Hytale は 2026 年 1 月 13 日からアーリーアクセスで、Windows、macOS、Linux 向けに入手でき、開始後の数日で 100 万人を超えるプレイヤーに達しました。そこまでの道筋は異例で、Hytale について書かれた古い記事がしばしばもう正しくない理由もそこにあります。

この年表から出てくる実務上の結論はこうです。今日の Hytale サーバーは 1 月のサーバーではありません。Update 6 でネットワークプロトコルが hytale/2 から hytale/3 へ変わり、2026 年 8 月 27 日の公式のパッチノートによれば、サーバーとプラグインは接続する前に作り直す必要があります。ですから可用性を計画する人は、攻撃に対してだけでなく、プロトコルの変更に対しても計画します。

2026 年 10 月 12 日が要注意の日程である理由

大きな内容の更新は、2 度目の発売のように働きます。古いプレイヤーを呼び戻し、新しいプレイヤーを引き寄せ、そして数日のあいだ、どのコミュニティサーバーがこの波で伸びてどれが逃すかを、到達可能かどうかが決めます。このパターンはほかのゲームで確認されています。Palworld は 2024 年 1 月に数日で数百万人のプレイヤーに達し、その立ち上がりのコミュニティサーバーは、失うものが最も大きいまさにその瞬間に、最も攻撃されました。その仕組みは Palworld サーバーを DDoS 攻撃から守る に詳しく書いてあり、そのまま Hytale に当てはめられます。

そこから、日程についての居心地の悪い事実が出てきます。10 月 12 日に注文した保護では遅すぎます。回線、保護 IP、ポートごとのルールセット、平常運転の測定値には、いずれも前倒しの時間が必要です。比較できるデータがなければ、意味のある設定はできません。大きな更新の 2 週間前に始めれば、時間は足ります。更新の当日に始めれば、計器なしの飛行で調整することになります。

Hytale サーバーで実際に問題になるポート

Hytale サーバーが開ける必要のあるポートは、ちょうど 1 つです。5520 UDP です。ゲームトラフィックは QUIC、つまり UDP の上を流れ、ゲームの動作に TCP は必要ありません。TCP だけを開けた場合に見えるのは、ファイアウォールを閉じたときと同じ絵です。プレイヤーはタイムアウトに落ちます。初期の束縛先は 0.0.0.0:5520 で、別のポートは起動時に --bind で指定します。

この表は、ほかのたいていのゲームより短いです。そしてそれが最も重要な違いです。Counter-Strike のサーバーは Steam 形式の A2S でステータス問い合わせに応答し、Minecraft Bedrock のサーバーは Unconnected Ping に応答し、Palworld のサーバーは独自のクエリポートを開いたままにします。Hytale については、公開されているドキュメントに 5520 UDP 以外のポートの記述がありません。出荷時の状態では、クエリポートも RCON のポートも REST のインターフェースもありません。Hytale サーバーが外に向けて出すものはすべて、1 つの UDP ポートに載っています。

数字で見る Hytale サーバー

以下の値は、フィルタールールと上限値についてのあらゆる判断の土台です。出どころは値ごとに添えてあります。それが、その値をどこまで信頼できるかを決めるからです。

QUIC が攻撃対象領域をどう変えるか

QUIC は、UDP の上で保護された接続を確立する転送プロトコルで、TLS 1.3 に沿った暗号化の確立を最初から組み込んでいます。暗号化されない QUIC は存在しません。サーバーの運用者にとって、これは互いに矛盾する 2 つのことを意味し、どちらも重要です。

1 つ目は本物の改善です。UDP は接続確立を強制せず、送信元アドレスは偽装できるため、コネクションレスパケットを扱う UDP のサービスは、第三者への攻撃の古典的な増幅器です。QUIC は標準の段階でこれを制限します。RFC 9000 は 8.1 節で、サーバーは送信元アドレスを検証する前に、受け取ったバイト数の 3 倍を超えて送ってはならないと定めており、14.1 節はクライアントが最初のデータグラムを少なくとも 1200 バイトまで埋めることを要求しています。この 2 つの規定が合わさって、QUIC のサービスの増幅率は最大 3 に抑えられます。一方で Steam のクエリポートや Bedrock の Unconnected Ping は、その何倍にもなります。ですから正しく動いている Hytale サーバーは、リフレクションの増幅器としては事実上の価値がありません。これは UDP を使うほぼすべてのゲームに対する構造的な利点で、Minecraft Bedrock サーバー と比べるとはっきり分かります。

2 つ目はその代償です。QUIC の接続確立はサーバーの計算時間を消費します。非対称鍵の暗号処理を含む TLS 1.3 のネゴシエーションが入るからです。偽装された 1 つのパケットで接続確立を強いることはできませんが、ボットネットからの本物の接続試行のあふれならできます。このとき攻撃側も計算時間を払っており、まさにその比率が決め手です。サーバーが接続試行 1 件につき攻撃側より多くの作業をしているあいだは、攻撃は採算が合います。ですから接続試行のあふれは回線ではなくプロセッサーに負荷をかけ、帯域幅の統計では何も起きていないように見えます。これは Minecraft で Nullping やハンドシェイクフラッドとして知られているものと同じ仕組みで、記事 Minecraft の DDoS 対策と Nullping 対策 で詳しく説明しています。

ここから実務に使えるのは、とくに 1200 バイトの規定です。新しい接続試行は、少なくとも 1200 バイトのデータグラムとして届かなければならず、そうでなければ標準に照らして有効な接続確立ではありません。これに対して、流れているゲームトラフィックは大半が小さなパケットです。この区別はフィルタールールに落とせます。それはすぐあとで扱います。

Hytale について公開されていないこと

この一覧は誠実な記事に必要です。数値に頼ってはいけない場所を定めるからです。以下はすべて、2026 年 9 月 27 日の時点で公式の裏づけがありません。

• サーバーがアドレスの検証に QUIC の Retry を使うかどうか。RFC 9000 は 8.1.2 節で、資源を確保する前にサーバーが送信元アドレスを検証するための、トークン付きの Retry パケットを認めています。Hytale がそれを行うのか、行うとしてどの負荷から行うのかは、ドキュメントにありません。頼りにできないものとして考えてください。
• config.json の RateLimit と ConnectionTimeouts のブロックの初期値。この 2 つのブロックが存在すること自体は、複数の出どころで一致しています。しかし挙げられている数値は互いに矛盾します。ある出どころは具体的な上限値を挙げ、別の出どころはブロックは存在するが効果がないと記しています。ですから本記事にはこれらの数値を一切載せていませんし、これらのブロックを防御として計画に入れるべきではありません。
• 認証モードの名称と初期値。公開されたサーバーのコードについてのコミュニティのドキュメントは、--auth-mode で指定する 3 つのモードを記しています。初期値が authenticated で、私的な環境と開発向けに offline と insecure があります。これは公式には確認されていません。それでも、そこから導かれる原則は明確です。公開サーバーではモードを変えないでください。
• TLS の確立の細部。公開されたサーバーのコードに基づくコミュニティのプロトコル文書は、双方向の証明書、起動時に生成される自己署名のサーバー証明書、その SHA-256 のフィンガープリントがセッションのサービス経由でクライアントに届く仕組み、そして無効化された 0-RTT を記しています。もっともらしく、TLS 1.3 とも整合しますが、公式には確認されておらず、この後の対策を変えるものでもありません。
• Hytale サーバーに固有の攻撃の規模。これについて公開された数値はありません。表に挙げた 5 から 50 Gbit/s は、ゲームサーバーのプロジェクトをまたいだ経験的な値であり、Hytale の統計ではないことを明示しておきます。
• 平常運転でのプレイヤー 1 人あたりのパケットレート。これについても信頼できる公開情報はありません。ですから本記事には、確認せずにそのまま使える上限値ではなく、ご自身で測る手順を載せています。

費用をかける前に自分でできること

以下の手順はボリューム型攻撃を止められません。それはサーバー上のソフトウェアにはできないことです。しかしその下にあるものはすべて片づけます。ポートスキャン、少数の発信源からの接続試行のあふれ、追加で入れた管理画面からの乗っ取りの試み、そして無関係な相手による全スロットの占有です。これが日常で Hytale サーバーを困らせるものの大半で、必要な時間は 1 時間あまりです。

1. 現状把握：サーバーで何が待ち受けているか

ルールを 1 本書く前に、お使いのサーバーが外に向けて何を出しているかを確認してください。推測ではなく、確認です。

ss -lntup

注目するのはローカルアドレスの列です。0.0.0.0:5520 は「インターネット全体から到達可能」を意味し、127.0.0.1:8080 は「ローカルだけ」を意味して開放は要りません。サーバーの Java のプロセスのほかに、使い込んだマシンではしばしば管理パネル、地図の表示用のウェブサーバー、データベースが現れます。攻撃側からの見え方は、外からのポートスキャンで分かります。

nmap -Pn -sU -p 5520 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2 つ目の実行のほうが重要です。ほかに何が開いているかを示し、実際にはほぼ必ず、思っていたより多く出てきます。

2. 5520 UDP だけを開け、ほかはすべて閉じる

開放は 2 つで足ります。UFW ではこうなります。自分を締め出さないために、順番はちょうどこのとおりにしてください。

ufw allow 22/tcp comment 'SSH'
ufw allow 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

5520 の TCP の開放は必要ありません。サーバーを別のポートで動かす場合は、開放を --bind の値に合わせる必要があります。合っていなければ起動は通るのに、プレイヤーは届きません。救出の道筋も含む完全な手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

管理のために追加で入れたものすべてには、ほかのどのゲームでも同じ原則が当てはまります。開いたネットワークに出さず、SSH のポートフォワーディング経由で到達できるようにし、そのあとローカルで 127.0.0.1 に対して作業します。

ssh -N -L 8080:127.0.0.1:8080 root@YOUR.SERVER.IP.ADDRESS

3. 想定どおりにサーバーを起動する

起動はコマンド 1 本です。サーバーのファイルは、公式の Hytale のダウンローダー、またはご自身のゲームのインストールから入手します。

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

最初の起動で、サーバーは config.json、ディレクトリ logs/、ワールドのディレクトリ universe/ を作ります。そのあと 1 度だけ、サーバーを自分のアカウントにログインさせます。プレイヤーの認証が働くようにするためです。これはサーバーのコンソールでのデバイスコードを通じて行います。

/auth login device
/auth status

-Xmx をマシンのメモリー全体に設定しないでください。オペレーティングシステム、ファイルシステムのキャッシュ、そしてヒープの外側にある Java の実行時の消費にも場所が必要です。負荷の下でスワップ領域に入るサーバーは、プレイヤーには攻撃とまったく同じに見えます。

4. スロット枯渇に対する許可リスト、サーバーパスワード、プレイヤー数の上限

スロット枯渇はコミュニティサーバーに対するもっとも安い攻撃で、帯域幅を必要としません。同時接続を十分な数だけ作れば、すべてのスロットを占めて本来のコミュニティを締め出せます。1 ギガビットも買わずにです。Hytale には、ほかの一部のゲームと違って、これに合う道具が出荷時の状態でそろっています。whitelist.json の許可リスト、bans.json の BAN リスト、permissions.json の権限、そして config.json のキー Password と MaxPlayers です。

{
  "ServerName": "My Hytale Server",
  "MOTD": "",
  "Password": "a value only your group knows",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password は出荷時の状態では空なので、アドレスとポートを知る人は誰でも入れます。閉じたサーバーでは、パスワードを設定することがスロット枯渇に対するもっとも効く単独の対策です。公開サーバーでは、攻撃の波のあいだに効くのは許可リストです。そして 1 つはっきりさせておく必要があります。サーバーパスワードが守るのはスロットで、回線ではありません。サーバーをあふれさせる攻撃側は、そもそも参加する気がありません。

これらのファイルは、サーバーを停止した状態でのみ編集してください。動いているサーバープロセスは自分の状態をメモリーに保持しており、その最中にファイルへ書いた変更を、終了時に何も言わず上書きすることがあります。運転中の変更には、エディターではなくコンソールのコマンドを使ってください。

5. 認証を初期値のままにする

初期のモードは、すべてのプレイヤーに有効な Hytale のアカウントを要求します。これはライセンスの確認以上のものです。大量のアカウントを高くつかせる、参加の入口のふるいです。スロットを占めたい攻撃側は、そのために有効なアカウントを必要とし、それにはお金がかかります。このふるいを外さないでください。

コミュニティのドキュメントは、初期のモードのほかに、私的な環境向けと開発向けの 2 つのモードを記しており、そこではアカウントの確認なしに参加できます。公開サーバーにとっては、これは到達しうる最悪の設定です。スロット枯渇をお金の問題からスクリプトの問題に変えてしまうからです。試験のために切り替えるなら、インターネットに出ていないマシンで行い、そのあと戻してください。

6. 新しい接続試行を制限する。1200 バイトの規定を使って

ここで QUIC の構造的な利点が実務になります。RFC 9000 によれば、有効な接続確立は少なくとも 1200 バイトのデータグラムとして届きます。流れているゲームトラフィックはそれよりはるかに小さいです。ですから接続追跡を使えば、新しいストリームを既存のものと区別し、新しくて小さすぎるものをすべて破棄できます。nftables で、nft -f から読み込みます。

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

1 つ目のルールは UDP の長さ、つまり 8 バイトのヘッダーに 1200 バイトのペイロードを足した 1208 を見ます。当たるのは、新しいストリームを開こうとしていながらそれには小さすぎるパケットだけで、接続中のプレイヤーに当たることはありません。2 つ目のルールは、1 つの送信元アドレスが毎秒いくつ新しい接続を開けるかを制限します。毎秒 5 は寛大な値です。本物のプレイヤーは接続を 1 つ確立し、それを保ちます。優先度 -10 は、どちらのルールも UFW のフィルターチェーンより前で効くようにします。

ゲームポート自体における送信元アドレスごとのパケットレートの上限が、3 つ目の意味のあるルールです。ここでは明示しておきます。数値は出発点であり、真理ではありません。

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

まず平常運転で 1 週間測り、そのあと上限を、測ったピーク値の 2 倍に設定してください。Hytale について公開された参照値はなく、値はプレイヤー数と描画距離に強く左右されます。厳しすぎる設定は自分のプレイヤーを追い出します。しかも最初に落ちるのは、回線がもっとも悪いプレイヤーです。

iptables だけのルールは再起動で消えます。Debian と Ubuntu では次のように保存します。

apt-get install -y iptables-persistent
netfilter-persistent save

UFW のもとでは、こうしたルールをあわせて /etc/ufw/before.rules にも置きます。そうしないと次の ufw reload で消えます。そのルールにそもそも届いているかは iptables -L INPUT -n -v で分かります。一致カウンターが 0 のままなら、効いていません。

7. カーネルの接続追跡を正しく設定する

この項目は、ボリューム型攻撃に見えて実はそうでない障害を説明します。カーネルは UDP のトラフィックについても接続追跡にエントリーを作り、送信元アドレスが偽装されていれば、アドレス 1 つごとに新しいエントリーになります。テーブルが満杯になると、カーネルは区別なくパケットを破棄し、攻撃とプレイヤーがそろって落ち、ログには「nf_conntrack: table full」と出ます。現在値と上限はこれで分かります。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

たいていのゲームでは、これに対する最良の答えはゲームトラフィックをそもそも追跡させないことです。Hytale ではこれは本当の天秤です。手順 6 の 1200 バイトの規定が接続追跡を必要とするからです。それがなければ、フィルターはどのパケットが新しいストリームを開くのかを知りません。ですから推奨はこうです。追跡は残し、テーブルを大きくし、UDP のタイムアウトを短く保つ。/etc/sysctl.d/ の下に置き、sysctl --system で有効にします。

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

それでも追跡を切りたい場合、たとえば同時接続のプレイヤーが非常に多いマシンでは、raw テーブルに udp dport 5520 notrack を置き、その代わりに 1200 バイトの規定をあきらめます。両方を同時には使えません。1 台の Hytale サーバーにとっては、節約できるテーブルのエントリーより、このルールのほうが価値があります。

Java のプロセスが取り出すより速くパケットが届けば、さらに受信バッファーがあふれます。プレイヤーには、回線が空いているのにパケットロスのように見えます。上のバッファーの設定が必要かどうかは、カーネル自身が教えてくれます。nstat -az の UdpRcvbufErrors が増えていれば効きます。カウンターが 0 のままなら、調整しても何も変わりません。

8. 描画距離とプレイヤー数を回線に合わせて選ぶ

この手順は安全のための対策ではありませんが、そもそもどれだけの攻撃に耐えられるかを決めます。Hypixel Studios は 2025 年 12 月 1 日の公式のハードウェア要件で明確に書いています。描画距離を 2 倍にすれば、プレイヤーの周りのワールドの量は 4 倍になります。公式の推奨は最大 12 チャンク、つまり 384 ブロックで、MaxViewRadius で指定します。クライアント側については、同じ要件が複数人プレイのためにプレイヤー 1 人あたり最小 2 Mbit/s、推奨 8 Mbit/s を挙げています。

お使いのサーバーについて、一度計算してみてください。描画距離を大きく取った 40 人のサーバーは、平常運転で 3 桁の低いメガビットの範囲を動かします。これがお使いの回線と比べるべき値であり、同時に、攻撃が目立つために超えなければならない値でもあります。1 Gbit/s の回線を平常運転で 3 分の 1 埋める運用は、5% に収まっている運用より余裕が少ないです。ですから描画距離を小さくすることは、性能の問題だけでなく、頑丈さの問題でもあります。

9. Mod、プラグイン、プロトコルの変更から目を離さない

Hytale はサーバー側で Mod を入れられます。Mod は .zip または .jar として mods/ ディレクトリに置き、プラグインはサーバーのインターフェースを直接呼びます。プレイヤーが何もインストールしなくてよいため便利ですが、同時に、攻撃とは関係のない可用性の危険でもあります。ネットワークのイベントごとに高くつく処理をするプラグインは、自分の家の中の増幅器です。

さらにプロトコルの変更があります。2026 年 8 月 27 日の公式のパッチノートによれば、Update 6 でネットワークプロトコルが hytale/2 から hytale/3 へ変わり、サーバーとプラグインは接続する前に作り直す必要があります。可用性の観点では、こうなります。Mod の一覧をバージョンつきで管理し、更新のたびに 2 台目のインスタンスで確認し、2026 年 10 月 12 日の前にメンテナンス枠を確保してください。更新後に起動しないサーバーは、プレイヤーから見て攻撃と区別できません。

10. 深刻になる前に測定値を集める

もっとも大事な手順は、事前にほとんど誰もやらないものです。すべてが平常に動いているあいだに基準値を取ることです。平常時の値がなければ、事案のあとで、毎秒 4 万パケットが多かったのか、それとも単に土曜の夜だったのかを言えません。apt-get install -y vnstat sysstat conntrack で測定は常時走り続けます。事案の最中は 5 つのコマンドで足ります。

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

tcpdump については、必ず -c で件数を区切ってください。全負荷の下での採取は、すでに過負荷のサーバーにさらに負担をかけます。Hytale サーバーは Java で動くため、もっとも多い誤報を除くための 2 つ目の検査が必要です。ガベージコレクションによる停止は、プレイヤーには攻撃とまったく同じに見えます。全員が同時に固まり、そのあと動き出します。違いは数字に出ます。

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

読み方は簡単です。Java のプロセスがほとんど働いていないのに受信パケットが平常時の値を大きく超えていれば、攻撃です。パケットレートに異常がないのにヒープが満杯になっていたり、ログに長い停止が出ていたりすれば、負荷です。ネットワークの値を個別にどう読むかは サーバーで DDoS 攻撃を検知する にあります。

11. バックアップ、切り戻しの計画、大きな日程の前の予行演習

一度も試していない保護の構想は、推測です。2026 年 10 月 12 日のような日程の前には、4 つを済ませておく必要があります。universe/ ディレクトリと config.json のバックアップをマシンの外に置くこと、以前のサーバーのバージョンへ戻せることを確認しておくこと、更新を先に当てる 2 台目のインスタンスを用意すること、そして自分のフィルタールールを実際に発動させる 1 回の負荷テストです。

負荷テストは、多くの運用者がやめてしまう地点であり、そしてもっとも重要です。確認するのは、ルールが攻撃を防ぐかどうかではなく、自分のプレイヤーを通すかどうかです。そのためには、本物のプレイヤー 20 人が同時に参加するあいだ、一致カウンターを見ているだけで足ります。そのときに破棄ルールのカウンターが増えるなら、上限が厳しすぎます。試していなければ、更新の当日、もっとも悪い条件でそれを知ることになったはずです。

ここまでの対策が限界を迎える地点：帯域幅とパケットレート

ここからは、どの設定ファイルでも解けない部分です。ここまでの対策はすべてお使いのサーバー上、つまり回線の端で動きます。ファイアウォールのルールが判断するのは、すでにケーブルを通り終えたパケットです。破棄はできますが、送られなかったことにはできません。

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s につながっており、これは毎秒 125 メガバイトで、誰かがそれより多く送った時点で回線は埋まります。ゲームサーバーのプロジェクトへの攻撃はふつう 5 から 50 Gbit/s、つまりお使いの回線の 5 倍から 50 倍です。その後ろにある nftables のルールの出来は、もう関係ありません。プレイヤーのパケットはその手前で通れなくなっているからです。

2 つ目の量はパケットレートで、帯域幅より先に効くことがよくあります。64 バイトの小さなパケットなら、1 Gbit/s の回線には毎秒約 149 万パケットが入ります。通常のサーバーのカーネルが破棄を始める前に処理できるのは、プロセッサーとネットワークカードによりますがそのうち数十万です。ですからお使いの回線を 3 分の 1 も埋めない攻撃でも、破棄のための計算時間が食われるため、サーバーを止められます。運用者にはこれが「使用率はまったく高くなかったのに、それでも全部落ちた」という形で見えます。

Hytale では、たいていのゲームにはない 3 つ目の量が加わります。接続確立のための計算時間です。ボットネットからの有効な接続試行のあふれは、回線を埋めず、目立つパケットレートも作らず、プロセッサーを暗号処理で忙しくさせます。こうした攻撃は帯域幅の統計では見えず、Java のプロセスのプロセッサー負荷にははっきり出ます。そして発信源が十分に多ければ、送信元アドレスごとのレート制限も、大きくした受信バッファーも役に立ちません。

実際に起きる規模の目安として、KernelHost のサーバーでは、ボイスサーバー宛ての毎秒 4150 万パケット超で 473.4 Gbit/s 超の攻撃や、ゲームサーバー宛ての 112.2 Gbit/s 超の UDP フラッドなどを除去しています。これに対するローカルの設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。

Hytale サーバーへの DDoS 攻撃に KernelHost が用意している対策

すべてのサーバープランに含まれる常時保護

KernelHost のすべてのサーバーには、3.2 Tbps の DDoS 基本保護が標準で含まれています。有効化も注文も設定もなしに常時動いており、Advanced DDoS Protection で強化することもできます。

• 標準装備：フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリング。 UDP フラッド、SYN フラッド、ICMP フラッドといった一般的なフラッド攻撃や、リフレクション攻撃、増幅攻撃を、サーバーの直前で検知し、パケット単位で破棄します。
• Advanced DDoS Protection 利用時：グローバルなスクラビングネットワークにおける最大 17 Tbps の緩和能力。 非常に大規模な攻撃は、データセンターに届く前に、発生源の近くで除去されます。さらに、特化したプロファイルが個々のゲームを狙った攻撃をフィルタリングします。

決定的な性質が 2 つあります。保護は常時動いており、攻撃を受けてから反応する必要がありません。つまり、最初の数分だけサーバーが落ちている、ということが起きません。そしてヌルルーティングは使いません。お使いの IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。IP アドレスをネットワークから外す事業者は、ご自身にとって攻撃側と同じ結果をもたらします。Advanced DDoS Protection が専用の保護プロファイルでどのタイトルとプロトコルに対応しているかは ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

継続的に攻撃される Hytale のプロジェクト向けの Advanced DDoS Protection

プロジェクトによっては、たまたまではなく狙って何週間も攻撃されます。アーリーアクセスのゲームでは、それがとくに、いま伸びているサーバーに当たります。そのために Advanced DDoS Protection があり、月額 50.00 EUR、PrePaid、最低利用期間なし、初期費用なしで利用できます。グローバルなスクラビングネットワークにおける最大 17 Tbps の緩和能力が加わり、制御できる範囲も大きく広がります。

• 専用の保護 IP をフランクフルトの中核から割り当て、お使いのサーバーを当社のネットワーク内で切り替えます。ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。5520 UDP で何を許可するかを、ほかのすべてと分けて指定でき、そのためにチケットは要りません。
• 変更はリアルタイムで反映されます。そのため、攻撃が進行している最中に調整できます。たとえば新しい接続だけを一時的に厳しく制限し、流れているゲームトラフィックには触れないという形です。
• プロトコルに合ったルールセットを用意しており、UDP 上の QUIC にも、任意の TCP または UDP ポートで動く独自のアプリケーションにも対応します。

Advanced DDoS Protection は KernelHost にあるサーバー向けです。Hytale のプロジェクトを現在よそで動かしていて継続的に攻撃されているなら、そのために KernelHost へ移します。そうすれば提供開始時点から基本保護が効き、Advanced DDoS Protection は申し込み後に追加されます。移転できない場合は、Remote DDoS Protection がサーバーを今の場所のまま守ります。

2 つの段階の比較

一般的なフラッド攻撃に対しては、標準で含まれる基本保護と、きれいなサーバー設定の組み合わせで足ります。Advanced DDoS Protection は、誰かがそれを個人的な問題にしてきた場合への答えです。

ほかのゲームから Hytale に当てはめられること

Hytale はまだ日が浅く、Hytale サーバーへの攻撃について公開された数値もないため、信頼できる知識へのもっとも速い道は、似たゲームを見ることです。当てはめられるのはポート番号ではなく、パターンです。

• 爆発的な立ち上がりと、それが引き起こすもの：Palworld は、新しいプレイヤーの波と攻撃の波が時間的に重なる様子と、なぜ伸びている最中のサーバーが標的になるのかを示しています。
• 問い合わせとゲームトラフィックの違い：Minecraft Bedrock は Unconnected Ping を例に、UDP での増幅がどう働くかを説明しています。まさにこの攻撃の道筋を、Hytale は QUIC のおかげで持ちません。違いを理解するのにいちばん向いています。
• 攻撃の標的としての接続確立：Minecraft の DDoS 対策と Nullping 対策 は、帯域幅をほとんど使わないハンドシェイクフラッドを説明しています。QUIC の接続フラッドにもっとも近い親戚です。
• 少ないプレイヤー数とスロット枯渇：Project Zomboid と Conan Exiles は、固定した集まりを締め出すのに必要な手間がいかに少ないか、そこで許可リストとパスワードがどんな役を果たすかを示しています。
• 継続的な負荷の下での運用：Terraria は、1 つのコアに負荷が寄る単一のサーバープロセスが攻撃にどう反応するかを示しています。Hytale サーバーは Java のプロセスで、根本の問題は比べられます。

Hytale サーバーでよくある失敗とその対処

「5520 の TCP を開けたのに、それでもプレイヤーが入れない」：ゲームトラフィックは QUIC、つまり UDP を通ります。TCP の開放はゲームの動作には何も与えません。5520 UDP を開け、外から nmap -Pn -sU -p 5520 で確認してください。サーバーを --bind で別のポートに置いた場合は、開放もそのポートを指定する必要があります。

「サーバーは動いているのに誰も参加できず、ログには攻撃のことが何もない」：/auth status で、サーバーが自分のアカウントにログインできているかを確認してください。ログインの期限が切れたサーバーは動き続けますが、それでもプレイヤーを拒みます。これはネットワークの問題でもフィルタールールの問題でもありません。

「更新のあと何も起動しない」：これは攻撃ではなく、プロトコルの変更です。Update 6 でネットワークプロトコルが hytale/2 から hytale/3 へ変わり、サーバーもプラグインも作り直しが必要です。更新は本番のサーバーに入れる前に、まず 2 台目のインスタンスで当ててください。

「全プレイヤーが同時に 2 秒固まり、そのあと動き出す」：これは高い確率で Java の実行環境のガベージコレクションで、攻撃ではありません。jcmd ... GC.heap_info とサーバーのログを確認してください。そのとき sar -n DEV 1 10 に異常がなければ、関わっていたのは攻撃ではなく、狭すぎるヒープか大きすぎる描画距離です。

「小さなパケットに対するルールでプレイヤーを締め出してしまった」：その場合、1200 バイトの条件が ct state new なしでチェーンに入っています。流れているゲームトラフィックは大半が小さなパケットで、状態の判定を伴わない長さの条件はまさにそれに当たります。この条件は、新しく開かれたストリームにだけ適用します。

「IP アドレスを変えたのに、2 時間後にまたオフラインになった」：攻撃側は新しいアドレスを、古いアドレスと同じ出どころから得ています。Hytale の場合、それはたいてい DNS に残った古い A レコード、ステータスを表示する Discord ボット、あるいは第三者による数多くのサーバーリストのどれかへの登録です。Update 6 以降、公式のサーバーリストではサーバーアドレスが出荷時の状態で隠されており、もっとも手軽な道は閉じましたが、すべてではありません。アドレスの変更は時間稼ぎで、解決ではありません。

「フィルタールールが効かない」：原因は 3 つがよくあります。ルールが UFW のチェーンの後ろにあって、そこに届いていない。前回の再起動で消えていた（その場合は netfilter-persistent save か /etc/ufw/before.rules への記載が助けになります）。あるいは攻撃がボリューム型で、ルールはすでに埋まった回線の上で正しく働いている。iptables -L INPUT -n -v で一致カウンターが増えているかを確認してください。

「これまでの事業者が私の IP アドレスを遮断した」：それはヌルルーティングです。事業者はそれで自分のネットワークを守りますが、ご自身にとっての結果は攻撃の成功と同じで、たいていその後も数時間続きます。迷うときは、フィルタリングするのかヌルルーティングするのかを尋ねてください。その答えは、どんなハードウェアの記載よりも可用性を左右します。

「tcpdump で目立つものが見えない」：トラフィックがすでに手前のネットワークで除去されているなら、サーバーには当然ながら何も届きません。フィルタリングが働いているときの通常の状態です。逆もあります。回線が飽和していると、測定に使おうとした SSH の接続さえ届かないことがあります。そのときはカスタマーエリアの VNC コンソールを使ってください。ゲスト側のネットワークとは独立して動きます。

まとめ

• Hytale サーバーが開ける必要のあるポートはちょうど 1 つ、QUIC 用の 5520 UDP です。ゲームの動作に TCP は必要なく、公開されているドキュメントには、問い合わせ、RCON、リモート操作のためのポートの記述がありません。
• QUIC は RFC 9000 により、アドレスの検証前に受け取ったバイト数の 3 倍を超えて送れず、最初の接続試行は少なくとも 1200 バイトなければなりません。ですから Hytale サーバーは、リフレクションの増幅器としては事実上の価値がありません。これが Steam の問い合わせや Bedrock の Unconnected Ping を持つサーバーとの違いです。
• その同じ 1200 バイトの規定が、もっとも良いローカルのフィルタールールです。5520 UDP で新しいストリームを開こうとしていながらそれより小さいものは、有効な接続確立ではありえないため、接続中のプレイヤーに当てずに破棄できます。
• QUIC の確立で高くつく部分は暗号処理で、帯域幅ではありません。有効な接続試行のあふれは帯域幅の統計では見えず、プロセッサーの負荷と、新しい接続のカウンターにだけ現れます。
• アカウントを必須とする初期のモードは、大量のアカウントを高くつかせる参加の入口のふるいです。公開サーバーではこれに手を付けず、スロット枯渇に対してはあわせて whitelist.json、bans.json、そして Password に値を設定することを使います。
• ローカルの対策は回線で終わります。1 Gbit/s は毎秒 125 メガバイトで、64 バイトのパケットならそこに毎秒約 149 万パケットが入ります。それを超えるものはすべて、サーバーの手前のネットワークで終わらせる必要があります。
• Hytale は 2026 年 1 月 13 日からアーリーアクセスで、Chapter 1 は 2026 年 10 月 12 日に予告されています。大きな日程は攻撃の日程でもあり、その日に注文した保護では間に合いません。
• KernelHost では、3.2 Tbps の基本保護がすべてのサーバープランに追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングは行いません。専用の保護 IP とポートごとに自分で管理できるルールを備えた Advanced DDoS Protection は、月額 50.00 EUR です。

Hytale サーバーをすでに KernelHost で動かしている場合、フィルタリングは何もしなくても有効です。それでも異常に気づいたときは サポートチケット を開いてください。お使いの IP アドレス向けにフィルタールールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。

本記事は 2026 年 9 月 27 日時点の内容です。Hytale はアーリーアクセスで、ネットワークプロトコルは今年すでに 1 度変わっています。本記事は Chapter 1 のあと、そして接続確立、ポート、サーバーリストに関わる更新のたびに書き足していきます。