If you want to block tough proxies like hidemyass.com, my previously posted .htaccess methods won’t work. Those methods will block quite a bit of proxy visits to your site, but won’t work on the stealthier proxies. Fortunately, we can use a bit of PHP to keep them out.
Block Tough Proxies with PHP
To stop tough proxy visits from sites like hidemyass.com, add the following slice of finely crafted PHP to the top of your header.php file:
<?php if(@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1))
die("Proxy access not allowed"); ?>
If you’re not using WordPress, just place the code at the top of your web page(s). No editing is necessary, so just add the code, upload the file, and done. You can check that it works by visiting your site via your favorite proxy service. If it works, access will be denied.
This method works for me on a Linux server running Apache 2.2.3, MySQL 5.0, and PHP 5.2.6. It should work on similar setups as well, but your results may vary depending on your server configuration.
Block Other Proxies with .htaccess
If for whatever reason you aren’t using the above PHP method, you can still block a majority of the “lesser” proxies by adding the following block of HTAccess code to your site’s root .htaccess file:
# BLOCK PROXY VISITS
# PerishablePress.com: http://bit.ly/12k6Uo
<ifModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:VIA} !^$ [OR]
RewriteCond %{HTTP:FORWARDED} !^$ [OR]
RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$
RewriteRule .* - [F]
</ifModule>
This proxy-blocking technique is less-effective than the PHP method, but should help reduce overall proxy traffic to your site. Using HTAccess to filter proxies requires fewer system resources than the PHP method. So if you get tons of traffic or have lots of pages, you’re better off sticking with the HTAccess technique. It’s sort of a trade-off between effective proxy-blocking and optimum performance, which will vary depending on your needs and server configuration.
My Strategy
On most of my personal sites, I allow proxy access. I understand the need for privacy, but there are situations where denying proxy visits makes sense. Most often, the .htaccess code is a suitable solution. But for sites where anonymity isn’t an option, the PHP method is the way to go.
10 Responses
Simon Sigurdhsson – July 18, 2011
Be aware that the “Tough proxy” block will also block any visitors that have a web server set up on their own network.
Jeff Starr – July 18, 2011
Good tip – Thanks for the reminder :)
PhpMyCoder – July 18, 2011
Jeff,
I agree that your PHP solution is a nice little trick, but I think it is possible it will do more harm than hurt.
By blocking requests from computers (or servers) that listen to port 80 you would basically be blocking anybody who has a home testing server setup. I have a LAMP and an XAMPP setup (and expose one to the internet) so this PHP would block me and I suspect would block a majority of the web development community. This code could also block Google’s spiders because if you navigate to a Googlebot IP, it redirects you to Google’s homepage (at least it did the last time I checked).
You also add the overhead of making a request before serving content to the user. Since PHP isn’t non-blocking like Node.JS, the script would have to wait for the request to fail or timeout for computers that don’t listen to port 80.
Personally I’d stick with the htaccess rules. They won’t block everything, but with them legitimate users won’t be identified as proxies.
Cheers,
PhpMyCoder
Jeff Starr – July 18, 2011
I agree – all good points. I should’ve gone into more detail in the post. The htaccess rules work great at reducing overall proxy visits, but for those (hopefully) rare situations where visitor identity is required, the PHP snippet does the job. Hopefully it well help those who need it, and maybe inspire someone to produce a more widely applicable method. Thanks for the feedback :)
vale – July 18, 2011
Jeff,
what about who’s using a secure VPN to avoid having their traffic unencrypted on a public WIFI network? Is this script gonna stop that traffic too?
Jeff Starr – July 18, 2011
I think it should, but don’t have anything like that set up for testing, so can’t say for sure.
vale – July 19, 2011
I understand. I think you might setup something together with Chris Coyer to simulate this situation. You might use this little utility to setup a VPN server; then configure another machine on a different network to use that VPN server as gateway. Don’t know if I’m saying a bunch of crap and there’s actually a faster way (ie a free VPN service) to test this thing.
Actually the number of people that is getting these VPN services on untrusted WIFI is growing; moreover people living in countries with a government limitation on internet are using these services too.
Jeff Starr – July 19, 2011
Thanks for the suggestion – sounds like another great idea :)
Procter – July 20, 2011
I tried with my blog in the header.php put it at very beginning. With most
proxies it works but with proxify.com it doesnt work.
Great blog.
All the best
Fabian Wolf – July 21, 2011
hi there,
comment via mail cause comments seem to be already closed – OT: definitely
NOT good (see my comments on your post over there) – so here we go:
Its plainly said dumb to let a local development server run open to the
public – thats why my local server is NOT publicy accesible; although I
sometimes open access to it using a DynDNS provider.
This also automatically solves problems like being blocked from using a site
because it “thinks” you’re homing in via proxy ;)
cu, w0lf.
ps: another question – does this block access by any proxy? Any mobile phone
provider I know of (at least in Germany) is using proxy servers – so won’t
mobile users get blocked, too?