Azure云服务（经典）检索客户端IP地址

Question

I have read numerous posts, blogs, questions and answers on this so I am confident that it's not a simple standard solution.

I am running an asmx style webservice within a web role and trying to retrieve the client IP address. I have multiple instances running which means the platform provides an external IP address and 'load balances' between the instances.

This all works fine but the retrieval of the client IP address through simple means like request.UserHostAddress returns the external port of the deployment.

Other solutions like ServerVariables["HTTP_X_FORWARDED_FOR"] or ServerVariables["X_FORWARDED_FOR"] all return null and there is nothing in the Request.ServerVariables that carries the information.

The complete list of server variables available within a request are

HTTP_CONTENT_LENGTH:1584
HTTP_CONTENT_TYPE:text/xml; charset=utf-8
HTTP_ACCEPT_ENCODING:gzip, deflate
HTTP_EXPECT:100-continue
HTTP_HOST:myhost
HTTP_SOAPACTION:myaction
HTTP_REQUEST_CONTEXT:appId=cid-###################################
HTTP_REQUEST_ID:|################################
LOCAL_ADDR: *This is the private instance ip address as expected*
REMOTE_ADDR: *This is the external port of the service*
REMOTE_HOST: *This is the external port of the service*

How can this be achieved ??

Answer 1

Could you check ?

     var Request = HttpContext.Current.Request; 
     string IP = Request.Params["HTTP_CLIENT_IP"] ??
     Request.Headers["CF-CONNECTING-IP"].ToString() ??
     Request.Headers["Forwarded"] ??
     Request.UserHostAddress; 

Other approach for owin self host:

 if (Request.Properties.ContainsKey("MS_OwinContext"))
    {
    dynamic owinContext = Request.Properties["MS_OwinContext"];
    return owinContext.Request.RemoteIpAddress;
    }

Also it might be enabled in Azure server options https://totaluptime.com/kb/getting-the-original-client-ip-with-x-forwarded-for-in-your-code/

Answer 2

Thanks to anyone that looked at this and to Oleg for his attempts. It took a lot of digging around with remote debuggers running into an Azure deployment but eventually I found the issue.

We have an old style .asmx webservice with a WCF service in front of it with various 'inspectors' and 'routers'. It's all pretty ugly but has worked for a long while (as I am sure many systems do!). The logging of the remote client address has been broken for some time but the need to have it working again has become more important again recently.

The issue is related to the WCF stack behaviors and how they deal with HTTP headers as opposed to SOAP headers. We had a version change in the Soap specification which broke the system a while back but that was fixed by setting SoapProcessingEnabled on a routing behavior to true which in essence strips all http headers and allows incompatible Soap services to communicate.

My attempts to set the header specifically in another behavior failed due to an order execution problem.

Looking forward to dropping the whole asmx / wcf stack and starting again but can't quite justify the months of development time ! Thanks again for the help