Troubleshooting

Status codes are on Errors. This page is the behaviour that looks like a fault and mostly is not.

A change I made has not taken effect

Firewall writes propagate in 5-10 seconds normally and can take up to 5 minutes. A read straight after a write may not show it yet.

Poll the read endpoint until the change appears rather than sleeping a fixed interval, and on a multi-port write check created against requested — the network applies one rule per port and the request is not atomic. A 502 means none of them landed. See Firewall.

A rule I deleted came back

A firewall group owns it. The group is the source of truth and its next reconcile restores anything removed by hand. Rules and filters carry managed_by_group on read, so you can tell before you try; edit the group in the portal instead.

Every player disconnected the moment I applied a filter

Expected. A stateful filter knows nothing about connections established before it existed, so everything on that port has to reconnect through it. Apply filters in a maintenance window, or before the port is in use — see Filters.

Legitimate traffic is being dropped

Work outwards from the things you control:

1. Your own deny rules. Read them back for the address rather than trusting what you think is there.
2. Geo rules. Country and ASN blocks are portal-only and do not appear in the API's rule list, so a script that reads clean rules can still be looking at a geo-blocked source.
3. Filters on the wrong port. A filter validates traffic against a specific protocol. Point a game filter at a port that is serving something else and valid traffic fails validation exactly as designed.
4. Then tell us. Source addresses, destination port, UTC timestamps, and a capture if you have one — see Support.

A 404 on an address I own

404 covers both "no such address" and "not yours", deliberately and indistinguishably — the alternative lets anyone with a key map our address space.

Check it against Ownership. The usual causes are an address on a service that has since been cancelled, and an address inside a prefix that a different organisation announces.

Attack history returned less than I asked for

History for an address only covers the time it has been on your account, so a window reaching further back is silently raised. meta.from reports the date actually used and meta.from_clamped is true when that happened — read both rather than assuming you got the window you requested. See Attack history.

No attack_ended webhook arrived

Two normal explanations before anything is wrong:

• it is not sent the instant traffic stops; it follows once the attack is settled, which is what makes its peak figures final rather than partial
• if the same address is under attack again when that delay expires, the ended event is suppressed entirely

See Attack webhooks.

Attack history is empty but I was clearly attacked

Filtering is always on and does not wait for detection, so traffic can be dropped without ever growing large enough to open an attack record. An empty history means no event crossed the reporting threshold, not that nothing was filtered — see How mitigation works.

A 403 on a key that used to work

A key acts as the person who created it and is re-checked on every request. It stops working if that person's permission is withdrawn, if they leave the organisation, or if the endpoint's flag is turned off for your organisation — which takes effect immediately, including for keys already issued.

Errors narrows the rest.

429 on a script that scaled out

Rate limits count against the bearer token, not the source address, so running the same key on twenty machines shares one bucket. Issue a key per workload instead — Rate limits.