底层机制不同肯定不等价。对用户来说是否等效关键在于用途是什么。比如希望不改变原本 A/B 平面 IPTV 的同时保证外部访问内网设备 IPv4/v6 的端口，这么配置跟桥接差不多。但如果对转发性能有要求、不信任光猫的安全性、需要自己控制 IPv6 分配等部分光猫没有的高阶功能，那效果还是会有区别。

根本原因是有基于域名的通信，不是做了解析本身

不经常打开 Web UI ，但是 BT 、Syncthing 、rsync 、相册一直在提供服务

看到现在还是觉得，HTTPS 内密码只能就来解决“有坏人但又不完全坏”的场景，例如：
1. 后端人员出问题原则上什么都可以拿到。但是也许有人看到明文 log 心生歹意，但是密文 log 就不去细想。
2. 中间人出问题原则上什么都可以篡改、窃取，但是也许有中间人只会拿明文 log ，不会分析前端加密、不会篡改前端直接拿到明文。

换言之，这种方法可以增加安全性，但增加的是非常狭窄的场景。同时，给工程增加复杂性、营造虚幻的安全感也可能会降低安全性。因此，不同厂商可能会有不同的取舍。

NAS 与移动硬盘最大的区别就在于实时在线。这样就能满足数据同步、随时调取数据、PT 上传等需求。
如果没有这种需求，在可以远程启动的前提下关机也是一种折中的选项。

对于非专业用户，手机号+验证码还是最方便，国内还能顺便落实实名制。毕竟来一句密码忘了/验证器删了/Key 掉了还得用其他方法来验证。
对于专业用户，Yubikey 这种推广的麻烦点还是在于成本，基于设备本身安全芯片的 Passkey 可能会应用更广。

@ShuWei 增加复杂度有时也会降低安全

@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升，虽然也是好事，但是这样场景数量太庞大，会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。

尝试总结一下

用户端：
恶意软件/人员有很多手段获得密码，很难想象一种只有 HTTPS 内明文才能获得密码的场景。（安全的增益太细微）

中间人：
当前移动端安装根证书很难，PC 端需要权限。如果有本事装上，那同样有很多手段获得密码。
既然是中间人，那自然可以篡改网页，从你手里明文获得密码再加密发给网站，双方都无感知。（只有当中间人坏但又不完全坏时才有意义）

服务端：
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠，到处都是漏洞，单单密码加密意义不大。
无论前端有无加密/散列，服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景，例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究，如果是明文可能会心生歹意。在这种
情况下，加密也许存在一定意义。

关键要讲清楚，前端加密的目的是什么，要防止什么样的攻击/泄露。对于用户侧的攻击，找不要有意义的场景。对于服务侧，因为会有很多环节，加一层防止意外泄露还算有那么点道理。

个人看下来：
对于用户侧，如果恶意软件/人士已经掌握足够权限，那再 HTTPS 内再加密也没意义。关键是要找到一种场景，HTTPS 内再加密能防住、HTTPS 防不住，且这种场景有考虑的价值。我暂时没还想到。
对于服务侧，经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发，通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御，那 HTTPS 内再加密还有点意义，据要结合具体场景分析。就拿 CDN 举例，如果 CDN 是坏人，只加密密码，用户隐私、Token 等信息都是明文，那一样可以窃取信息、拿下账户、伪造信息，那加密的意义也就不是很明显。

搞不好是总部玩 AI 玩崩了

看操作系统，主要和临时 IPv6 地址都跟 MAC 无关的隐私保护预设也很常见

现在很多存量光猫的配置选项还是不能满足需求，比如防火墙、IPv6 前缀再下发等

还有一种情况是不信任运营商的光猫想建立自己的内网，更换光猫又会有别的麻烦，路由模式又会双层 NAT

@xz410236056 安卓既想要国产又希望干净一般需要刷机，可以通过刷机社区的反馈来筛选机型 https://github.com/KHwang9883/MobileModels/blob/master/misc/bootloader-kernel-source.md