你买了矿机，也不能阻止矿机公司（比如比特大陆）继续生产更多的矿机并卖给别人，更不能阻止 ASIC 矿机技术更新换代……所以，即使是牛市，也存在“按比特币计价挖矿永远回不了本”（换句话说是“挖矿不如直接屯币”）的情况。

你买了矿机，也不能矿机公司（比如比特大陆）继续生产更多的矿机并卖给别人，更不能阻止 ASIC 矿机技术更新换代……所以，即使是牛市，也存在“按比特币计价挖矿永远回不了本”（换句话说是“挖矿不如直接屯币”）的情况。

更新失败这个梗不是 Win7 时代就有了么？

楼上还有说 360 的，我一直觉得更新失败和“ 360 搞炸系统”是玄学，我几乎就没找到什么简明易懂的(中文)资料能把这个解释清楚的。
不过我个人确实碰到过两个(大概)可以解释清楚的案例:
1.KB3146706 蓝屏事件
Dism++强行给 Win7 加上类似 dism /cleanup-image /startcomponentcleanup /resetbase 的系统组件清理功能，貌似是通过硬链接来实现的，导致依赖关系错乱。然后，安装 KB3146706 后，ci.dll 因为错乱的依赖关系没得到更新，还是老版本，不认识新版数字签名，导致安装更新重启后 6B 蓝屏。
但是，这件事里面，管家 /卫士反倒声称自己才是背后默默解决问题的人(而不是像传闻那样，总是以各种奇怪的姿势搞坏系统)。新闻也有报道只有 GHOST 系统才会蓝屏。
2.以前碰到过一台开机蓝屏的机器，WinDbg 打开 dmp 文件，好像能看到调用栈里有个 cmpcallback(一种内核回调，可以用来拦截注册表操作)，然后，我用 WinPE 启动，再用 autoruns 的离线分析禁用掉几个国产软件的驱动，再开机就正常进桌面了。
所以……如果说国产流氓导致了怪问题，可能不过是各种自我保护 hook 捣的鬼吧，难道他们也会把系统组件搞炸？
网上(尤其是知乎)总是流传管家卫士搞炸系统，那么搞炸的具体机理究竟是什么样的呢？

@parametrix #13
MASQUERADE 是 zone_wan_postrouting 里的，一个数据包需要走这个路径才能被 MASQUERADE:
POSTROUTING->delegate_postrouting->zone_wan_postrouting
但是，在 delegate_postrouting 那里有约束条件-o [WAN 口 iface] -j zone_wan_postrouting。
因为 DNS 响应包是从 lo 发出的，所以压根就不会走到 zone_wan_postrouting 和后面的 MASQUERADE 吧。

@BOYPT 又打错…… REROUTING=>PREROUTING

@BOYPT 我其实没看懂你前一个回复的意思……不是本机发出的包走 OUTPUT、转发的包走 REROUTING，“井水不犯河水”么？

@azh7138m 打错……退而求其次，REDIRECT+ss-tunnel

@mt7620
其实也不能说路由器上的这个 TPROXY 是废的，因为其他 UDP 包(比如内网机器执行 nslookup qq.com 114.114.114.114 这种)还是会走这个 TPROXY 的。
但是，路由器上跑的软件自己发出的 UDP 包就不会走这个 TPROXY 了(压根不会过 mangle PREROUTING 链)，尤其是路由器上的那个 dnsmasq。

@azh7138m 这是让 dnsmasq 直接把 ss-tunnel 当上级服务器么？这样也许可以绕过问题，不过我还是好奇为什么会出现这种怪状……
换句话说，是我一个人碰到这个问题，还是很多人都能重复出来这个问题？
从另一个方面说，万一我有个需求是让路由器上其他软件发的 UDP 包也走代理呢？ TPROXY+ss-redir 看样子是解决不了这个问题了(因为本机发出的包没经过 mangle PREROUTING 链)，退而求其次，REDIRECT+ss-local 居然也不行，这就蛋疼了……

@BOYPT 我 tcpdump -i lo 抓包了，OpenWRT 症状如上述，另一台 Debian VPS 则没有问题。

@mt7620
我知道 openwrt 用了 dnsmasq，然后内网机器从 DHCP 获取的 DNS 服务器就是它。然后，内网机器的 DNS 请求被这个 dnsmasq 接受、转发，不就是相当于路由器本机上跑的软件发了 DNS 请求了么？
接下来不就是我碰到的问题了？
我也装了编译好的 ipk 包(ss-libev 和 luci 插件两个包)，然后，好像是通过 ss-rule 生成规则，但对 UDP 来说，ss-rule 只是加了一个 PREROUTING 的 TPROXY，然而内网的机器 DNS 服务器都是路由器上的这个 dnsmasq 啊，所以这个 TPROXY 基本上是废的。
(ss-rule 还在 nat 表的 OUTPUT 链加了 REDIRECT，不过只对 tcp 生效)
没记错的话，为了绕过这个问题，我一般是手动在 nat 表的 PREROUTING 链再加一条 REDIRECT 或 DNAT，把内网(不是本机)的 DNS 请求转到 ss-tunnel 上(然后实际上是绕过了这个 dnsmasq)。

@parametrix
Debian VPS 上用这个 REDIRECT 是没问题的，抓包也能看到来回数据包都被正确修改了。但是这台 OpenWRT 路由器就不正常，抓包可以看到只有请求包被修改了，响应包没有被修改，然后就被 ICMP port unreachable 拒绝。

@ThirdFlame LAN 口 IP 也是一样的，不行……

@parametrix
在 OUTPUT 里加入 REDIRECT 规则后，本机 DNS 请求包的目的 IP:端口被修改，变成 127.0.0.1:[REDIRECT 的目标端口]；监听那个端口的是 dnsmasq，它发出的 DNS 响应包的源 IP:端口也被修改，变成[软件请求的 DNS 服务器]:53。

@parametrix
我在 Debian VPS 上抓包看了，确实是这样。
@ThirdFlame
试一下倒是可以，不过这很奇怪啊，难道是我这路由器里有别的什么奇怪的规则在捣鬼？我不信我还能碰到 bug。

@parametrix 其实路由下的机器都已经能走 ss 了，就是路由器自己不能走 ss，很奇怪。

@parametrix
TPROXY 只能在 mangle 表的 PREROUTING 链上使用(其实这台路由也已经用上了)，不能对本机生效吧。

空间够用的话，最好别乱删。

补丁安装后会留一个备份，这个非常占空间，包括 winsxs、installercache 之类，用 spacesniffer 可以扫出来(不过注意 spacesniffer 不考虑硬链接)。
dism++慎用，没记错的话，微软在 win8 才开始在 dism 里提供组件清理功能(清理掉老版本备份来省空间，不过用 /resetbase 清理完就不能卸载补丁)，dism++这个第三方软件“强行”给 win7 实现这个功能，似乎出过很严重的问题(不止补丁不能卸载)。

1709 ？那右键点那 svchost.exe ，转到服务，看看是哪个服务。
1703 以前的版本上一个 svchost 还跑着 N 个服务呢，出了问题都不太好区分。