docmirror/dev-sidecar · warning

macOS 代理服务检测：未检测到当前网络设备，尝试备用方法

Error message

macOS 代理服务检测：未检测到当前网络设备，尝试备用方法

What it means

Non-fatal warning from getMacNetworkService(). The primary strategy requires the active network device name parsed from `route -n get 0.0.0.0` (an `interface: enX` line). When the route command succeeded but no interface line could be parsed — parseMacRouteDevice returned null — this warning is logged and the fallback service-list strategy is used instead.

Source

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

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)
  }

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

View on GitHub (pinned to 7710cd56cc)

Solutions

  1. No action required — the fallback `networksetup -listallnetworkservices` path runs automatically and typically picks Wi-Fi or Ethernet
  2. Ensure the Mac has an active network connection (Wi-Fi/Ethernet with a default route) before enabling the system proxy; test with `route -n get 0.0.0.0 | grep interface`
  3. If you rely on a VPN/tunnel as your only route, manually configure the proxy or ensure the underlying physical interface is up
Defensive patterns

Strategy: validation

Validate before calling

const { execSync } = require('node:child_process')
function hasDefaultRoute() {
  try {
    const out = execSync('route -n get 0.0.0.0').toString()
    return /interface:\s*\S+/.test(out)
  } catch { return false }
}
if (!hasDefaultRoute()) console.warn('No default route; automatic service detection will use fallback')

Type guard

function parseInterface(routeOutput) {
  if (typeof routeOutput !== 'string') return null
  const m = routeOutput.split(/\r?\n/).find(l => l.trim().startsWith('interface:'))
  return m ? m.slice('interface:'.length).trim() || null : null
}

Try / catch

if (!hasDefaultRoute()) {
  // pre-check before enabling system proxy; fall back to manual proxy settings
  return
}
await DevSidecar.api.config.set('proxy.enable', true)

Prevention

When it happens

Trigger: `route -n get 0.0.0.0` returns output without an `interface:` line (no default route, unusual locale/format), or returns empty/unexpected output while the machine has no active IPv4 default route.

Common situations: Machine with no active network connection when the proxy is toggled on; only an IPv6 route present; heavily localized/modified routing table output; running inside a sandbox where the routing table is inaccessible.

Related errors

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