Introduction#
Minecraft servers are constantly threatened by DDoS attacks. In this article, I will share the challenges we faced and the technical transitions we adopted based on nearly four years of operational experience with the DDoS protection service "Nohit.cc," which ended its service at the end of June 2025.
I have experience operating large-scale Minecraft servers, and I leveraged that knowledge to establish Nohit.cc with three students. I hope this record will help server administrators and engineers facing similar challenges.
Evolution of Protection Methods#
Initial Configuration: HAProxy and Free Services (2021)#
At the start of the service, we operated HAProxy on Oracle Cloud's free tier and our surplus VPS. We utilized docker kill -s HUP to reload configurations while maintaining existing connections, creating a somewhat shaky system with a PHP-based API that dynamically rewrote settings. Users were assigned random ports from a panel, and we used gdnsd for round-robin load balancing in DNS.
However, due to a rapid increase in users, this makeshift system became unstable, and with the departure of a key member, we had to temporarily pause operations after about six months.
Technical Refresh: Transition to infrared (August 2021 - )#
Upon resuming service, we shifted from free provision to a policy of "users sharing costs to build stronger protection." We also revamped the system, switching the proxy software from HAProxy to a Go language-based fork of infrared. This allowed all users to utilize port 25565 and enabled a more sophisticated configuration that routed communications by domain name.
Introduction of Cloudflare Spectrum and Fighting L7 Attacks (2022 - Early 2023)#
With the consolidation to infrared, many ports became unnecessary, leading us to start using Cloudflare Spectrum. We were able to implement strong L4 protection at a low cost (through resellers), but a critical flaw was that the IP of the origin server was exposed to malicious users, making it susceptible to direct attacks. There were no affordable and reliable upstream firewalls available domestically, so we temporarily adopted this configuration.
During this period, the trend of attacks shifted from simple L4 floods to more sophisticated L7 attacks. We particularly struggled against attack types that did not leave logs.
Ultimately, it was determined that the cause of the unstable behavior was due to Cloudflare Spectrum's unique rate limits and specifications. We faced issues where it could not handle a large number of new connections, resulting in players being disconnected irregularly. The configuration using the proxy protocol between Spectrum and infrared made L3/L4 level access control difficult, and there were limitations in real-time processing on the application side.
Transition to Full-fledged DDoS Protection: Adoption of GSL and Path.net (2023 - 2024)#
We deemed the continued use of Spectrum unrealistic and transitioned to an environment using GSL's custom firewall in February 2023. Subsequently, to address new L7 attacks targeting CPU resources, we temporarily implemented Web Captcha authentication as a countermeasure.
In May 2023, we reassessed cost performance and migrated back to Path.net. This also involved a price revision. Since bare metal servers with fixed costs lacked scalability, we ultimately utilized Linode, Datapacket, etc., to facilitate easier scaling of infrastructure.
Entering 2024, we officially added overseas locations to meet demand from regions like Singapore, Taiwan, and Hong Kong. However, considering the challenges of keeping up with GeyserMC updates and changes in demand due to the rise of competing services, we stopped supporting UDP in March 2024 and optimized our scale.
Final Protection Configuration Details (Post-2023)#
+--------------+ +---------------+
| Player | | Vercel (Panel)|
+--------------+ +---------------+
| |
(1. DNS Query) | | (A. Panel Operation)
v v
+--------------+ +---------------+
| gdnsd | | API |
+--------------+ +---------------+
| |
(2. Return IP) | | (B. Reflect Settings)
| |
| v
| +------------------+
| | infrared(fork) |
| +------------------+
| ^ |
+--------------------------+ | (C. Metrics)
(3. Connect to Retrieved IP) v
+----------+
| Grafana |
+----------+
Overall Structure#
The final configuration centralizes the administrator flow and player communication flow through the central infrared proxy. Considering fluctuations in user numbers and changes in costs, we settled into a state that allows for flexible scaling up and down.
DNS / Load Balancing#
To efficiently operate multiple locations, including overseas PoPs, advanced DNS control combining GeoDNS (location-based connection changes), Failover (automatic switching during failures), and RoundRobin (load balancing) was essential. Commercial services like AWS Route53 / Constellix were costly, so we adopted gdnsd, which we could build ourselves.
In particular, traffic distribution using GeoDNS played a crucial role in avoiding load concentration on a single location. We restricted user connections to the server exclusively through domain names, rejecting all direct connections to the IP addresses of each PoP. This ensured that unless L7 botnets intentionally circumvented DNS, attack traffic would be distributed across the entire global infrastructure, just like player traffic. This architecture proved highly effective in preventing attacks from concentrating on specific locations.
Here are some actual configuration examples for Japanese users.
# Define data centers and weighting
jpgeo => {
map => map_japan
up_thresh = 0.00000001
service_types => mc
plugin => weighted
dcmap => {
DC-JP => {
JP01 => [1.1.1.1,1], #nht-tyo-1
JP02 => [1.1.1.2,1], #nht-tyo-2
JP03 => [1.1.1.3,1], #nht-tyo-3
JP04 => [1.1.1.4,1], #nht-tyo-4
},
DC-SG => [1.1.1.5,1] #nht-sgp-1
DC-UK => [1.1.1.6,1] #nht-lon-1
DC-CN => [1.1.1.7,1] #Softbank
}
}
# Assign the optimal data center based on the continent/country of access using the GeoIP database
map_japan => {
geoip2_db => GeoLite2.mmdb,
datacenters => [DC-JP,DC-SG,DC-UK,DC-CN],
map => {
AF => [DC-UK],
AN => [DC-JP],
NA => [DC-JP],
SA => [DC-JP],
AS => {
default => [DC-JP],
SG => [DC-SG],
MY => [DC-SG],
ID => [DC-SG],
CN => [DC-CN],
}
OC => [DC-JP],
EU => [DC-UK],
}
}
Health Check#
To enhance the accuracy of Failover, we conducted health checks using mcping. Simple TCP port connectivity checks could misjudge a server as "Up" even when it was not responding correctly under L7 attacks. By using mcping, we achieved more accurate monitoring based on whether it could respond as Minecraft.
service_types = {
mc = {
plugin = extmon
cmd = ["/etc/gdnsd/mcping/mcping", "%%ITEM%%", "25565"]
interval = 8
timeout = 5
up_thresh = 3
ok_thresh = 3
down_thresh = 2
}
}
Measures at Each Protection Server#
At each PoP, we used nftables as needed. We dynamically applied rate limits based on the attack situation.
Lessons Learned from Operating Nohit.cc#
The biggest lesson learned from operating Nohit.cc for four years was the importance of supplementing areas that off-the-shelf products could not reach with our own hands.
A symbolic example of this is that Minecraft (Java) uses TCP. The stateful nature of TCP allows it to ignore simple attacks like UDP floods, but it also creates unique vulnerabilities against cleverly designed attacks. Understanding these and addressing them accurately required more than just generic DDoS protection services.
The experience gained as an operator was also invaluable. In a niche area where both demand and supply are limited, the feeling that the service we developed was accepted by the community and was genuinely helpful was an irreplaceable joy. There were even instances where we received information requests from law enforcement, experiences that an individual pursuing technology would never encounter, making me acutely aware of the responsibility and excitement of providing a service as a social infrastructure.
I hope the four-year record shared in this article will be of some assistance to those who will tackle DDoS countermeasures in the future.
In the next article, I plan to delve deeper into the specific "quirks" of DDoS protection at various hosting providers like GSL and Path.net, as well as how to choose them effectively.