5 ms·

If that's the case...how to explain that the docs say source IP is not provided? Troubleshooting Load balanced traffic does not have a source address of

If that's the case...how to explain that the docs say source IP is not provided? Troubleshooting Load balanced traffic does not have a source address of the original client Traffic from the load balancer to your instances has an IP address in the ranges of 130.211.0.0/22 and 35.191.0.0/16. When viewing logs on your load balanced instances, you will not see the source address of the original client. Instead, you will see source addresses from this range. Is it the case that, if the X-Forwarded-For header is present, then it is not providing a source IP, or it is providing a source IP, but that this IP is not listed in the traffic logs?

seanp2k2 9y ago
To be slightly pedantic, websockets specifically don't have HTTP headers like XFF, which is IMO part of the problem with Websockets -- you end up re-inventing basic functionality. IMO (and combined with other factors) this is a great reason to choose http/2 over websockets. EDIT: ALB also supports http/2, but they can also do websockets as well as WSS (where you'd term SSL on the ALB for websockets).
- manigandham 9y ago
  Http/2 and websockets are not interchangeable, you cant choose to use http/2 if you want a bidirectional lightweight communications protocol to the client. The initial upgrade http request from the client should have all the headers you need.
manigandham 9y ago
The source IP of the HTTP request is the IP of the system that makes the TCP connection, so when you use a load balancer it will always be coming from a single IP. This is what webservers and other software use when logging which is why the source IP does is not accurate in regular logging. That's what the documentation is saying - it's in the troubleshooting section because if you're only seeing a single IP then it's because you're looking at logs that won't have the right information. Instead most proxies and load balancers add the X-Forwarded-For header which appends all IPs that are involved in the request. If you read the entire documentation page, the Fundamentals section shows what headers are added: https://cloud.google.com/compute/docs/load-balancing/http/#components https://cloud.google.com/compute/docs/load-balancing/http/#c... The proxies set HTTP request/response headers as follows: Via: 1.1 google (requests and responses) X-Forwarded-Proto: [http | https] (requests only) X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (requests only) X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (requests only)
- 19eightyfour 9y ago
  Just wanted to thank you for that information. And also give you some feedback on commenting. The HN commennt guidelines mention to not insinuate someone hasn't read the article. What you might not know is that I did read the section you quote, but I did not know enough to resolve it myself without asking a question. When I read that you didn't think I had, I felt you were saying, the answer would be obvious if you had read it. That hurt because it was like saying my question was stupid, which I don't like and I don't want to feel discouraged from asking questions in future. Anyway, thanks for your information, and I hope this feedback is useful.

seanp2k2 9y ago

To be slightly pedantic, websockets specifically don't have HTTP headers like XFF, which is IMO part of the problem with Websockets -- you end up re-inventing basic functionality. IMO (and combined with other factors) this is a great reason to choose http/2 over websockets. EDIT: ALB also supports http/2, but they can also do websockets as well as WSS (where you'd term SSL on the ALB for websockets).

manigandham 9y ago
Http/2 and websockets are not interchangeable, you cant choose to use http/2 if you want a bidirectional lightweight communications protocol to the client. The initial upgrade http request from the client should have all the headers you need.

manigandham 9y ago

The source IP of the HTTP request is the IP of the system that makes the TCP connection, so when you use a load balancer it will always be coming from a single IP. This is what webservers and other software use when logging which is why the source IP does is not accurate in regular logging. That's what the documentation is saying - it's in the troubleshooting section because if you're only seeing a single IP then it's because you're looking at logs that won't have the right information. Instead most proxies and load balancers add the X-Forwarded-For header which appends all IPs that are involved in the request. If you read the entire documentation page, the Fundamentals section shows what headers are added: https://cloud.google.com/compute/docs/load-balancing/http/#components https://cloud.google.com/compute/docs/load-balancing/http/#c... The proxies set HTTP request/response headers as follows: Via: 1.1 google (requests and responses) X-Forwarded-Proto: [http | https] (requests only) X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (requests only) X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (requests only)

19eightyfour 9y ago
Just wanted to thank you for that information. And also give you some feedback on commenting. The HN commennt guidelines mention to not insinuate someone hasn't read the article. What you might not know is that I did read the section you quote, but I did not know enough to resolve it myself without asking a question. When I read that you didn't think I had, I felt you were saying, the answer would be obvious if you had read it. That hurt because it was like saying my question was stupid, which I don't like and I don't want to feel discouraged from asking questions in future. Anyway, thanks for your information, and I hope this feedback is useful.