You're launching your application, starting a service, or running a script—and suddenly everything stops. The error message appears: "Cannot assign requested address." On Linux, it's errno 99. On Windows, it's error 10049 (WSAEADDRNOTAVAIL). Either way, your socket binding has failed, and you're stuck troubleshooting instead of deploying.
This error hits developers and sysadmins at the worst possible times: during production deployments, container startups, automated testing, or system boot sequences. One moment your code works perfectly in development; the next, it refuses to bind in staging or production. The frustration compounds when you verify the IP address exists on the system, the port isn't in use, and every configuration looks correct—yet the bind operation still fails.
The "cannot assign requested address" error occurs when your application attempts to bind a socket to an IP address or port combination that the operating system cannot assign. This happens across multiple platforms (Linux, Windows, macOS), programming languages (Python, C, Java, Node.js), and environments (bare metal, virtual machines, Docker containers). Whether you're running Ubuntu, CentOS, or any other distribution, understanding why this happens—and how to fix it quickly—saves hours of manual troubleshooting and prevents deployment delays.
The "cannot assign requested address" error stems from several distinct causes, each requiring a different troubleshooting approach.
The most common cause is attempting to bind to an IP address that doesn't exist on any local network interface. Your application might be configured with an IP address from a previous environment, a typo in configuration files, or an address that hasn't been assigned yet. The operating system rejects the bind request because it cannot assign an address that isn't available on the system.
This frequently occurs in Docker containers trying to bind to the host's IP address instead of the container's internal address, or during system startup when network initialization hasn't completed yet. On Windows systems with DHCP-configured adapters, the bind can fail if attempted before the DHCP lease completes. Similarly, binding to a hostname that doesn't resolve to a local interface, or attempting to use a loopback address incorrectly configured, will trigger this error.
When your application makes outbound connections, the operating system assigns temporary (ephemeral) ports from a limited range. If too many connections remain in TIME_WAIT state, the ephemeral port pool becomes exhausted. New connection attempts fail with "cannot assign requested address" because no ports remain available.
This scenario is particularly common in high-traffic environments, load testing scenarios, API servers handling thousands of requests, or applications that create many short-lived connections without properly managing socket lifecycle. The error appears intermittently as ports cycle through TIME_WAIT and become available again.
Docker containers operate in isolated network namespaces with their own IP addresses. When a containerized application tries to bind to localhost or a specific host IP address, the bind fails because that address doesn't exist within the container's network namespace. The container can only bind to addresses assigned to its virtual network interfaces—typically 0.0.0.0 for all interfaces or the container's specific internal IP.
This affects common services like Nginx, SSH servers, and API endpoints running in containers. The endpoint configuration must account for the container's isolated network environment.
On Unix-like systems, binding to ports below 1024 requires root privileges. Attempting to bind to privileged ports without sufficient permissions generates this error. Additionally, firewall rules or security policies (SELinux, AppArmor) can prevent binding to specific addresses or ports.
During system boot or network reconfiguration, applications that start before network interfaces are fully initialized encounter this error. The IP address may be configured in the system but not yet active on the interface when the bind attempt occurs. DNS resolution, router connectivity, and network interface activation all need time to complete during startup.
Resolving this error requires identifying which root cause applies to your situation, then applying the appropriate solution. Here's a systematic approach to diagnosis and resolution.
What to do: Confirm the IP address you're trying to bind actually exists on a local network interface.
On Linux (Ubuntu, CentOS, or other distributions), use ip addr or ifconfig:
ip addr show
# or
ifconfigOn Windows, use ipconfig:
ipconfig /allOn macOS, use ifconfig:
ifconfigWhy this matters: You cannot bind to an IP address that isn't assigned to your system. Look for the exact IP address in the output under inet (IPv4) or inet6 (IPv6) entries. Also verify your hostname resolves correctly with hostname -I on Linux or hostname on other systems.
Common mistakes: Assuming an IP address is available because it's in your configuration file, or not accounting for DHCP delays during system startup. Binding to a hostname instead of an IP address can fail if DNS resolution isn't working or the hostname doesn't map to a local interface.
The fix: If the IP address doesn't appear, either:
0.0.0.0 (all IPv4 interfaces) or :: (all IPv6 interfaces) instead of a specific IP127.0.0.1 for local-only services0.0.0.0 or the container's internal IP, never the host IPWhat to do: Determine if another process is using the port, or if you've exhausted available ephemeral ports.
On Linux, use lsof, ss, or combine with grep for filtering:
# Check specific port
sudo lsof -i :8080
# Check ephemeral port usage
ss -tan | grep TIME_WAIT | wc -l
# View ephemeral port range
cat /proc/sys/net/ipv4/ip_local_port_range
# Find processes on specific port with grep
sudo netstat -tulpn | grep :8080On Windows, use netstat:
netstat -ano | findstr :8080
netstat -ano | findstr TIME_WAITWhy this matters: If thousands of connections are in TIME_WAIT state, you may have exhausted your ephemeral port range. This is especially common in load testing, API gateways, or high-throughput applications like Nginx reverse proxies.
The fix for port conflicts: If another process is using the port, either stop that process or configure your application to use a different port.
The fix for port exhaustion:
On Linux, adjust kernel parameters:
# Increase ephemeral port range
sudo sysctl -w net.ipv4.ip_local_port_range="15000 65000"
# Reduce TIME_WAIT timeout
sudo sysctl -w net.ipv4.tcp_fin_timeout=30
# Enable TIME_WAIT reuse
sudo sysctl -w net.ipv4.tcp_tw_reuse=1Make these changes permanent by adding them to /etc/sysctl.conf.
What to do: If running in Docker, adjust your bind address to work within the container's network namespace.
The problem: Your application code specifies a host IP address like 192.168.1.100, but inside the container, that address doesn't exist. This commonly affects Nginx configurations, SSH servers, and API endpoints.
The fix: Change your application to bind to 0.0.0.0:
# Don't do this in Docker:
app.run(host='192.168.1.100', port=5000)
# Do this instead:
app.run(host='0.0.0.0', port=5000)Then use Docker's port mapping to expose the service:
docker run -p 192.168.1.100:5000:5000 your-imageThis allows the container to bind successfully to all interfaces internally, while Docker handles mapping to the specific host IP externally.
What to do: Ensure your application has appropriate permissions and handles network initialization timing.
For privileged ports (< 1024):
On Linux, either run with sudo or grant specific capabilities:
# Grant bind capability without full root
sudo setcap 'cap_net_bind_service=+ep' /path/to/your/binaryFor startup timing issues:
Add retry logic with exponential backoff in your application:
import time
import socket
def bind_with_retry(host, port, max_attempts=5):
for attempt in range(max_attempts):
try:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind((host, port))
return sock
except OSError as e:
if e.errno == 99 and attempt < max_attempts - 1:
time.sleep(2 ** attempt) # Exponential backoff
continue
raiseOr configure your service to start after network initialization:
# In systemd unit file
[Unit]
After=network-online.target
Wants=network-online.targetThis ensures DNS, router connectivity, and all network interfaces are ready before your service attempts to bind.
When binding to localhost fails in containers:
Some applications hardcode localhost or 127.0.0.1. In containers, replace these with 0.0.0.0 or use environment variables to make the bind address configurable.
For Python applications using specific libraries:
If using Flask, Gunicorn, or similar frameworks, check their configuration options:
# Gunicorn
gunicorn --bind 0.0.0.0:8000 app:app
# Flask
flask run --host=0.0.0.0 --port=5000For Nginx and web servers:
Verify your Nginx configuration uses valid IP addresses or 0.0.0.0 in the listen directive:
# Nginx configuration
server {
listen 0.0.0.0:80;
# or for IPv6
listen [::]:80;
}For SSH servers:
Check /etc/ssh/sshd_config to ensure the ListenAddress directive uses a valid IP or is commented out to listen on all interfaces.
For debugging persistent issues:
Enable debug logging in your application and use strace (Linux) or Process Monitor (Windows) to see the exact bind() system call and parameters:
strace -e trace=bind,socket,connect your-applicationThis reveals exactly what address and port your application is attempting to bind, helping identify configuration mismatches. You can also use grep to filter debug output for specific error patterns.
Use configuration management: Store bind addresses in environment variables or configuration files rather than hardcoding them. This makes it easy to adjust for different environments (development, staging, production, containers).
Implement health checks: Before attempting to bind, verify the IP address exists on the system:
import socket
import netifaces
def ip_exists_on_system(ip_address):
"""Check if IP address is assigned to any interface"""
for interface in netifaces.interfaces():
addrs = netifaces.ifaddresses(interface)
if netifaces.AF_INET in addrs:
for addr in addrs[netifaces.AF_INET]:
if addr['addr'] == ip_address:
return True
return FalseImplement automation for deployment validation: Create automated tests that verify network configuration before deploying services. Include checks for IP address availability, port conflicts, and DNS resolution in your CI/CD pipeline.
Monitor connection states proactively: Use network monitoring tools to track TIME_WAIT connections and ephemeral port usage before exhaustion occurs. PRTG Network Monitor provides sensors for monitoring TCP connection states, port usage, and network interface status, giving you visibility into potential binding issues before they cause failures.
Standardize container configurations: For containerized applications, always bind to 0.0.0.0 internally and use Docker port mapping for external access. Document this pattern in your deployment guides.
Test across environments: Include binding tests in your CI/CD pipeline that verify your application can bind successfully in container environments, not just on development machines. Test on Ubuntu, CentOS, and other target platforms to catch platform-specific issues early.
Want to catch network and system issues before they impact your applications? Download a free trial of PRTG to monitor your infrastructure proactively, including TCP connection states, network interface status, and application health.
The "cannot assign requested address" error is frustrating, but it's solvable once you understand the root cause. Start by verifying the IP address exists on your system with ip addr or ifconfig. Check for port conflicts and ephemeral port exhaustion using lsof or netstat, and use grep to filter results. If you're running in Docker, bind to 0.0.0.0 instead of specific host IPs. Address permission issues for privileged ports and implement retry logic for timing-related failures.
Whether you're troubleshooting SSH servers, Nginx configurations, API endpoints, or custom applications, the systematic approach outlined here will help you identify and resolve the issue quickly. Most importantly, implement proactive monitoring and automation to catch these issues before they cause downtime. With the right troubleshooting approach and preventive measures, you'll spend less time debugging socket errors and more time shipping features.