tengo el siguiente código:¿Por qué ServerVariable ["REMOTE_ADDR"] devuelve la IP del servidor?
string ip = Request.ServerVariables["REMOTE_ADDR"];
Lo cual, en el entorno de prueba no devolver el addrress IP del usuario, pero cuando hacemos uso de la página web a la producción, esta variable tiene el IP del servidor donde está alojada la aplicación . ¿Alguna ayuda?
Supongo que hay un proxy en el medio. Utilice HTTP_X_FORWARDED_FOR primero, y si eso es nula, a continuación, utilizar REMOTE_ADDR
Desde el MSDN article:
Aunque recuperar sólo la variable de servidor REMOTE_ADDR debería ser suficiente, me encontré con recursos en línea que sugirió que un código como éste también debe comprobar la variable HTTP_X_FORWARDED_FOR; si la solicitud proviene de un servidor proxy que traduce la dirección, esta es la variable que contiene la dirección correcta. Si solicita una variable de servidor que no existe, la propiedad ServerVariables devuelve una cadena vacía. Por lo tanto, aunque esta propiedad no aparece en mis pruebas, intentar recuperar su valor no causa problemas.
ACTUALIZACIÓN:
Si se trata de un equilibrador de carga que hay que tienen configuraciones estables el, usted debe preguntar a ver si pueden tener la IP de origen pasa a través. Sé que esto se puede hacer con el servidor ISA de Microsoft.
Si eso no es una opción, existen estas otras variables de servidor que puede probar y ver si producen un resultado:
"HTTP_X_COMING_FROM"
"HTTP_X_FORWARDED_FOR"
"HTTP_X_FORWARDED"
"HTTP_X_REAL_IP"
"HTTP_VIA"
"HTTP_COMING_FROM"
"HTTP_FORWARDED_FOR"
"HTTP_FORWARDED"
"HTTP_FROM"
"HTTP_PROXY_CONNECTION"
"CLIENT_IP"
"FORWARDED"
es incorrecto porque si tiene un proxy, entonces siempre le enviará una dirección IP incorrecta –
@Bhargav Mistri - Tengo un código similar que se ejecuta en varios cuadros de producción. Me encontré con esto en el pasado y puedo asegurarle que se debe a un problema de proxy. Tenga en cuenta que algunos servidores proxy pueden falsificar HTTP_X_FORWARDED_FOR o dejarlo todo junto. – zeroef
@zeroef Gracias por la ayuda. Hice los cambios en HTTP_X_FOWARD_FOR, pero sigo recibiendo la misma IP. Hablé con el equipo de infraestructura y resulta que no es la IP del servidor la que está regresando, sino que en realidad es una IP de equilibrio de carga. ¿Alguna idea? – FelixMM
¿Por qué usan, las variables del servidor de estilo VB viejos en lugar de Request.UserHostAddress?
Ver MSDN Library.
Como han indicado los otros, obtendrá la dirección IP del proxy inverso/terminador SSL si no hace que las solicitudes parezcan que provienen del cliente original (como es posible al menos en el servidor ISA, y probablemente en la mayoría de los otros proxies inversos).
Si no, obtendrá la dirección pública del cliente (que probablemente sea una dirección de enrutador en el sitio del cliente, ya que la mayoría de las LAN son NAT-ed).
¿En qué se diferencia su configuración en el entorno de producción de su entorno de prueba?
¿De verdad está obteniendo la dirección IP del servidor web o de algún otro servidor en la misma red?
Veo que esta es una vieja pregunta, pero la encontré y creo que sé la respuesta. La respuesta es más simple que las anteriores ... Me encontré con el mismo problema hoy. Apuesto a que está tratando de obtener la IP de una página llamada por XMLHTTP que devolverá la IP del servidor, ya que es el que realiza la solicitud y no el usuario.
¿Qué esperas que vuelva? Ver esto: http://stackoverflow.com/questions/3812166/difference-between-remote-host-and-remote-addr – Oded
@Oded Esa respuesta de stackoverflow es aceptada y tiene un número de votos positivos, pero no obstante es incorrecta. – mhenry1384
Lo mismo 'HttpContext.Current.Request.ServerVariables [" REMOTE_ADDR "]. ToString();' y 'Request.UserHostAddress.ToString(); ' – Kiquenet