A familiar support ticket goes something like this: a customer can open your website, but the login page keeps challenging them. Or the contact form returns a 403 error. Everything works when you test it, and other customers are still placing orders.
The tempting fix is to ask for the customer’s IP address and add it to an allowlist.
That may clear the ticket today. It may also trust an address used by an entire office, a mobile carrier, a university network, or hundreds of people using the same privacy service. The next person behind that address will inherit the same exception.
A better investigation starts with a simple fact: a web application firewall does not see people. It sees requests. Before changing a rule, you need to find out what was unusual about this request and whether the IP address was even the reason it was stopped.
An IP Address Is a Clue, Not an Identity
A public IP address sometimes represents one home. Just as often, it does not.
Companies commonly send employee traffic through a shared gateway. Universities do the same for parts of a campus. Hotels and coffee shops place unrelated guests behind the same connection. Mobile providers may use carrier-grade network address translation, allowing many subscribers to share a smaller pool of public addresses. Privacy tools create another version of the same pattern by routing many users through common exit servers.
This matters when a security rule counts behavior by IP.
Imagine a login limit of 20 attempts in ten minutes. For a household, that may leave plenty of room while slowing an automated attack. For a large office starting work at 9 a.m., 20 attempts may be ordinary traffic from different employees. The WAF sees one busy address, even though no individual user is behaving strangely.
Reputation rules have a similar weakness. An address may have a poor history because of someone who used it yesterday. The person visiting your site today may have nothing to do with that activity.
None of this makes IP-based controls worthless. It means they should be treated as one signal among several. An address can help you locate an event in the logs. It should not automatically decide who is trusted.
Reproduce the Failure the Customer Actually Saw
Site owners often test a cleaner version of the problem by accident. The customer says checkout failed, so someone on the team opens the homepage, sees a 200 response, and reports that the site is working.
The homepage was never the problem.
Ask for the exact URL and action: submitting the form, uploading the image, applying the coupon, or sending the login request. Get the time and time zone, the response code, and any request or reference ID shown on the block page. A screenshot can help, as long as passwords, payment details, session cookies, and personal information are removed.
Then repeat the same action as closely as possible. Use the same type of account, request method, and form data. If the action can create an order, send an email, or lock an account, test it with a staging site or a safe test account. Repeatedly hitting a live login form can trigger the very limit you are trying to understand.
Also confirm which layer produced the response. A 403 may come from the CDN, WAF, hosting control panel, web server, WordPress security plugin, or the application itself. If you begin editing Cloudflare rules when a plugin generated the block, the investigation is already heading in the wrong direction.
Change the Network Before You Change the Rule
Once you can repeat the action, try it through a genuinely different network route while keeping everything else as similar as possible.
A laptop on home Wi-Fi and a phone connected to that same Wi-Fi are usually not two useful tests; both may leave through the same public IP. A better comparison is home broadband versus mobile data, an office connection versus a personal hotspot, or a direct connection versus a VPN.
Suppose the same login succeeds on home broadband and mobile data but fails through a shared exit address. That does not prove an IP reputation or rate-limiting rule is responsible. Changing the route may also change the location, IPv4 or IPv6 path, latency, DNS behavior, and signals used by bot protection. But it gives you a useful event to look for.
Write down the result of each attempt with its time, network, URL, and response. Three clean tests are far more useful than 30 clicks with no record of what changed.
This is also where many investigations should pause. If the error cannot be reproduced and there is no matching security event, do not create a permanent exception based on a guess. Keep the incident details and watch for the next report.
The Log Should Name the Rule, Not Just Confirm a Block
Search the edge security events around the recorded time. Filter by hostname, path, source IP, action, or request ID. You are looking for more than proof that something was blocked. You need the product that acted, the rule ID, the matched request detail, and the scope of the problem.
For example, a managed WAF rule matching part of a form field requires a different fix from a rate limit counting an entire office. A bot challenge on one browser may point toward cookies or JavaScript. A custom country rule may explain why every request from one route fails before it reaches WordPress.
Cloudflare acknowledges that managed rules can produce false positives—legitimate requests classified as malicious. Its troubleshooting guidance recommends using Security Events to identify the cause and applying an exception or rule-specific adjustment when appropriate.
If the edge log contains nothing that matches the incident, move down the stack. Check the reverse proxy, web server, application, and security-plugin logs. Make sure the origin is receiving the real client IP as well. A broken proxy configuration can make every visitor appear to come from the proxy, turning a reasonable per-IP limit into a site-wide bottleneck.
Do not paste full request headers or browser archive files into an ordinary support ticket without reviewing them. Authorization headers, cookies, form bodies, and tokens can contain far more information than the person investigating the WAF needs.
Fix the Smallest Condition That Explains the Failure
Once you know which rule acted, the fastest-looking fix is still often the wrong one.
Disabling the WAF proves only that the WAF was involved; it does not produce a safe production configuration. Allowing the shared IP everywhere is hardly better. Both changes remove protection from requests that were never part of the customer’s problem.
A useful exception describes the legitimate request as narrowly as possible. You might exclude one verified form parameter from one managed rule, adjust a limit for a low-risk endpoint, or apply an exception only to a specific path and request method. A noisy rule can also be changed to logging or count mode while you measure its effect.
Cloudflare’s own recommendation is blunt: if one managed rule causes false positives, disable that rule rather than the whole ruleset. AWS takes a similar approach in its WAF testing guidance, advising teams to test changes before production and evaluate rules in count mode with real traffic before enforcing them.
There is no universal safe exception. Skipping a body-inspection rule on a public upload form may carry much more risk than adjusting a rate limit on a read-only endpoint. The important question is not “What setting makes the error disappear?” It is “What is the narrowest change that allows this valid request without allowing unrelated ones?”
Re-Test the Journey, Including Something That Should Still Fail
After making the change, repeat the original request through the network that failed. Then test the steps around it. A checkout fix is not complete until the product page, cart, payment step, and confirmation behave as expected. A homepage returning 200 says almost nothing about whether the protected action works.
Run a negative test too. Confirm that an obviously invalid or over-limit request is still logged, challenged, or blocked. If the exception now applies to other paths, methods, or users, tighten it again.
Finally, watch the relevant events after deployment. A shared-address problem may arrive in bursts when an office opens, a mobile carrier changes routing, or a popular exit server sends more users your way. You are looking for fewer false blocks without a sudden drop in the detections the rule was meant to provide.
The goal is not to trust every shared address. It is to stop treating an address as if it were a person. Reproduce the customer’s exact action, compare network routes, let the log name the rule, and change only the condition that caused the false positive. The WAF does not need to become weaker. It needs to become more precise.
