Flask port 5000 blocked

@jtittle thanks for the help. I mistakingly setup iptables following the 14.04 instructions. I flushed those and am all good now. Thanks!

@davidreedc

Try running ufw disable to disable the firewall, then attempt to connect. If you’re able to connect with the firewall down, you may need to reset and reconfigure the firewall.

We can do that by running the following commands, after the above command:

ufw reset

ufw default deny incoming

ufw default allow outgoing

Now we need to at least allow ports 22 and 5000 in, so we’ll go ahead and add those first:

ufw allow 22/tcp

ufw allow 5000/tcp

Once you’ve ran each of those commands, we’ll re-enable ufw:

ufw enable

Make sure you allow port 22 – not allowing that port means you won’t be able to SSH in, thus you’d either be locked out (if you’re using SSH Keys) or would need to access the console (if you’re using passwords).

Heya,

It looks like you’re trying to serve your Flask application with uWSGI and Nginx. If you’re following this tutorial, the end result should be that your Flask app is served via uWSGI, and Nginx acts as a reverse proxy to forward web requests to uWSGI.

If you’re able to see the website by running curl localhost:5000 on the server itself, it means the Flask app is running properly on port 5000. However, you might not be able to access it from outside the server because:

1. Nginx Configuration: If you’ve set up Nginx to reverse proxy to the Flask app, you should be accessing the app via the port Nginx is listening on (commonly 80 for HTTP), not 5000. The Nginx configuration should have a section that looks something like this:

location / {
    include uwsgi_params;
    uwsgi_pass unix:/path/to/your/uwsgi.sock;
}

This configuration tells Nginx to pass requests to the uWSGI application via a Unix socket. Therefore, you should be trying to access your Flask app from outside using the server’s IP (without specifying port 5000).

2. UFW Rules: If you’ve allowed traffic on port 5000, and you’re trying to access the Flask app directly (bypassing Nginx), you need to make sure no other firewall rules are blocking the request. Additionally, if you’re using Nginx, you’ll need to allow traffic on port 80 (or 443 for HTTPS if you’ve set up SSL):

sudo ufw allow 'Nginx Full'

3. App Binding: By default, Flask’s development server binds to 127.0.0.1, which means it’s only accessible from the same machine. If you’re trying to access the Flask app directly, ensure it’s bound to 0.0.0.0:

if __name__ == "__main__":
    app.run(host='0.0.0.0')

However, keep in mind that binding to 0.0.0.0 in a production environment without any protections (like a firewall or reverse proxy) is not recommended due to security concerns.

4. DigitalOcean Firewall: If you’re using a DigitalOcean Droplet, you might also have DigitalOcean’s cloud firewall rules applied to your Droplet. Ensure that the required ports (e.g., 80, 443, 5000) are allowed in the DigitalOcean dashboard under “Networking” > “Firewalls”.

Additionally, the issue can be caused by SELinux. SELinux (Security-Enhanced Linux) can be the cause of many seemingly inexplicable issues when deploying applications on Linux, especially when it comes to networking or file access permissions.

Here’s how you can determine and possibly resolve SELinux-related issues:

Check SELinux Status: To check if SELinux is enabled on your system:

getenforce

If it returns Enforcing, then SELinux is actively enforcing its policies. If it returns Permissive, SELinux is running but not enforcing, meaning it’ll log violations without blocking them. If it returns Disabled, SELinux is off.

Check Logs for SELinux Issues: If you suspect SELinux might be blocking your application, you can check the audit logs:

sudo cat /var/log/audit/audit.log | grep nginx

This command looks for log entries related to nginx. Replace nginx with uwsgi or flask as necessary. If you see any denied messages, those are SELinux policy violations that might be causing your problem.

Adjusting SELinux Policies: If you determine that SELinux is causing the issue, you have a few options:

• Temporarily Set SELinux to Permissive Mode: This will let you determine if SELinux is the cause of the problem without completely disabling it:

sudo setenforce 0