boNote

## 为什么要用 Warp play余额充多了没处花买了warp+ ，warp 可以有效拯救服务器的媒体解锁能力，妈妈再也不怕咕噜咕噜（非洲方言：指咕鸽）把我给 `Region: CN` 了 而且还能顺便处理掉咕噜咕噜天天弹点选消失型验证码让我搜一次点一年的优异体验 （和群友吹水顺手测了下梯子落地鸡的 [RegionRestrictionCheck](https://github.com/lmc999/RegionRestrictionCheck)，看到花了不大价钱买的 Youtube Premium 不能用，感觉像吃了屎一样，正好从记忆的角落翻出来了 warp 这个东西 想起来跟着龟龟白嫖了warp+的流量 ，就顺手试试） ## 效果预览  ## 安装 Wireguard 因为 warp 使用 wireguard 协议，所以我们需要安装 wg 的客服合一p2p端软件 [Instruction 参见](https://www.wireguard.com/install/) rh 系都进 epel 了，除了 rh 系都进官方源了，我真想不出还有什么再在这件事上多费口舌的必要  ## 其他系统需求 本文基于 Debian 10，所使用的 `ipproto`这个 selector 在 18 年底才 [被引入 iproute2](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=b2e8bf158460568ec5b48cba69f657f95891c901) ，Debian 的速度当然是还算快的，但是对于[19年11月 前的 RHEL](https://bugzilla.redhat.com/show_bug.cgi?id=1678111) / [200428 前的 CentOS](https://git.centos.org/rpms/iproute/c/72258cdf3818ca898511fda04947914f6a11be

22/04/02 Update: 有一位朋友在留言中问了下面的问题： > cfw中启用Specify Protocol或者pac对访问https网站依旧无效 于是我又打开阔别已久的 Windows 开发机看了一下（顺便一提，果子也挺烂的，尤其是ARM版的，不过看在字体渲染的份上还是先用果子吧）： 问题在于 Clash for Windows 的Specify Protocol处理其实还是有问题，如果你之前没有仔细完全阅读下面那个设定代理服务器的函数，翻下去看一下它，就在倒数第二张图。 可以看到如果只是单纯地把注册表项的内容由 `127.0.0.1:7890`改为`http://127.0.0.1:7890`的话，urllib只会返回一个只有一个key也就是`http`的代理dict。 这时候从pip的请求调用链往上找，可以看到负责决定使用这个dict中哪个代理的代码是 `requests/utils.py`的`select_proxy`函数：  因为红框中的部分的限制，当你请求`https://pypi.org`的时候，只有key为`https`/`https://pypi.org`/`all`/`all://pypi.org`的代理会被使用，上面那个`http`的代理自然也就不会被使用。 BTW，因为这个代码是 requests 库的，这也就意味着在 Windows 平台上 Clash for Windows 的系统代理不会影响到大部分py应用的http请求。 而正确的做法是什么呢？让我们在IE中设置上代理，然后看一看它给出的行为：   同时，因为 urllib 中还存在代理的类型推测代码，所以正确的设置应该是： `http=http://127.0.0.1:7890;https=http://127.0.0.1:7891` 21/06/07 Update: CFW [解决了](https:/

目前实验室内的代理方案是OpenClash，但是他劫持PREROUTING的行为让我感觉很不爽，虽然软路由性能充足，但是使用体验总让人膈应。于是想要找点别的法子。 最近 Proxifier 4 的release引爆了我常见的几个群的群友，纷纷上线作为自己的代理处理措施，也有老哥因为想起来proxifier看了一眼日志，结果发现了个[恶意扩展](https://blog.berd.moe/archives/chrome-spyware-extension-user-agent-switcher/)。而我，因为一位群友发出了域内WPAD自动"智能"尝试的错误日志，想起了还有这么个解决方案，实操感觉良好。 ## 准备代理 这个clash肯定还是要跑在路由器上，鉴于现在在用openclash，干脆就不换了。在配置中没有看到相关的选项，估计他也没想到有人这么想开倒车回到pac时代，总之我们修改他的服务脚本`/etc/init.d/openclash`和看门狗脚本`/i/forgot/that/path`，把所有带 `-j openclash`的注释掉，这样就不会劫持PREROUTING链了。 当然，如果你在用fake_ip方案，别忘了把dns劫持选项关掉。 ## 准备 PAC WPAD的代理配置是通过分发一个PAC文件来做的，所以我们需要一个可以通过http被访问得到的PAC文件，这里我直接丢到路由器的`/www`，让uhttpd顺便分发一下。 因为最后负责分流的还是clash，这里的PAC可以直接简单粗暴地这样来： ```javascript function FindProxyForURL(url, host) { return "PROXY 10.0.0.1:1380; DIRECT" } ``` 当然如果你想要有个gfwlist先在客户端做个黑名单，也可以去github上随便找个。 ## 设置DHCP luci中跟这个相关的dhcp选项不在dhcp里，在`interface - (select one) - DHCP Server - Advanced setting`有个DHCP-Options，该选项支持我们下发任何dhcp option，如果对于可能的内容感到好奇可以看rfc。 WPAD的opt

markdown ## 前言 之前忘了从哪惊闻知名韩国“统治阶级”之一，SK海力士，做SSD了，寻遍淘宝无踪迹，于是抓紧去美亚下了个单：  然后好好体验了一把属于转运中国的美国速度：  我能在今天收到这块硬盘，还得感谢转中美国仓的小伙伴，冒着疫情的风险，在3月20号把我2月中旬就送达的件交给usps。 ## 表面话题 言归正传，这块106刀（约750元人民币）的硬盘花了我一百块的运费，以一共850元的价格到达我手中，和860evo水平差不多（指价格）。 如果对巨大照片没兴趣请空降：[性能与参数](#性能与参数) 太长不看请：[TL;DR](#tldr) 平平无奇的盒子在来的鹿上看起来受了点磕碰，本来打算用祖传70D拍照来着，仔细一想：我又不想做后期，用个jb单反，所以就用咕鸽相机拍了。  好，让我们小心翼翼地打开包装  这玩意就长这样，以下略  ## 性能与参数 首先是经典的CDI时间（这些smart信息是在做完测试之后取得的）  大批的厂商特定项目？不要怕，幸好海力士为我们提供了贴心的spec文档： ![image-20200530221222030](https://vip1.lo

markdown ## 引言 最近因为网课消息闭塞的我于4月13号凌晨突然看到群友说要开车。  然后打开才知道是JD的阿斯加特4T ssd，不是深夜开的那种车，虽然2000r/4t的确是很香吧……一看就知道是灵车，作为资深灵车受害者我必须得上一上 于是整了一个  不要在意三块，另外两块是别人的（ 到货之后拍了两张序列号当保修留底，盒子没什么特别的，没有拍的欲望。 测试环境记录： > OS：Windows 10 2004 > Motherboard：ROG Z370i > CPU：Shitel 8086k > Ram：[email protected] > 系统盘：760p 512G ## 跑分 先进行一下例行的跑分： 没啥区别，忘截图了，过。 ## 测试 因为这次的车非常的大，又非常的灵，让我有一种小孩开大车的感觉，所以干脆测试地彻底一点，按评(虐)测(待)的标准来。 然后打开我心爱的HDTune Pro……不对，HDTune不支持200G+的文件，我还是用 dd for Windows 自己写个脚本来测试吧。 然后让我们先用大文件读写个半盘并记录数据：  这个……明显是全盘slc擦(ca)车(che)，平时体验不错，能用能用（五毛一条，发时删除）。  暂且不谈缓外60M直接吓得我停了测试，读的那四个在底部的点是怎么回事呢？是坏块，当读到的时候系统报错数据错误无法读取，然后四个文件就这样阵亡了…… 有SMART为证（图中框出来的A1项是出厂坏块数，A6项是目前坏块数，差值即为当前坏块） ![image-2020041

markdown 在 [VMware 技术预览版](http://bit.ly/getworkstation-tp)的诱惑下，我果断地投入了Windows insider的怀抱，开始我曾经梦想的wsl2+docker windows+VMware的生活。 然后炸了我一脸，幸好因为疫情暂时没啥锅要背。 ## wsl2 ### 错误 0xffffffff 刚装上之后总是转不过去wsl2，看到[一篇issue](https://github.com/microsoft/WSL/issues/4364#issuecomment-520742839)中说到53端口的问题，看了一下发现确实有个（以前搞的没啥卵用的）服务在占用53端口，关闭并重启就ok了 ## docker desktop ### 神秘端口占用 常用的端口全被他给日了，一旦启动docker desktop就会被占用。 看到[这篇博文](https://blog.miniasp.com/post/2019/03/31/Ports-blocked-by-Windows-10-for-unknown-reason)意识到又是`excludedportrange`的锅（如果你有在win10 1803更新后打不开ss，提示1080被占用，怎么找都找不到端口占用的话，那就是这个了） #### before 忘截图了，总之就是只有几个条目的样子 #### after  #### solution 因为忘了截图，所以上面的after其实是我解决之后的截图。 docker desktop会占下一批的端口留待动态分配，看到上面那个博文中「每次占用的端口都有变化」之后，如果你还没有意识到他是在从系统整动态端口的话就说不过去了。 通过`netsh int ipv4 show dynamicport tcp`检查自己的动态端口分配规则发现：tmd竟然是从1000开始的？ 使用`netsh int ipv4 set dynamicport tcp startport=40000 numberofports=20000`将tcp动态端口的范围设置为「40000-60000」，当然你愿意严格按照IANA那个