macOS防火墙默认放行sharingd等系统服务，无法通过常规设置拦截；真正限制需手动停用AirDrop、SMB、打印共享等对应服务，或配置持久化pf规则。
macOS 防火墙不拦 sharingd，因为默认放行系统服务
macOS 内置防火墙（pf + socketfilterfw）默认对系统级服务如 sharingd、afpd、smbd 完全放行，哪怕你开了「阻止所有传入连接」——这和 Windows 或 Linux iptables 的直觉完全不同。
实操建议：
- 用
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate确认防火墙实际状态（不是「系统设置」里那个 UI 开关） - 检查是否启用了「自动允许已签名的下载应用」：
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned，返回yes时，sharingd必过 - 真正想限制网络共享端口（如 548/445/631），必须手动禁用对应服务，而非依赖防火墙拦截
停用 AirDrop、SMB、打印机共享等服务比配防火墙更有效
macOS 的「网络共享」面板本质是开关一堆后台 daemon，防火墙不参与控制逻辑。直接关服务，既彻底又避免规则冲突。
常见服务与对应操作：
- AirDrop：关闭「隔空播放接收器」+ 关闭「接力」，或终端执行
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.airdropd.plist（需 SIP 临时关闭） - SMB 共享：系统设置 → 通用 → 登录项 → 关掉「文件共享」；或命令行
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.smbd.plist - IPP 打印共享（端口 631）：关掉「打印机共享」，或
sudo launchctl unload -w /System/Library/LaunchDaemons/org.cups.cupsd.plist - 注意：
launchctl unload后若重启仍生效，说明 plist 被系统保护，需在恢复模式下运行csrutil disable（不推荐日常开启）
socketfilterfw 添加自定义入站规则容易被系统覆盖
macOS 会周期性重载防火墙配置，尤其在系统更新、网络切换或「系统设置」中修改共享选项后，手动加的 pf 规则或 socketfilterfw --add 条目大概率丢失。
如果你坚持用规则（比如只封某 IP 访问 445）：
- 不要用
--add直接加进程，改用端口规则：sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/sbin/smbd不可靠，应改用sudo pfctl -f /etc/pf.anchors/myrules配原生pf - 自定义
pf规则必须放在/etc/pf.anchors/下，并在/etc/pf.conf末尾显式 include：load anchor "myrules" from "/etc/pf.anchors/myrules" - 每次修改后必须
sudo pfctl -ef /etc/pf.conf，且确认sudo pfctl -s rules输出中有你的规则 - 系统升级后
/etc/pf.conf可能被重置，备份习惯不能少
网络共享服务的真实监听行为藏在 lsof -iTCP -sTCP:LISTEN 里
你以为关了「文件共享」就万事大吉？sharingd 可能在后台监听 548（AFP）、445（SMB）、60000+（Bonjour 服务发现），甚至配合 iCloud Drive 暴露额外端口。
排查方法：
- 运行
sudo lsof -iTCP -sTCP:LISTEN -P | grep -E "(548|445|631|60000)"，看哪些进程真在听 - 特别注意
sharingd经常绑定*:548（全接口），而不仅仅是127.0.0.1:548 - 如果看到
filecoind（iCloud Drive 后台）监听高随机端口，那是正常行为，但意味着仅靠关 SMB 无法阻断全部共享面 - 临时测试可先
sudo killall sharingd，观察端口是否释放——这是验证服务依赖最直接的方式
