docmirror/dev-sidecar · warning

macOS 代理服务检测：获取网络服务列表失败:

Error message

macOS 代理服务检测：获取网络服务列表失败:

What it means

Non-fatal warning from getMacNetworkService(). The inner `exec('networksetup -listnetworkserviceorder')` call threw (spawn failure, non-zero exit, or command not found), so the device-to-service mapping step is skipped and the function proceeds to the fallback strategy. It signals that the networksetup binary itself failed rather than that parsing found no match.

Source

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

  return services[0]
}

async function getMacNetworkService (exec) {
  try {
    const routeOutput = await exec('route -n get 0.0.0.0')
    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)

View on GitHub (pinned to 7710cd56cc)

Solutions

  1. No immediate action — the code falls back to `networksetup -listallnetworkservices`; check the attached e.message in the log for the real cause
  2. Confirm `which networksetup` resolves (normally /usr/sbin/networksetup) when launching the app, and launch DevSidecar from a normal user session
  3. If networksetup persistently fails, reboot or check `systemstatus`/configd health; as a last resort set the macOS system proxy manually and disable automatic proxy setup
Defensive patterns

Strategy: fallback

Validate before calling

const { execSync } = require('node:child_process')
function networksetupAvailable() {
  try { execSync('networksetup -listallnetworkservices', { stdio: 'ignore' }); return true }
  catch { return false }
}

Try / catch

try {
  await DevSidecar.api.config.set('proxy.enable', true)
} catch (e) {
  log.warn('system proxy setup failed:', e.message)
  // instruct user to set macOS proxy manually
}

Prevention

When it happens

Trigger: `networksetup` is not on PATH or cannot be spawned from the DevSidecar child process; networksetup exits non-zero (e.g. restricted environment, sandboxed process, corrupted network configuration daemon state); the exec wrapper rejects on any stderr/non-zero code.

Common situations: Running under a heavily restricted environment (CI, container with macOS shell wrappers); macOS system configuration daemon (configd) temporarily unresponsive; PATH differences when launched from Finder vs terminal so /usr/sbin is not found.

Related errors

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