ShadowTLS： TLS 伪装代理

来自： https://www.v2ex.com/t/875975 （已经被审查）

这是做啥的

向中间人表演一次 TLS 握手，之后将流量交给其他连接透明代理掉。

你可以用它来包装任意的 TCP 连接，它的 client 会加一层 TLS 握手头，server 会将这层头剥离。双边部署即可。

啥原理啊

Trojan 将 payload 基于一个伪装的 TLS 连接承载，但它部署起来略微麻烦，主要在于需要证书签发上；并且最近某地开始搞百名单策略，这种方式就不再适用。

那么一个 idea 就是：作为 server 不再自己处理握手，而是将握手流量转发至一个可信的域名上。当握手结束则立刻跳车开始向自己的服务器中转流量。这样中间人看到的就是和 www.gov.xx 的合法握手（观测到的证书也是合法的），而这显然是个白名单域名，这时中间人就会标记这个连接为合法连接。

我咋部署

看项目 Wiki 。推荐使用 docker compose 一键启动。

限制

它基于 Monoio 实现，可以利用 io_uring 和 zero_copy 实现高性能数据转发，当前仅支持 Linux 和 macOS 。
对于握手后的数据没有做封装。

运营商改造为 IPoE 的优势与劣势以及 IPv6 的安全性问题

来自： https://v2ex.com/t/875762

相关贴
江苏电信： /t/875362
江苏联通： /t/875742
浙江移动： /t/875467

PPPoE 什么时候被淘汰： /t/859349
运营商架构改变： /t/802962

在各个回帖中，都对 IPoE 的优势劣势意见不一，
看下来大概的讨论方向

认为优势的
1.IPoE 性能更好，真正原生以太网性能，对运营商对用户都可以降低成本，不再需要为 PPPoE 的低性能买单，跑高带宽不再需要投入更好的硬件，软路由也不需要很高配置，任意硬件都可以双向满速传输。
2.IPoE 不存在 MTU 问题。
3.IPoE 目前三家都是静态分配地址和 prefix ，DDNS 需求或许可以降低？

认为劣势的：
1.运营商加料，让协议不通用。
2.都习惯了 PPPoE ，老设备改造很麻烦。
3.担心丢失公网 IP 。
4.担心运营商限制桥接。
5.影响自己跑 PCDN 。

另外改造 IPv6 的安全性问题，
目前看到电信和联通是光猫默认阻断入站连接，
移动是默认开放全部连接，直接裸奔
在这个默认配置上的争议也很大，有人需要放通，为此不惜折腾桥接，有人要阻断，要安全，
而且目前很多人都是直接关闭光猫的阻断或者桥接，并且没有配置任何终端防护措施。

相关贴：
/t/875719
/t/875489
/t/875570
/t/875608

问题：
1.运营商选择 IPoE 的路线正确吗，这个是未来趋势吗，以及为什么运营商会选择在这个时间改造呢？
2.仅仅是区域性改造，还是有计划全国都要改造呢？
3.IPoE 静态分配地址后是否会产生安全性相关的问题，比如内网设备全部裸奔的情况，是选择运营商在网关默认阻断呢还是选择用户自己为每个设备配置防火墙呢？

第 1 条附言 · 1 天前

好了，此贴终结，不讨论了，
好好一个讨论 IPoE 的帖子被歪成讨论真假公网 IP 了，不知你们是对 IPoE 有什么误解。
也不知是哪个地方让如此多的人在群里被歪曲理解成改造了 IPoE 就没有公网 IP 了，就没有自由了。

IPoE 与 PPPoE 一样都是互联网接入认证 AAA 系统的一个环节，IPoE 改造与否都不会影响你们公网 IP 的分配，
希望不要将 IPoE 视为魔鬼，我们不应当阻止运营商的发展，应当安心接受现实。

犹如 PPPoE 一样，既能分配公网地址，也能分配私网地址，分配公网地址与否与你们当地运营商有关，与技术无关。
IPoE 认证也一样，既能分配公网地址，也能分配私网地址，分配公网地址与否与你们当地运营商有关，与技术无关。

并不是说原来有公网 IP 的改造为 IPoE 就没有公网 IP 了，原来私网 IP 的改造为 IPoE 就有公网 IP 了，完全无关。

而且目前所有的光猫，只要是千兆以上接口的，在 IPoE 接入场景下不会存在任何性能问题，不会像 PPPoE 一样需要硬件加速或者需要占用很高的 CPU 资源。

真假公网 IP 也没有必要讨论，既然运营商选了这项技术，那你们也没有办法阻止，安心接受吧。

为了防止谣言满天飞，特意联系三个运营商的相关帖子的宽带主人做了以下测试：

目前三地改造只针对部分地区宽带新装用户，老用户暂无群友反馈被改造。

江苏电信改造 IPoE 后：IPv4/IPv6 原生公网直接 DHCP 分配到光猫，Prefix 长度 /56 ，IPv4/IPv6 除了 80 ，123 ，139 ，443 ，445 等常见不开放端口外，其他端口全部正常开放，公网可连通（ IPv6 需要联系后台开放），NAT1 、Fullcone ，IPv4/IPv6 均支持 MTU 1500 ，IPv4 最大连接数可正常跑出 10 万以上。

江苏联通改造 IPoE+4in6 后：IPv6 原生公网直接 DHCP 分配到光猫，IPv4 采用 4in6 接入，Prefix 长度 /60 ，IPv4 采用 1:1 NAT 方式分配给 4in6 接口地址，除了 80 ，123 ，139 ，443 ，445 等常见不开放端口外，其他端口全部正常开放，公网可连通，NAT1 、Fullcone ，IPv4/IPv6 均支持 MTU 1500 （其中 IPv6 到 AFTR 网关 MTU 2048 ）。IPv6 端口除上述常见不开放端口外，全部正常开放，入站连接正常。IPv4 最大连接数可正常跑出 10 万以上。

浙江移动改造 IPoE+4in6 后：IPv6 原生公网直接 DHCP 分配到光猫，IPv4 采用 4in6 接入，Prefix 长度 /60 ，IPv4 采用 CGNAT 方式分配给 4in6 接口地址，IPv4 所有端口均不开放。NAT1 、Fullcone ，IPv4 MTU 1480 ，IPV6 MTU 1500 。IPv6 端口除上述常见不开放端口外，全部正常开放，入站连接正常。IPv4 最大连接数最大只能同时保持 6000 左右。

微信删干净还占8GB UP主深扒：聊天记录删了5遍依然全都在

来自：https://news.mydrivers.com/1/854/854042.htm

前不久，有网友解压微信APK安装包发现，11年来膨胀了575倍。其中真正实现聊天的代码可能只占0.1%，大部分代码用来运行小程序、视频号等功能，并吐槽“微信占用的99.9%空间都是存放的垃圾功能和资源。”

而且让用户崩溃的是，微信动不动就占用三四十GB的空间，即便彻底清理掉聊天记录、图片、视频等文件，占用的空间依然高达8GB以上。

那么这8GB的微信文件到底是什么呢？B站UP主“玄离199”花上百小时，深扒微信空间占用的秘密，找到了微信不能清理的“其他数据”到底存了什么。

查看微信占用的存储空间，会发现有三部分：缓存、聊天记录、其他数据。

其中，其他数据包括：主程序、程序文件、资源文件、其他帐号聊天记录等。微信还提醒，如需清理其他帐号的聊天记录，可登录该帐号进行清理；除此之外的其他数据不可清理。

该UP主将所有聊天记录删除了5遍，然后将微信文件夹复制到电脑分析，发现最大的“EnMicroMsg”文件高达5GB，解密发现，其中91%都被存放聊天记录的“message.spl”占用。

UP主查看内容发现，她所有的聊天记录竟然都存放在这张表中。也就是说，自己反复删除了5次的聊天记录，不但没有被清除，反而全部完整的保存下来。

网友调侃：笑死，微信拿你的手机当作服务器备份。但问题是，即便保留了聊天记录，但微信就是不给用户看。

鉴于以上分析，网友表示，微信还是只有备份聊天记录，卸载，重装，恢复聊天记录，清理的比较彻底。。。

星際檔案系統：如何以 Web3 應對網路攻擊消耗戰？

来自： https://matters.news/@mingnhsu/315585-%E6%98%9F%E9%9A%9B%E6%AA%94%E6%A1%88%E7%B3%BB%E7%B5%B1-%E5%A6%82%E4%BD%95%E4%BB%A5-web3-%E6%87%89%E5%B0%8D%E7%B6%B2%E8%B7%AF%E6%94%BB%E6%93%8A%E6%B6%88%E8%80%97%E6%88%B0-bafyreibsht6y65kshxl7q5jwvcfs4yfy3ubyx2wmylti4yoqdqkdllbhsy

上週美國眾議院議長裴洛西訪台後，中國隨即宣布對台軍演。除了有形的飛彈試射之外，無形的網路戰火也同步開打。過去幾天，台灣政府的網站例如總統府、國防部、外交部都曾遭到網路攻擊而短暫癱瘓，引起國內外媒體注意。

即將就任數位發展部長的唐鳳在接受《自由時報》專訪時，說明為什麼政府網站遭到癱瘓並不代表資料外洩，並指出數位發展部網站已經以 Web3 架構 —— 星際檔案系統（IPFS）—— 應對這類的網路攻擊，也鼓勵白帽駭客幫忙壓力測試。

可惜從最後呈現的報導來看，內容並沒能完整傳達訪問當下的意思，使得許多人覺得唐鳳用 Web3 在裝神弄鬼。就連專門討論區塊鏈的 PTT 論壇，版主也將這篇報導以無關 Web3 為由刪除。相當可惜。

這篇文章會先說明駭客如何以 DDoS 癱瘓政府網站，再討論數位發展部如何以 IPFS 應對網路攻擊的消耗戰。

電話佔線

根據中央社上週的報導：

美國聯邦眾議院議長裴洛西（Nancy Pelosi）計劃今天晚間抵台訪問。總統府今天表示下午約 5 時 15 分起，總統府官網遭受境外 DDoS 攻擊，攻擊流量為平日的 200 倍，導致官網一度無法顯示。但經總統府處置後，已於 20 分鐘內恢復正常運作。

同樣的狀況也陸續發生在國防部、外交部。媒體報導多半以政府網站「遭駭」下標。但熟悉資安的人就知道，DDoS 攻擊並不會造成政府資料外洩，駭客只是找來一群殭屍電腦以流量把政府網站給塞爆，藉此創造話題而已。

唐鳳在受訪時就以電話佔線來比喻 DDoS 攻擊如何運作：

這幾天政府網站有點像電話佔線，非常多人從國外跨境打電話到專線，就無法撥進去，這技術上叫大量阻斷服務攻擊（DDoS）。但實際上電話線並沒有壞掉，政府資料也沒外洩。如果大家不當一回事，就沒達到擾亂民心作用，如果當成是一件很荒謬讓大家睡不好的事，則攻擊就會產生心理戰作用，大概就會常態化。

不會有人因為銀行的客服電話佔線，就說銀行被駭客入侵了。同樣道理，政府網站被 DDoS 攻擊也只是一種「電話佔線」。

換句話說，駭客發動 DDoS 攻擊目的不是要竊取政府與民眾資料，而是為了打心理戰。看準人們分不清「電話佔線」與駭客入侵的差異，藉此製造社會動亂。因此，駭客發動 DDoS 時，攻擊的對象普遍是具有指標意義的網站，才能吸引媒體關注，進而引發民眾恐慌。

DDoS 攻擊在全球相當常見。甚至人們搶演唱會門票就與 DDoS 攻擊效果相當類似，一不小心就會癱瘓網站。因此，在技術上也早有一套應對方法：

我們的因應措施，技術上叫流量清洗。就好像電話打不進去，多設專線就可撥通，這種流量清洗的對應不斷在做，當然也已經投入相應資源。但這有點像消耗戰，為了對抗境外攻擊，我們投入相應資源去擋。

DDoS 的攻擊與防禦雙方都得付出相對應的資源。一旦駭客發現可以成功擾亂民心，透過媒體讓大眾誤以為電話佔線是一種駭客入侵，或許駭客未來還會投入更多資源發動攻擊。

反過來說，如果媒體與民眾都能知道短時間的「電話佔線」不會造成嚴重危害，甚至不當一回事，也就讓駭客自討沒趣。除了提升人們對 DDoS 攻擊的認知之外，唐鳳還以數位發展部的網站測試另一套基於 Web3 的不對稱防禦架構，希望減少防禦方的資源消耗。

星際檔案系統

唐鳳指出：

在共軍演習開始當天中午，數位發展部的網站上線，目前為止一秒鐘都沒卡住過。這個新網站是 Web3 的架構，其後端採用星際檔案系統（IPFS），跟全球區塊鏈社群或者 Web2 全球骨幹綁在一起，是個不對稱防禦的架構，例如打電話過去，不需有接線生，接的都是機器人或是語音答錄機，當他花了多少資源攻擊時，你不太需要花資源防禦，這與傳統的流量清洗，跟對方互相消耗不一樣。

數位發展部目前將網站架設在 Web3 的「星際檔案系統」（IPFS），網址是 ipns://moda.gov.tw。這與大家熟悉的 HTTP 開頭網址不一樣。開頭不同，代表使用的通訊協定不一樣。

只可惜，市面上絕大多數的瀏覽器都「看不懂」這串 IPFS 網址。暫時只有 Brave1 及 Opera Crypto Browser2 這兩款瀏覽器才能直接造訪這個架設在 IPFS 的網站，如下方截圖。其他瀏覽器只能間接造訪。

乍看之下只有網址開頭不一樣，但實際上兩種網址背後的運作機制天差地別。

大家對 HTTP 網址都不陌生，但可能是第一次看到以 IPFS（及 IPNS）開頭的網址。兩者的差別，在於取得內容的方式不同。舉例來說，我的兩位朋友小明、小華不約而同分別推薦我《區塊鏈社會學》這本書，只是兩個人推薦我去購買這本書的方式不太一樣。

小明說：「我推薦你到捷運中山站的銅鑼灣書店，進門之後在第二個書架上的第 5 本，就是我推薦你的那本書了。」

小華則說：「我推薦你買《社會學》，它的 ISBN 編號是 9789888599288。」

小明說的是書擺放的位置（location addressing），類似於 HTTP 的運作方式。他告訴我位置，卻沒告訴我是什麼內容。好處是路線明確。只要老闆沒有更換擺放位置，而且書店還沒關門，我就可以找到正確的書。

小華說的則是書的內容（content addressing），類似於 IPFS 的運作方式。他告訴我內容，卻沒告訴我可以去哪裡取得。好處是目標明確。只要市面上還有人在賣，我就可以找到正確的書。

這邊只是以書為舉例。但在駭客發動 DDoS 攻擊的時候，目標是政府網站。套用到 HTTP 的例子，那就像是銅鑼灣書店忽然被一大群不買書的黑衣人霸佔，讓循著路線要來買書的人根本不得其門而入。因此，書店就得動用「流量清洗」機制來反制，讓真正要買書的人可以進得去。

但是 IPFS 不會有這個問題。IPFS 提供的不是找「書」的路線，而是書的作者、名稱和 ISBN 編號。因此，如果發現銅鑼灣書店被黑衣人霸佔，我可以走到對面的誠品書店或者網路上的博客來買書，就不會因為某家書店被癱瘓而買不到書。

若駭客要對 IPFS 進行 DDoS 攻擊，就得想辦法找到更多「黑衣人」，才有可能把全球的通路都塞住。這樣一來，攻擊成本就遠高於防禦成本。易守難攻就是數位發展部架設在 IPFS 的網站難以被駭客癱瘓的主因，也是唐鳳在專訪裡所說的不對稱防禦架構。

台灣政府用 IPFS 抵禦網路駭客攻擊，是從烏克蘭戰爭中找到與大國對抗的新方法。即便是技術專家也還很陌生。但事實上 IPFS 在最近幾年，已經成為人們與強權對抗、避免內容「被消失」的重要工具。

不對稱防禦系統

2017 年，土耳其政府稱維基百科危害國家安全並下令封殺。許多土耳其網友為了保存資料，紛紛開始將維基百科的內容上傳到 IPFS 保存。

若以剛剛的書店為例，這就好像政府以公權力強制書店關門，讓循著地址到維基百科網站找資料的人們只能吃閉門羹。當時網友就想到能改以 IPFS 建立不對稱防禦系統，鼓勵民眾改用建立在 IPFS 上的維基百科就可以照常瀏覽，藉此與政府對抗。

類似的應用在台灣也找得到。2018 年，區塊勢曾介紹3過 Matters 的 IPFS 功能，替創作者將內容永存網路，避免因為政治或商業因素「被消失」。只不過以往大家總覺得自己不會是弱勢或少數，也就難以理解額外將文章備份到 IPFS 的具體用途。

經過近期的網路攻擊事件，大家會逐漸發現不只有個人是弱勢。在大國面前，小國也是可以被忽略的少數。而無論是加密貨幣或是 IPFS，Web3 科技工具都是為弱勢與少數族群建立的不對稱防禦系統。

将Google Voice号码转入Ultra Mobile Paygo美国实体卡步骤

来自：https://mapgun.com/archives/2418

一、前言

最近将一个Google Voice靓号转入了美国实体SIM卡，发现网上的教程都比较滞后，这里更新一下步骤说明。

转入实体卡好处：

只要交钱就不用担心号码回收
Azure等手机号限制VOIP号码绑定，转为移动号码后不受此限制

转入实体卡坏处：

每月需要缴纳不等金额月租
使用通话/短信功能可能需要缴纳不菲费用

考虑使用方便程度和价格后，选择了Ultra Mobile的Paygo 3美元月租卡（原T-Mobile Paygo套餐）

100分钟免费通话/100条免费短信可满足日常使用（需开启WIFI Calling）
资费最低能在中国漫游，不受虚拟运营商限制的美国实体卡（依然认为是T-Mobile用户）
养号成本仅3美元/月，且中国大陆购卡成本低

购买通道（供参考）

Ultra mobile美国电话卡提货券3美金月租券【包邮】
【券后价】 228 元
【优惠券】 20 元
【下单链接】https://m.tb.cn/h.fAZwS6S
【现价】 248 元
3Fu😊zhi3$WqCA2tOtVNY$:// CA1831,打開/

二、操作步骤

网络上很多介绍都是针对老界面的，目前Google Voice老界面访问通道已彻底关闭，必须从新界面设置。

（一）Google Voice解锁号码

1.登录Google Voice设置页面，解锁需要解锁的号码（需要支付3美元一次性费用），如果是从第三方购买号码，登录非本人账号操作的话，完成支付后记得在Google Pay支付管理页面删除支付方式，避免被他人盗刷。

2.如图操作，创建并保存PIN码，用于将Google Voice号码转移至实体卡。

至此，在Google Voice部分操作全部完成。

（二）UltraMobile Paygo SIM卡激活

1.首先确保手上有一张有效未激活的Paygo SIM卡（可从淘宝购买或自行eBay海淘），到手后打开 https://my.ultramobile.com/paygo/activation 页面激活SIM卡，输入SIM卡背面右上角11位ACT CODE，开始激活。

2.检查当前使用设备是否支持UltraMobile网络，只要能在国内正常使用的手机一般没问题，这一步找不到自己手机的话可以跳过。

3.输入使用城市邮编检测是否有信号覆盖，国内使用的话随便输一个城市的即可，然后根据情况选择使用语言，并选择转入已有号码进入下一步。

4.如图填写内容，信息确认无误后提交（Account填写纯数字号码仅适用于Google Voice，其他运营商请以运营商提供信息为准）。

5.根据页面信息提示输入账户注册信息（不建议跳过），万一激活出现问题好联系客服解决，完成后提交信息。

6.激活过程等待，可刷新页面检查激活状态

7.激活成功，登录Ultra Mobile App可以看到刚刚注册的号码

（三）检查转移状态

网页提示成功后手机可能依然无法接收到UltraMobile信号，可进行以下操作：

重新插拔SIM卡
重启手机（开关飞行模式没用）
等待一段时间网络刷新后，再进行上述步骤

手机能收到信号后，可访问 https://www.revealname.com/ 检查手机号码状态，可发现原号码由VOIP number变为Mobile number，运营商由Google变为T-Mobile，说明号码“洗白”成功（该结果可能需要较长时间等待）。

使用 Railway 和 Miniflux 零成本搭建 RSS 服务

来自：https://blog.cysi.me/2022/05/build-miniflux-rss-on-railway.html

Miniflux 是一款优秀的 RSS 聚合软件，相较于 FreshRSS，TT-RSS 等同类，它更加简约迅速但主要功能却一个不少。更重要的是因为它的 v2 版本使用 Go 语言编写，因此可以直接运行在一些 PaaS 平台上，个人用户完全可以使用这些平台零成本搭建一个属于自己的 RSS 聚合阅读器。

May 24, 2022

RSS（聚合内容），一种 “古老” 的消息来源格式，古老到连著名的 RSS 聚合器兼阅读器 Google Reader 都快停止服务十年了。但近几年随着开源项目 RSSHub 发布极大程度上丰富了可订阅内容，加之 RSS 本身无算法、纯用户主导（须用户主动订阅）的特性和对各互联网公司的算法推荐的唾弃，让 RSS 这一古老协议焕发了第二春。我也是从那时候开始重新依赖 RSS 获取信息。

想要使用 RSS 作为自己的信息获取工具，就一定需要一个 RSS 聚合工具，将你所感兴趣的信息源全部集中到一处，通常可以使用下面的几种方案：

本地应用程序（如 Reeder），但这种方案无法原生多设备同步，订阅源和阅读状况只在单台设备内存储，必须配合商业网络服务或自建服务来跨设备同步内容。
商业订阅服务（如 Feedly、Feedbin），但大多数需要每月支付一定的订阅费用。
自建服务（如 FreshRSS、tt-RSS、Miniflux），需要花一定的心思自行搭建，大多需要自行准备服务器，同样需要一定的物质（金钱）成本。

RSS 聚合软件对比

今天我们要讨论的是第三种方案，目前常用的自建 RSS 聚合器框架主要有：

FreshRSS，功能强大、易于使用，基于 PHP 和 SQL 数据库
Tiny Tiny RSS（tt-RSS），功能非常强大、扩展性极强，基于 PHP 和 SQL 数据库
Miniflux，极度简约但应有的功能一个不缺，基于 Go 语言

可以看出，前两个框架虽然功能上更强大且搭建起来比较简单（可以使用 Docker，或者直接使用 PHP 虚拟主机搭建）但受限于 PHP+SQL 的组合，整个框架都显得比较 “重” 或者慢，且无法做到真正的 0 成本。因此我们将目光转向到了使用 Go 语言便携的简约框架 Miniflux。

事实上 Miniflux 官方就给出了使用 Heroku 搭建的教程，但 Heroku 免费版会定时休眠且经过测试发现无法使用 ping 工具保持真唤醒状态（为什么说 “真唤醒”？因为此时在 Heroku 控制面板中该服务并没有显示在休眠，但实际上它已经处于待机状态了），严重影响首次访问速度，体验较差。

Railway：不休眠的 PaaS 平台

虽然本文的目的是 0 成本搭建，但也并不意味着我们就要因此妥协使用体验。这时候我们可以把目光转向另一个 PaaS 平台：Railway（该链接含 Referral Code)

这是一个 2020 年成立的 PaaS 平台，无需信用卡的免费版可以提供 5 美元的额度，如果绑定信用卡则每个月可以使用 10 美元的额度，用户仅需支付超过该额度的使用费，对于普通个人用户而言，5 美元的额度早就足够。

—— 更重要的是，它支持数据库和 Docker，所以比起 Vercel 或 Netlify，它更像是 Heroku 的替代品，更优质的替代品。这就为我们达成 0 成本搭建 RSS 聚合器且不损失使用体验带来了可能。

动手搭建

说了这么多，现在让我们开始动手搭建基于 Miniflux+Railway 的专属于自己的 RSS 聚合器。

需要注意的是，为了让更多人能够自行搭建服务，因此本文中所有的操作都尽量使用有图形化的程序并使操作尽可能简单。

准备工作

正式开始之前，我们需要准备：

GitHub 账号
Railway 账号
GitHub Desktop 客户端（可选，图形化管理更加简单，或者你可以直接使用 Git）
一台电脑

首先我们需要去 Miniflux v2 的 GitHub 页面并 Fork 该项目到自己的账户中。完成后打开并登录 GitHub Desktop 客户端，点击顶部菜单栏的 “File - Clone a repository”，找到自己刚刚 Fork 的项目，选择好下载目录位置并点击 Clone 按钮，将该项目下载到本地。

创建稳定版分支

由于 Miniflux 的默认分支（master）本身其实是不稳定的开发版，直接部署使用开发版多多少少会遇到各种问题，为了保证服务的稳定性和可用性，故我们还需要单独创建一个稳定版分支。

让我们回到 Miniflux 的 GitHub 页面，注意上图标黄的 “Release” 部分，可以看到当前稳定版版本号为 2.0.36，这也是该 Release 对应的 tag，记住这个版本号，在 GitHub Desktop 打开下载到本地的项目，点击左栏的 “History”，找到带有对应版本号的一栏，右键点击 “Create a branch from commit”，在弹出的窗口中输入新的分支名 stable 并 Create branch，完成后，顶部的第三个大按钮会变成 “Publish branch”，点击它使之同步到 GitHub 仓库中。至此，稳定版分支创建完成。

更新稳定版分支

如果要更新你的稳定版分支，做法也很简单，首先确定 Miniflux 已经发布了新的稳定版，打开 GitHub Desktop，点击客户端窗口上的 “Current branch”，先从本地删掉 stable 分支，再重复上一节里面的创建稳定版分支的操作即可。

使用 Supabase 数据库

Miniflux 需要用到 PostgresSQL 作为数据库，虽然 Railway 本身可以直接创建数据库，但为了避免账单爆炸，还是建议使用 Supabase 这类数据库服务。

注册完成后，创建一个 Project，数据库位置建议选择美东或者美西，设定并记住数据库密码，等待创建完成。

数据库创建好后，进入该 Project，在左侧菜单里面选择 Settings - Database，找到页面的 Connection string，获取你的数据库 URL，形如 postgresql://postgres:[YOUR-PASSWORD]@db.xxxxxx.supabase.co:5432/postgres，记得把 URL 中间的 [YOUR-PASSWORD] 改成自己先前设定的数据库密码，并复制备用。

部署到 Railway

现在我们可以将稳定版分支部署到 PaaS 平台，比如我们接下来会用到的 Railway。

进入 Railway 控制面板，新建项目（New Project）- Deploy from GitHub repo - 绑定 GitHub 账号并选择我们在上一节做好稳定版分支的项目，这时系统会自动开始部署，因为我们还没有设置数据库和环境变量，所以这次部署一定会失败，暂时不需要理会。

接着，回到刚刚连接的 GitHub Repo 模块，点击它，在右侧的弹出的窗口，导航到 “Settings” 选项卡，将 “Deployment Trigger” 下面的选项从 master 改为 stable，即切换为我们在上一节里面增加的稳定版分支。同时，你还可以在 “Service Domains” 里面自定义该服务的域名（免费提供 up.railway.app 子域名)，或绑定自己的域名。

完成后切换到 “Variables” 选项卡，点击右侧的 “RAW Editor”，将下面的变量按需修改并去掉注释后复制粘贴到文本框内，点击 Update 即可。

1
2
3
4
5
6
7


DATABASE_URL=上一节复制留存的PostgreSQL链接
PROXY_IMAGES=all
RUN_MIGRATIONS=1
BASE_URL=https://域名，如果你无法自备域名则可以直接填写免费提供的子域名
ADMIN_PASSWORD=管理账户密码
ADMIN_USERNAME=管理账户用户名
CREATE_ADMIN=1

提交了环境变量后 Railway 会自动重新部署，可以在 “Deployments” 选项卡里面查看进度。完成后即可登录使用。Miniflux 原生支持 Fever 和 Google Reader API，可以在 Miniflux 的设置中启用，这样即可配合相应的 RSS 阅读客户端使用（iOS 推荐 Reeder，Android 推荐 FeedMe）。

2022 年 7 月 27 日更新 如果部署后无法使用，log 中提示 app not found，目前推测原因是 Railway 新使用的 Nixpacks Builder 的问题，在 Railway 里面，点击你的 Miniflux 模块的 Settings，找到 Builder，换成 Heroku，等待重新部署即可。

至此，一个简约但不简单的 0 成本 RSS 聚合器就搭建完成了！快去订阅自己喜欢的源享受干净可控的阅读环境吧！

扩展阅读：RSSHub

有了自己的 RSS 聚合器后，剩余的工作就是寻找并订阅自己喜欢的内容（源）了，这里推荐使用 RSSHub，让各种原本无法使用 RSS 的平台支持 RSS，可以极大幅度丰富订阅内容。RSSHub 官方虽然有在免费提供服务，但由于访问量太大，较多网站会对之启用反爬措施，但好在零成本搭建一个 RSSHub 服务非常简单，可以阅读这篇文章了解如何使用 Vercel 免费搭建一个自己的 RSSHub。

DNS Hijacking(劫持) 和防御

来自：
https://twitter.com/evilcos/status/1557222252349108226

DNS 可以让我们访问目标域名时找到对应的 IP： Domain -> IP_REAL 如果这种指向关系被攻击者替换了： Domain -> IP_BAD(攻击者控制) 那这个 IP_BAD 所在服务器响应的内容，攻击者就可以任意伪造了。最终对于用户来说，在浏览器里目标域名下的任何内容都可能有问题。

DNS 劫持其实分为好几种可能性，比如常见的有两大类： 1. 域名控制台被黑，攻击者可以任意修改其中的 DNS A 记录(把 IP 指向攻击者控制的 IP_BAD)，或者直接修改 Nameservers 为攻击者控制的 DNS 服务器； 2. 在网络上做粗暴的中间人劫持，强制把目标域名指向 IP_BAD。

第 1 点的劫持可以做到静默劫持，也就是用户浏览器那端不会有任何安全提示，因为此时 HTTPS 证书，攻击者是可以签发另一个合法的。第 2 点的劫持，在域名采用 HTTPS 的情况下就没法静默劫持了，会出现 HTTPS 证书错误提示，但用户可以强制继续访问，除非目标域名配置了 HSTS 安全机制。

重点强调下：如果现在有 Crypto/Web3 项目的域名没有强制 HTTPS(意思是还存在 HTTP 可以访问的情况)，及 HTTPS 没有强制开启 HSTS(HTTP Strict Transport Security)，那么对于第 2 点这种劫持场景是有很大风险的。大家擦亮眼睛，一定要警惕。

对于项目方来说，除了对自己的域名 HTTPS + HSTS 配置完备之外，可以常规做如下安全检查： 1. 检查域名相关 DNS 记录(A 及 NS)是否正常； 2. 检查域名在浏览器里的证书显示是否是自己配置的； 3. 检查域名管理的相关平台是否开启了双因素认证； 4. 检查 Web 服务请求日志及相关日志是否正常。

对于用户来说，防御要点好几条，我一一讲解下。对于关键域名，坚决不以 HTTP 形式访问，比如： http://example[.]com 而应该始终 HTTPS 形式： https://example[.]com 如果 HTTPS 形式，浏览器有 HTTPS 证书报错，那么坚决不继续。这一点可以对抗非静默的 DNS 劫持攻击。对于静默劫持的情况，不管是 DNS 劫持、还是项目方服务器被黑、内部作恶、项目前端代码被供应链攻击投毒等，其实站在用户角度来看，最终的体现都一样。浏览器侧不会有任何异常，直到有用户的资产被盗才可能发现。那么这种情况下用户如何防御呢？
用户除了保持每一步操作的警惕（尤其是钱包要签名要确认的那一刻）外。我推荐一个在 Web2 时代就非常知名的浏览器安全扩展：
@noscript (推特虽然很久很久没更新，不过惊喜发现官网更新了，扩展也更新了)，是
@ma1的作品。 NoScript 默认拦截植入的 JavaScript 文件。

但是 NoScript 有一点的上手习惯门槛，有时候可能会很烦，我的建议是对于重要的域名访问可以在安装了 NoScript 的浏览器(比如 Firefox)上进行，其他的尽管在另一个浏览器(如 Chrome)上进行。隔离操作是一个很好的安全习惯。许多你可能觉得繁琐的，驾驭后、习惯后，那么一切都还好。

但是这并不能做到完美防御（从来就没有完美防御），比如这次@CurveFinance 的攻击，攻击者更改了其 DNS A 记录，指向一个 IP_BAD，然后污染了前端页面的： https://curve[.]fi/js/app.ca2e5d81.js 植入了盗币有关的恶意代码。如果我们之前 NoScript 信任了 Curve，那么这次也可能中招。

可能有人会说了要不要多安装一些浏览器安全扩展，我的看法之前已经提过（这里补充 NoScript，你用的前提最终一定来自你自己的独立研究，DYOR）。其他一些姿势，后面有机会我再展开。如果你觉得对你有帮助或有什么要补充的

记一次被 AirTag 跟踪的经历

来自： https://blog.meathill.com/device/an-experience-of-being-followed-by-airtag.html

前些天，我们几家人一起去川西自驾游，旅行到第 5 天的时候，我突然收到一条推送：

发现正在跟随您移动的 AirTag
此物品的物主可查看其位置。轻点打开“查找”并查看可用操作。

我是 TestV 的铁丝，对 AirTag 闻名已久，于是这条推送立刻引起了我的注意。我想了想，像我这种家里蹲，应该没人想追踪我。同游的亲戚里，倒是有社会关系比较复杂的；而且话说回来，如今这个年代，家里人互相丢个 AirTag 也不是不可能。

于是我先找到老婆，本意是让她先找大家试试口风，没想到她立刻就跟所有人都说了，然后全家总动员，开始寻找陌生人放下的 AirTag。

0. 关于 AirTag

其实 AirTag 是个不小的发明。它本身不支持联网，无法使用 Wi-Fi 或者 4G/5G；不支持存储；也不支持定制发送的内容。这些“瘦身手段”使得它的构造可以尽量简单，体积小巧；尽量省电，一颗普通纽扣电池可以使用很长时间。

AirTag 会定时向周围广播位置，只有苹果设备认得这些加密数据，它们收到广播后，如果处于联网状态，就会把这些信息转发给苹果的中心服务器。AirTag 的拥有者可以登录到苹果服务器查看 AirTag 的位置。

AirTag 可以用来追踪物品，但是也可以拿来追踪人。

1. 为什么我会收到推送

正常情况下，这些数据会通过拥有者的设备转发（因为他们会和 AirTag 长期近距离接触）；或者在开放区域，就会被一批随机设备转发。

我们的情况比较特殊：我们在川西自驾，很长一段路程甚至连网络都没有，于是 AirTag 周围就只有屈指可数的几台苹果设备可以作为转发渠道。而这几台设备都不是 AirTag 拥有者的设备，当一个设备反复帮不是同一个 Apple ID 的 AirTag 转发位置信息后，就会触发苹果的风控系统，苹果就要通知 ta：

小心，可能有人在跟踪你。

2. 寻找 AirTag

按照推送，打开”查找“，可以看到这个 AirTag 一路跟着我们跨域几百公里，从昨晚的酒店来到今天的酒店，甚至包含中间去做核酸的当地医院。基本可以排除偶遇同路，一定是有人故意放在车上、或者行李里。

”查找“可以让 AirTag 发出声音，于是我在几个房间转了一圈，确认无法连接。猜测 AirTag 应该在车上，于是我带着一群小朋友（其实也不小了）来到停车场，能连接的上，但是没有声音。那么只有两个可能：

喇叭被拆掉了
藏的比较深，声音传不出来

为排除（2），大家开始翻行李。翻来翻去，翻去翻来，始终找不到，多半是喇叭被拆掉了。看来放 AirTag 的人处心积虑不想让人找到。眼看越来越晚，我就把大家拉回去了，今晚先放弃。

我回去搜了半天，但没找到什么有价值的信息。能够帮被追踪者查找 AirTag 的方式，只有播放声音，或者蓝牙信号定位。前者拆了喇叭就白给，后者则要求环境可控，比如能够关闭或屏蔽大部分蓝牙设备，但现实中很难做到。如果是自己的 AirTag，苹果提供了非常丰富的定位手段；而别人的 AirTag，就没法使用。

第二天，我尝试了前一晚积累的几个想法，都没成功。于是大家决定先放弃。大家都认为不会是追踪自己，多半跟原车主有关，为了接下来的旅程，就先不管吧。

3. 答案

回家之后，经询问，AirTag 是其中一位车主放在车上的，为的是好找车。

事实就是这么简单，跟吴啊萍一样。

4. 想法

这件事情之后，我对 AirTag 的不信任进一步加深了。

AirTag 很小、很薄、很容易藏。攻防两方的地位不对等，被投放的人想找到 AirTag 很困难。
AirTag 并不如设计的那般可靠，拆喇叭很容易，拆掉之后几乎没法寻找。
AirTag 非常容易买到，没有持有成本。
AirTag 的认知度非常低，大外甥告诉我，他两天前就接到过推送，但他根本不了解 AirTag，没多想就直接关掉了。

如果有个人存心想追踪另外一个人，他可以用很低的成本（rmb 100+）了解到对方的行踪，对方可能长时间都不知道自己处于被跟踪状态。苹果应该设计更好的方案，或者增加 AirTag 的持有和使用成本。

创作没了，心凉

来自： https://www.v2ex.com/t/867078

突然被封

7 月 15 号（上周五）下午 17:03 ，我在出差回京的高铁上。突然接到腾讯云邮件、站内信通知，我的在线思维导图、流程图工具——画图本 huatuben.com 域名因涉嫌欺诈，被停止解析，同时禁止解封、禁止域名转移。

一瞬间，整个人都不好了。

最开始的挣扎

高铁上信号差，七拐八拐终于联系上了腾讯云客服。被告知执行监管部门指令，不得解封、不得转移。同时，不告知是哪个部门封禁的、也不告知封禁的具体原因，自称没有权限。

周六日两天，心如死灰。

不死心

今天周一，各部门上班了。不死心，致电工信部备案中心，对方反馈没有封禁操作。邮件给反诈中心，对方告知 5/31 日解封后也没有任何操作。

继续找腾讯云客服，依然不告知原因、不告知受什么监管部门的指令。在我连续追问下，被逼急了，一直跟我回复法条，并开启复读机模式，无论我问什么问题，都只发送法条。

要求腾讯云技术专员电话联系我。几小时来电，依然复读机，自称无法告知谁封禁的、无法告知原因。

决定放弃

到现在，基本确定是个死局。估计即使报警、拨打 12315 热线，也解决不了问题。神秘力量太强大了。无奈，只能放弃。域名肯定要不回来了，好在网站数据还在，因此打算新注册个域名，把服务整体迁移到到海外。

尾巴

这个网站倾注了我太多心思和精力，奔四的人了，和小伙伴配合弄个小工具站，想着多少能有个自己的事情做，算是个中年人的念想。把域名从国外转到国内，服务器也迁到腾讯云。工信部备案，公安备案，一顿操作折腾。从春节到现在，每个假期、每天下班，基本没有休息一直在改进使用体验。这一路都走过来了，也积累了一批原始用户。

这一下瞬间给关了，愤怒，心里凉的透透的。发个贴，舒缓一下。希望能给其他独立开发者作个参考，别再掉我这个坑。

顺便问一句，想给国内用户提供在线服务，有啥不被封的方法么？咱就做个学习工具而已，太难了！

如何用一个(Git) 仓库记录自己的一年

来自 https://github.com/yihong0618/gitblog/issues/209

写在前面

从最开始的用 GitHub 的 Issues 写博客，到尝试用 GitHub 记录的年度数据已经二年有余了，从最开始有想法 2020, 到 2021 加了很多功能，把大部分的记录自动化，一点一点记录也算是有些心得了，这篇文章就介绍一下我是怎么做的，能帮助到同样感兴趣的大家就更好了。也算是践行这 2 年对我影响最大的文章之一

People Die, but Long Live GitHub

GitHub 的一个 repo 能做什么？

能记录 Issues
Issues 可以评论
能给 Issue 打标签
能有一张展示的 README
README 能引入 svg
有 Actions 可以辅助自动化
Actions 可以放 secrets
可以用 cron 和各种事件触发 Actions
API 公开，可以自己 DIY
有手机应用，不用开电脑能随时随地记录
有评论区
私有仓库这些以上的都有

好，我们把这些结合起来，记录自己的一年~

数字区

上图这些数字区是怎么实现方式分为两部分:

API 获取 -- 扇贝，开心词场，多邻国
Issues 配合 labels 获取，俯卧撑，花费。。。

每天早 8 点和晚 9 点，定时跑一次，计算数据进行整合，并配合 telegram 的 bot 提醒自己。
入口大家可以参考 Actions 的这个 workflow

Issues 的代码思路为获取 label -> 通过 label 找 issues -> issues 的评论特定格式 -> 通过函数解析 -> 整合 -> 通过正则替换 README 中的原有数据（文字）（README 可以写注释，而注释是不显示的，利用这个完成显示和替换）

def main(
    login_dict,
    github_token,
    repo_name,
):
    my_num_stat_str = MY_NUMBER_STAT_HEAD
    # API STAT STR
    for name, value_dict in MY_STATUS_DICT_FROM_API.items():
        try:
            url = value_dict.get("url")
            md_name = f"[{name}]({url})"
            # maybe a better way?
            total_data, streak, today_check = value_dict.get("daily_func")(
                *login_dict.get(name, tuple())
            )
            total_data_str = str(total_data) + value_dict.get("unit_str", "")
            my_num_stat_str += make_stat_str(
                md_name, total_data_str, streak, today_check
            )
        # just a tricky code for others for use
        except Exception as e:
            print(e)
            continue

    u = Github(github_token)
    # COMMENTS STAT STR
    for name, value_dict in MY_STATUS_DICT_FROM_COMMENTS.items():
        try:
            labels, map_func, reduce_func = LABEL_DAILY_DICT.get(name)
        except:
            # tricky for mine
            continue
        func = value_dict.get("daily_func")
        if not func:
            break

        issues = u.get_repo(repo_name).get_issues(labels=labels)
        total_data, streak, today_check, url, month_summary_dict = func(
            issues, map_func, reduce_func
        )
        # change the issue body for month summary
        unit = value_dict.get("unit_str", "")
        for i in issues:
            body = ""
            for b in i.body.splitlines():
                # from the summary table
                if b.startswith("|"):
                    break
                body += b + "\r\n"
            body = body + "\r\n" + make_month_summary_str(month_summary_dict, unit)
            # edit this issue body
            i.edit(body=body)
        name = f"[{name}]({url})"
        total_data_str = str(total_data) + unit
        my_num_stat_str += make_stat_str(name, total_data_str, streak, today_check)

    replace_readme_comments("README.md", my_num_stat_str, "my_number")

多说几句早起

关于早起这个数据和 issue 因为自己喜欢诗歌，我找了一个获取一句诗的 API, 然后自动评论，评论是带时间戳的，正好记录自己的起床时间。
那么是怎么触发的呢？
我用的是 iOS 系统，而 iOS 有个重要的功能是“捷径“。利用捷径可以触发 Actions workflow 的 api, 触发 api 就有时间戳了，再判断是不是早起，给自己发送就好了。
捷径的触发条件是闹钟关闭，为了保险起见，我可能比闹钟起的早，再加一条关闭背单词软件，解决了用 GitHub 记录早起的问题。

def make_get_up_message():
    sentence = get_one_sentence()
    now = pendulum.now(TIMEZONE)
    # 3 - 6 means early for me
    is_get_up_early = 3 <= now.hour <= 6
    get_up_time = now.to_datetime_string()
    body = GET_UP_MESSAGE_TEMPLATE.format(get_up_time=get_up_time, sentence=sentence)
    return body, is_get_up_early

关于如何利用捷径配合 Actions 我写过一篇文章 -- 巧妙利用 iOS 的快捷指令配合 GitHub Actions 实现自动化

而早起这句诗，我期待好久的 -- 苟利国家生死以，岂因福祸避趋之。还没随机到，随到这一天我决定跑 19.26 km.

GitHubPost 区

利用了我写的 GitHubPoster 项目，自动生成 svg 引入，而自动跑的脚本也在那个项目上。

GitHub Repos 区

利用我写的 github-readme-stats 自动替换生成。

娱乐区

全部利用 Issues 评论 -> 触发 Actions -> 自动替换 README 的注释区域生成

def replace_readme_comments(file_name, comment_str, comments_name):
    with open(file_name, "r+") as f:
        text = f.read()
        # regrex sub from github readme comments
        text = re.sub(
            GITHUB_README_COMMENTS.format(name=comments_name),
            r"\1{}\n\3".format(comment_str),
            text,
            flags=re.DOTALL,
        )
        f.seek(0)
        f.write(text)
        f.truncate()

做饭区

和上面类似，因为做的太多，我生成了个表格

def parse_cook_issue_table(me, issues):
    comments_str = MY_FOOD_STAT_HEAD
    food_dict = defaultdict(lambda: ["", "", 0])
    for issue in issues:
        comments = issue.get_comments()
        for c in comments:
            if not isMe(c, me):
                continue
            date_str = format_time(c.created_at)
            food_list_str = c.body.splitlines()[0]
            food_list = food_list_str.split(" ")
            for food in food_list:
                if food not in food_dict:
                    food_dict[food][0] = f"[{date_str}]({c.html_url})"
                    food_dict[food][1] = f"[{date_str}]({c.html_url})"
                else:
                    food_dict[food][1] = f"[{date_str}]({c.html_url})"
                food_dict[food][2] += 1
    for k, v in food_dict.items():
        comments_str += MY_FOOD_STAT_TEMPLATE.format(
            name=k, first_date=v[0], last_date=v[1], times=v[2]
        )
    return comments_str

月度数据

每次自动生成还会 edit issue 的内容生成月度数据整合

博客区

在 blog 的 repo 写 issue ->curl 2021 的 Actions workflow api -> 自动生成

收藏文章博客区

这个完全手动添加，我想保留一些仪式感

我也想做一个

如果大家想同样做一个这样的年度数据可以 follow 以下步骤:

fork or clone 这个项目
增加 issues 打 label
修改 config
修改一些 api 的 config 数据换成自己的
如果有问题可以邮件或私信我

COOK_LABEL_LIST = [
    "Cook",
]
MOVIE_LABEL_LIST = [
    "Movie",
]
READ_LABEL_LIST = [
    "Read",
]
DRAMA_LABEL_LIST = [
    "Drama",
]
PUSHUP_LABEL_LIST = [
    "PushUps",
]
BANGUMI_LABEL_LIST = [
    "Bangumi",
]
GAME_LABEL_LIST = [
    "Game",
]
MONEY_LABEL_LIST = [
    "Money",
]
MEDITATION_LABEL_LIST = [
    "Meditation",
]
MORNING_LABEL_LIST = [
    "Morning",
]
GTD_LABEL_LIST = [
    "GTD",
]
MY_BLOG_REPO = "yihong0618/gitblog"
GITHUB_README_COMMENTS = (
    "(<!--START_SECTION:{name}-->\n)(.*)(<!--END_SECTION:{name}-->\n)"
)

# add new label here
LABEL_DICT = {
    "Cook": {"label_list": COOK_LABEL_LIST, "comment_name": "my_cook"},
    "Movie": {"label_list": MOVIE_LABEL_LIST, "comment_name": "my_movie"},
    "Read": {"label_list": READ_LABEL_LIST, "comment_name": "my_read"},
    "Drama": {"label_list": DRAMA_LABEL_LIST, "comment_name": "my_drama"},
    "Bangumi": {"label_list": BANGUMI_LABEL_LIST, "comment_name": "my_bangumi"},
    "Game": {"label_list": GAME_LABEL_LIST, "comment_name": "my_game"},
}


##### SHANBAY ######
MY_SHANBAY_USER_NAME = "ufewz"
SHANBAY_CALENDAR_API = "https://apiv3.shanbay.com/uc/checkin/calendar/dates/?user_id={user_name}&start_date={start_date}&end_date={end_date}"
MY_SHANBAY_URL = f"https://web.shanbay.com/web/users/{MY_SHANBAY_USER_NAME}/zone"

##### DUO ######
MY_DUOLINGO_URL = "https://www.duolingo.com/profile/yihong0618"

##### CICHANG ######
MY_CICHANG_URL = "https://twitter.com/yihong06181/status/1359040099107897344?s=20"


##### FOOD ######
MY_FOOD_STAT_HEAD = (
    "| Name | First_date | Last_date | Times | \n | ---- | ---- | ---- | ---- |\n"
)
MY_FOOD_STAT_TEMPLATE = "| {name} | {first_date} | {last_date} | {times} |\n"

##### Month Summary ######
MONTH_SUMMARY_HEAD = "| Month | Number | \n | ---- | ---- | \n"

MONTH_SUMMARY_STAT_TEMPLATE = "| {month} | {number} |\n"

订阅：博文 (Atom)