How do I set the IP when accessing the same server?

Hey community,

loving linode, but having an issue with internal IPs. On a linode server, I have a service running behind a an IP whitelist, On the same server I have another service running, that needs access to the When I try to call the api on I get a whiltelist error:

"Response: matched none of the trusted IPs."

So I thought, since the the DNS routes to the same server, it uses an internal IP to access the api. When I added to the whitelist it worked. But it stopped working again shortly after, since the IP changed, now the error is:

"Response: matched none of the trusted IPs"

I know I could add the services in the same docker network and use the docker service name to access it, but I would like to use the external approach since it is a testing server and it should equal the prod server as much as possible. How can I make this happen? Can I somehow set an internal IP that is being used for access on the same server?

Thank you for your help!

5 Replies

A few questions. Can you describe in more detail how you have implemented your white list? Are they defined in the Linode or in the containers themselves?

If they are "per container", Have you added to your whitelist in both containers?

Here is an article that might inspire a solution:

Hey @hphillips, I am using traefik as reverse proxy and only exposed docker service to the outside world, here I do the whitelisting. If the IP passes, traefik routes the request to the running docker container. Works like a charm. Except when requesting data from the same linode machine. When accessing from other linode machines, there is no problem. I add the IP to the whitelist and it works.

I have not added the IP address, as I think it might change again, as before the request came from another IP (

Pardon my confusion. I confused with a public address.

I do not have experience with Traefik, and I apologize if my suggestion is naive:

My interpretation of "it should equal the prod server as much as possible." is that you want to test things as if they were coming from outside the host.

My thought process was that you might be able to configure your docker services to communicate with each other via the host's public address instead of talking to each other over internal addresses. You would therefore only need to allowlist ingress traffic coming from your own host's public address.

Another thought would be to allowlist the private IP address ranges if there is no need to firewall the containers from each other.

@hphillips I saw that in the network tab in the cloud manager, you can add public/private ip addresses. Is there a way to set a fixed ip here and then use it for internal requests to the same linode machine? Or what is this for?

The [Network] tab allows you to add additional external IPv4 and IPv6 addresses.

In the context of the Cloud Manager, Public addresses are additional external addresses used to communicate over the internet. Private addresses are external addresses used to communicate between Linodes and services in the same data center. Separate private addresses are used inside Docker for communication between services, but those are private to Docker where as the ones offered in the Cloud Manager are private to the Linode Data Center.

A detailed explanation of the various options can be found here:

You could configure any of your Linode's external addresses to communicate with your Docker containers, however I was under the assumption that you wanted a single point of ingress. The typical way to refer to the same machine is to use the default loopback address (IPv4) or ::1/128 (IPv6). Software using any additional addresses/interfaces will most likely need to be configured to do so.


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct