痛点拆解：为什么「偶发连不上」比「永远连不上」更难排
痛点 1：把间歇超时当成认证问题。双栈环境下，客户端可能对同一主机名先尝试 IPv6、失败后回退 IPv4，或相反；若其中一条路径被中间盒丢弃或 MTU 黑洞，表现就是偶发卡在 TCP 握手，与 authorized_keys 无关。
痛点 2：DNS 与企业 split-horizon。内网解析给出一套 A/AAAA，外网解析给出另一套；工程师在 VPN 内外切换时，「同一域名」实际指向不同监听面，远程 Mac 上的 sshd 日志会出现来源地址族切换，与 known_hosts 中入库指纹预期不一致。
痛点 3：防火墙只配了半套。许多模板默认写 22/tcp 但不区分 inet/inet6；在 macOS 自带 pf 或上游云安全组只放行 IPv4 时，IPv6 会话会被静默丢弃，开发者却看到「有时能传有时不能」。
痛点 4：CGNAT 与上传队列叠加。家宽或某些运营商出口在 IPv4 侧处于 CGNAT，IPv6 反而更直连；若 CI 与人工共用入口而不做 并发与 keepalive 评审，会把路径抖动放大成「传输慢=密钥问题」。
威胁模型与观测指标：把「网络层」从「会话层」里剥离
建议记录：DNS 的 A/AAAA、TCP 握手 RTT、SSH 协商耗时与 SFTP 子系统首包时延。远程 Mac 上统一日志里 sshd 谓词应与防火墙计数器同一会话对齐。若已部署 Tailscale/Headscale，优先把威胁模型收敛为「仅私网 IP 可达」，再调 ListenAddress。
可引用数据：用可重复数字结束「感觉网络不稳」
跨洲链路里 v4/v6 RTT 差 20–80ms 很常见；Happy Eyeballs 并行尝试可能叠加数百毫秒到数秒的失败等待。把 ConnectTimeout 与 ServerAliveInterval 写入基线后，异常先对照 DNS 变更。CI 侧若 IPv4 NAT 出口漂移，先把 TCP 可达与解析稳定，再联动 MaxAuthTries 讨论认证重试。
决策矩阵：仅 IPv4、仅 IPv6 与双栈如何选
| 场景 | 优先策略 | 主要收益 | 主要风险 |
|---|---|---|---|
| 企业仅发 AAAA | 客户端 AddressFamily inet6，服务端全 v6 监听 + v6 防火墙 | 路径单一、排障清晰 | 旧客户端/库无 v6 时需跳板 |
| 双栈但 v6 质量差 | 客户端强制 inet 或禁用该主机的 AAAA（谨慎） | 稳定走成熟路径 | 与「未来只发 AAAA」冲突，要文档化 |
| 远程 Mac 在云上同时有公网与私网 | 生产入口走私网或 mesh，公网仅运维 | 攻击面小、延迟稳 | 需要额外路由与 DNS 分层 |
| CI 无头 + 人工并行 | 拆分账号与端口，或拆分地址族策略 | 避免人类调试踩 CI 限流 | 需要更多监控面板 |
实操步骤：从解析到监听再到防火墙（How-to）
# 1) 先看 DNS：是否同时返回 A 与 AAAA（示例域名请替换）
# dig +short A your.remote.mac.example
# dig +short AAAA your.remote.mac.example
# 2) 客户端：为特定 Host 强制地址族（示例：仅 IPv4）
# Host rm-prod
# HostName your.remote.mac.example
# AddressFamily inet
# ServerAliveInterval 30
# ServerAliveCountMax 6
# 3) 客户端：需要仅 IPv6 时
# Host rm-prod-v6
# HostName your.remote.mac.example
# AddressFamily inet6
# 4) 服务端（远程 Mac / Linux）：查看 sshd 实际监听
# sudo sshd -T | egrep 'listenaddress|addressfamily|port'
# 5) 快速验证端口在双栈是否可达（分别在能访问 v4/v6 的机器上执行）
# nc -vz <host> 22
# nc -6vz <host-v6> 22
步骤 1：在变更窗口冻结 DNS，记录 A/AAAA TTL 与发布者，避免「运维以为改好了解析，客户端仍缓存旧 AAAA」。
步骤 2：为工程师与 CI 分别建立 Host 别名，CI 侧明确写 UserKnownHostsFile 与指纹策略，复用 known_hosts 固定 文的可执行模板。
步骤 3：在远程 Mac 上核对 ListenAddress：若只监听 0.0.0.0 而不监听 ::，IPv6 客户端必然失败；反之亦然。
步骤 4：把防火墙规则拆成 v4/v6 两张表计数；出现「一侧命中为 0」时优先修网络而不是改 SSH 配置。
步骤 5：将 并发 SFTP 与 MaxSessions、ClientAliveInterval 一并压测，观察长传是否与地址族切换同窗口出现。
强相关阅读与站内 CTA
阅读顺序：本文 → known_hosts → 并发 SFTP → 限次 → ProxyJump → 首页。
FAQ 与为什么考虑 SFTPMAC 托管远程 Mac
我应该在公司网络禁用 AAAA 吗？
不建议作为长期策略；更稳妥的是为关键主机名拆分 Host 记录、在客户端分段 AddressFamily，并在文档中写明「此入口仅 v4」或「仅 v6」，避免团队各自「本地 hosts 硬改」造成隐性分叉。
macOS 客户端与 Linux CI 行为不一致怎么办？
先统一 OpenSSH 版本与配置文件加载顺序（系统级与用户级），再在 CI 镜像里固化 ssh -G 输出做回归基线；差异多半来自解析库与默认地址族，而不是密钥。
双栈问题会影响 rsync 吗？
会：rsync 走 -e ssh 时与 SFTP 同源，应共用 Runbook。
总结：2026 年远程 Mac 作为交付入口时，「能 ping」与「能稳定传产物」之间隔着 DNS、地址族、监听面与防火墙四张表；把双栈问题从认证层剥离后，排障路径会短很多。
局限：运营商与企业 DNS 任一侧悄悄变更 AAAA，都会让团队回到间歇性泥潭。
对比与收束：SFTPMAC 托管远程 Mac 将稳定在线与传输治理产品化，减少跨部门追查 AAAA 与半套防火墙；长期对外提供 SFTP/rsync 时，租赁专用节点通常更易获得可重复 SLA。
把地址族、监听面与 known_hosts 固化到同一 Runbook，托管入口更易一致回归。