Hytale 서버를 DDoS 공격으로부터 방어하기

저녁에 게임이 한창일 때 모든 연결을 동시에 잃고, 몇 분 동안 접속되지 않다가 저절로 다시 돌아오는 Hytale 서버는 하드웨어 문제인 경우가 드뭅니다. 대개는 공격이 진행 중입니다. 이 글은 Hytale 서버를 DDoS 공격으로부터 어떻게 방어하는지 보여 줍니다. 먼저 추가 비용 없이 직접 설정할 수 있는 것, 그다음 그 조치가 기술적으로 어디에서 끝나는지, 마지막으로 서버가 계속 접속 가능하도록 서버 앞단 네트워크에서 무엇이 이뤄져야 하는지입니다.

모든 내용은 Hypixel Studios의 공식 전용 서버, 곧 Java 25에서 Assets.zip과 함께 돌아가는 HytaleServer.jar를 기준으로 하며, Debian 12, Debian 13, Ubuntu 22.04 LTS 또는 Ubuntu 24.04 LTS에서 운영하는 경우입니다. 명령은 root 기준으로 적었으니, 일반 사용자라면 앞에 sudo를 붙이세요. Hytale은 얼리 액세스 단계이고 빠르게 움직입니다. 그래서 이 글에서 게임에 관한 모든 진술에는 날짜가 붙어 있고, 공식적으로 확인되지 않은 것은 예상 또는 커뮤니티 출처로 분명히 표시했습니다. 공격이 지금 진행 중이라면 순서가 하나 더 있습니다. 먼저 측정하고, 그다음 바꾸세요. 부하 상태에서의 강제 재시작은 마지막 저장 시점 이후에 월드에서 일어난 모든 것을 버리고, 그 사건의 측정값도 그 뒤에는 함께 사라집니다.

Hytale 서버가 DDoS 공격으로 표적이 되어 멈춰 세워지는 이유

Hytale 서버는 고정된 주소에 붙은 관객이고, 그 관객은 대체 가능합니다. 저녁에 세 번 연달아 단골 서버에 들어가지 못한 사람은 다른 서버를 찾습니다. 커뮤니티 서버를 향한 공격의 사업 모델이 바로 이것입니다. 데이터도 협박도 목적이 아니고, 떠나가는 플레이어가 목적입니다. 월 몇 유로에 주소 하나를 쏘아 주는 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월의 서버가 아닙니다. 업데이트 6으로 네트워크 프로토콜이 hytale/2에서 hytale/3으로 바뀌었고, 2026년 8월 27일 공식 패치 노트에 따르면 서버와 플러그인은 연결되기 전에 새로 빌드해야 합니다. 그러므로 가용성을 계획하는 사람은 공격만이 아니라 프로토콜 변경도 함께 계획해야 합니다.

2026년 10월 12일이 결정적인 날인 이유

큰 콘텐츠 업데이트는 두 번째 출시처럼 작동합니다. 옛 플레이어를 돌아오게 하고 새 플레이어를 끌어들이며, 며칠 동안은 접속 가능성이 어느 커뮤니티 서버가 이 물결에서 자라고 어느 서버가 놓치는지를 결정합니다. 이 패턴은 다른 게임에서 확인되었습니다. Palworld는 2024년 1월에 며칠 만에 플레이어 수백만 명에 도달했고, 그 출시 국면의 커뮤니티 서버들은 잃을 것이 가장 많은 바로 그 순간에 가장 많이 공격받았습니다. 그 구조는 Palworld 서버를 DDoS 공격으로부터 방어하기에 자세히 설명되어 있고, Hytale에 그대로 옮겨 적용할 수 있습니다.

여기서 일정에 관한 불편한 진실이 따라옵니다. 10월 12일에 주문하는 방어는 너무 늦습니다. 회선, 방어 IP, 포트별 규칙 세트, 평상시 운영의 측정값은 모두 준비 기간이 필요합니다. 비교 데이터 없이는 의미 있게 설정할 수 없기 때문입니다. 큰 업데이트 2주 전에 시작하는 사람은 시간이 넉넉합니다. 업데이트 당일에 시작하는 사람은 눈을 감고 값을 맞추는 셈입니다.

Hytale 서버에서 실제로 문제가 되는 포트

Hytale 서버는 정확히 포트 하나만 열려 있어야 합니다. 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 서버가 외부에 내주는 모든 것이 단 하나의 UDP 포트에 놓여 있습니다.

숫자로 보는 Hytale 서버

다음 값들은 필터 규칙과 한계값에 관한 모든 판단의 토대입니다. 출처를 함께 적었습니다. 출처가 그 값의 신뢰도를 결정하기 때문입니다.

QUIC가 공격 표면을 어떻게 바꾸는가

QUIC는 UDP 위에서 보안 연결을 수립하는 전송 프로토콜이며, TLS 1.3에 따른 암호화 수립이 프로토콜에 고정되어 들어 있습니다. 암호화되지 않은 QUIC는 없습니다. 서버 운영자에게 이것은 서로 모순되는 두 가지를 뜻하고, 둘 다 중요합니다.

첫째는 실제 개선입니다. UDP는 연결 수립을 강제하지 않고 출발지 주소를 위조할 수 있으므로, 연결 없는 UDP 서비스는 제3자를 향한 공격의 고전적인 증폭기입니다. QUIC는 표준에서 이를 제한합니다. RFC 9000은 8.1절에서 서버가 출발지 주소를 검증하기 전에 수신한 바이트 양의 최대 3배까지만 보낼 수 있도록 규정하고, 14.1절은 클라이언트가 첫 데이터그램을 최소 1200 바이트로 채우도록 요구합니다. 이 두 규칙이 함께 QUIC 서비스의 증폭 계수를 최대 3으로 끌어내리는 반면, Steam 조회 포트나 Bedrock의 Unconnected Ping은 그 몇 배에 이릅니다. 그래서 올바르게 동작하는 Hytale 서버는 반사 증폭기로는 사실상 매력이 없습니다. 이는 UDP 트래픽을 쓰는 거의 모든 다른 게임에 비해 구조적인 이점이며, Minecraft Bedrock 서버와 비교하면 뚜렷하게 드러납니다.

둘째는 그 대가입니다. QUIC 연결 수립은 서버에 연산 시간을 요구합니다. 비대칭 암호 연산이 들어가는 TLS 1.3 협상을 포함하기 때문입니다. 위조된 패킷 하나로는 수립을 강제할 수 없지만, 봇넷에서 쏟아지는 진짜 연결 시도의 홍수는 강제할 수 있습니다. 그때 공격자도 마찬가지로 연산 시간을 냅니다. 그리고 바로 이 비율이 결정합니다. 서버가 연결 시도 하나마다 공격자보다 더 많은 일을 하는 동안에는 그 공격이 경제적입니다. 그래서 연결 시도의 홍수는 회선이 아니라 프로세서에 부담을 주고, 대역폭 통계에서는 아무것도 아닌 것처럼 보입니다. 이는 Minecraft에서 nullping과 핸드셰이크 플러드로 알려진 것과 같은 구조이며, Minecraft DDoS 방어와 nullping 방어 글에서 자세히 설명합니다.

여기서 실무에 쓸 수 있는 것은 무엇보다 1200 바이트 규칙입니다. 새 연결 시도는 최소 1200 바이트의 데이터그램으로 도착해야 하고, 그러지 않으면 표준에 따라 유효한 연결 수립이 아닙니다. 반면 진행 중인 게임 트래픽은 대부분 작은 패킷으로 이뤄집니다. 이 구분은 필터 규칙으로 바꿀 수 있고, 그것은 곧 다루겠습니다.

Hytale에 대해 공개적으로 문서화되지 않은 것

이 목록은 정직한 글이라면 들어가야 합니다. 여러분이 숫자에 의존해서는 안 되는 지점을 정해 주기 때문입니다. 아래의 모든 내용은 2026년 9월 27일 기준으로 공식적으로 확인되지 않았습니다.

• 서버가 주소 검증에 QUIC Retry를 쓰는지 여부. RFC 9000은 8.1.2절에서 토큰이 담긴 Retry 패킷을 허용하며, 서버는 자원을 묶기 전에 이것으로 출발지 주소를 검증할 수 있습니다. Hytale이 그렇게 하는지, 어느 부하부터 그렇게 하는지는 문서에 없습니다. 거기에 의존할 수 없다고 가정하세요.
• config.json의 RateLimit 블록과 ConnectionTimeouts 블록의 기본값. 두 블록이 존재한다는 점은 여러 출처에서 일관됩니다. 그러나 언급되는 숫자는 서로 모순됩니다. 한 출처는 구체적인 한계값을 제시하고, 다른 출처는 두 블록이 존재하지만 효과가 없다고 기술합니다. 그래서 이 글에는 그 숫자 가운데 어느 것도 적지 않으며, 여러분도 이 블록을 여러분의 방어 수단으로 계획해서는 안 됩니다.
• 인증 모드의 이름과 기본값. 공개된 서버 코드에 관한 커뮤니티 문서는 --auth-mode로 설정하는 세 가지 모드를 기술하며, 기본값은 authenticated이고 사설 환경과 개발용으로 offline과 insecure가 있다고 합니다. 공식적으로 확인된 바는 아닙니다. 그래도 거기서 나오는 규칙은 분명합니다. 공개 서버에서는 이 모드를 바꾸지 마세요.
• TLS 수립의 세부 사항. 공개된 서버 코드에 기반한 커뮤니티 프로토콜 문서는 양방향 인증서, 시작할 때 생성되는 자체 서명 서버 인증서, 그 SHA-256 지문이 세션 서비스를 통해 클라이언트에 전달되는 구조, 그리고 0-RTT가 꺼져 있다는 점을 기술합니다. 이는 그럴듯하고 TLS 1.3에도 들어맞지만 공식적으로 확인된 바는 아니며, 아래의 조치를 바꾸지도 않습니다.
• 특히 Hytale 서버를 겨냥한 공격 규모. 이에 관한 공개 수치는 없습니다. 표에 적은 5에서 50 Gbit/s는 게임 서버 프로젝트 전반의 경험값이고, Hytale 통계가 분명히 아닙니다.
• 평상시 운영에서 플레이어별 패킷 전송률. 이에 대해서도 믿을 만한 공개 자료가 없습니다. 그래서 이 글에는 여러분이 검증 없이 그대로 가져다 쓸 수 있는 한계값이 적혀 있지 않고, 그 값을 직접 측정하는 방법이 적혀 있습니다.

돈을 쓰기 전에 직접 할 수 있는 일

다음 단계들은 볼류메트릭 공격을 막아 내지 못합니다. 그것은 서버의 어떤 소프트웨어도 해낼 수 없습니다. 그러나 그 아래에 있는 모든 것을 치워 줍니다. 포트 스캔, 소수의 출발지에서 오는 연결 시도의 홍수, 추가로 설치한 관리 화면을 통한 서버 탈취 시도, 그리고 외부인이 모든 자리를 점유하는 일입니다. 이것이 평소에 Hytale 서버를 괴롭히는 것의 대부분이고, 한 시간 남짓이면 됩니다.

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. 5520 UDP만 열어 두고 나머지는 모두 닫기

허용 두 줄이면 충분합니다. 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. 서버를 의도된 방식으로 시작하기

시작은 명령 하나로 끝납니다. 서버 파일은 공식 Hytale 다운로더를 통해 받거나 여러분의 게임 설치본에서 가져옵니다.

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

첫 시작 때 서버가 config.json과 logs/ 디렉터리와 월드 디렉터리 universe/를 만듭니다. 그다음 서버를 자기 계정에 한 번 로그인시켜야 플레이어 인증이 동작합니다. 이는 서버 콘솔의 기기 코드로 진행됩니다.

/auth login device
/auth status

-Xmx를 머신의 전체 메모리로 설정하지 마세요. 운영체제, 파일 시스템 캐시, 힙 밖의 Java 실행 비용도 자리를 요구하며, 부하 상태에서 스왑 영역으로 넘어가는 서버는 여러분의 플레이어에게 공격과 똑같이 보입니다.

4. 슬롯 고갈에 맞서는 허용 목록, 서버 비밀번호, 플레이어 상한

슬롯 고갈은 커뮤니티 서버를 향한 가장 값싼 공격이고 대역폭이 필요하지 않습니다. 동시 연결을 충분히 많이 만드는 사람은 모든 자리를 점유해서 정작 그 공동체를 막아 버리며, 기가비트 하나도 사지 않습니다. Hytale은 다른 몇몇 게임과 달리 기본 상태에 그에 맞는 도구를 갖추고 있습니다. whitelist.json의 허용 목록, bans.json의 차단 목록, permissions.json의 권한, 그리고 config.json의 키 Password와 MaxPlayers입니다.

{
  "ServerName": "내 Hytale 서버",
  "MOTD": "",
  "Password": "여러분의 그룹만 아는 값",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password는 기본값이 비어 있으므로 주소와 포트를 아는 누구나 들어옵니다. 닫힌 서버라면 비밀번호를 설정하는 것이 슬롯 고갈에 맞서는 가장 효과적인 단일 조치이고, 공개 서버라면 공격 물결이 이어지는 동안에는 허용 목록입니다. 그리고 한 가지는 분명해야 합니다. 서버 비밀번호는 여러분의 자리를 지켜 주고 회선을 지켜 주지는 않습니다. 여러분의 서버를 플러딩하는 공격자는 애초에 접속할 생각이 없습니다.

이 파일들은 서버를 멈춘 상태에서만 편집하세요. 실행 중인 서버 프로세스는 자기 상태를 메모리에 들고 있고, 그동안 여러분이 파일에 쓴 변경을 종료할 때 아무 말 없이 덮어쓸 수 있습니다. 운영 중에 바꿀 일은 편집기 대신 콘솔 명령으로 하세요.

5. 인증을 기본값 그대로 두기

기본 모드는 모든 플레이어에게 유효한 Hytale 계정을 요구합니다. 이는 라이선스 검사 이상입니다. 대량 계정을 비싸게 만드는 접근 필터입니다. 자리를 점유하려는 공격자는 그러려면 유효한 계정이 필요하고, 그 계정에는 돈이 듭니다. 이 필터를 빼지 마세요.

커뮤니티 문서는 기본값 외에 사설 환경용과 개발용 모드 두 개를 기술하며, 그 모드에서는 계정 검사 없이 접속할 수 있습니다. 공개 서버에서는 이것이 도달할 수 있는 가장 나쁜 설정입니다. 슬롯 고갈을 돈 문제에서 스크립트 문제로 바꿔 놓기 때문입니다. 시험을 위해 전환한다면 인터넷에 놓여 있지 않은 머신에서 하고, 그 뒤에는 되돌리세요.

6. 새 연결 시도 제한하기, 그것도 1200 바이트 규칙으로

이제 QUIC의 구조적 이점이 실무가 됩니다. 유효한 연결 수립은 RFC 9000에 따라 최소 1200 바이트의 데이터그램으로 도착합니다. 진행 중인 게임 트래픽은 그보다 뚜렷하게 작습니다. 그래서 연결 추적을 쓰면 새 데이터 스트림과 기존 스트림을 구분하고, 새것이면서 너무 작은 모든 것을 폐기할 수 있습니다. nft -f로 불러오는 nftables에서는 이렇게 합니다.

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
    }
}

첫 번째 규칙은 UDP 길이를 기준으로 동작합니다. 곧 머리 8 바이트에 페이로드 1200 바이트를 더한 1208입니다. 이 규칙은 새 데이터 스트림을 열려고 하면서 그에 필요한 크기에 미치지 못하는 패킷만 때리고, 접속해 있는 플레이어는 건드릴 수 없습니다. 두 번째 규칙은 출발지 주소 하나가 초당 몇 개의 새 연결을 열 수 있는지를 제한합니다. 초당 다섯 개는 넉넉합니다. 실제 플레이어는 연결 하나를 열고 그대로 유지합니다. 우선순위 -10은 두 규칙이 UFW의 필터 체인보다 앞에서 걸리게 해 줍니다.

게임 포트 자체에 출발지 주소별 패킷 전송률 상한을 두는 것이 세 번째로 의미 있는 규칙이며, 여기서는 분명히 말씀드립니다. 숫자 값은 출발점일 뿐이고 정답이 아닙니다.

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

먼저 평상시 운영에서 한 주는 측정하고, 그다음 측정한 최고치의 두 배로 한도를 설정하세요. 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 트래픽에도 연결 추적 항목을 만들고, 출발지 주소가 위조되어 있으면 주소마다 새 항목이 생깁니다. 테이블이 가득 차면 커널은 구별 없이 패킷을 폐기하고, 공격과 여러분의 플레이어가 함께 튕겨 나가며, 로그에는 “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 바이트 규칙을 포기합니다. 둘을 함께 쓸 수는 없습니다. Hytale 서버 한 대라면 그 규칙이 아낀 테이블 항목보다 값어치가 큽니다.

Java 프로세스가 가져가는 속도보다 패킷이 빨리 들어오면 수신 버퍼까지 넘칩니다. 플레이어에게는 회선이 비어 있는데도 패킷 손실처럼 보입니다. 위의 버퍼 설정이 필요한지는 커널이 직접 알려 줍니다. nstat -az에서 UdpRcvbufErrors가 올라가면 그 설정이 효과를 냅니다. 카운터가 0에 머물러 있으면 그 조정은 아무것도 바꾸지 않습니다.

8. 시야 거리와 플레이어 수를 회선에 맞게 고르기

이 단계는 보안 조치가 아니지만, 여러분이 공격을 얼마나 견딜 수 있는지를 결정합니다. Hypixel Studios는 2025년 12월 1일 공식 하드웨어 요구 사항에서 이를 분명히 적었습니다. 시야 거리를 두 배로 하면 플레이어 주변의 월드 양은 네 배가 됩니다. 공식 권고는 최대 12 청크, 곧 384 블록이고 MaxViewRadius로 설정합니다. 클라이언트 쪽으로는 같은 요구 사항이 멀티플레이 기준 플레이어별 최소 2 Mbit/s와 권장 8 Mbit/s를 제시합니다.

여러분의 서버에 대해 한번 계산해 보세요. 시야 거리를 넉넉하게 둔 플레이어 40명의 서버는 평상시 운영에서 낮은 세 자리 메가비트 범위를 움직입니다. 그것이 여러분의 회선이 맞춰야 하는 값이고, 동시에 공격이 눈에 띄려면 넘어야 하는 값입니다. 1 Gbit/s 회선을 평상시에 3분의 1까지 채우는 사람은 5 퍼센트에 머무는 사람보다 여유가 적습니다. 그러므로 시야 거리를 작게 두는 것은 성능 문제만이 아니라 견고함의 문제이기도 합니다.

9. 모드, 플러그인, 프로토콜 변경을 계속 살피기

Hytale은 서버 쪽에서 모드를 붙일 수 있습니다. 모드는 .zip이나 .jar로 mods/ 디렉터리에 놓이고, 플러그인은 서버 인터페이스를 직접 호출합니다. 플레이어가 아무것도 설치하지 않아도 되니 편리하고, 동시에 공격과는 무관한 가용성 위험입니다. 네트워크 이벤트마다 비싸게 일하는 플러그인은 여러분 집 안의 증폭기입니다.

여기에 프로토콜 변경이 더해집니다. 2026년 8월 27일 공식 패치 노트에 따르면 업데이트 6으로 네트워크 프로토콜이 hytale/2에서 hytale/3으로 바뀌었고, 서버와 플러그인은 연결되기 전에 새로 빌드해야 합니다. 가용성 측면에서 이는 이런 뜻입니다. 모드 목록을 버전과 함께 관리하고, 업데이트마다 두 번째 인스턴스에서 먼저 검증하고, 2026년 10월 12일 전에 유지보수 시간을 미리 잡아 두세요. 업데이트 후에 시작되지 않는 서버는 여러분의 플레이어에게는 공격과 구별되지 않습니다.

10. 심각해지기 전에 측정값 모으기

가장 중요하면서 거의 아무도 미리 하지 않는 단계가 있습니다. 모든 것이 정상으로 돌아가는 동안에 기준값을 만들어 두는 것입니다. 평상시 값이 없으면 사건이 끝난 뒤에 초당 40,000 패킷이 많았던 것인지 그냥 토요일 저녁이었던 것인지 말할 수 없습니다. apt-get install -y vnstat sysstat conntrack으로 측정이 상시 돌아갑니다. 사건이 진행되는 동안에는 다섯 개의 명령으로 충분합니다.

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에서 돌아가기 때문에, 가장 흔한 오경보를 배제할 두 번째 검사가 필요합니다. 가비지 컬렉션의 멈춤은 플레이어에게 공격과 똑같이 보입니다. 모두가 동시에 멈추고 그 뒤에 계속 진행됩니다. 차이는 숫자에 있습니다.

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

해석은 간단합니다. Java 프로세스가 거의 일하지 않는데 수신 패킷이 평상시 값을 크게 넘어서면 공격입니다. 패킷 전송률은 평범한데 힙이 가득 차거나 로그에 긴 멈춤이 보이면 부하입니다. 네트워크 값을 구체적으로 어떻게 해석하는지는 서버에서 DDoS 공격 알아내기에 있습니다.

11. 백업, 복구 계획, 그리고 큰 날 앞의 예비 점검

한 번도 시험해 보지 않은 방어 계획은 추측입니다. 2026년 10월 12일 같은 날 앞에서는 네 가지를 끝내 두어야 합니다. 머신 밖에 두는 universe/ 디렉터리와 config.json의 백업, 이전 서버 버전으로 검증된 복귀 경로, 업데이트를 먼저 올려 볼 두 번째 인스턴스, 그리고 여러분 자신의 필터 규칙을 걸리게 해 보는 일회성 부하 테스트입니다.

부하 테스트는 대부분의 운영자가 멈추는 지점이고, 가장 중요한 지점입니다. 여러분의 규칙이 공격을 막아 내는지를 확인하는 것이 아니라, 여러분의 플레이어를 통과시키는지를 확인하세요. 그러려면 실제 플레이어 스무 명이 동시에 접속하는 동안 매칭 카운터를 지켜보는 것으로 충분합니다. 그때 폐기 규칙의 카운터가 올라간다면 여러분의 한도가 너무 좁게 잡힌 것이고, 그 사실을 업데이트 당일 최악의 조건에서 알게 되었을 것입니다.

이 조치들이 한계에 이르는 지점: 대역폭과 패킷 전송률

이제 어떤 설정 파일로도 해결할 수 없는 부분입니다. 지금까지의 모든 조치는 여러분의 서버, 곧 회선의 끝에서 동작합니다. 방화벽 규칙은 이미 케이블을 지나온 패킷을 두고 판단합니다. 그 패킷을 폐기할 수는 있지만 보내지 않은 것으로 만들 수는 없습니다.

한번 계산해 보겠습니다. 일반적인 게임 서버는 1 Gbit/s에 물려 있고, 이는 초당 125 메가바이트이며, 누군가 그보다 많이 보내는 순간 회선은 꽉 찹니다. 게임 서버 프로젝트를 향한 공격은 보통 5에서 50 Gbit/s 사이, 곧 여러분 회선의 5배에서 50배입니다. 그렇게 되면 그 뒤의 nftables 규칙이 훌륭한지는 아무 상관이 없습니다. 여러분 플레이어의 패킷이 그 앞에서 이미 통과하지 못하기 때문입니다.

두 번째 수치는 패킷 전송률이고, 대역폭보다 먼저 터지는 일이 잦습니다. 64 바이트짜리 작은 패킷이라면 1 Gbit/s 회선에 초당 약 149만 개가 들어갑니다. 일반적인 서버 커널은 프로세서와 네트워크 카드에 따라 그중 수십만 개를 처리한 뒤 폐기를 시작합니다. 그러므로 여러분의 회선을 3분의 1도 채우지 못하는 공격이 서버를 멈춰 세울 수 있습니다. 폐기하는 데 연산 시간이 다 들어가기 때문입니다. 운영자는 이것을 “사용률은 전혀 높지 않았는데 그래도 전부 죽었다”로 경험합니다.

Hytale에는 대부분의 게임에 없는 세 번째 수치가 더해집니다. 연결 수립에 드는 연산 시간입니다. 봇넷에서 쏟아지는 유효한 연결 시도의 홍수는 회선을 채우지 않고 눈에 띄는 패킷 전송률도 만들지 않으며, 프로세서를 암호 연산으로 붙잡아 둡니다. 그런 공격은 대역폭 통계에서는 보이지 않고 Java 프로세스의 프로세서 부하에서는 뚜렷하게 보이며, 출발지가 충분히 많다면 출발지 주소별 속도 제한도 더 큰 수신 버퍼도 도움이 되지 않습니다.

어떤 규모가 실제로 나타나는지 가늠해 보자면, KernelHost 서버에서는 음성 서버를 향한 초당 4,150만 패킷과 함께 473.4 Gbit/s를 넘는 공격과, 게임 서버를 향한 112.2 Gbit/s를 넘는 UDP 플러드가 걸러졌습니다. 이에 대한 로컬 설정은 없습니다. 볼류메트릭 공격은 서버 앞단 네트워크에서 끝나야 합니다.

KernelHost가 Hytale 서버를 향한 DDoS 공격에 맞서 제공하는 것

모든 서버 상품에 포함된 상시 방어

KernelHost의 DDoS 방어는 두 단계로 구성되어 있고 상시 동작합니다. 여러분이 무엇을 켜거나 주문하거나 설정할 필요가 없습니다.

• 1단계: 글로벌 스크러빙 네트워크의 17 Tbps 방어 용량. 볼류메트릭 공격은 발생지에 가까운 곳에서 정화되어 데이터센터에 닿기 전에 걸러집니다.
• 2단계: 프랑크푸르트암마인의 3.2 Tbps Arbor 실시간 필터링. 서버 바로 앞에서 프로토콜별 패턴을 찾아내 패킷 하나하나를 폐기합니다.

두 가지 특성이 결정적입니다. 이 방어는 상시 동작하며 공격에 먼저 반응할 필요가 없으므로, 초반에 서버가 사라지는 몇 분이 존재하지 않습니다. 그리고 null-routing을 쓰지 않습니다. 여러분의 IP 주소는 네트워크에 그대로 남고, 폐기되는 것은 악성 패킷뿐입니다. IP 주소를 네트워크에서 빼 버리면 여러분에게는 공격자와 같은 결과를 안기는 셈입니다. 어떤 게임과 프로토콜이 자체 방어 프로필로 덮여 있는지는 실시간 게임 서버 DDoS 방어에 정리되어 있습니다.

계속 공격받는 Hytale 프로젝트를 위한 Advanced DDoS Protection

어떤 프로젝트는 어쩌다 한두 번이 아니라, 표적이 되어 몇 주에 걸쳐 공격받습니다. 얼리 액세스 단계의 게임이라면 특히 지금 자라고 있는 서버가 그 대상이 됩니다. 이런 경우를 위해 Advanced DDoS Protection이 월 50.00 EUR부터, PrePaid 방식으로, 최소 이용 기간과 설치비 없이 제공됩니다. 차이는 용량이 더 커지는 데 있지 않고 통제권에 있습니다.

• 전용 방어 IP: 프랑크푸르트 코어에서 발급되며, 서버는 자체 네트워크에서 이 IP로 전환됩니다. 여러분 쪽에서 손볼 것은 없습니다.
• 포트와 프로토콜별로 직접 관리하는 방어 규칙: 고객 포털에서 5520 UDP에 무엇을 허용할지를 다른 모든 것과 분리해 정하고, 그러기 위해 티켓을 열 필요가 없습니다.
• 변경은 실시간으로 반영: 공격이 진행되는 중에도 값을 조정할 수 있습니다. 예를 들어 새 연결만 잠시 더 좁게 제한하고 진행 중인 게임 트래픽은 건드리지 않을 수 있습니다.
• 프로토콜에 맞춘 규칙 세트: UDP 위의 QUIC뿐 아니라 임의의 TCP 또는 UDP 포트에서 돌아가는 자체 애플리케이션도 같은 방식으로 다룹니다.

Advanced DDoS Protection은 KernelHost에 놓인 서버를 대상으로 합니다. Hytale 프로젝트를 현재 다른 곳에서 운영하면서 계속 공격받는다면, 그 프로젝트를 KernelHost로 이전하면 두 단계가 서버 제공 시점부터 동작합니다.

두 단계 비교

대부분의 Hytale 서버에는 깔끔한 서버 설정과 포함된 상시 방어면 충분합니다. Advanced DDoS Protection은 누군가 이 일을 개인적으로 받아들였을 때의 답입니다.

다른 게임에서 Hytale로 옮겨 적용할 수 있는 것

Hytale이 아직 어리고 Hytale 서버를 향한 공격에 관한 공개 수치가 없으므로, 믿을 만한 지식으로 가는 가장 빠른 길은 비교할 만한 게임을 보는 것입니다. 이때 옮겨 적용할 수 있는 것은 포트 번호가 아니라 패턴입니다.

• 폭발적인 출시와 그것이 불러오는 것: Palworld는 새 플레이어의 물결과 공격의 물결이 어떻게 시간적으로 겹치는지, 그리고 왜 하필 자라는 서버가 표적이 되는지 보여 줍니다.
• 조회와 게임 트래픽의 차이: Minecraft Bedrock은 Unconnected Ping을 예로 UDP를 통한 증폭이 어떻게 동작하는지 설명합니다. Hytale에는 QUIC 덕분에 바로 이 공격 경로가 없고, 그래서 그 차이를 가장 잘 이해할 수 있습니다.
• 공격 대상이 되는 연결 수립: Minecraft DDoS 방어와 nullping 방어는 대역폭이 거의 들지 않는 핸드셰이크 플러드를 설명합니다. QUIC 연결 플러드의 가장 가까운 친척입니다.
• 적은 플레이어 수와 슬롯 고갈: Project Zomboid와 Conan Exiles는 고정된 집단을 막아 버리는 데 얼마나 적은 수고가 드는지, 그리고 그때 허용 목록과 비밀번호가 어떤 역할을 하는지 보여 줍니다.
• 지속적인 부하 아래의 운영: Terraria는 단일 서버 프로세스가 단일 코어 부하로 공격에 어떻게 반응하는지 보여 줍니다. Hytale 서버는 Java 프로세스이고, 근본 문제는 비슷합니다.

Hytale 서버에서 자주 나오는 실수와 해결 방법

“포트 5520 TCP를 열었는데 플레이어가 여전히 들어오지 못합니다”: 게임 트래픽은 QUIC를 통해, 곧 UDP를 통해 흐릅니다. TCP 허용은 게임 트래픽에 아무 도움이 되지 않습니다. 5520 UDP를 허용하고 nmap -Pn -sU -p 5520으로 외부에서 확인하세요. --bind로 서버를 다른 포트에 올려 두었다면 허용이 그 포트를 가리켜야 합니다.

“서버는 돌아가는데 아무도 접속하지 못하고, 로그에는 공격에 관한 내용이 없습니다”: /auth status로 서버가 자기 계정에 로그인되어 있는지 확인하세요. 로그인이 만료된 서버는 계속 돌아가면서도 플레이어를 거절합니다. 이는 네트워크 문제도 아니고 필터 규칙도 아닙니다.

“업데이트 후에 아무것도 시작되지 않습니다”: 공격이 아니라 프로토콜 변경입니다. 업데이트 6으로 네트워크 프로토콜이 hytale/2에서 hytale/3으로 바뀌었고, 서버와 플러그인은 새로 빌드해야 합니다. 업데이트는 운영 서버에 올리기 전에 두 번째 인스턴스에 먼저 적용하세요.

“플레이어 전원이 2초 동안 동시에 멈추고 그 뒤에 계속 진행됩니다”: 높은 확률로 Java 실행 환경의 가비지 컬렉션이고 공격이 아닙니다. jcmd ... GC.heap_info와 서버 로그를 확인하세요. 그때 sar -n DEV 1 10이 평범하게 나오면 공격은 관여하지 않았고, 힙을 너무 빡빡하게 잡았거나 시야 거리가 너무 큰 것입니다.

“작은 패킷을 막는 규칙이 플레이어를 내쫓았습니다”: 그렇다면 1200 바이트 조건이 ct state new 없이 체인에 들어가 있는 것입니다. 진행 중인 게임 트래픽은 대부분 작은 패킷이고, 상태 검사가 없는 길이 조건은 바로 그것을 때립니다. 이 조건은 새로 열리는 데이터 스트림에만 적용됩니다.

“IP 주소를 바꿨는데 두 시간 뒤에 다시 오프라인이 되었습니다”: 공격자는 새 주소를 옛 주소와 같은 경로에서 얻었습니다. Hytale에서는 보통 DNS에 남은 오래된 A 레코드, 상태를 표시하는 Discord 봇, 또는 서드파티 서버 목록 가운데 하나의 항목입니다. 업데이트 6 이후 공식 서버 목록에서는 서버 주소가 기본값으로 숨겨져 있어 가장 편한 경로는 닫혔지만, 모든 경로가 닫힌 것은 아닙니다. 주소 변경은 시간을 벌어 주지만 해결책은 아닙니다.

“필터 규칙이 적용되지 않습니다”: 흔한 원인이 세 가지입니다. 규칙이 UFW 체인 뒤에 있어 전혀 도달하지 못하거나, 마지막 재시작 이후 사라졌거나(이때는 netfilter-persistent save 또는 /etc/ufw/before.rules 항목이 도움이 됩니다), 공격이 볼류메트릭이어서 규칙은 이미 꽉 찬 회선에서 제대로 동작하고 있는 경우입니다. iptables -L INPUT -n -v로 매칭 카운터가 올라가는지 확인하세요.

“기존 업체가 제 IP 주소를 차단했습니다”: 그것이 null-routing입니다. 업체는 그렇게 자기 네트워크를 지키지만, 여러분에게 남는 결과는 공격이 성공한 것과 똑같고, 보통 그 뒤로 몇 시간 더 이어집니다. 확실하지 않으면 필터링을 하는지 null-routing을 하는지 물어보세요. 그 답이 어떤 하드웨어 사양보다 여러분의 가용성을 더 크게 좌우합니다.

“tcpdump에 이상한 것이 보이지 않습니다”: 트래픽이 이미 앞단 네트워크에서 걸러지고 있으면 서버에는 아무것도 도착하지 않는 것이 당연합니다. 필터링이 작동하고 있을 때의 정상적인 모습입니다. 반대로 회선이 포화되면 측정에 쓰려던 SSH 세션조차 닿지 않을 수 있습니다. 그럴 때는 게스트 시스템의 네트워크와 무관하게 동작하는 고객 포털의 VNC 콘솔을 이용하세요.

핵심 요약

• Hytale 서버는 정확히 하나의 열린 포트가 필요합니다. 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에서는 2단계 상시 방어가 모든 서버 상품에 추가 요금 없이 포함되어 서버 제공 시점부터 동작하며, null-routing을 쓰지 않습니다. 전용 방어 IP와 포트별로 직접 관리하는 규칙을 갖춘 Advanced DDoS Protection은 월 50.00 EUR부터 시작합니다.

Hytale 서버가 이미 KernelHost에 있다면 필터링은 여러분이 아무것도 하지 않아도 동작하고 있습니다. 그래도 이상한 점이 보이면 지원 티켓을 열어 주세요. 해당 IP 주소의 필터 규칙을 다시 맞춰 드립니다. 공격이 진행 중일 때는 WhatsApp 긴급 채팅 +43 650 8209883으로도 연락하실 수 있습니다.

이 글은 2026년 9월 27일 기준입니다. Hytale은 얼리 액세스 단계이고 네트워크 프로토콜은 올해 이미 한 번 바뀌었습니다. 이 글은 Chapter 1 이후, 그리고 연결 수립이나 포트나 서버 목록에 영향을 주는 업데이트마다 갱신됩니다.