关于通过.htaccess规则拦截含特定查询字符串的请求以降低WordPress服务器负载的可行性及最优方案咨询

Hey there! Let's break down your current approach, fix up those rules to make sure they actually work, and talk through whether this is the best way to handle those spammy requests.

First off, your existing rules have a couple of key issues that are probably why you're unsure if they're working:

1. The RewriteRule path match is targeted wrong: You're using ^404\.html$ as the match, which means these rules will only trigger if someone is directly visiting your 404.html page with that query string. But those spammy requests are hitting your homepage or other WordPress pages, right? So the rule never actually fires for the requests you care about.
2. The redirect target is unnecessary: When using R=404, you don't need to specify an external URL like https://example.com. Apache will automatically serve your site's 404 page when you use this flag, so that part is just extra noise that doesn't help.
3. You don't need two separate rules: Your second rule already covers the first one (since "o" is just one of the letters in [a-z]), so you can combine them into a single, cleaner rule.

Here's the fixed, fully functional version of the rules: #

RewriteEngine On
# Block requests with query strings like ?o=12345, ?x=67890, etc.
RewriteCond %{QUERY_STRING} ^[a-z]=[0-9-]+$ [NC]
RewriteRule ^ - [R=404,L]

Let me break down what each part does:

• RewriteCond %{QUERY_STRING} ^[a-z]=[0-9-]+$ [NC]: This matches any query string that starts with a single letter, followed by an equals sign, then one or more numbers/hyphens. The [NC] flag makes it case-insensitive, so it'll catch uppercase letters too (like ?O=123).
• RewriteRule ^ - [R=404,L]: The ^ matches any request path (homepage, blog posts, etc.). The - means we don't want to redirect to a new URL—we just want to return a 404. R=404 sends the 404 status code, and L tells Apache to stop processing any more rewrite rules once this one fires.

How to test if it's working: #

• Use a tool like curl in your terminal: Run curl -I "https://yourdomain.com/?o=12345" (replace with your actual domain). You should see a 404 Not Found status code in the response.
• Or, just visit that URL in your browser and check if your site's 404 page loads. You can also open your browser's DevTools (F12), go to the Network tab, and confirm the status code is 404 for that request.

Is this the best approach? #

Absolutely! This is one of the most efficient ways to handle these spammy requests. By using .htaccess rules, you're intercepting the requests at the Apache server level—before they ever reach WordPress. That means PHP doesn't have to spin up, WordPress doesn't have to load its core files, and you save tons of CPU/memory compared to letting WordPress handle the 404.

A few extra tips to make this even better: #

• Put these rules first in your .htaccess: Make sure they come before WordPress's default rewrite rules (the ones that start with # BEGIN WordPress). That way, Apache blocks the spam requests before it even processes WordPress's routing.
• Watch your server logs: Every so often, check your Apache access logs to see if new spam patterns pop up (like multi-letter parameters, or different character sets). You can tweak the regex to cover those if needed—for example, if you see ?ab=123, you could change the regex to ^[a-z]+=[0-9-]+$ to match one or more letters.
• Double-check for false positives: Make sure none of your legitimate WordPress functionality uses query strings that match this pattern. For example, WordPress uses ?p=123 for post IDs—if that's the case, you'll need to adjust the regex to exclude specific letters. You could use ^[a-z](?![ps])=[0-9-]+$ to exclude p (post IDs) and s (search parameters), for example. Just make sure you don't block your own valid traffic!

Content来源于stack exchange