局域网ping不通不等于连通失败，常见原因是目标或中间设备静默丢弃icmp包；应优先用curl/nc测实际端口、检查默认路由接口、验证dns解析及使用traceroute -i或mtr定位真实链路。
局域网设备 ping 不通，不等于连通失败。macOS 下很多“不通”其实是策略性静默或配置错位导致的，关键在于跳过表象、直击协议层和路由路径。
先确认是不是 ICMP 被拦截了
局域网里 ping 不通但 SSH 或网页能访问，大概率是目标设备或中间网络设备（比如交换机、路由器）静默丢弃 ICMP 包——它收到了，但故意不回。这不是故障，是常见安全策略。
- 用 curl -I http://192.168.1.100 或 nc -zv 192.168.1.100 22 测试 TCP 端口是否可达，更贴近真实服务行为
- 别只测一个 IP：同一台设备的不同服务端口（如 22/80/443）可能表现不同，优先测你实际要用的端口
- 如果 curl/nc 成功而 ping 失败，基本可排除本机设置问题，重点查目标设备防火墙或网络设备 ACL
查清楚流量到底走哪条路
Mac 可能同时连着 Wi-Fi 和有线，但默认只走优先级高的那个接口。你看到“以太网已连接”，数据却全走 Wi-Fi，自然局域网设备就“失联”了。
- 运行 netstat -nr | grep '^default' 看当前默认路由走的是 en0 还是 en1
- 用 networksetup -listallhardwareports 查 en0/en1 分别对应什么物理接口（Wi-Fi？有线？）
- 若需强制走有线，执行 sudo networksetup -setmetric "Ethernet" 10（数值越小优先级越高）
盯住 DNS 和本地解析规则
有时你能 nslookup 到设备名，却 ping 不通或无法访问，是因为 macOS 的 resolver 配置把特定域名导向了错误 DNS，尤其在公司内网或自建 DNS 场景下很常见。
- 检查 /etc/resolver/ 目录下是否有按后缀（如 .local、.corp）配置的文件
- 临时禁用：重命名该目录下相关文件，再执行 sudo dscacheutil -flushcache
- 验证系统级解析是否生效：用 scutil --dns 查当前实际使用的 DNS 策略
用对工具看真实路径
traceroute 默认用 UDP，很多企业网络设备不响应 UDP 探测，显示一串 * * * 并不代表断了；mtr 或 traceroute -I 才能反映真实链路。
- 装 mtr：brew install mtr，然后运行 mtr --report 192.168.1.100，它持续采样，能看出丢包位置和抖动
- 不用装也能用：traceroute -I 192.168.1.100（大写 i），强制走 ICMP，行为更接近 Windows tracert
- 配合 arp -a | grep 192.168.1.100 确认 MAC 地址是否已学习，没记录说明二层未通
