A Docker container can successfully ping the host, but consistently times out when trying to access a specific port. Superficially, the network appears to be working, indicating that the communication path between the host and the container isn't completely blocked. However, behind the port access failure often lie complex firewall policies, Docker network mode conflicts, incorrect port binding, or NAT forwarding issues. To understand this problem, it's essential to first understand the fundamental difference between ping and port access.

　　The ping command uses ICMP (Internet Control Message Protocol), which is only used to test network connectivity and doesn't involve TCP or UDP ports. Accessing ports (such as HTTP, SSH, and MySQL connections) uses TCP or UDP protocols, requiring multiple steps including host port listening, NAT forwarding, and firewall filtering. In other words, even if the ping packet is successful, it doesn't guarantee a TCP connection will be established. In many cases, the host's firewall or Docker's network rules will block access to specific ports, resulting in "ping successful but access timed out."

　　One of the most common reasons is that the host's firewall or security policies prevent the Docker container from accessing specific ports. For example, most Linux distributions have firewalld or iptables firewalls enabled by default. Although Docker automatically modifies iptables rules at startup to support communication between containers and the host, manual rule adjustments by system administrators or the use of security enhancements (such as SELinux or ufw) may block Docker's forwarding chain.

　　You can check the current firewall status using the following command:

sudo systemctl status firewalld

　　If it displays as "active", it means the firewall is running. You can view the specific rules:

sudo iptables -L -n

　　If a rule is found to contain DROP or REJECT operations on specific ports (such as 8080, 3306), access to these ports will be denied even if the container can ping the host. The solution is to allow access to the corresponding ports.

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

　　Alternatively, temporarily disable the firewall for testing:

sudo systemctl stop firewalld

　　If access is possible after disabling the firewall, the problem is indeed with the firewall policy.

　　Besides the firewall, another common cause is improper Docker network mode configuration. Docker containers have several network modes, including bridge (the default bridged mode), host (shared host network), none (no network), and custom network. In most cases, containers use bridge mode, in which the container communicates with the host through the virtual network interface docker0.

　　To check the Docker network configuration, you can use:

docker network ls

　　Next, check the detailed information of the bridge network:

docker network inspect bridge

　　If the container and host are not on the same network, or if the NAT rules are not configured correctly, port access will fail. For example, if a service on the host only listens on 127.0.0.1, the container may be able to ping the host's external IP address, but accessing the port will time out. You can use the following command to check the host's listening ports:

sudo netstat -tlnp

　　Assume the output is as follows:

tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 1234/java

　　This means the service only listens on the local loopback address. Docker containers on a bridged network cannot access the host's 127.0.0.1, so the connection will inevitably time out. The solution is to change the application's listening address to:

0.0.0.0

　　Alternatively, you can bind the host's internal IP address (e.g., 172.17.0.1) to allow the container to access the network through the real network interface card.

　　In some cases, Docker's NAT rules may be lost or overridden. Docker automatically creates a series of iptables rules for the bridge network upon startup to forward traffic between the container and the external network. If other programs or system security tools modify these rules, it will affect the container's access path. You can verify the existence of the Docker forwarding chain using the following command:

sudo iptables -t nat -L -n | grep DOCKER

　　If the output is empty or the rules are missing, you can restart the Docker service to restore the default rules:

sudo systemctl restart docker

　　Also ensure that IP forwarding is enabled in the system kernel; otherwise, Docker's NAT forwarding will not work.

sudo sysctl -w net.ipv4.ip_forward=1

　　And write it to the configuration file:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

　　Sometimes the problem lies inside the Docker container. While the container may be able to access the external network, timeouts when accessing host ports are often due to DNS resolution or routing configuration issues within the container. You can check the network routing by entering the container:

docker exec -it Container name bash
route -n

　　Ensure the default gateway is 172.17.0.1 (the host's docker0 IP). If not, you can reconfigure the routing or rebuild the network. Also, check if testing tools such as curl or telnet are installed inside the container to verify port connectivity.

curl -v http://172.17.0.1:8080

　　If you see "Connection timed out," it means the host port is indeed not open to the container.

　　For Docker environments running on Japanese cloud servers, special attention needs to be paid to cloud security group rules. Many Japanese cloud platforms only allow port 22 (SSH) by default, blocking all other ports. Even if the host firewall and Docker are configured correctly, a blocked security group will still cause port access timeouts. You need to log in to the cloud platform console and add inbound rules in "Security Groups" or "Firewall Rules" to allow TCP access from any IP (0.0.0.0/0) or a specific subnet.

　　Another easily overlooked detail is the SELinux security mechanism. SELinux strictly controls inter-process communication when strengthening system security. If an application on the host is restricted by SELinux policies to only accept connections from the local machine, even if the Docker container is on the same host, it will not be able to access it. You can temporarily disable SELinux for testing:

sudo setenforce 0

　　If the problem is resolved, then consider configuring the correct security context for the Docker process or host service, rather than permanently disabling it.

　　During debugging, you can use the following command combination to quickly locate the source of the problem:

　　1. Confirm whether the host port is listening.

sudo netstat -tlnp | grep 8080

　　2. Check Docker network connectivity

docker exec -it Container name ping 172.17.0.1

　　3. Test the connection between the container and the host port.

docker exec -it 容器名 curl -v http://172.17.0.1:8080

　　4. View iptables rules

sudo iptables -t nat -L -n

　　By checking these directions step by step, you can pinpoint which layer is blocking communication.

　　If the host is running a reverse proxy service such as Nginx or Apache, incorrect proxy configuration may also cause access failure. For example, Nginx may only listen on the local address:

listen 127.0.0.1:80;

　　In this case, the Docker container cannot access it; it should be changed to:

listen 0.0.0.0:80;

　　Similarly, for applications using Spring Boot, Flask, Django, Node.js, etc., it is essential to ensure that all API addresses are listened to.

　　In production environments, it is recommended to configure a fixed bridge network for Docker containers and manage communication through custom DNS or internal network segments, rather than relying on the default network. For example:

docker network create --subnet=172.20.0.0/16 mynetwork
docker run -d --network=mynetwork --ip=172.20.0.10 myapp

　　This avoids conflicts between the default docker0 network segment and other services on the host, improving network controllability and security.

　　Fundamentally, the "ping successful but port access timed out" error indicates that the network layer (Layer 3) is accessible, but the transport layer (Layer 4) is blocked. Possible causes include: the host firewall not allowing the port, incorrect Docker NAT rules, incorrect application listening address, cloud security group restrictions, SELinux policies, or incompatible network modes. By checking these aspects sequentially, the problem can be found.