Grpc-go: NO_PROXY does not work with DNS name but with IP

Created on 26 Feb 2020  Â·  5Comments  Â·  Source: grpc/grpc-go

What version of gRPC are you using?

v1.23.0

What version of Go are you using (go version)?

go version go1.13.6 linux/amd64

What operating system (Linux, Windows, …) and version?

PRETTY_NAME="Debian GNU/Linux 10 (buster)", actuall it is the docker image golang:1.13.6-buster.

What did you do?

In my Kubernetes cluster, I set the env HTTP_PROXY to an HTTP proxy (a tinyproxy pod) and set NO_PROXY with the domain name in Kubernetes to bypass these traffics on gRPC clients.

For example, I set up a service not-proxied in the default namespace, and if I set NO_PROXY to .default.svc.local.cluster or not-proxied.default.svc.local.cluster, the dial address in client is not-proxied.default.svc.local.cluster, the gRPC call to these services still uses the HTTP proxy. Only If I set the NO_PROXY to the cluster IP of that service, these gRPC traffics will not use the HTTP proxy.

What did you expect to see?

The gRPC call to those services in NO_PROXY should not use the HTTP proxy.

What did you see instead?

The gRPC call to those services in NO_PROXY still uses HTTP proxy for I can get proxied logs from my HTTP proxy.

P2 Bug

Most helpful comment

Proxy is currently implemented as a dialer, so it doesn't see the hostname before name resolution.

A solution would be to also pass the un-resolved name, and check that against NO_PROXY.

For now, as a workaround, if you want to disable proxy for one ClientConn, override its dialer WithContextDialer.

All 5 comments

Proxy is currently implemented as a dialer, so it doesn't see the hostname before name resolution.

A solution would be to also pass the un-resolved name, and check that against NO_PROXY.

For now, as a workaround, if you want to disable proxy for one ClientConn, override its dialer WithContextDialer.

We are hitting this same issue, I can submit a PR to do as @menghanl suggests.

There is a recent change related to #3411 that may make this less important / needed.

To add more details:

We want to support proxy at two levels:

  • on the server name, before name resolution
  • on the IP addresses, after name resolution

With the current set of APIs, there's no easy way to support both.
To do this, we will need to design another proxy API.

There was an old PR (#1095) that does this.

Makes sense.

We have worked around this by doing the env var detection up front. If it is not conducive to the round robin balancing we fall back to single direct host with passthrough - to prioritise honouring NO_PROXY

Was this page helpful?
0 / 5 - 0 ratings

Related issues

23doors picture 23doors  Â·  3Comments

arcana261 picture arcana261  Â·  3Comments

kushp picture kushp  Â·  4Comments

reterVision picture reterVision  Â·  3Comments

felixwang66 picture felixwang66  Â·  3Comments