看起来你碰到了个挺有意思的Windows底层行为问题，结合你描述的测试环境和现象，我来一步步帮你理清排查思路和解决办法：

一、先验证你的证书更新猜测（大概率是这个方向） #

你一开始怀疑是Iron浏览器残留的证书更新需求，这个方向很靠谱——Chrome系浏览器（包括Iron）会预装Google相关的根证书，这些证书需要定期检查吊销状态（CRL/OCSP），而检查地址往往指向Google的服务器。你可以这么验证：

• 打开任务计划程序，展开Microsoft > Windows > CertificateServicesClient文件夹，看看有没有新增的、或者最近触发过的任务，尤其是和AutomaticRootCertificateUpdate、CRLRetrievalTask相关的，这些就是负责证书吊销检查的核心任务。
• 导出并清理证书缓存：打开管理员权限的命令提示符，先备份缓存：

  certutil -urlcache * > certcache_backup.txt
  

  然后清空缓存：

  certutil -urlcache * delete
  

  之后观察1-2分钟，看看连接尝试是否停止。
• 检查Google相关证书：打开mmc控制台，添加「证书」管理单元（选择「本地计算机账户」），在「受信任的根证书颁发机构」和「中间证书颁发机构」里找Google相关的证书，右键查看「证书路径」，切换到「吊销」选项卡，看看CRL分发点是不是指向了那个34.104.35.123的IP——如果是，那你的猜测就实锤了。

二、深入定位计划任务服务的具体触发项 #

既然已经锁定是Schedule服务发起的连接，那得找出是哪个具体任务在搞事情：

• 导出所有任务的详细信息：打开管理员cmd，运行：

  schtasks /query /v /fo list > all_tasks.txt
  

  然后用记事本打开all_tasks.txt，搜索google、34.104.35.123或者URL这类关键词，看看有没有任务配置里包含这些内容。
• 启用任务历史记录：打开任务计划程序，点击顶部「操作」→「启用所有任务历史记录」，然后等待一次连接尝试触发，在「历史记录」里过滤事件ID为**100（任务已启动）和101（任务已完成）**的事件，对应时间点的任务就是罪魁祸首。
• 用Process Monitor抓包：用微软Sysinternals的ProcMon工具，过滤进程为svchost.exe（注意要关联到Schedule服务的PID，可以通过任务管理器「服务」选项卡找到），操作类型选「TCP Connect」，然后看连接发起前后的注册表、文件操作，就能找到触发连接的具体任务或配置项。

三、终止异常连接的具体办法 #

找到根源后，就可以针对性解决了：

• 禁用异常证书任务：如果是CertificateServicesClient下的任务导致的，右键禁用对应的任务，然后重启Schedule服务：

  net stop schedule && net start schedule
  

  之后观察连接尝试是否停止。
• 删除残留的Google证书：如果确认是Iron浏览器留下的Google根证书，在证书管理单元里找到对应的证书右键删除，然后再清空一次证书缓存，这样就断了后续检查的源头。（测试机随便删，生产环境要谨慎）
• 关于WFP规则的说明：你之前加的Windows防火墙规则没用，是因为WFP的系统默认规则优先级高于用户自定义规则，所以拦截还是会发生。但解决问题的核心是从源头停止连接尝试，而不是修改WFP规则（风险较高，不推荐）。

四、验证解决效果 #

• 用netsh wfp show state生成最新的wfpstate.xml，搜索那个IP地址，看看有没有新的拦截记录。
• 用tcpview或者任务管理器的「性能」选项卡实时监控网络，确认60秒一次的连接尝试已经消失。
• 重启系统后再次检查，确保问题不会复发。

备注：内容来源于stack exchange，提问作者Amazon Dies In Darkness