@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 个服务呢，出了问题都不太好区分。

@f2f2f 我擦，那我还真得小心了，我一般都是大版本更新的时候才清理。

@f2f2f
内置的磁盘清理？ cleanmgr 么？
我也用过啊，也是勾选清理老系统文件……不过我的系统没被搞死，哈哈。
还有，如果是我，可能会尝试用 WinRE 里的命令提示符手动 dism /apply-image 来重装，这样就不用格 C 盘了（不过需要有 wim 镜像）

@jedihy
即使不能绕，或者说你用的本来就是非管理员账号，UAC 也只是护着系统本身而已。软件想作恶其实还是可以作恶（比如截屏 /记录键盘 /上传文件等等），毕竟没有沙盒隔离……

@jedihy
UAC 也只是防手贱而已，默认挡是筛子，各种绕，甚至，连最高档也存在绕过（没错，就是这么坑爹，哪怕你还调了组策略提示凭据，也能绕，详情请搜 UACME ）。
微软早就说了 UAC 不是安全边界，绕了也（基本）不修的。

@yksoft1
如果在 360 找回来的是一个空的新账号，也未必能推断出 360 爬了数据吧。

我也用过这玩意…… Android 4.4
好像是只能走 NDP，不能 DHCPv6，所以有些热点的 V6 是通的，有些不通，然后我才装了这玩意。

“跌！跌！跌！真的跌啦！”.jpg

@Mingsaul 算不上研究，您有空可以看看我贴的几个链接。