Question How to 'selectively' block Mackintosh Chrome browsers

[tetrahall]

Server operating system version

CentOS Linux release 7.6.1810

Plesk version and microupdate number

Plesk Obsidian Version 18.0.81

Hi,

I need to block visitors using Mackintosh Chrome browsers - There are thousands of them on a daily basis, and almost all have unique ip addresses.

But I must allow genuine visitors who use iPhone, android or destop windows explorer, as well as search engines bots.

I have tried htaccess to no avail. Having searched the internet, the cause is running Nginx.

"The htaccess file and RewriteRule syntax belong strictly to Apache web servers. Since you are running Nginx on CentOS 7, any rules you write in an htaccess file will be completely ignored by the server."

The solution involves editing Nginx file "/etc/nginx/nginx.conf".

I am not famiilar with Nginx and I don't want to make a miss of things.

Can I do this effectively via Plesk? Or would it be better if I edited file "/etc/nginx/nginx.conf".

Please advise me.

 

[Kaspar]

What's the exact htaccess configuration you're using?

By default Plesk uses nginx as a proxy only and internally forwards request to Apache. Which means that using htaccess should work fine, unless Proxy Mode has been disabled for the domain. In that case all requests are handled by nginx.

If proxy mode has been disabled for your domain, you can use something like the nginx directive bellow. I haven't tested this, so use at your own digression. Nginx directives can be added to a domain via Domains > example.com > Hosting & DNS > Apache & nginx Settings via the Additional nginx directives field.

location / {
    if ($http_user_agent ~* "Macintosh.*Chrome/") {
        return 403;
    }
}

But again, htaccess should work fine if you have not disabled Proxy Mode for the domain.

However, since you're writing that you want to "allow genuine visitors", I am assuming your intention is to block traffic that you see as harmful (or unwanted). So I want to point out that it's incredibly easy for anyone to "spoof" or change their User Agent (the data send with every request to identify the users browser and OS). Blocking traffic based on the user (supposed) browser and OS is generally not considered very practical and efficient.

More effective methods usually are some sort of challenge–response test to determine whether a visitor is actually human. Like a captcha, turnstile or something similar.

 

[tetrahall]

Hi Kaspar

Thanks for your reply.

In Plesk's nginx settings: Proxy mode is ticked. I assume it's enabled.

The code in htaccess is:-

RewriteEngine On

# 1. Allow major search engines (Google, Bing, Yahoo, DuckDuckGo)
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot|Slurp|DuckDuckBot) [NC]

# 2. Allow Android and iPhone
RewriteCond %{HTTP_USER_AGENT} !Android [NC]
RewriteCond %{HTTP_USER_AGENT} !iPhone [NC]

# 3. Block Chrome on Mac
RewriteCond %{HTTP_USER_AGENT} Intel\sMac\sOS\sX [NC]
RewriteCond %{HTTP_USER_AGENT} Chrome [NC]
RewriteCond %{HTTP_USER_AGENT} !Edge [NC]
RewriteCond %{HTTP_USER_AGENT} !OPR [NC]
RewriteRule ^ - [F,L]

# 4. Block Chrome on Linux
RewriteCond %{HTTP_USER_AGENT} Linux [NC]
RewriteCond %{HTTP_USER_AGENT} Chrome [NC]
RewriteCond %{HTTP_USER_AGENT} !Android [NC]
RewriteCond %{HTTP_USER_AGENT} !Edge [NC]
RewriteCond %{HTTP_USER_AGENT} !OPR [NC]
RewriteRule ^ - [F,L]

order allow,deny
deny from xxx.xxx.xxx.xxx
 .. several lines

You mentioned:

location / {
if ($http_user_agent ~* "Macintosh.*Chrome/") {
return 403;
}
}

I think there is more code needed to allow mobile browsers and search engines crawlers.

 

[tetrahall]

UPDATE:
I am not absolutely sure about my last statement:

"I think there is more code needed to allow mobile browsers and search engines crawlers."

But just to be on the safe side, lest the code should block everything!

 

[tetrahall]

UPDATE:

Using the following Plesk command, one could test if visitoes using Mackintosh Chrome are blocked from using my website

curl -I -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" mywebsite.com

The output indicates that a visitor would be blocked :

HTTP/1.1 403 Forbidden
Server: nginx
Date: Mon, 12 Oct 2026 00:33:39 GMT
Content-Type: text/html
Content-Length: 4897
Connection: keep-alive
Last-Modified: Thu, 16 Oct 2014 13:20:58 GMT
ETag: "1321-5058a1e728280"
Accept-Ranges: bytes

If I remove the code in htaccess and try the plesk command again, The output indicates that a visitor CAN access my website

HTTP/1.1 302 Found
Server: nginx
Date: Mon, 12 Oct 2026 00:37:30 GMT
Content-Type: text/html; charset=windows-1256
Connection: keep-alive
X-Powered-By: PHP/7.2.34
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Mon, 12 Oct 2026 00:37:30 GMT
X-Powered-By: PleskLin

Doesn't that show the the htaccess code works, but for some unknown reason, Mackintosh users can still access the website?

 

[tetrahall]

I was wondering if there is an alternative to Cloud flare?

I joined it a couple of days ago. It made a mess of my emails. They dropped from 1000 per day to 17. about 200 subscribed members have left.

The attack has been going on - 40,000 per day. Their settings are complex to adjust.

I would greatly appreciate your input. Thank you in advance.

 

[Kaspar]

With the risk of sounding blunt; I think you're jumping between different possible solutions without really explaining the underlying problem.

Your original question was about blocking certain browsers, but we still don't know what you're actually trying to prevent, why you believe these requests are harmful, or what evidence you've gathered to reach that conclusion. The fact that you see thousands of requests from Macintosh Chrome user agents doesn't, by itself, tell us much about the nature of the traffic.

The same applies to your comments about Cloudflare. Saying that it caused problems with your emails and that you're receiving 40,000 requests a day doesn't give anyone enough information to understand what actually happened or suggest a suitable alternative.

Before suggesting more configuration changes, more details are needed to understand what problem you're actually trying to solve. Is it excessive server load, spam registrations or something else? What evidence do you have that these requests are responsible for the problem? Have you checked your access logs or server resource usage? And what exactly happened when you enabled Cloudflare? How did it affect your email, and what settings or changes did you make?

Please explain the actual problem and the steps you've already taken to investigate and mitigate it. Without that context, we're just guessing at possible solutions, and that's unlikely to get you anywhere.