The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Port 2375 is the conventional TCP port for the Docker daemon’s remote API when that API is served without TLS. An open port 2375 does not, by itself, prove that a host runs Docker, that the API is reachable from the internet, or that it accepts commands without credentials. Those are separate conditions, and each one needs its own check. This article explains what the port is for, why an unauthenticated daemon is a serious control-plane exposure, what the headline figure of 1,436,696 hosts can and cannot tell you, and how to confirm and close exposure on systems you run.
What port 2375 is used for
By default, the Docker daemon (dockerd) listens only on a local Unix socket, /var/run/docker.sock on most Linux systems. The Docker CLI talks to that socket. Remote access is an deliberate addition: an operator configures the daemon to also listen on a TCP address. Docker’s remote-access documentation gives the conventional ports as 2376 for TCP with TLS and 2375 for TCP without TLS. Port 2375 is therefore a naming convention for an unencrypted listener, not a fingerprint that identifies a service on its own.
A client that uses that listener typically sets the host explicitly, for example docker -H tcp://192.0.2.10:2375 ps. Anything that can open a TCP connection to that address and port can send Docker API requests, so the security of the listener depends entirely on what sits in front of it.
What the 1,436,696-host figure does and does not establish
The number comes from the title of a DEV Community listing dated September 22, 2026. The full article and its scan method could not be retrieved, so the figure should be attributed to that listing title and nothing more. It is not a result from Docker, from a named security vendor, or from an independently validated study.
#1 Best Overall
The following points are not established by anything accessible:
- What is counted. The figure could refer to unique hosts, network endpoints, scan responses, or historical observations. Those are very different quantities.
- When and where the scan ran. The observation date, geography, and measurement window are unknown, so the figure cannot be read as a current global census.
- How the results were filtered. The query, search filters, and any deduplication are not visible.
- Whether each result was verified. Nothing shows that each responder was a Docker daemon, that it was reachable from the public internet, or that it lacked authentication.
The count therefore tells you that a search of some kind matched a very large number of endpoints on port 2375. It does not tell you how many of those endpoints are compromised, exploitable, or even running Docker. If you are assessing your own exposure, the figure does not change the checks described below.
Why an unauthenticated daemon API is a control-plane exposure
Docker’s security documentation states that TCP access to the daemon is unencrypted and unauthenticated by default. It also warns that changing the daemon’s binding can create host-root risk. The reason is structural: the Docker API can create containers, and a container can mount host directories, run with extra privileges, or share host namespaces. Anyone who can drive the API can therefore usually reach the host’s filesystem and processes, not just the containers.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
OWASP’s Docker Security Cheat Sheet advises against exposing the Docker daemon socket to an internet-connected network for the same reason. This is why an exposed daemon is treated as a control-plane problem and not as an ordinary application port. Compromise of the daemon means compromise of every container it manages and of the host it runs on.
Open port, reachable API, or unauthenticated daemon: four different claims
Security reviews often blur these conditions together. Keep them separate when you report or triage findings:
- Open TCP port. Something accepts connections on port 2375. It may be Docker, a proxy, a forwarder, or an unrelated service that happens to use the number.
- Service fingerprint. The responder behaves like the Docker API, for example by answering a version request with Docker-shaped JSON.
- Reachable Docker API. A client on the network path you are testing can complete Docker API requests. Firewalls, binding addresses, load balancers, and proxies determine this, and they can differ between your internal network and the internet.
- Confirmed unauthenticated daemon. A request that should require credentials succeeds without them, on a daemon you have confirmed is yours.
Only the last two matter for an access-control finding, and both should be verified from the network position that matters to you.
Rank #3
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
How to check your own hosts
Run these checks on systems you administer. Apply them from both the host itself and from a machine on the network segment you want to test.
- See whether anything listens on 2375 or 2376. On the host, run
sudo ss -tlnp | grep -E ':(2375|2376)b'. No output means no TCP listener on those ports on that host. - Inspect the daemon configuration. Check
/etc/docker/daemon.jsonfor ahostsentry containingtcp://. Then runsystemctl cat dockerand look for-H tcp://inExecStart. A TCP address can be set in either place. - Test reachability from another host. Run
curl -m 5 http://HOST:2375/version, replacingHOSTwith the address you administer. A JSON response containing fields such asVersionandApiVersionmeans the Docker API answered without credentials from that position. A refused connection or timeout means that path did not reach a listener. - Test from outside your perimeter. If you have an approved external scanning or cloud vantage point, repeat step 3 from there. Internal reachability and internet reachability are different findings.
A successful response in step 3 is a confirmed exposure. Treat it as an incident: restrict the listener immediately, then review container, image, and host logs for unexpected activity before restoring service.
Choosing a secure remote-access method
If you do not need remote API access, the safest configuration is to remove the TCP listener entirely and use the local Unix socket. If you do need remote control, the three approaches below differ in how they authenticate and encrypt traffic.
| Criterion | Local Unix socket | TLS-protected TCP (port 2376) | SSH-based remote context |
|---|---|---|---|
| Authentication and identity | Filesystem permissions on the socket; membership in the docker group is effectively root-equivalent |
Client certificate verified against your CA when tlsverify is enabled |
SSH authentication to the remote host, then Docker permissions on that host |
| Transport encryption | Not applicable; traffic stays local | TLS | Encrypted by SSH |
| Network reachability and boundary | Local host only | Listens on a network address, so host firewall rules and binding address are essential | Uses the SSH port; reachability is governed by SSH access controls |
| Setup and operating burden | Lowest | Highest: certificate issuance, rotation, and distribution to every client | Moderate: requires Docker CLI on the client, SSH keys, and remote user permissions |
No single option is best in every environment. Choose the one whose identity model and operating burden your team can maintain, and enforce strong identity and network controls with whichever you select.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configuring TLS for the Docker daemon
Docker’s “Protect the Docker daemon socket” guide describes generating a certificate authority, a server certificate, and client certificates with OpenSSL. Follow its steps for key generation and file permissions rather than improvising your own. Once the certificates exist, the daemon configuration in /etc/docker/daemon.json typically looks like this:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →{
"hosts": ["unix:///var/run/docker.sock", "tcp://10.0.10.5:2376"],
"tls": true,
"tlsverify": true,
"tlscacert": "/etc/docker/certs/ca.pem",
"tlscert": "/etc/docker/certs/server-cert.pem",
"tlskey": "/etc/docker/certs/server-key.pem"
}Bind to a specific internal address rather than 0.0.0.0 where possible. Then restrict the port to the networks that need it. On Ubuntu with UFW, for example:
Best Value
sudo ufw allow from 10.0.10.0/24 to any port 2376 proto tcp
sudo ufw deny 2375/tcpA client then connects with its certificate files:
docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://10.0.10.5:2376 versionExpected result: the client prints both client and server version blocks. A connection that is rejected without a client certificate confirms that verification is enforced. If you see certificate signed by unknown authority, the client’s CA file does not match the one that signed the server certificate.
Using SSH-based remote contexts
Docker contexts can route CLI commands over SSH, so the daemon never needs a TCP listener. On the client, with SSH access to the remote host and the Docker CLI installed:
docker context create remote --docker "host=ssh://deploy@build01.example.internal"
docker --context remote psThe remote user must have permission to use the Docker daemon, which usually means membership in the docker group. Treat that group membership as privileged access. Use dedicated, key-based SSH accounts and restrict them with your normal SSH controls.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Troubleshooting common problems
- Docker fails to start after adding
hoststo daemon.json. The systemd unit may still pass-H. Docker reports that the same directive is set both as a flag and in the configuration file. Remove the-Harguments from the unit’sExecStartline, runsudo systemctl daemon-reload, then restart Docker. - Port 2376 is open but the client still cannot connect. Confirm the client is using the same address the daemon bound to, and that the firewall allows the client’s source network.
- Port 2375 still answers after the change. Another configuration source, such as an override file or an older unit, may still define a TCP listener. Repeat the four checks above and confirm the listener is gone with
ss.
Recheck after every change
Repeat the checks in the detection section after each configuration change, a Docker upgrade, or a firewall edit. Exposure often returns through a forgotten override, a new host built from an old template, or a cloud security-group rule that opened a port for testing. A host is only considered closed when the local listener check and the external reachability test both come back negative.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
