Introduction#
Minecraft servers are constantly exposed to the threat of DDoS attacks. In this article, I will share the challenges faced and the technical transitions 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 Trial-and-Error Free Services (2021)#
At the start of the service, we operated HAProxy on Oracle Cloud's free tier and our surplus VPS. Utilizing docker kill -s HUP to reload settings while maintaining existing connections, we created a somewhat shaky system with a PHP-based API that dynamically rewrote configurations. Users were assigned random ports from a panel, and we used gdnsd for DNS round-robin load balancing.
However, due to a sudden increase in users, this makeshift system became unstable, and with the departure of a key member, we had to temporarily suspend operations after about six months.
Technical Refresh: Transition to infrared (August 2021 onwards)#
Upon resuming the service, we shifted from free provision to a policy of "users sharing costs to build stronger protection." The system was also revamped, 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 distributed traffic based on domain names.
Introduction of Cloudflare Spectrum and Fighting L7 Attacks (2022 to Early 2023)#
With the consolidation to infrared, many IPs became unnecessary, leading us to start using Cloudflare Spectrum as the next measure. We were able to implement strong L4 layer protection at a low cost (via resellers), but it had a critical flaw: if the origin server's IP was exposed to malicious users, it would be directly attacked. Since there were no affordable and reliable upstream filters in the country, we temporarily adopted this configuration.
During this period, the mainstream of attacks shifted from simple L4 floods to more sophisticated L7 attacks. We particularly struggled against attack types that left no logs.
Ultimately, it was discovered 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, leading to intermittent disconnections for players. The configuration using proxy-protocol between Spectrum and infrared made L3/L4 level access control difficult, and there were limitations for real-time processing on the application side.
Transition to Full-fledged DDoS Protection: Adoption of GSL and Path.net (2023 to 2024)#
Judging that continued use of Spectrum was unrealistic, we transitioned to an environment using GSL's custom firewall in February 2023. Subsequently, to respond to 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 the infrastructure.
Entering 2024, we officially added overseas locations to meet demand from regions like Singapore, Taiwan, and Hong Kong. However, considering the difficulties in 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.
Details of the Final Protection Configuration (2023 onwards)#
+--------------+ +---------------+
| 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 Obtained IP) v
+----------+
| Grafana |
+----------+
Overall Structure#
The final configuration consolidates the administrator flow and player communication flow into the central infrared proxy. Considering fluctuations in user numbers and changes in costs, we settled into a state where flexible scaling up/down is possible.
DNS / Load Balancing#
To efficiently operate multiple locations, including overseas PoPs, advanced DNS control combining GeoDNS (changing connection destinations based on location), Failover (automatic switching during failures), and RoundRobin (load balancing) was essential. Since commercial services like AWS Route53 and Constellix were costly, 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 limited user connections to the server exclusively via domain names, rejecting all direct connections to the IP addresses of each PoP. This way, unless the L7 botnet intentionally bypassed DNS resolution, 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.
Below is an example of actual settings 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 based on 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 improve the accuracy of Failover, we conducted health checks using mcping. Simple TCP port connectivity checks could mistakenly indicate "Up" even when the server was not responding correctly under L7 attacks. By using mcping, we achieved more accurate monitoring based on whether it could actually 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
}
}
Countermeasures at Each Protection Server#
At each PoP, we used nftables as needed. We dynamically applied rate limits according to the attack situation.
Lessons Learned from Operating Nohit.cc#
The greatest 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 specific vulnerabilities to cleverly designed attacks. Understanding these and addressing them accurately required more than just generic DDoS protection services.
Not only the technical challenges but also the experiences gained as an operator were invaluable. In a niche area with limited demand and supply, 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 years of records 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.