In my experience, REMOTE_ADDR is the proxy if HTTP_X_FORWARDED_FOR exists. In which case, HTTP_X_FORWARDED_FOR is the client IP.

php docs says fsockopen is opening a socket, so for some reason he reaches out to touch the proxy. I'm not sure it makes any sense to do that, but I'm also not sure of the need for any of the other checks if you are simply trying to ID a Proxy use.

I think this should work:
<cfif cgi.HTTP_X_FORWARDED_FOR neq "">
proxy
</cfif>

Also, in your version, there should be one HTTP_X_FORWARDED_FOR instead of two HTTP_X_FORWARDED.

Thanks Ray and everyone else for helping me out with this code. The reason for the code if anyone is wondering is to detect when a scammer from Nigeria is trying to trick my site into thinking they're from the US.

I've played around with the code above on this page,
I created this page test http://www.pickrent.com/misc/proxy.cfm I can't seem to get it to work.

Here is the code that is on the link above (from Shag):

<cfif cgi.HTTP_X_FORWARDED_FOR neq "">
   <h4>You ARE coming from a proxy.</h4>
<CFELSE>
   <h4>You are NOT coming from a proxy.</h4>
</cfif>

The code above always indicates that I am NOT coming from a proxy whether I am or not.

I also tried Ray's code above but it doesn't matter if I am coming from a proxy or not, the code always say that I AM coming from a proxy.

@dave, my memory may have served me wrong, and it could be that my bubble works differently. I would suggest cfdump the cgi scope and run it directly and behind a proxy. You should be able to figure something out. I'm wondering if different proxies give different responses.

Just an aside, it's relatively easy to manipulate the 'forwarded for' just as the 'remote_addr'. I'd imagine anyone trying to seriously cause trouble would have taken this into account when doing their thing. It'll still catch the casual ones though.

@gary that's a bummer.

I would have thought others with CF sites would have a similar issues as mine and there would be code out there in use to detect proxies.

Hmmm... MegaProxy is tricky.

https://free.megaproxy.com/go/_mp_framed?http://ww...

If this is for a commercial application you could use the Geo Intelligence from a company like Quova - http://www.quova.com/.
They'll give you very accurate information on an IP; I'm not just talking about the usual country & roughly the nearest state/county data; real "this is where they are" and a confidence factor with the data too :)
They also tell you things like the speed of the link, type of link (adsl,cable,satellite,etc) and proxy type (public, private, aol, etc).
Could be very useful for you. Remember that not everyone behind a proxy is bad. Some people have to use a proxy from their company. I'd recommend you give a confidence factor to the order based on multiple attributes.

Something that has proven to be quite cheap & effective is if you're taking an order on your site then you're probably taking their address. You could use the free GeoLite city DB (http://www.maxmind.com/app/geolitecity) and then do a distance between their IP location and their address. If it's more than say 50miles then minus 10 from the confidence factor. Simple, free & very effective. (NB The key is not to rely on any one attribute!)

Disclaimer: I do NOT work for either of those companies!

Dave -- Did you ever find a solution for this? I'm facing the exact same issue. I've been considering using an ASAPI Rewrite list of known proxy IPs. I'm just wondering if you found a good way of protecting your site.

I found a somewhat interesting solution to sniffing out proxy servers. Its not fool proof and will occasionally return false positives but so far it is the best automated method for checking proxies I have come up with. We have been having issues with order fraud coming from behind proxy servers on orders that would otherwise had never thrown red flags. So we started google searching IP's from larger orders to see if they appeared on any proxy listing websites. To automate this for us I do an HTTP post to google (or you can use the search engine of your choice) with the ip address of the order and parse the results for keywords indicating a proxy (proxy, socks, socks5, socks4, etc.) if it detects any of these keywords
it flags the order as a potentially placed behind a proxy.

So far this method has thrown up red flags a few times on orders we would have otherwise shipped. Its not elegant, but it works great!

@ Hi Group, i would like to share my opinion also to this matter since i need a solution to that too.
So, first of all, code like bellow
<cfif cgi.HTTP_X_FORWARDED_FOR neq "">
<h4>You ARE coming from a proxy.</h4>
<CFELSE>
<h4>You are NOT coming from a proxy.</h4>
</cfif>

won't have any chance to see between cgi variables. i have testing for weeks with various platforms and different versions of ACF and Railo 3.2 final too. Strage thing is that on the same apache instance a simple code like from the first post or, even better one like:

srv#cat testp.php
<?php
if(isset($_SERVER['HTTP_X_FORWARDED_FOR']) ||($_SERVER['HTTP_USER_AGENT']=='') || ($_SERVER['HTTP_VIA']!=''))
{
die("Don't use proxies, please.");
}
?>

will act like it is suppose to do. Note HTTP_VIA variable which apears only when it is a matter of anon or high-anon proxy server.

Second, Garrett Johnson gave us a clue maybe without knowing (no ofence please). So, have you ever has to install, running and administrate a proxy server before, even for a small lan ? I have few years ago and still remember something about "little" SQUID proxy server. Basicly for everyone who's goingo to use proxy server must
put proxy ip and port into browser connection dialog .. etc (sorry for this long explanation i am sure all of you have know already).
So, if you can not access header values for those variables via cgi dump what if we reverse the process ? We still have access to remote_addr and remote_host values. Now, i just want to test if remote_addr ip it is a proxy or not. How ? Trying to connect ot it. Remember that a proxy server must accept connection, right ? Well...

<!-- define function to check connection; it will return true or false if it could connect or not --->
<cfscript>
function checkMe(host,port) {
connection = createObject("java", "java.net.Socket");
connection.init(host, port);
connected = connection.isConnected();
return connected;
}
</cfscript>

<cftry>
<cfoutput>
<!--- define a variable whitch hold remote address and a variable for counting open ports --->
<cfset ip="#CGI.REMOTE_ADDR#" />
<cfparam name="q" default="0" />

<!--- checking remote ip connection within well-known range of ports --->
<cfif checkMe(#ip#,80)>
<cfset p1 = true />
<cfset q = 1 />
</cfif>

<cfif checkMe(#ip#,8080)>
<cfset p2 = true />
<cfset q =q+1 />
</cfif>

<cfif checkMe(#ip#,3128)>
<cfset p3 = true />
<cfset q =q+1 />
</cfif>
</cfoutput>

<!--- here leave empty in case this is not a proxy not to show anything --->
<cfcatch type="Any">

</cfcatch>
</cftry>

<!--- display and parsing the results
it is very basic in order to see on whitch port remote ip accept connection;
--->
<cfoutput>
<cfif IsDefined("p1")>
proxy on port 80: #p1#<br />
<cfelse>
no proxy on port 80<br />
</cfif>
<cfif IsDefined("p2")>
proxy on port 8080: #p2#<br />
<cfelse>
no proxy on port 8080<br />
</cfif>
<cfif IsDefined("p3")>
proxy on port 3128: #p3#<br />
<cfelse>
no proxy on port 3128<br />
</cfif>
</cfoutput>

<!--- then just logical detection --->
<cfif IsDefined("variables.q") AND variables.q NEQ 0>
<h2>No proxy allowed here, mate!</h2>
<cfelse>
<!--- normal processing page code as visitor it is not using a proxy --->
</cfif>

Obviously this method could be more elaborate incorporated into a CFC where to just pass only CGI.REMOTE_ADDR and wait for a boolen answer.

Hope this helps; If any has anotjer suggestion....

best regards from Romania