macOS 从家中无线网络切到公司网络后无法访问，先检查当前网络服务和残留代理，再检查 DNS 与客户端状态。网络连接图标正常只表示基础连接存在；此前写入的本地代理地址，可能仍然指向已经退出的客户端。
网络服务比网络名称更值得记录
苹果的代理设置文档把配置入口放在具体网络服务之下。无线网络、以太网和其他网络服务可能有不同设置，因此排查时应写清正在使用哪一个服务，而不只写“换了网络”。扩展坞插入后活动路径改变，也可能让原来的判断不再适用。
开始之前，记录当前服务名称、是否自动获取地址、代理开关、自动配置地址和 DNS 设置。截图应隐藏认证信息。对有企业管理配置的设备，先确认设置是否来自管理员，不要删除管理描述文件来验证一个普通连通性问题。
接下来用正常的系统网络检测确认本地网络能否完成认证。酒店、校园或者公共热点可能要求先打开认证页面，代理客户端的自动连接并不能替代这个步骤。在登录门户尚未完成时连续切换节点，只会增加无关变量。
识别仍指向本地端口的设置
客户端正常退出时可能恢复它管理的代理设置，但异常结束、系统重启过程或多客户端竞争都可能留下不符合当前状态的配置。检查代理地址是否为本机，以及对应客户端是否确实运行。不要仅看菜单栏图标，有时界面仍在而内核已经停止。
如果当前网络服务中启用了手动代理，先把设置完整记下来，再按照实际需求暂时关闭该项进行对照。不要同时清空 DNS、删除网络服务并重置路由，这样即使恢复，也无法知道是哪一步起作用。恢复直连后只证明原访问链路存在问题，并不自动证明远端服务正常。
自动代理配置还需要单独看待。配置地址不可达、返回内容失效或应用不支持相同的自动配置行为，都可能造成表现差异。不要从浏览器可访问配置地址，直接推断所有程序都按它运行。作用范围的思路可以参照Windows 代理范围检查，但不能照搬其中的系统操作。
DNS 检查需要保留网络上下文
切网意味着网关、解析服务器及可用地址族都可能变化。一个只在公司网络内部可解析的域名，在家中失败并不说明 DNS 客户端坏了。相反，把公司域名查询送给外部解析器，也不能保证得到正确的内部地址。
先用普通公共域名确认一般解析，再测试发生问题的具体域名。记录是否为名称不存在、超时，还是已经获得地址但连接失败。只写“打不开”会混合解析和传输两个阶段。必要时查阅加密 DNS 的引导解析，避免在解析服务器尚不可达时依赖它解析自身的地址。
不要把清缓存作为第一步。缓存可能提供故障证据，清理后问题暂时消失却难以重现。更有价值的是记录切网前后的解析结果、客户端生效配置与失败时间，再决定是否需要重新建立连接或清理应用缓存。不同应用还有自己的缓存，系统层操作不一定影响全部应用。
一个扩展坞场景的排查顺序
下面是方法示例，不是本站实测。用户在无线网络下使用正常，插入有线扩展坞后浏览器超时。首先确认有线服务拿到了地址且网关可达；其次检查有线服务的代理是否与无线服务一致；再确认本地监听端口存在；最后比较目标解析与路由。
如果有线服务没有使用预期代理，修正范围后重新打开测试连接即可。如果服务仍指向旧端口，应恢复到当前客户端实际监听的入口。如果只有内部办公域名失败，就转向内部解析或访问策略，而不是把所有流量强制送往公网节点。
每完成一项都保留结果。断开扩展坞后再次恢复正常，可以加强“切换路径相关”的判断，但不是根因证明；有线和无线可能同时改变了运营商、DNS、地址族和管理策略，仍需逐项分离。
收尾时验证睡眠与恢复
修复后安排一次受控的睡眠唤醒、一次网络服务切换和一次客户端退出，观察是否需要手动恢复。不要在重要会议正在进行时测试。对经常移动办公的电脑，应记录正常退出顺序和应急恢复步骤，放在本地可离线阅读的位置。
最终配置应尽可能由一个明确的工具负责。多个客户端都尝试写系统代理时，退出顺序可能改变结果。保留旧工具用于回退并不意味着让它持续运行。需要比较不同方案时采用配置对照测试，分别启动和记录，避免竞争同一网络设置。
还应注意系统时间和目标证书错误。如果网络切换恰好伴随长时间关机，首先确认时间合理；不要用关闭证书验证作为恢复网络的常规手段。若仅某个网站出现证书警告，而其他站点正常，需要记录证书错误原文和目标域名，检查是否进入了需要认证的网络。这样的证据与代理端口拒绝连接属于不同类别，应分别处理，不能统一归为节点故障。
参考资料
- Apple：更改 Mac 代理设置，核验日期：2026-10-15。本文提供诊断顺序，不假定所有系统版本的界面文字完全相同。