Random Port Generator

What the three port ranges mean, and where to run your dev server

IANA, the organization that manages internet standards, divides the 65,535 port numbers into three ranges. The tabs at the top of the tool correspond to these ranges.

But there's a trap here. The Dynamic/Private range is officially designated for operating systems to use for temporary, or "ephemeral," outbound connections. However, the default ephemeral port range on Linux is often 32768–60999, which significantly overlaps the registered and dynamic ranges. If you run a server on a port in this range, another process's outbound connection might grab that port before your server starts. This leads to intermittent "Address already in use" errors during reboots or redeploys—a frustrating bug that's hard to reproduce.

Why ports below 1024 require root and how to handle it in practice

On Linux, ports below 1024 are considered privileged and require root permissions to bind. This is a legacy security measure to prevent any user from starting a fake web server on a standard port like 80. However, running your web application as the root user is the worst possible choice — if your app is compromised, the entire server is compromised.

In practice, the standard solution is to run the application on a non-privileged port (like one in the 3000s) and use a reverse proxy like Nginx to listen on ports 80 and 443 and forward traffic to your app. The ports you generate with this tool are typically used for that "backend" service.

# Method 1 (Recommended): Nginx handles 80/443, app runs on a non-privileged port
#   proxy_pass http://127.0.0.1:3000;

# Method 2: Grant bind capability to the executable
sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/node

# Method 3: Grant capability to a systemd service
# [Service]
# AmbientCapabilities=CAP_NET_BIND_SERVICE

Debugging Port Conflicts

"Address already in use (EADDRINUSE)" is one of the most common errors a developer will encounter. Following these steps will usually solve the problem in under a minute.

• The most common culprit is your own process. Check if a previously launched nodemon or pm2 process is still running.
• If no process is using the port but you still get the error, the port may be in a TIME_WAIT state. This means a connection from a recently terminated server is still being cleaned up and will be released shortly. For dev servers, you can often avoid this using the SO_REUSEADDR socket option.
• On macOS, if port 5000 is unavailable, it's likely being used by the system's AirPlay Receiver feature. This is why 5000 is included in the reference table.
• If the server starts correctly but you can't connect, the issue is likely your firewall, not the port. Check if your cloud provider's security group allows traffic on that port.

# Linux/macOS — who is using port 3000?
ss -ltnp | grep :3000
lsof -i :3000

# Windows
netstat -ano | findstr :3000
taskkill /PID 12345 /F

# Check Docker too (containers often hold ports)
docker ps --format '{{.Names}}\t{{.Ports}}'

What "Avoid well-known/common ports" Does (and Doesn't Do)

When this option is enabled, ports listed in the reference table below are excluded from the results. This includes conventional ports like 3306 (MySQL), 6379 (Redis), 5432 (PostgreSQL), 3000 (Node/Grafana), 5173 (Vite), and 8080. This helps prevent you from accidentally choosing the default Redis port for your app, only to find you can't run Redis later.

However, this table only covers about 60 of the most common ports. It has no way of knowing about ports already in use within your company, ports occupied by system agents, or ports reserved by other teams. This tool generates candidates that are unlikely to clash by convention, but you must always verify on the server that a port is actually available.

How to Manage Ports Within a Team

Once you start running multiple services, ports can get tangled quickly. Establishing a convention is often easier in the long run than picking ports at random. For example, you could assign ranges like 31xx and 32xx to different teams, who then document their service ports within a shared document. This tool can then be used with the "Custom" range to find an available port within your team's assigned block.

By increasing the count and enabling "Sort ascending," you can generate a clean list of ports that can be saved as a .txt file. This is useful for allocating ports for several new projects at once.

• If you use containers, you can avoid host port conflicts altogether. Inside their containers, all services can use the same standard port; you only need to map them to different, unique ports on the host when you expose them.
• A port number is not a secret. The idea that "security through obscurity" by using an unusual port will keep you safe is false; automated scanners will find it in minutes. Real security comes from proper authentication and firewalls.
• This tool uses a cryptographically-secure, unbiased random number generator to pick unique ports. However, unpredictability is rarely a requirement for port selection—the primary goal is simply to avoid collisions.