When players cannot connect

Protection that is tuned too tightly looks exactly like an outage: players time out, nobody can join, and nothing on the server itself looks wrong. This page works through the causes most likely first, with the check that confirms each one and the change that fixes it.

Start here: is it your protection at all

Filtered: the line names the cause

game-01 / AttacksExample view

Address lookupCheck whether a specific address was filtered before it reached your server, and which protection acted. Counts are exact, not sampled.

198.51.100.23

2Look up

3

198.51.100.23 · 1,240 packets filtered across 1 attack windowThis address had completed a valid session, so some of these drops affected legitimate traffic. Worth reporting to support.First packet dropped; a normal client retries and gets in · udp/30120

Not filtered: look past Prism

game-01 / AttacksExample view

Address lookupCheck whether a specific address was filtered before it reached your server, and which protection acted. Counts are exact, not sampled.

198.51.100.40Look up

198.51.100.40 was not filteredNo packets from this address were dropped in any published attack report, so its traffic reached your server. Reports publish after an attack ends, if one is running now, its data is not in yet.

1. Get the public IP address of one affected player

   Anyone who cannot connect will do. One real address turns the rest of this page from guesswork into a lookup.

2. Run Address lookup on the Attacks tab

   Open Attacks, find the Address lookup card, paste the address in, and press Look up. This reads the exact drop ledger, so its answer is not a sampling artefact.

3. Read the verdict

   If it says the address was not filtered, its packets reached your server and your protection settings are not the cause. Skip to If it is not your settings.

   If it comes back with packets filtered, you also get a plain-language line naming what dropped them and the protocol and port involved. That line tells you which section below to read.

4. Note the port and protocol

   Open the Firewall tab and find the rule for that exact port and protocol. Rules are per protocol, so a service that needs both TCP and UDP needs two of them, and the rule you are looking at might not be the one doing the dropping.

1. A rate limit set below your real peak

The most common cause, because the number that stops an attack and the number that stops your busy hour are often not far apart.

Symptom. Players drop out or fail to join at your busiest time and connect fine when the server is quiet. New players cannot get in while people already in the game stay connected. It started right after you set or lowered a limit, or applied a preset.

Confirm it. In Port activity on the Attacks tab, your game port shows a large Dropped figure and a Top reason naming a rate or capacity check, while other ports are quiet. The Rule column on that row shows the cap that is in force. Address lookup on an affected player returns a line such as "Server's aggregate inbound cap was full" or "Per-source packet rate exceeded".

Fix it. Open the rule and raise Whole port, packets/sec (pps_limit) above your real peak, or set it to 0 to remove the aggregate cap entirely. If the per-connection ceiling is the one biting, raise Per connection, packets/sec (estab_flow_pps). A value of 0 there is not unlimited, it means the filter falls back to its built-in default for that service.

For scale, on Minecraft an estab_flow_pps of 250 is about what one established player needs, and a value of 80 is low enough to cut real players off. See Rate limits for how to pick numbers from your own traffic instead of from an attack.

2. No rule for the port, with the default set to Deny all

Symptom. Nobody connects at all, from any network, including you. One service works and another is completely dark. It started when you changed the default policy, applied a preset, or deleted a rule.

Confirm it. On the Firewall tab, look at Default for unlisted ports. The two settings describe themselves:

Allow: unlisted ports pass through to always-on mitigation.

Deny: only ports with a rule below are reachable. Everything else is dropped.

On that description, a server set to Deny all needs an enabled rule for every port its players use. So check the rules table for the exact port, the exact protocol, and, on a range, that the port really falls inside it. In Port activity, a row carrying a no rule badge is a port that took traffic with nothing configured for it.

Fix it. Add the missing rule with Add rule, or set the default back to Allow. Three things that catch people out here:

• A rule showing Disabled in the table is not doing anything, and the panel has no control to switch it back on. Delete it and add it again.
• After applying a preset, count the rules that actually landed against the rules that preset is meant to write. What is in the table is what is in force.
• A server is capped at 15 rules. Past that, adding one is refused with "Rule limit reached (15 rules per server). Delete a rule before adding another.", so a server sitting at the cap has no room for the rule you are about to add.

3. Protocol validation rejecting a client

Symptom. Most players connect but one group cannot: a modded or alternate client, an older build, a launcher that connects its own way. The affected players fail immediately and consistently, not intermittently.

Confirm it. Open the rule for the game port and look at Protocol validation (L7) (l7_validation). Its job is described in the dialog: "Checks that traffic actually speaks this service's protocol and drops what doesn't." On an affected player, Address lookup returns a line such as "First packet of a new flow wasn't a valid game handshake".

Worth knowing before you go hunting: this switch is off by default on a rule you add by hand and on for most preset rules. Two rules on the same port can behave differently purely because of how they were created.

Fix it. Turn Protocol validation (L7) off on that rule, save, and have the player retry. If the rule is for a service with no validator the dialog says so directly, "This service has no protocol validator. No effect on this one.", and this is not your cause. More detail on Protocol validation.

4. An engine producing false positives

Three protection engines can be switched off per rule, and each is available only where it applies:

A switch that is on means the engine is running, so turning one off is what clears its bit. A switch that is greyed out does not apply to this rule's protocol or service and is not your cause.

Symptom. Players get in on the second or third attempt but not the first. Connections succeed intermittently with no pattern by time of day. One group of players, often on one kind of network, is affected far more than the rest.

Confirm it. Address lookup on an affected player returns a line about a first packet or a first attempt being dropped. That is a challenge working as designed, and it is also exactly what a client that never retries experiences as a permanent failure. Which line you get decides what you can do about it:

• "First packet dropped; a normal client retries and gets in" is the UDP challenge, and you own the switch for it.
• "First connection attempt dropped; a normal client retries and gets in" is the TCP equivalent, and the rule dialog has no switch for that one. Take it to support rather than hunting for a control.

If the lookup adds "This address had completed a valid session, so some of these drops affected legitimate traffic. Worth reporting to support.", the panel is telling you outright that a known-good player was hit. Say so in the ticket.

Fix it. For the UDP case, turn UDP first-packet challenge off on that rule, save, and retest. Change one engine at a time, and turn it back on if it made no difference, so you do not leave protection off for nothing.

5. A known-good source that was never allowed through

Symptom. Ordinary players are fine, but one specific source keeps being dropped: your own admin connection, an uptime monitor, a voice server, a relay or proxy your players connect through.

Confirm it. Address lookup on that address returns filtered packets. Then open the Source IPs tab and check whether the address is listed at all. Look at both sides of that list:

• An entry with an ALLOW badge is a whitelist entry. If the address is not there, nothing is exempting it.
• An entry with a DENY badge is a block you or someone on your account added. The block dialog is explicit about its reach: "Packets from this address will be dropped at the edge before they reach your server. Bypasses port rules." An address shared by many players, such as a mobile carrier's gateway, blocked once to stop one attacker takes out every player behind it too. Check the Expires column while you are there: an entry added with Expires set to Never is still in force.

Fix it. Use Whitelist to add the address, with a note so you know later why it is there. The dialog states what it buys: "Traffic from this address bypasses all rate limits and behavioral filters." Whitelist entries do not expire, and only single IPv4 addresses are accepted. To undo a block, remove the entry from the list. See Blocking and allowing IPs.

6. A rule that was edited and quietly lost a value

Symptom. Nothing changed except that you opened a rule and saved it, and traffic now behaves differently. Or a port you did have a rule for is suddenly unlisted.

Confirm it. Read the rule row in the table against what you meant to set, field by field. The things that change without an obvious warning:

• A cleared box saves as 0. Editing a rule writes the fields the form owns exactly as you left them. Clearing Whole port, packets/sec saves 0, which removes the aggregate cap. It does not mean "leave it as it was".
• Changing Service moves the rule. Picking a different Service inside the edit dialog rewrites Port and Protocol from that service's defaults and clears the range. If you only wanted to relabel a rule, you have relocated it. If the new port and protocol collide with another rule you get an error naming it, such as "A TCP rule starting at 3389 already exists."
• Drop UDP on this port (disallow_udp) drops all UDP aimed at that port. On a UDP game that is every player.
• Proxied sources only (only_proxied) accepts only known proxy and CDN ranges on that port. Ordinary players are not in those ranges.

Fix it. Reopen the rule, set every field deliberately, and save. Do not leave a field you did not intend to touch to whatever the form filled in. If the rule now sits on the wrong port, fix the port rather than adding a second rule, because a port and protocol pair can only belong to one rule. See Port rules.

If it is not your settings

Traffic that Prism dropped and a server that is not answering look identical from a player's side. These tell them apart.

Prism is not dropping it when:

• Address lookup says the address was not filtered. The panel spells out what that means: no packets from it were dropped in any published attack report, so its traffic reached your server.
• Port activity shows 0 dropped on that port for the range you selected, and the header posture reads Protected rather than Elevated or Under attack.

Then check the server itself:

• Its power state and the live gauges on Server overview. A server that is off or pinned at 100% will refuse connections with nothing in the Attacks tab to show for it.
• Console access reaches the machine without going through the game port at all. If the console works but the port does not, the game process or a firewall running inside your own server is the suspect. Prism's rules are separate from anything configured inside the server, and the panel does not manage that.
• Connecting to your server for getting in over SSH or RDP to check the service is listening.

When to open a ticket

Open one when the lookup says a verified player was dropped, when it names a check that has no control on the Firewall tab, or when Address lookup keeps returning was not filtered while players still cannot reach a server you have confirmed is running.

Two lookup results always belong in a ticket rather than in a settings change, because no control on your side produces them: "Country is blocked" and "Network (ASN) is blocked". Those come from filtering set above your server, so quote the line and the affected address and let support take it from there.

Include the incident ID from the Attacks tab, the affected source address, the port and protocol, the time it happened, and the exact line Address lookup returned. Those five things are what turn a ticket into an answer. See Opening a ticket.

The platform status card is not a substitute for this check. It reports whether the panel's own upstream systems are answering, not whether your server is running.

Related