What the heck is this extra IP address that sometimes masquerades as a client IP?

When I request various pages from the local Apache virtual host (locally, from the same droplet) whose hostname resolves to a floating IP, the apache log shows two different IP addresses making the requests.

One of those IPs is my droplet’s anchor IP, as expected. The other one is from an address in the same subnet, but is not configured on my droplet.

Usually, and for most urls, it shows the anchor IP.

However, requests for certain urls (“/server-status”, for example) always appear to come from the other IP.

This is a problem for me because I want to limit access to certain pages from local and NATed tunnel address. However, I can’t do that until I know whether it is safe to allow access from this other pesky IP address:

Configured interface:

  • The droplet has two interfaces: eth0 and lo.
  • eth0 has only two addresses: my_server_ip and floating_ip_anchor
  • Internal networking is not enabled.
  1. ip addr show dev eth0
. . .
    inet scope global eth0
. . .

Verified anchor address info:

$ for attr in address netmask gateway; do
    echo -n "${attr}="
    curl -s$attr


  1. curl -IL https://www.mydomain.tld/server-status
  2. curl -IL https://www.mydomain.tld/
HTTP/1.1 401 Unauthorized
. . .
HTTP/1.1 200 OK
. . .
/var/log/apache2/mydomain-access.log - - [08/Jul/2017:23:43:53 -0400] "HEAD /server-status HTTP/1.1" 401 4449 "-" "curl/7.47.0" - - [09/Jul/2017:00:06:59 -0400] "HEAD / HTTP/1.1" 200 4583 "-" "curl/7.47.0" - - [09/Jul/2017:00:06:59 -0400] "GET /s/img/logo.png HTTP/1.1" 200 27233  "-" "curl/7.47.0"
. . .

Probably irrelevant, but FYI:

  • The HTTP 401 is expected, as I have yet to allow access from .
  • The Apache server is actually proxying requests to a uwsgi instance.
    • uwsgi is listening on a domain socket and serving a django project.

Its not just Apache and HTTP:

  • After shutting down Apache and related HTTP services, I can still ping
  • After inspecting some other log files, I noticed that ssh logins to the floating-ip-mapped hostname also appear to come from

So, my first thought was that is doing SNAT on traffic destined for my anchor IP

If that is true, it raises the question, “Is it even possible to safely control access based on IP addresses to hosts which resolve to a floating IP?”

The only problem with that hypothesis is that only ever appears to make the request in two situations:

  1. HTTP/HTTPS requests initiated from the droplet itself
  2. SSH logins to the hostname in question from any remote address

All other connections, so far as I can tell, appear to come from the actual IP address of the requesting client.

If someone knows what actually is going on here, please let me know.

Show comments

Submit an answer
Answer a question...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

This answer is simply so I can mark an answer as accepted. All the credit goes to hansen and dwilkin’s comment above.

see dwilkin's comment

Your question is really difficult. Maybe you need to use some tools to check information about your IP address or domain of this site. I often use the service [IP whois] ( it can helps me to find out more information about needed me IP adress or efficiency of proxy or VPN software.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.