All users have the same IP (the Servers IP)?

Installation
1

So I have recently noticed that all my users seem to be using the same IP which happens to be the IP of my server (176.31.6x.xxx) …

I have no idea where to even start fixing this issue, yes I am using cloudflare.

1 Like
2

CloudFlare sets additional HTTP headers that contain the original IP address. You can tell nginx to pass these on to Discourse using this configuration.

2 Likes
3

Yes, I am currently using the code you have sent me. The problem is that
even with the above code it seems that the servers IP is detected (you can
even put that IP in the url bar and it would bring you to the forums). I
have tried turning off cloud flare but I am still getting the same result.

Edit: I have used PHP on my machine to check my IP and the IP is returning fine. (outside of discourse) I am wondering if there is any way to debug what’s happening so that I know what the exact problem is. Currently all I know is that Discourse seems to be grabbing the servers address instead of the clients.

Edit 2: I have found that the issue is being caused because I am using a proxy port. Currently trying to fix the issue using a code similar to this configuration ( that was mentioned above by @bartv ). Will update this post once again with my progress.

Edit 3: No luck so far… Lets say I am using port 80 and port 1337, I am using port 80 to proxy over to 1337 because my port 80 is already in use by something else. My settings are…

"1337:80"   # fwd host port 1337 to container port 80 (http)

When I connect to example.com:1337 my IP resolves correctly however when I connect to example.com:80 my IP resolves to the servers IP.

My nginx settings to get to Discourse are…

location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_redirect off;
    # pass to the upstream discourse server mentioned above
    proxy_pass http://xx.xx.xx.xxx:1337;
}

I really hope I can get some help with this…

4

Did you try to disable the nginx running in the container and expose the Unicorn app server itself? You’ll probably want to use your firewall to prevent direct external access to that port, tho.

5

No I have not and I am not even sure on how I would do that. Plus I would like to avoid messing around with IP Tables.

I noticed that you have replied on a similar topic to this one allready…
https://meta.discourse.org/t/run-discourse-with-or-alongside-existing-apache-sites/19514

Would it be possible to do the same thing via nginx?

Edit: I have finally got it to work by using this nginx setup…

upstream discourse {
    #fail_timeout is optional; I throw it in to see errors quickly
    server 127.0.0.1:1337 fail_timeout=5;
}
 
# configure the virtual host
server {
    listen          80;
    server_name     f.example.com;
    return          301 $scheme://forums.example.com$request_uri;
}

server {
    listen 80;

    # replace with your domain name
    server_name forums.example.com;

    location / {
        proxy_redirect off;
        # pass to the upstream discourse server mentioned above
        proxy_pass http://127.0.0.1:1337;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP  $remote_addr;
    }
}

Now I just need to fix the registration IPs for my users…

1 Like
6

I don’t think there’s much that Apache can do that nginx can’t. The discussion you linked to focused on Apache’s ability to handle large amounts of concurrent connections, so it’s not exactly the same thing.

Anyway, good job getting it to work. :slight_smile:

7

Thanks, would you happen to know any simpler way to get the IPs users have registered under in order.

Or does it not matter if the first batch is broken?

8

In a worst case scenario, one of the first-batch users gets hacked, starts spamming and Discourse decides that all users with the same registration IP are spammers, too. But I don’t have enough experience with Discourse’s anti-spam features (never needed them, thankfully) to tell for certain what would happen.

Anyway, you can run this in the Rails console inside the container (or, if you prefer that, extract the SQL bit and run it in psql):

User.exec_sql("UPDATE users SET registration_ip_address = ip_address WHERE registration_ip_address = inet '10.0.0.1' AND ip_address IS NOT NULL")

Simply replace 10.0.0.1 with your server’s public IP that was erroneously used as your users’ registration IP. All users who at this point still have that IP as their reg. IP will instead have their last seen IP address set as the registration IP.

(Caveat emptor: always make backups before manually running SQL statements over your production database.)

1 Like
9

Thank you very much for your help, I will need to get all the users to join at-least once first before using the SQL above, so that will have to wait.

Also about the Caveat, to utterly misquote Lenin… “Backup, backup, and once again backup!”

10

Actually, you can run that query as often as you like. It will only update users who still have the old, invalid registration IP and have a non-null current IP.

11

Ah alright, I will probably save it then. Maybe even write it into my slightly modded launcher. That I have posted here before.

12

I tried to run this command from:

cd /var/discourse/
./launcher enter app
rails c

But it shows me errors, how i should reset all registered-ip’s from the users?

13

Have you already fixed the problem, or are users still showing as coming from internal IPs?

1 Like
14

I fixed the problem from the nginx conf (reverse proxy that connects to the container) giving the correct ip, with the most relevant as like:

    proxy_redirect off;
    proxy_pass      https://example.com:25655;
    proxy_set_header    Host $http_host;
    proxy_set_header    X-Real-IP   $remote_addr;
    proxy_set_header    X-Request-Start "t=${msec}";
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    #proxy_set_header    X-Forwarded-Proto   $scheme;
    proxy_set_header    X-Forwarded-Proto   https;
    proxy_set_header    X-NginX-Proxy  true;
    proxy_read_timeout      90;
    # Socket.IO Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

About the existing users I don’t remember if was they fixed, but there were just a few users while the site was in construction, what I can say is that using this conf for nginx-reverse proxy makes it working properly :slight_smile:

2 Likes