docmirror/dev-sidecar · warning

macOS 代理服务检测：获取路由信息失败:

Error message

macOS 代理服务检测：获取路由信息失败:

What it means

Non-fatal warning from getMacNetworkService(). The first strategy failed entirely: the outer `exec('route -n get 0.0.0.0')` rejected, so the route/device detection could not run at all. The code logs the underlying e.message and continues to the fallback strategy using `networksetup -listallnetworkservices`.

Source

Thrown at packages/core/src/shell/scripts/set-system-proxy/index.js:262

    const device = parseMacRouteDevice(routeOutput)
    if (device) {
      log.info('macOS 代理服务检测：当前网络设备:', device)
      try {
        const networkServiceOrder = await exec('networksetup -listnetworkserviceorder')
        const matchedService = parseMacNetworkServiceByDevice(networkServiceOrder, device)
        if (matchedService) {
          log.info('macOS 代理服务检测：通过设备名匹配到网络服务:', matchedService)
          return matchedService
        }
        log.warn('macOS 代理服务检测：未通过设备名匹配到网络服务，尝试备用方法')
      } catch (e) {
        log.warn('macOS 代理服务检测：获取网络服务列表失败:', e.message, '，尝试备用方法')
      }
    } else {
      log.warn('macOS 代理服务检测：未检测到当前网络设备，尝试备用方法')
    }
  } catch (e) {
    log.warn('macOS 代理服务检测：获取路由信息失败:', e.message, '，尝试备用方法')
  }

  try {
    const allServicesOutput = await exec('networksetup -listallnetworkservices')
    const fallbackService = pickMacNetworkService(allServicesOutput)
    if (fallbackService) {
      log.info('macOS 代理服务检测：通过服务列表备用方法找到网络服务:', fallbackService)
      return fallbackService
    }
    log.warn('macOS 代理服务检测：未通过服务列表找到可用网络服务')
  } catch (e) {
    log.warn('macOS 代理服务检测：获取所有网络服务列表失败:', e.message)
  }

  throw new Error('未找到可用的 macOS 网络服务，无法设置系统代理')
}

// macOS exit code 14 = "You don't have permission to change the system preferences."

View on GitHub (pinned to 7710cd56cc)

Solutions

  1. No action needed — the code automatically falls back to listing all network services and picks Wi-Fi/Ethernet
  2. Check the logged e.message: if it is 'no route to host'/'not in table', connect to a network before enabling the system proxy
  3. If `route` is genuinely missing from PATH, launch the app from a standard shell environment where /usr/sbin is on PATH
Defensive patterns

Strategy: validation

Validate before calling

const { execSync } = require('node:child_process')
function routeCommandWorks() {
  try { execSync('route -n get 0.0.0.0', { stdio: 'ignore' }); return true }
  catch (e) { console.warn('route check failed:', e.message); return false }
}

Try / catch

try {
  await DevSidecar.api.startup()
} catch (e) {
  if (/route|network/i.test(e.message)) {
    // network detection failed; prompt user to check connectivity
  }
}

Prevention

When it happens

Trigger: The `route` binary is missing or not spawnable; `route -n get 0.0.0.0` exits non-zero because there is no route to the default destination (common when offline); exec wrapper treats any non-zero exit as rejection.

Common situations: Offline or airplane-mode machines where enabling the proxy is attempted; restricted environments lacking /sbin on PATH; freshly booted machines before the network is up.

Related errors

AI-assisted analysis of docmirror/dev-sidecar@7710cd56cc (2026-08-31). Data as JSON: /api/errors/d119d169d5de9d95. Report an issue: GitHub.