Investigate a blocked legitimate request by matching the visitor's failure to a specific firewall event. The objective is to restore the required action while keeping the rest of the website's protection effective.
01 Collect a reproducible example
- Record the exact time and time zone, URL, action, visible error code and request reference. Include the affected public IP through a private support channel where relevant.
- Repeat the action once with harmless test data. Note whether all users fail or only a network, country, browser or particular form submission.
- Open the firewall settings and relevant events for the site. Determine whether the failure comes from an explicit country, address or URL block, an attack-detection rule, or the hosting server.
- Ask the application owner to review the request. A business user can unintentionally submit data that exposes an application defect or resembles an attack.
- Apply the narrowest justified correction, such as removing an accidental address block or defining a specific supported exception. Record who approved it and why.
- Retest the same action and a normal visitor path. Remove temporary exceptions after the investigation and watch for renewed failures.
Common questions
Does every SiteLock error mean the firewall blocked me?
No. For example, origin connection failures can display a SiteLock-branded page. Codes identifying a block need a different investigation from a timeout reaching the hosting server.
Should I allow an entire country or network?
Only if that matches a deliberate access policy. A broad exception can admit unrelated traffic and may still fail to address a rule targeting a URL or request body.
Can I send the full failed request to support?
Remove passwords, session cookies, payment details and private form content. A request reference, timestamp and redacted description usually provide a safer starting point.