Para los proxies web transparentes y solo con el seguimiento estático (por ejemplo, los registros de acceso de su servidor web), no puede. La solicitud se realizó en su servidor web desde el propio servidor proxy, por lo tanto, a menos que sea un proxy no transparente que se adjunte a la información de reenvío de solicitudes web, como por ejemplo, X-Forwarded-For campo de encabezado HTTP que revela la dirección IP de la solicitud original, no tiene suerte.
Estos campos de encabezado HTTP pueden variar por diferentes proxies HTTP no transparentes, algunos de los más utilizados son: X_FORWARDED_FOR , VIA , USERAGENT_VIA , FORWARDED , PROXY_CONNECTION , XPROXY_CONNECTION , HTTP_PC_REMOTE_ADDR , HTTP_CLIENT_IP .
Estos pueden revelar cualquier cosa de la dirección IP pública de la solicitud original, el nombre de la red local, la cadena del agente de usuario del cliente web, etc., según su implementación. Sin embargo, solo con su presencia (todos estos son campos de solicitud HTTP no estándar para conexiones no proxy) confirmaría sus sospechas de que las solicitudes web son proxy. Por supuesto, nuevamente, suponiendo que el proxy no sea transparente y que ni siquiera incluya ninguno de estos campos de encabezado personalizados en sus solicitudes a su servidor. Y a veces, el hecho de que la solicitud provenga del servidor proxy también puede ser establecido por el nombre DNS de la solicitud (si incluye "proxy" en el nombre, entonces probablemente lo sea). También debe configurar su servidor para informar estos valores de campos HTTP personalizados y nombres DNS en sus archivos de registro de acceso, de lo contrario, es posible que ni siquiera se registren.
Otra cosa que añadir, ya que estamos hablando de coordenadas, es que son más o menos inútiles. Es casi imposible geolocalizar las direcciones IP a través de las solicitudes HTTP, a menos que los propios clientes elijan permitir que su información de geolocalización se comparta a través de las respuestas de HTML 5. Lo mejor que puede esperar con las solicitudes de proxy es establecer la ubicación aproximada del servidor, a veces en qué ciudad se encuentra, pero más comúnmente solo en qué estado se registró el rango de IP a la que pertenece la IP del servidor. Registros de Whois, por ej. con la herramienta de búsqueda de direcciones IP de Hurricane Electric (y hay muchas otras disponibles en línea) y tal vez pueda establecer quién es el servidor proxy en cuestión pertenece a.
En cuanto al seguimiento activo de clientes web (navegadores que realizaron solicitudes iniciales y revelar su verdadera dirección IP), no lo recomendaría. Es delicado, técnicamente exigente y no todas sus partes divertidas pueden ser legales en su país o consideradas éticas. No es imposible, pero necesitará un experto calificado para que lo configure en su servidor. Y es posible que aún no funcione, especialmente si los verdaderos clientes web que acceden a su servidor a través de un proxy no son siquiera los navegadores de usuario final adecuados, sino los robots web con guión que automatizan las tareas web para quien los controla y dependen de las API web que no lo hacen. acepte complementos y extensiones de navegador a través de los cuales se pueda revelar la dirección IP real (por ejemplo, a través de objetos Flash), o el cliente web con una huella digital más única para un seguimiento más sencillo.
En la mayoría de los casos, lo mejor que puede hacer es bloquear ciertos clientes web por cadenas de agente de usuario, direcciones IP / rangos de IP, sus nombres DNS, o implementar una verificación más profunda (como Búsquedas de DCRDNS , Listas negras de CBL , Honeypots and Honeynets , ...) en su extremo, ya sea en las reglas de acceso del servidor web, WAF u otros firewalls, ... para evitar que clientes no deseados utilicen sus propios recursos en su contra. Es decir. implementar una política de autorización integral que proteja sus activos antes de que sufra, en lugar de inclinarse hacia los molinos de viento después del hecho.