Use this guide when legitimate visitors, administrators, or trusted services appear to be blocked by the Web Application Firewall or other EDGE security rules.

A WAF block can affect a single request, a specific page, an administrator action, an API request, a country, an IP address, or a larger part of the site. This guide helps you confirm whether the WAF or firewall is involved, identify the likely rule or pattern, restore legitimate access safely, and avoid weakening site protection unnecessarily.

When to use

Use this guide when:

  • Visitors see an access denied, forbidden, blocked, or security-related message
  • A specific page, form, checkout, login, API request, or admin action is blocked
  • A trusted IP address or service cannot access the site
  • Users from a specific country or network cannot access the site
  • The site returns repeated 403 responses
  • Security Events & Analytics shows repeated blocked requests
  • A recent firewall, WAF, geo-blocking, plugin, theme, or deployment change may have caused legitimate traffic to be blocked

If only one legitimate request is being blocked by a WAF rule, also review False Positive WAF Blocks.

Symptoms

Common signs that legitimate access may be blocked include:

  • Site inaccessible: The site does not load for affected users.
  • Access denied: The browser shows an access denied or forbidden message.
  • 403 response: The request returns 403 Forbidden.
  • Security block page: A security or WAF-related block message appears.
  • Specific pages blocked: Only certain URLs, forms, admin actions, checkout steps, or API requests fail.
  • Specific users blocked: Only users from a specific IP address, network, country, or device are affected.
  • Trusted service blocked: A payment gateway, webhook, monitoring service, API client, or third-party integration cannot reach the site.
  • Recent rule change impact: The issue started after a firewall, IP access, geo-blocking, WAF, plugin, or application change.

Immediate actions

Step 1: Confirm whether this is a WAF or firewall block

Start by confirming that the issue is actually caused by EDGE security rules.

Check:

  • The exact browser error or response code
  • Whether the response is 403, 401, 429, redirect, timeout, or another status
  • Whether the issue affects all users or only specific users
  • Whether the issue affects one URL or the whole site
  • Whether the affected user is coming from a blocked IP address or country
  • Whether the issue appears in Security Events & Analytics
  • Whether the issue started after a recent firewall, WAF, plugin, theme, DNS, or deployment change

Open the affected URL in a private browser window and test from another network or device if possible.

Step 2: Review Security Events & Analytics

Use Security Events & Analytics to investigate blocked requests and repeated patterns.

  1. Log in to the Pressidium Dashboard.
  2. Go to Websites.
  3. Select the affected site.
  4. Go to Security -> Events & Analytics.
  5. Select the relevant date range.
  6. Review the event tables and charts.

Check:

  • The time the block happened
  • The requested path
  • The source IP address
  • The source country
  • The source user agent
  • The rule or event type
  • The action recorded for the event
  • Whether the same IP, country, user agent, or path appears repeatedly

Use a shorter date range when investigating a recent issue. Use a longer range when you need to identify repeated patterns.

See Security Events & Analytics for more details.

Step 3: Review Firewall settings

Use the Firewall screen to check IP-based and country-based access rules.

  1. Log in to the Pressidium Dashboard.
  2. Go to Websites.
  3. Select the affected site.
  4. Go to Security -> Firewall.
  5. Review IP Access and Geo Blocking.

Check:

  • Whether the affected IP address is in the blocked list
  • Whether the affected IP address should be added to the allowed list
  • Whether the affected country is blocked
  • Whether a country block affects legitimate visitors
  • Whether a recent rule was added or changed
  • Whether a locked platform-managed rule is involved

Be careful when changing Firewall rules. Incorrect rules can block legitimate visitors, administrators, or trusted services.

See Firewall screen for Firewall controls.

Step 4: Identify the affected traffic

Before making changes, identify exactly what is blocked.

Collect:

  • Affected URL
  • Affected IP address
  • Affected country or region
  • User agent, if available
  • HTTP method, such as GET or POST
  • Response code
  • Timestamp with timezone
  • Screenshot of the block or error
  • Whether the affected user is logged in or logged out
  • Whether the issue affects one user, many users, or all visitors

This helps avoid broad changes that reduce protection for the whole site.

Common causes

A blocked IP address

Issue: The affected user, administrator, or service is connecting from an IP address that is blocked.

What to check:

  • The affected user’s public IP address
  • The Blocked IPs section in Security -> Firewall
  • Recent IP block changes
  • Whether the IP is part of a broader CIDR range that was blocked
  • Whether the IP belongs to a trusted service or a suspicious source

What to do:

  • Remove the block if the IP was blocked by mistake.
  • Add the IP to the allowlist only if it is known and trusted.
  • Avoid allowing unknown IPs only because they are blocked.
  • Confirm the user can access the site after the change.

Geo Blocking

Issue: Visitors from a country are blocked by a Geo Blocking rule.

What to check:

  • The affected user’s country or network location
  • The Geo Blocking section in Security -> Firewall
  • Whether the country was intentionally blocked
  • Whether the business still needs the country restriction
  • Whether a VPN or proxy may make the user appear to come from a blocked country

What to do:

  • Remove the country block if legitimate visitors from that country need access.
  • Keep the country block if it is intentional and expected.
  • Add a trusted IP to the allowlist only when the IP is known and stable.

WAF false positive

Issue: A legitimate request matches a WAF rule because the request resembles an attack pattern.

This can happen with forms, checkout, search, API requests, LMS actions, membership flows, file uploads, custom endpoints, or admin actions.

What to check:

  • The blocked URL or endpoint
  • The request method
  • The matched rule or security event, if shown
  • The source IP and user agent
  • Whether the action is legitimate
  • Whether the same user action always triggers the block
  • Whether the issue started after a plugin, theme, form, checkout, LMS, membership, or API change

What to do:

  • Confirm the request is legitimate.
  • Collect the event details.
  • Create the narrowest possible exception if available.
  • Avoid disabling broad protections.
  • Contact Support if you are unsure which rule caused the block.

See False Positive WAF Blocks for detailed false positive troubleshooting.

Bot or abuse protection

Issue: Traffic is blocked because it resembles bot activity, scraping, brute-force attempts, excessive requests, or automated abuse.

What to check:

  • Request frequency
  • Repeated requests from the same IP or user agent
  • Requests to login, XML-RPC, REST API, search, checkout, or form endpoints
  • Repeated 403, 404, or 429 responses
  • Whether the traffic pattern is expected
  • Whether a trusted integration uses automated requests

What to do:

  • Confirm whether the traffic is legitimate.
  • Ask trusted services for their current IP ranges.
  • Allowlist only verified IPs or request patterns.
  • Keep abusive or unknown traffic blocked.
  • Review Traffic Analytics if request volume is high.

Recent firewall or WAF configuration change

Issue: A recent rule change blocks more traffic than intended.

What to check:

  • Recent blocked IP entries
  • Recent allowed IP entries
  • Recent country blocks
  • Recent custom rule changes
  • Recent plugin, theme, or deployment changes that changed request behavior
  • Whether the issue started immediately after a security change

What to do:

  • Review the most recent changes first.
  • Revert or narrow the suspected rule if it blocks legitimate traffic.
  • Test the affected URL or user flow after each change.
  • Document the change and result.

Plugin, theme, or application behavior

Issue: A plugin, theme, form, page builder, checkout flow, API client, or custom code sends requests that look suspicious to security rules.

What to check:

  • Recently updated plugins or themes
  • Forms that submit large payloads or encoded content
  • Checkout or payment requests
  • LMS or membership actions
  • Custom API requests
  • Search filters or query parameters
  • Upload requests
  • Requests with unusual headers or payloads

What to do:

  • Test the exact user action that triggers the block.
  • Review recent application changes.
  • Check whether the issue is limited to one plugin or feature.
  • Contact Support with the affected URL, timestamp, source IP, and request details.

Solutions

Remove an incorrect IP block

Use this when a known legitimate IP address is blocked.

  1. Go to Websites.
  2. Select the affected site.
  3. Go to Security -> Firewall.
  4. Open the IP Access section.
  5. Search for the affected IP address in Blocked IPs.
  6. Remove the block if it was added by mistake.
  7. Ask the affected user to retest.
  8. Monitor Security Events & Analytics after the change.

Only remove a block after confirming that the IP belongs to a legitimate user, administrator, or trusted service.

Allow a trusted IP address

Use this when a trusted IP address must bypass IP or country restrictions.

  1. Confirm the IP address with the affected user or service provider.
  2. Go to Security -> Firewall.
  3. Open the Allowed IPs section.
  4. Add the trusted IP address or CIDR range.
  5. Save the rule.
  6. Retest access from the affected source.
  7. Remove the allowlist entry later if it is temporary.

Add only known and trusted IP addresses. Avoid broad CIDR ranges unless required and verified.

Remove or adjust a country block

Use this when legitimate users are blocked because of Geo Blocking.

  1. Go to Security -> Firewall.
  2. Open the Geo Blocking section.
  3. Review the blocked countries.
  4. Remove the country block if legitimate users from that country need access.
  5. Retest from the affected location if possible.
  6. Monitor traffic after the change.

If the entry is locked or cannot be removed in the Dashboard, contact Support.

Handle a WAF false positive

Use this when a legitimate request is blocked by a WAF rule.

  1. Reproduce the blocked action if possible.
  2. Record the exact timestamp with timezone.
  3. Collect the source IP, affected URL, user agent, and error message.
  4. Check Security Events & Analytics for the matching event.
  5. Confirm that the request is legitimate.
  6. Look for a narrow exception or rule adjustment if available.
  7. Avoid disabling broad protections.
  8. Contact Support if the required exception cannot be safely configured from the Dashboard.

Temporarily relax protection only when necessary

Only relax or bypass protection when the business impact is high and the traffic is confirmed as legitimate.

Before relaxing protection:

  • Confirm the affected traffic is legitimate.
  • Confirm the issue is caused by security rules.
  • Use the narrowest possible change.
  • Avoid disabling broad WAF protections unless Support recommends it.
  • Set a reminder to restore normal protection.
  • Monitor Security Events & Analytics after the change.

If the site is production-critical and legitimate users are blocked, contact Support immediately.

Restore access during an emergency

If the site or a critical workflow is blocked:

  1. Confirm the affected URL and user flow.
  2. Check whether the site is blocked for everyone or only specific users.
  3. Review Security Events & Analytics.
  4. Review IP Access and Geo Blocking rules.
  5. Remove an accidental block if you can identify it safely.
  6. Allowlist a verified trusted IP if appropriate.
  7. Contact Support if you cannot identify or safely resolve the block.
  8. Continue monitoring after access is restored.

Emergency guidance

Contact Pressidium Support immediately if:

  • The whole site is inaccessible
  • A production checkout, payment, login, LMS, membership, API, or form flow is blocked
  • Administrators cannot access the site
  • A trusted third-party service is blocked
  • You cannot access or change the relevant Firewall settings
  • You suspect an active attack and legitimate traffic is also affected
  • You are unsure whether it is safe to remove or adjust a rule

When opening the support request, mark the urgency clearly and include all details listed in the Support section below.

Prevention

WAF and firewall configuration best practices

  • Keep firewall rules narrow and intentional.
  • Review blocked IPs and allowed IPs regularly.
  • Remove outdated allowlist entries.
  • Avoid broad country blocks unless they are required.
  • Avoid broad CIDR blocks unless you understand the impact.
  • Add only verified trusted IPs to the allowlist.
  • Test important user flows after security changes.
  • Document why each long-term access rule exists.
  • Review Security Events & Analytics before changing rules.

Site and application best practices

  • Test forms, checkout, login, LMS, membership, API, and upload flows after plugin or theme changes.
  • Keep WordPress, plugins, and themes updated.
  • Avoid unusual request patterns in custom code where possible.
  • Use standard HTTP methods and expected request formats.
  • Review new integrations before allowing traffic.
  • Keep a record of trusted service IP ranges.
  • Monitor security activity after campaigns, launches, or high-traffic events.

Monitoring best practices

  • Review Security at a Glance for overall security status.
  • Review Security Events & Analytics for blocked traffic and repeated patterns.
  • Review Traffic Analytics if traffic volume or source patterns look unusual.
  • Review logs when you need request-level details.
  • Compare timestamps before and after rule changes.
  • Keep screenshots or exports for important events.

Troubleshooting checklist

  • [ ] Confirmed the exact error or response code
  • [ ] Confirmed whether the issue affects all users or specific users
  • [ ] Confirmed whether the issue affects one URL, one workflow, or the whole site
  • [ ] Tested from another browser, device, or network
  • [ ] Collected the affected user’s public IP address
  • [ ] Checked Security -> Events & Analytics
  • [ ] Checked Security -> Firewall
  • [ ] Reviewed blocked IPs
  • [ ] Reviewed allowed IPs
  • [ ] Reviewed Geo Blocking
  • [ ] Checked recent firewall or WAF changes
  • [ ] Checked recent plugin, theme, deployment, DNS, or application changes
  • [ ] Confirmed whether the blocked traffic is legitimate
  • [ ] Removed only incorrect blocks
  • [ ] Added only verified trusted IPs to the allowlist
  • [ ] Created only narrow exceptions where needed
  • [ ] Retested the affected page or workflow
  • [ ] Monitored for recurrence
  • [ ] Contacted Support if the issue persists or affects production users

When to contact Support

Contact Pressidium Support immediately when:

  • The site is completely inaccessible
  • A critical user flow is blocked
  • Legitimate users are blocked and you cannot identify the rule
  • A trusted service cannot access the site
  • You cannot remove or adjust the relevant rule
  • A locked or platform-managed rule appears to be involved
  • Security changes did not restore access
  • You are unsure whether the traffic is legitimate
  • You need help creating a safe and narrow exception
  • The issue affects a live production site

When contacting Support, include:

  • Site name
  • Site URL
  • Affected domain or hostname
  • Affected URL or path
  • Exact error message or status code
  • Screenshot of the block or error
  • Timestamp with timezone
  • Affected source IP address
  • Affected country or region
  • User agent, if available
  • Whether the issue affects all users or specific users
  • Whether the issue affects one page, one workflow, or the whole site
  • Relevant Security Events & Analytics details
  • Screenshot of the Firewall page, if relevant
  • Recent firewall, WAF, DNS, plugin, theme, deployment, or WordPress changes
  • Steps already taken
  • Urgency level

Where to go next

  • Review Security Events & Analytics to investigate blocked requests, source IPs, source countries, user agents, paths, and recorded actions.
  • Review Firewall screen to manage IP Access and Geo Blocking rules.
  • Review Security at a Glance to review overall site security status and recent protection activity.
  • Review False Positive WAF Blocks if a legitimate request is being blocked by a WAF rule.
  • Review Security Alerts if you need help understanding security alerts and event severity.
  • Review DDoS Attack Response if the block is related to abnormal traffic volume or suspected attack traffic.
  • Open a Support Request if legitimate access is still blocked after completing the checks in this guide.