Hey there! Let's break down your problem and work through some practical solutions to fix your WiFi connection verification issue, plus explain why that weird cross-process DNS behavior is happening.

First, Why the DNS Discrepancy Between Processes? #

The key here is how Node.js handles DNS configuration caching:

• The dns.resolve method uses Node.js's built-in DNS client, which caches your system's DNS server settings when the process starts. When you switch WiFi networks, your system updates its DNS config, but the existing Node.js process doesn't automatically refresh this cache.
• A new Node.js process, however, reads the latest DNS settings on startup, which is why it can resolve the router IP immediately while your existing script can't.

Even switching to dns.lookup (which relies on the system's getaddrinfo call instead of Node's internal client) might help, but there's a more reliable way to verify connectivity.

Better Approach: Skip DNS, Test Direct TCP Connectivity #

DNS resolution isn't the best way to confirm your WiFi connection is ready—especially when you're targeting a router IP directly. Instead, test a direct TCP connection to an open port on your router (like port 80 for its admin interface, or 53 for DNS). This bypasses any DNS configuration headaches and directly validates network reachability.

Here's an optimized version of your code with this approach, plus exponential backoff for smarter retries:

const wifi = require("node-wifi");
const net = require('net');
const debug = require('debug')('wifi');

// Verify connectivity by connecting directly to the router's open port
const canConnectToRouter = (host, port = 80) => new Promise((resolve) => {
  const socket = new net.Socket();
  const connectionTimeout = 2000; // 2-second timeout for each attempt

  socket.setTimeout(connectionTimeout);

  socket.on('connect', () => {
    debug(`Successfully connected to ${host}:${port} - network is ready`);
    socket.destroy();
    resolve(true);
  });

  socket.on('timeout', () => {
    debug(`Timeout connecting to ${host}:${port}`);
    socket.destroy();
    resolve(false);
  });

  socket.on('error', (err) => {
    debug(`Connection error: ${err.message}`);
    socket.destroy();
    resolve(false);
  });

  socket.connect(port, host);
});

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

// Use exponential backoff to avoid excessive retries while giving slow connections time
const waitForConnection = async (maxRetry, host, retry = 0) => {
  if (retry >= maxRetry) {
    throw new Error('Failed to establish working network connection after maximum retries');
  }

  // Exponential backoff: wait longer between each retry (capped at 5s)
  const waitTime = Math.min(1000 * Math.pow(2, retry), 5000);
  await sleep(waitTime);

  const isConnected = await canConnectToRouter(host);
  if (isConnected) return;

  debug(`Retry ${retry + 1}/${maxRetry}...`);
  return waitForConnection(maxRetry, host, retry + 1);
};

Key Improvements in This Code #

1. Direct TCP Check: No more DNS-related failures—we're testing if we can actually reach the router over the network, which is the real indicator of a ready connection.
2. Exponential Backoff: Instead of fixed 1-second waits, we double the wait time each retry (up to 5 seconds). This reduces unnecessary frequent checks while giving slow network handshakes time to complete.
3. Clean Error Handling: Clear debug messages and proper socket cleanup to avoid resource leaks.

If You Still Want to Use DNS... #

If you prefer sticking with DNS verification, switch to dns.lookup instead of dns.resolve. It uses the system's native address resolution call, which is more likely to pick up network changes quickly:

const canResolve = host => new Promise((resolve) => {
  if (!host) host = 'google.com';
  debug(`Attempting to resolve ${host}`);
  dns.lookup(host, (err) => {
    if (err) {
      debug(`Failed to resolve: ${err.message}`);
      resolve(false);
    } else {
      resolve(true);
    }
  });
});

But again, the TCP connection test is more reliable for verifying that your WiFi connection is fully operational and ready for requests.

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