Node.js WebSocket本地连接正常远程连接异常问题求助

Hey there, let’s work through this WebSocket disconnect issue together—since it works in some environments but not your Windows host ↔ VM setup, we can narrow this down to network or OS-specific quirks rather than your core server code. Here’s a step-by-step troubleshooting plan tailored to your scenario:

Firewalls are the #1 culprit for "connect then immediately drop" issues across different OSes:

• Windows Host Firewall: Head to Windows Defender Firewall > Allow an app or feature through Windows Defender Firewall. Find your Node.js process (or add it manually if missing) and make sure it’s allowed for private networks (your host-only network falls into this category). For testing, you can check both Private and Public temporarily, then lock it down later.
• VM Firewall: If your Linux VM uses ufw or firewalld, double-check the port your WebSocket server runs on is open. For ufw, run sudo ufw allow <your-ws-port>/tcp—WebSocket relies on TCP under the hood, so don’t forget the /tcp suffix.

Ping working doesn’t mean your WebSocket port is accessible. Let’s test directly:

• Windows Host: Use telnet <vm-ip> <ws-port> in Command Prompt. If it connects to a blank screen, the port is reachable. If it throws a "Could not open connection" error, the network is blocking it. (If telnet isn’t enabled, turn it on via Control Panel > Programs > Turn Windows features on or off > Check Telnet Client.)
• PowerShell Alternative: Run Test-NetConnection <vm-ip> -Port <ws-port> and look for TcpTestSucceeded : True in the output.

It’s easy to accidentally bind your Node.js server to localhost (127.0.0.1) instead of all interfaces—this would let local connections work but block external ones.

• Check your server code: Replace server.listen(8080, 'localhost') with server.listen(8080, '0.0.0.0') (the 0.0.0.0 address tells the server to listen on all available network interfaces).
• Verify with ss -tulpn on your Linux VM—look for a line like LISTEN 0 128 0.0.0.0:<ws-port> 0.0.0.0:* to confirm it’s not restricted to loopback.

Windows has default TCP settings that can interfere with WebSocket handshakes:

• Disable TCP Offloading: Go to Device Manager > Network adapters > Right-click your host-only adapter > Properties > Advanced. Find options like "TCP Offload" or "Large Send Offload" and set them to Disabled. This fixes handshake issues caused by offloaded packet processing.
• Check for Proxies/VPNs: If your Windows host uses a proxy or VPN, disable it temporarily—these can intercept and drop WebSocket connections unexpectedly.

Let’s get concrete data about why the connection is dropping. If you’re using the popular ws library, add these logs:

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080, host: '0.0.0.0' });

wss.on('connection', (ws, req) => {
  console.log(`Client connected from: ${req.connection.remoteAddress}`);
  
  ws.on('close', (code, reason) => {
    console.log(`Disconnected: Code ${code}, Reason: ${reason.toString()}`);
  });
  
  ws.on('error', (err) => {
    console.error('WebSocket Error:', err);
  });
});

Common close codes to watch for:

• 1006: Abnormal closure (almost always a network issue)
• 1011: Server-side error (unlikely here since other connections work)
• 1000: Normal closure (if the client intentionally disconnects)

Make sure your Windows host and VM are on the same subnet for the host-only network. For example:

• If your VM has an IP like 192.168.56.101, your Windows host’s host-only adapter should be in the same range (e.g., 192.168.56.1, the default for VirtualBox).
• Run arp -a on Windows to check for IP conflicts—duplicate IPs can cause intermittent or immediate disconnects.

Since your server works between Linux VMs and EC2 instances, the core code is solid. Start with the firewall and binding checks—those are the most likely fixes here.

内容的提问来源于stack exchange，提问作者chuck1