The Firewall page decides which traffic your server accepts and which it drops, with live analytics to show you what's actually hitting it. Here's the honest part first: most servers never need to touch this. Falix already sits behind network-level DDoS protection, and a normal Minecraft server or web app runs fine with the firewall left off. It's here for when you have a real reason — a specific attacker to block, an admin port to lock down, a flood to rate-limit. Open Firewall from your server menu.
| At a glance | |
|---|---|
| You need | Any Falix server, and a specific reason to filter traffic |
| Plan | All plans |
| Time | Twenty minutes if you're writing rules |
🎯 Good to know: Leaving the firewall off doesn't mean "no protection" — the platform's own DDoS mitigation runs regardless. The firewall is your layer on top, for rules only you know you want.
Turning it on
A master Enable toggle switches the firewall on or off. When it's on, one setting decides what happens to traffic that matches no rule: the default action — Allow (let unmatched traffic through) or Drop (block everything except what your rules explicitly allow). Allow is the sane default; only switch to Drop if you're building a strict allow-list and know exactly what to open. A Sync button re-pushes your rules to the node if they ever look out of step.
Traffic analytics — look before you write rules
Before blocking anything, see what's really happening. The analytics section pulls a live report over a window you choose — 15 minutes, 1 hour, 6 hours, 24 hours, 3 days, 7 days, or 30 days — and shows:
- Counters: Allowed packets, Blocked packets, Active connections, Unique sources, and Countries.
- A traffic chart you can switch between traffic in/out, connections, and sources over time.
- Insight panels: Top sources (with IP, network/ASN, country, and port), Top countries, Protocols, Top ports, and Connection states.
- A threats strip that flags anomalies with a severity tag when something looks like an attack.
This is how you find the one IP or country hammering you — then you write a rule for exactly that, instead of guessing.
The three kinds of rule
Rules live in three groups. Every rule can be Allow, Drop (silently discard), or Reject (discard and tell the sender), and you can enable or disable each one without deleting it. A server holds up to 50 rules.
| Group | You specify | Use it to |
|---|---|---|
| IP rules | A source IP or CIDR range (e.g. 203.0.113.0/24), an action, a description |
Block one attacker, or allow-list only trusted addresses |
| Port rules | A port (or a start–end range), protocol (both / TCP / UDP), an action, a description | Close an admin/query port to outsiders, or restrict a port to certain traffic |
| Rate limiting | Connections per second and a burst allowance | Slow down connection floods from busy sources |
Port rules only offer ports you've actually allocated on the Network page — you can't filter a port your server doesn't own.
Rate limiting, with numbers
A rate-limit rule caps how fast new connections are accepted, dropping the excess. Two values: connections per second (default 50, up to 10000) and a burst allowance (default 100, up to 1000) that absorbs short spikes. Three preset buttons set both at once:
| Preset | Connections/sec | Burst |
|---|---|---|
| Light | 100 | 150 |
| Medium | 50 | 100 |
| Strict | 25 | 50 |
Start Light; tighten toward Strict only if a flood is getting through. Rate-limit rules always drop the overflow.
Priority — order matters
Rules are checked top to bottom, and the first match wins. Each rule has a priority, and you set it by dragging rules into order. This is the part people get wrong: if a broad "drop everything from this range" sits above a narrow "allow this one IP", the allow never gets a chance. Put your specific allows above your broad drops.
DDoS protection — sensible defaults, rarely touched
A DDoS section adds flood-specific protections. All of the flood protections ship turned off, because the platform already handles the heavy lifting — you turn one on only if you're chasing a specific pattern. The defaults, if you do enable them:
| Protection | Default | Tunable values |
|---|---|---|
| SYN flood | Off | rate 50, burst 100 |
| ACK flood | Off | rate 200, burst 400 |
| UDP flood | Off | packets/sec 5000, burst 1000, bytes/sec 0 (off) |
| Fragment protection | Off | on/off |
| Invalid packets (drop) | Off | on/off |
| Preserve existing connections | On | on/off |
| Per-source tracking | Off | on/off |
"Preserve existing connections" being on by default is deliberate — it means enabling a protection won't cut off players already connected. Saving requires at least one flood/packet protection to be active; turning them all back off removes the DDoS rule entirely.
⚠️ Heads up: Aggressive flood thresholds can drop legitimate players on a busy server. If enabling a protection makes people unable to join, loosen the numbers or turn it off — the defaults above are a conservative starting point, not a target.
Who can touch the firewall
The page is governed by firewall permissions: read to view analytics and rules, create to add rules, update to toggle the firewall, reorder, and edit DDoS settings, and delete to remove rules. Hand these out per person on the Sub-users page. Firewall changes also show up in your server's Activity log.
Troubleshooting
- My rule isn't taking effect — check its position. A broader rule above it may be matching first; drag your specific rule higher. Also confirm the firewall itself is enabled and the rule is switched on.
- Everything got blocked — you likely set the default action to Drop without allow rules for normal traffic. Switch the default back to Allow, or add the allows you need.
- Players suddenly can't join — a DDoS threshold or rate limit is too tight for your player count. Loosen it or turn it off.
- Changes didn't apply — press Sync to re-push rules to the node.