Node.js、TCP Sockets与Docker：并发超32次为何出现连接重置？

Hey Drew, since you're new to Docker and hitting this intermittent connection problem when pushing past 200 concurrent connections, let's walk through the most likely culprits and fixes:

1. Check Docker's File Descriptor Limits #

TCP connections rely on file descriptors, and Docker containers have default lower limits compared to your host machine. When you hit 200+ connections, you might be hitting this ceiling.

• First, verify the limit inside your container:

  docker exec <your-container-name> ulimit -n
  

  If it returns something like 1024 (a common default), that's probably the issue.
• Fix it by setting a higher limit when starting your container:

  docker run --ulimit nofile=65535:65535 <your-image-name>
  

  This sets both soft and hard limits to 65535, which should handle way more than 200 connections comfortably.

2. Tune Node.js TCP Server Settings #

Your Node.js TCP server might have default backlog or connection queue limits that get overwhelmed at higher concurrency:

• When creating your TCP server, explicitly set the backlog parameter to a higher value (the default is 511). This controls the number of pending connections the OS will queue before rejecting new ones:

  const net = require('net');
  const server = net.createServer({ backlog: 1024 }, (socket) => {
    // Your connection handling logic
  });
  server.listen(3000);
  

• Also, make sure you're properly handling socket errors to avoid unhandled exceptions that could drop connections silently:

  socket.on('error', (err) => {
    console.error('Socket error:', err);
    // Clean up resources if needed
  });
  

3. Rule Out Docker Network Bottlenecks #

Default bridge networking in Docker uses NAT, which can introduce overhead at very high concurrency:

• Test using host network mode to bypass Docker's network layer entirely (this makes your container use the host's network stack directly):

  docker run --network host <your-image-name>
  

  If the connection issues disappear, the problem was likely with bridge network NAT performance. You can stick with host mode if it fits your use case, or look into optimizing bridge network settings (like increasing buffer sizes) if you need isolation.

4. Check for Unhandled Errors or Resource Leaks #

Even if local runs work, containerized environments can expose resource leaks you didn't notice:

• Enable verbose logging in your Node.js server to track connection attempts and errors in real time.
• Use docker stats <your-container-name> while running the load test to monitor CPU, memory, and network usage. If CPU spikes to 100% or memory runs out, your server might be struggling to keep up with the load.

5. Verify the Load Testing Tool's Behavior #

While the tool claims to support arbitrary concurrency, double-check:

• That it's not hitting its own limits when connecting to a containerized service.
• That it's properly handling connection timeouts or retries (sometimes intermittent errors stem from the test tool itself, not your server).

内容的提问来源于stack exchange，提问作者Drew S.