anubu

用了不到一个月，速度还可以。就是前两天不可用，以为就是常规跑路了，又临时买了个备用的。看到你发帖再试试才发现恢复了。
建议官网挂个公告通知什么的，官网大部分可以直连，群却基本无法直连，导致没有备用链路的话，完全不清楚故障情况。

人作为个体，可以发挥一定的主观能动性，改善自己的境遇。但人不能脱离时代，每个时代都有当下的结构性问题，结构性问题是宏观的，不以个体意志转移的。
就像高考录取率，个体可以努力考上大学，但宏观统计层面，不管大家是否努力，录取率固定就是有固定比例的人上不了大学。
网络上讨厌宏大叙事，但时代局限性是客观存在的，秦始皇再努力也用不上一个千元机，这种局限性在生产力层面比较明显，生产关系层面往往被忽视了。

各种贴牌、严选类的都在向南极人靠拢。

现状是正确的，归因是错误的。
OP 的结论是厂家故意把消费者骗进来杀，实际上产品厂家和安装服务是 2 个独立的利益主体，甚至有点冲突。安装服务本身就是一个非标的场景，OP 的意思应该是厂家应该提高售价，把这个非标环节包含进去，这个其实去买高端品牌应该可以缓解。走量的低端品牌，每个环节都要精打细算，不会算的都被市场淘汰了。

个人感觉还挺好用，最近 hy3 免费，基本常开了。比较适合干一些运维杂活，最近的 2 个会话：
- 在 2 个内网自建的 Nexus 实例间迁移 maven snapshots 制品，弄了十来分钟，算是一次性完成。
- 从 AzureDevOpsServer 中迁移 git 仓库到 gitea 实例，几百个仓库，半个小时迁移完成。
都是些零碎脏活，自己弄要翻 API 写脚本，怎么都要半天一天的，免费的 hy3 还没碰到排队，还要什么自行车。

@NealLason 从 gitlab runner 迁移到 Jenkins 还是挺更新我的认识的，以前总认为这是个反向操作。

感谢分享。
说一个我用此类工具的痛点，关于 DNS-01 验证的权限问题。涉及到和域名解析服务商 API 交互，几乎没有工具明确说明自己需要哪些权限，如何精细化控制权限。把整个域名解析能力交给一个第三方应用是很大的风险点，没有强背书的话，很难忽略这个风险。当然，可以自己根据服务商 API 文档自行摸索出一个最小权限，但真的很繁琐，甚至你看了半天文档，然后确认 API 权限不支持，无法缩小最小权限。如果工具本身有明确的说明，或更进一步对主流服务商有一个各自的权限配置示例，体验会好很多，可以节省很多风险评估时间。
上面只是说签发层面，全流程的话，第三方应用直接更新生产环境证书也是个风险点，各个环节都要认真评估才好。