Investigate false positives
Recover legitimate player actions without disabling every protection blindly.
Recognize the symptom
Rejected items, delayed actions, disconnects, or slow circuits do not automatically indicate an attack. Correlate the event with a redacted Nusa warning: module, reason, and action. Log rate limits can hide some repeated events.
Isolate one cause
- Record the normal action, relevant client/plugin version, time, and item/function involved. Do not request suspicious payloads from players.
- Reproduce on staging with matching configuration and plugins.
- Identify the guard actually triggered and consult its settings.
- Adjust one relevant value, or disable one guard only for a bounded staging comparison, then restart.
- Repeat legitimate actions, inspect logs/profiles, and restore defaults if the change does not help.
Do not lower limits when legitimate NBT is already rejected. Check plugin data size/format. Narrow or remove unverified operator pattern rules. For player-work exhaustion, investigate expensive plugin handlers before expanding the budget.
SKIP and disconnect
SKIP normally retains a healthy connection after recognized rejection; the tick guard instead defers bounded gameplay work. It does not keep every malformed protocol connection alive. DISCONNECT closes the connection sooner but does not repair slow handling.
Emergency recovery
Safemode also bypasses all six Nusa guards. Restrict access and keep a diagnosis plan if emergency use is necessary. It is not a permanent solution or plugin certification.
Prepare a redacted support report, excluding inventories, secrets, addresses, and raw full configurations that are not required.