[{"content":"近期網信辦對《互聯網信息服務管理辦法（修訂草案徵求意見稿）》（以下簡稱《辦法》）再次公開徵求意見1，稿件內部分修訂的條文引起了很多人的擔憂——尤其是涉及「穿透、繞過技術措施」和「被依法阻斷的信息」等表述，一時間「翻牆徹底違法」「一刀切要來了」的聲音甚囂塵上。\n網上幾乎每年都能見到所謂「一刀切」、「白名單」的討論，如果不能體會這種論調的市場有多大，看看前幾年「禁止相關個人數據出境」的條文在當時是如何被解讀的就知道了。那好，我們就來看看這次的《辦法》到底是一般的技術性修法還是真的所謂「管控升級」。\n第二十六條：明確規定「翻牆」違法？ 第二十六條 任何組織和個人不得實施下列行為，擾亂互聯網信息服務秩序：\n（一）實施信息發佈、刪除、屏蔽、斷開鏈接、替換、下沉、算法推薦等行為，或者為他人提供信息發佈、刪除、屏蔽、斷開鏈接、替換、下沉、算法推薦等服務；\n（二）虛假註冊或者批量註冊互聯網賬號、非法囤積或者非法交易互聯網賬號；\n（三）操縱、利用多個互聯網賬號批量發佈含有法律、行政法規禁止內容的信息和不良信息，從事虛假點擊、投票、榜單、排行、評論、交易、評價等活動，實施流量造假、流量劫持，製造虛假輿論熱點，操控榜單、熱搜等重點環節等；\n（四）實施違法穿透、繞過國家有關機構技術措施的活動；\n（五）法律、行政法規禁止的其他行為。\n互聯網信息服務提供者應當採取異常數據監測、人工複審複核等措施，加強對前款規定行為的預防和監測。\n乍一看確實很嚇人，這不就是明確規定翻牆違法了嗎？法律法規的訂立往往需要嚴格的咬文嚼字，每一條法律條文幾乎都經過反覆的推敲和字句斟酌，再讀一遍這一句：\n實施違法穿透、繞過國家有關機構技術措施的活動\n「違法」是定語，修飾「穿透、繞過國家有關機構技術措施的活動」這個行為。意思是：不是所有穿透、繞過都被禁止，只有「違法的」穿透、繞過才被禁止。\n何謂「違法」 那什麼是「違法」呢？\n全國人大法工委的《立法技術規範》對「違法」的概念有明確的界定：「違法」一般用於違反法律強制性規範的行為2。換言之，要判定一個行為「違法」，必須存在一條明確的法律強制性規範被違反——不能憑空認定。以下是這份規範給出的參考用例：\n示例一：被檢查單位或者個人拒不停止違法行為,造成嚴重水土流失的,報經水行政主管部門批准,可以查封、扣押實施違法行為的工具及施工機械、設備等。（水土保持法第四十三條） 示例二：村民委員會不及時公佈應當公佈的事項或者公佈的事項不真實的,村民有權向鄉、民族鄉、鎮的人民政府或者縣級人民政府及其有關主管部門反映,有關人民政府或者主管部門應當負責調查核實,責令依法公佈;經查證確有違法行為的,有關人員應當依法承擔責任。（村民委員會組織法第三十一條） 如果依然不能理解，可以對比看看「非法」，《立法技術規範》對「非法」的說明是：「非法」通常情況下也是違法，但主要強調缺乏法律依據的行為。什麼意思呢？當然不是指「找不到允許你做的法律條文」，而是指：這類行為本來依法必須有某種依據、許可、資格、授權或合法來源，但行為人沒有。例如「非法行醫」——你本來應該要有執業醫師資格證的，但你沒有，所以你是非法行醫。同樣的結構，如果換成「違法行醫」，那聽起來就像是你有執業醫師資格證，但是行醫的方式錯了，這種表達也不太常用。\n用語 焦點 隱含意思 非法行醫 你根本沒有醫師資格 你不該行醫 違法行醫 （不太常用）暗示有資格但違規操作 你行醫方式不對 非法持有槍支 你沒有合法持有依據 你不該有這東西 非法拘禁 你沒有法定權力拘禁他人 你無權這麼做 違法穿透 已有相關法律和行政命令明令禁止「穿透」 有個法律、禁令在那裡，你違反了 從這份技術規範及其用例可以看出，要判定一個行為是否「違法」，需要有明確的前置法律依據。問題是，你上哪裡去找這樣一個前置法律依據呢？眾所周知，GFW 阻斷 Google、YouTube、Twitter 等網站，但這種阻斷從來沒有對應的法院命令、簽署後的行政文件，甚至連一份非正式的官方封鎖列表都沒有3。法外狂徒張三自行搭建 ShadowSocks 服務器並且用來訪問 Google、YouTube、Twitter 等網站，首先其並未構成法規適用的前提——擾亂互聯網信息服務秩序，其次亦沒有任何法規和行政文件明確封鎖或者禁止訪問這些網站，因此，在單純的法律意義上，張三是不「違法」的。\n也就是說，第二十六條第（四）項對張三並不適用——因為他的行為不滿足「違法」這一前置要件。\n這條法規主要針對誰 這條是和以下行為並列的：\n操縱信息發佈/刪除/算法推薦 批量虛假註冊賬號 刷量、刷榜、假流量、假輿情 違法穿透、繞過國家有關機構技術措施 其他 前三項打擊的對象比較清楚，無非就是黑產、水軍、SEO/GEO操控。第（四）項和它們並列，語境上暗示它針對的也是有組織的、商業化的、擾亂信息服務秩序的行為，而不是張三在家上個 Google Scholar 查論文。\n可能的打擊對象：\n商業機場、VPN 服務（未經許可經營電信業務和穿透技術措施，這個在以前以加速器的名義處在灰色地帶，現在理論上也可以） 用翻牆工具做境外輿論操控、跨境詐騙、賭博引流的 幫助已被依法關停的網站通過技術手段復活的 突破政府、企業的內網、專網等網絡的安全措施的攻擊行為 第三十條：掐死整個灰色產業鏈？ 第三十條　明知他人違反本辦法規定實施以下行為的，任何組織和個人不得為其提供數據、技術、程序、工具、軟件、廣告、服務、支付結算等方面的支持、協助或者其他幫助：\n（一）製作、複製、發佈、傳播違反本辦法第二十四條和第二十五條第一款、第二款規定的信息的；\n（二）違反本辦法第二十六條第一款規定，擾亂互聯網信息服務秩序的；\n（三）為他人獲取、傳播被依法阻斷的信息的。\n這條看起來也很嚇人，只要在任何相關的環節幫助他人看到依法阻斷的信息就算違法？那豈不是機場老闆、風險支付商、評測推廣頻道、翻牆內核的開發者這一路人全都被納入了這條法律的管轄範圍？\n何謂「被依法阻斷的信息」 現實中的「依法阻斷」大概分為這幾類：法院裁定、行政處罰、公安辦案、部委專項行動。\n法院裁定在知識產權領域最常見。比如版權方起訴某盜版網站，法院判決侵權成立，裁定要求ISP屏蔽該域名。有判決書、有案號、有被告、有生效日期。\n再說行政處罰，例如通管局對某未備案網站作出行政處罰決定，責令改正後拒不執行，再通知接入商停止服務。有處罰決定書編號、有送達回證、有法律依據引用、有救濟告知（如不服本處罰決定，可在收到本決定書之日起六十日內向XX機關申請行政複議，或者在六個月內向XX人民法院提起行政訴訟。）。\n公安機關辦案這一類很好理解，比如掃黃，涉及詐騙、賭博、色情的網站，公安立案偵查後可以要求 ISP 配合切斷。通常有立案決定書、有協助通知書發給運營商。運營商檔案裡會留存公安的正式函件。\n部委專項行動這一類稍微特殊一些，比如國家版權局每年的「劍網行動」，會公佈一批侵權網站名單，通知各ISP屏蔽。有公開的通知文件、有網站列表、有引用的法律依據。雖然程序簡化了，但至少有白紙黑字的部門文件可查。\n幫助他人「翻牆」，算他人獲取、傳播被依法阻斷的信息嗎？ 這裡的邏輯和前文類似，現實中，沒有任何一份公開的行政文書、法院命令寫著類似「依據《某法》第某條，決定阻斷對 Google/YouTube/Telegram 的訪問」的內容。你找不到一個蓋章的決定書，找不到作出阻斷決定的具體行政機關署名，找不到阻斷的期限，找不到申訴途徑。\nGFW 對境外網站的封鎖，在法律性質上一直是一個事實行為而非法律行為。它存在，它運作，但它沒有走過「作出行政決定 → 通知當事人 → 可申訴」這套程序。不難看出，GFW 對於 Google、Twitter 等平臺的封鎖並不是法條中提到的「依法阻斷」\n到了這裡可能有人要問了，第八條規定在境內提供互聯網信息服務必須取得 ICP 牌照 → Google 沒有 ICP 牌照 → Google 屬於非法提供服務 → 對非法服務進行阻斷 = 依法阻斷，這不就構成了依法阻斷嗎？這看起來有道理，實際上問題卻很大。\n其一，管轄權問題。 第二條寫的是「在中華人民共和國境內從事互聯網信息服務」。Google 的服務器不在中國，公司不在中國（當年退出中國的時候保留部分研發部門至今，但研發部門並不從事任何 Google 直接面向公眾的業務），它沒有主動在境內從事服務——中國用戶訪問它，和它主動在境內從事服務，是兩個完全不同的事。第九十二條確實說「境外的組織、個人向中華人民共和國境內提供互聯網信息服務的，應當遵守法律」——但這只是一個義務宣示，不等於自動取得管轄權。你得先認定它「向境內提供服務」，這個認定本身需要一個正式的行政程序。\n其二，未取得 ICP 牌照的法律後果並非「阻斷」。 第七十四條寫得很清楚：未取得許可擅自從事互聯網信息服務的——「由電信主管部門責令改正；拒不改正的，責令停業整頓」。注意法律後果是「責令改正」和「責令停業整頓」，不是阻斷。這些處罰措施的前提是你能送達、能執行——對境內主體可以這麼做，對境外主體你怎麼責令？你連個送達地址都沒有，難不成你把法律文件寄到山景城去嗎？\n其三，第六十七條管不到從未持有許可的境外網站。 「被電信主管部門吊銷/撤銷/註銷許可或取消核准編號的，由電信主管部門通知相關互聯網接入服務提供者和域名解析服務提供者停止為其提供服務。」這條最接近依法阻斷——通知 ISP 切斷服務。但它的適用對象是「被吊銷/撤銷/註銷」的——你得先有許可，然後被取消，才觸發這條。從來沒有取得過許可的境外網站，這條完全管不到。\n事實上，從備案制度實施至今的互聯網現狀就能反推出這一點。已知：如果對所有未經備案的網站一律執行「依法阻斷」，其效果等同於白名單制度——只有備案過的網站可以訪問，其餘全部封鎖。然而現實是，國內互聯網顯然不是白名單狀態，大量未備案的境外網站仍然可以正常訪問。由此可以得出結論：GFW 對特定網站的封鎖並非法條意義上的「依法阻斷」。既然通過翻牆獲取的信息不屬於「被依法阻斷的信息」，第三十條第（三）項自然也就不適用。\n第十五條：正式給專線機場判死刑？ 第十五條　國家對互聯網協議地址的分配使用實行備案管理。互聯網協議地址分配機構應當及時向電信主管部門報備互聯網協議地址信息。\n互聯網接入服務提供者提供接入服務前，應當核驗相應互聯網協議地址備案信息，不得為未實名或者虛假的互聯網協議地址提供服務。\n這條針對 IDC、ISP 的監管規定是早就有了，然而機場依舊通過「加速器」等名義或者掛靠別的持有牌照的實體照常運作，具體什麼時候查、用什麼力度查由工信部根據國內的政治經濟需要隨時調整。近期大規模的拔線潮，時間上恰好與工信部領導層調整吻合——這種執法力度是否屬於「新官上任三把火」式的階段性運動，還是意味著長期收緊，尚有待觀察。\n罰則和其他細節 第八十四條　違反本辦法第二十六條、第三十條、第三十二條、第四十八條、第四十九條規定，依照有關法律、行政法規的規定處罰。法律、行政法規沒有規定的，由網信、電信、公安部門和其他有關主管部門依據職責責令限期改正，可以並處10萬元以上100萬元以下罰款；拒不改正或者情節嚴重的，處100萬元以上500萬元以下罰款，並可以責令暫停相關業務、停業整頓。\n注意這裡的罰款起步就是 10 萬元，上限 500 萬元，還可以「責令暫停相關業務、停業整頓」——這些措辭明確指向的是組織和商業化主體，而非個人用戶。個人在家用代理看個 Google 的行為，既不涉及「業務」也不涉及「整頓」，從罰則的設計邏輯上也可以印證：這套條文針對的是有組織的商業行為，而不是普通網民。\n此外，罰則適用的前提是違反第二十六條和第三十條——而前文已經分析過，個人翻牆行為在法律構成要件上並不滿足這兩條的適用條件。罰則再重，構成要件不滿足，也輪不到你頭上。\n現實中對「翻牆」行為的處罰 達摩克利斯之劍 前面從法律條文的角度分析，個人翻牆行為並不滿足新《辦法》相關條款的構成要件。但法律文本是一回事，現實執法是另一回事。\n事實上，針對個人使用 VPN 的行政處罰一直存在，依據的也不是這部新《辦法》，而是 1997 年便已頒佈的《計算機信息網絡國際聯網管理暫行規定》第六條4——「計算機信息網絡直接進行國際聯網，必須使用郵電部國家公用電信網提供的國際出入口信道」，以及第十四條規定的處罰措施：警告、沒收違法所得、對個人處以最高 5000 元罰款，對單位處以最高 15000 元罰款。\n這條規定掛在那裡將近三十年了，大部分時間處於休眠狀態。但它從未被廢止，意味著執法機關隨時可以選擇將它激活——而激活的時機、力度和對象，完全取決於當時的政治氣候和地方執法意願。\n值得一提的是，「國際出入口信道」這個概念本身就存在定義模糊的問題。《暫行規定》要求必須使用「國家公用電信網提供的國際出入口信道」，但許多專線機場採購的恰恰就是中國電信、中國聯通、中國移動三大運營商運營的 IPLC（國際專用租用線路）或 IEPL（國際以太網專用線路）——這些都是三大運營商合法銷售的國際信道產品，面向企業客戶公開經營。如果用戶通過合法採購的運營商國際專線訪問境外網絡，是否滿足了「使用國家公用電信網提供的國際出入口信道」這一要件？條文沒有給出答案，執法實踐中也從未做出明確界定。這種模糊性進一步加劇了選擇性執法的空間。\n真實案例 根據公開可查的行政處罰信息5，截至目前可檢索到的涉及個人使用 VPN 的處罰案例遠超公眾認知。以下是幾個有據可查的案例：\n廣東韶關南雄（2019年）：當事人使用藍燈（Lantern）翻牆共 487 次，被南雄市公安局予以警告並處罰款 1000 元。 浙江金華（2020年）：金公東(網警)行罰決字[2020]00751號，當事人因使用未經授權的國際信道被處以行政處罰。 四川遂寧（2019年）：遂船公(永)行罰決字[2019]489號，類似處罰。 某地（2025年）：當事人「小張」在網絡安全檢查中被發現存有 VPN 使用記錄，被處罰款 15000 元（頂格處罰）。 湖北孝感（2026年3月）：孝感新華派出所出動 10 餘名警力上門，當事人因使用 VPN 被處罰款 500 元。 上述案例幾乎全部援引同一法律依據：《計算機信息網絡國際聯網管理暫行規定》第六條和第十四條。\n執法中的問題 從這些案例中可以看出幾個值得注意的問題：\n選擇性執法。 中國的翻牆用戶保守估計有數千萬6，而公開可查的處罰案例僅數十起。這意味著絕大多數人並不會被追究，但任何人都有可能成為那個被追究的人——法規在這裡充當的不是普遍適用的規範，而是一把懸在頭頂的劍，什麼時候落下來取決於執法者的意志。這些年經濟增長放緩，地方財政壓力不斷增大，部分地區出現的「遠洋捕撈」便是這種選擇性執法最具諷刺性的寫照——欲加之罪，何患無辭？乖乖交出你的「違法所得」，老子的績效獎金終於有著落了。\n法律適用混亂。 不同地區對相同行為援引的法條不同：有的用《暫行規定》第六條，有的用《網絡安全法》第二十七條或第六十三條，有的甚至用《治安管理處罰法》中的條款。同一個行為在不同地方可能面對完全不同的法律評價，這本身就說明法律適用標準是混亂的。需要指出的是，中國是成文法國家而非判例法國家，法院判決不具有先例約束力，你在 A 地因翻牆被罰 500 元，在 B 地同樣的行為可能被罰 15000 元或者乾脆不被追究，而你無法援引 B 地的不追究來為自己在 A 地辯護。\n執法手段與違法程度不成比例。 湖北孝感案例中，出動 10 餘名警力處理一起最終罰款 500 元的行政違法行為——這種執法姿態更像是震懾而非正常的行政管理。\n援引其他口袋罪名。 部分案例中，翻牆本身的處罰微乎其微，但公安機關以此為切入點，進一步追查當事人在境外平臺上的言論，繼而以「尋釁滋事」等口袋罪追究刑事責任。翻牆在這裡成了援引其他口袋罪名的引子——處罰的不是翻牆本身，而是借翻牆的由頭處罰當事人的言論或政治立場。\n你能做什麼 說了這麼多，你可能會覺得：法律條文上不構成，但現實中還是有風險，那不就等於白說了？\n不，這是一份徵求意見稿，你現在擁有一個白紙黑字寫在法定程序裡的參與立法工作的渠道。\n提交立法意見 《辦法》目前處於公開徵求意見階段。根據《規章制定程序條例》第十五條，任何公民都有權對徵求意見稿提出意見。這不是恩賜，這是法定程序。你可以通過網信辦公佈的徵求意見渠道，正式提交你的意見——比如建議對「違法穿透、繞過」的表述增加更明確的構成要件界定，或者建議對「依法阻斷」做出程序性定義以防止概念被濫用。\n聯繫你的人大代表 《中華人民共和國憲法》第四十一條：\n中華人民共和國公民對於任何國家機關和國家工作人員，有提出批評和建議的權利。\n《中華人民共和國全國人民代表大會和地方各級人民代表大會代表法》第四條：\n代表應當與原選區選民或者原選舉單位保持密切聯繫，聽取和反映選民和選舉單位的意見和要求，努力為人民服務。\n你所在選區的區/縣人大代表有義務聽取你的意見，各區縣人大常委會官網通常會公佈代表名單及聯繫方式。找到你的代表，打個電話或者寫封信，告訴他們：\n你認為互聯網立法應當遵循明確性原則，模糊的條文不應成為選擇性執法的工具； 你支持依法治網，但反對以「依法」之名行「無法可依」之實； 你希望「被依法阻斷」這一概念在法律中獲得明確的程序性定義。 踐行社會主義核心價值觀，從聯繫你的人大代表開始。\nTL;DR 是技術性修法，該怎麼過日子以後還怎麼過，任何行為自己權衡風險，都散了吧。\n《互聯網信息服務管理辦法（修訂草案徵求意見稿）》全文及徵求意見公告可在國家互聯網信息辦公室官網查閱: https://www.cac.gov.cn/2025-04/15/c_1746821732498092.htm\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考《立法技術規範（試行）（二）》: https://npcobserver.com/wp-content/uploads/2023/02/Technical-Specifications-for-Legislation-for-Trial-Implementation-II.pdf\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n中國政府從未正式承認 GFW 的存在，也從未公佈過被封鎖網站的完整列表。2015 年國務院新聞發言人在回答外國記者提問時僅表示「中國依法管理互聯網」，但未指明具體的法律依據或封鎖清單。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n《計算機信息網絡國際聯網管理暫行規定》（1997年頒佈，2024年最新修訂）全文可參閱國務院官網: https://www.cac.gov.cn/1996-02/02/c_126468621.htm\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n王宇揚（2020年9月5日）通過裁判文書網和行政處罰信息公開平臺檢索，共找到 51 起相關案例。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGlobalWebIndex 在 2014 年的調查報告顯示中國 VPN 用戶約 9300 萬，約佔當時網民總數的 14%。考慮到此後網民總數持續增長且翻牆工具日益普及，當前實際用戶數只會更高。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2026-07-05T13:44:28Z","permalink":"/zh-hant-tw/2026/07/understanding-the-viral-cac-legislation/","title":"理解《互聯網信息服務管理辦法（修訂草案徵求意見稿）》——針對翻牆的一刀切要來了嗎？"},{"content":"點進這篇文章的人想必基本都對 DNS 洩露這一概念有所耳聞了，其中也不乏談 DNS 洩露色變者，由於評論區和 Issue 裡提出相關問題的人已經有數位，鄙人這次寫一篇說明，儘可能將這個問題講清楚，澄清一些大家對這個概念可能的誤解，也為各位編寫自己的代理配置提供一個參考。\n這個概念已經被一些 VPN 廠商和一大堆 YouTuber 講爛了，基本的意思是：當你在代理時，電腦卻通過本地網絡向本地 DNS 請求你正在訪問的網址，使得運營商可以依據你的 DNS 請求記錄得知你的瀏覽記錄。\nflowchart LR U[用戶設備瀏覽器 / App] --\u003e VPN[VPN 客戶端加密隧道] VPN --\u003e|正常情況：DNS 請求走 VPN| VPNDNS[VPN 提供的 DNS 服務器] VPNDNS --\u003e NET[目標網站 / 互聯網] U -.-\u003e|異常情況：DNS 洩露| ISP[本地 ISP DNS 服務器] ISP -.-\u003e LOG[ISP / 第三方可記錄訪問過的域名] NET --\u003e SITE[example.com] subgraph Normal[正常 DNS 解析路徑] VPN VPNDNS NET end subgraph Leak[DNS 洩露路徑] ISP LOG end classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000; classDef user fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1; class U user; class VPN,VPNDNS,NET,SITE safe; class ISP,LOG danger;搞清楚需求 首先需要想明白的是，我們煞費苦心地防止 DNS 洩露究竟是為了什麼——大家的第一反應可能都是：「那還用說！肯定是為了不讓審查者看到我們通過代理訪問了哪些網站啊！」\n其實這個說法並不完全準確，具體還得看情況。不妨想一想：讓審查者知道你在刷抖音、聊微信會有什麼實質性的危害嗎？恐怕沒有。但如果讓審查者發現你在訪問維基百科、瀏覽 X（推特）或者其他帶有明確政治傾向的敏感內容，那問題就有點大了。防止 DNS 洩露的目的，從來不是為了讓你在所謂的「DNS 洩露測試」網站上拿到一個全綠的滿分，也不是為了隱藏你使用國內常用服務的事實，而是為了不讓審查者知道你在訪問那些被封禁、被視為敏感的網站和服務。\n對於生活在牆內的我們來說，區分什麼是敏感內容其實非常簡單：直接參考 GFWList1 即可——能讓 GFW 專門將其重點關照的，自然就是敏感內容。\n那些 DNS 洩露測試的網站，測試用的隨機域名甚至連 GFWList 的邊都沾不上，本身就毫無敏感性可言。對於一些經過優化的正常代理配置來說，這類域名連看都不想多看一眼，通常會直接被略過並扔給最後的兜底規則（比如 MATCH, DIRECT）去處理，這個過程自然而然地觸發了本地 DNS 解析。於是，測試網站便如獲至寶般地亮起紅燈，警告你「存在 DNS 洩露」。但明白機制的我們自然清楚，很多時候這種所謂的洩露完全是無關痛癢的，只要配置得當，你真正需要保護的敏感訪問記錄，早就匹配到前面的分流規則被安全地送進加密隧道了。\n更有甚者，諸如 Surfshark、ExpressVPN 這類海外商業 VPN 廠商，以及一眾跟著恰飯的無良 YouTuber，成天拿這種毫無實際意義的測試結果製造隱私焦慮。可笑的是，這些傳統的商業 VPN 客戶端往往連最基礎的域名分流規則功能都不具備，全靠粗暴的一把梭將所有網絡請求強行塞進虛擬網卡。而更諷刺的是，即便是這種簡單粗暴的全局代理，他們過去還曾因為自身客戶端軟件的缺陷，真真切切地導致過 DNS 洩露問題。所以，與其聽信這些販賣焦慮的恰飯營銷，不如自己弄懂代理軟件的運作原理。\n出現洩露的環節 其實現在主流的代理軟件都比較成熟，配置得當完全不需要擔心 DNS 洩露的問題。問題出就出在很多配置根本就不得當。接下來我將會簡要地解釋代理軟件在系統代理模式和透明代理（虛擬網卡）模式下可能出現 DNS 洩露的環節。\n代理軟件本身 在使用系統代理的情況下（假設代理地址是socks5://127.0.0.1:78902）用瀏覽器訪問https://www.example.com，會經歷如下的請求過程：\n第一步：瀏覽器會把網絡請求打包發送給socks5://127.0.0.1:7890 第二步：代理軟件收到請求後根據配置的分流規則匹配節點 第三步：代理軟件根據匹配結果向節點轉發整個網絡請求 sequenceDiagram participant B as 瀏覽器 participant P as 代理軟件(127.0.0.1:7890) participant R as 分流規則引擎 participant N as 遠端代理節點 B-\u003e\u003eP: ① 將請求打包發送(攜帶域名, 不做 DNS 解析) Note over B,P: 瀏覽器不發起 DNS 查詢不會洩露 P-\u003e\u003eR: ② 根據域名等信息匹配分流規則 Note over P,R: 規則匹配過程可能觸發 DNS 查詢 ⚠️ R--\u003e\u003eP: 返回匹配結果(PROXY / DIRECT / REJECT) P-\u003e\u003eN: ③ 加密轉發請求至節點 Note over P,N: 加密隧道傳輸不會洩露 N--\u003e\u003eP: 返回響應 P--\u003e\u003eB: 返回響應在整個發起請求的過程中，瀏覽器將網絡請求打包交給代理，不會向本地 DNS 發出請求，這一環節不會產生 DNS 洩露；代理軟件將網絡請求轉發給服務器，整個過程加密，也不會產生 DNS 洩露；真正產生 DNS 洩露的環節，是根據分流規則匹配的過程。\n向本地 DNS 發起域名查詢這件事情本身並不一定是壞事，但配置不當的分流規則會讓代理軟件在拿到域名後過早地向本地 DNS 發起查詢，導致洩露不應洩露的隱私信息。假設在極端情況下，蓋世太保從運營商調取所有人的 DNS 查詢記錄，凡是查詢過域名包含 GFW 封鎖列表中的項目者都拉出去槍斃，在這種情況下，為了保全自身，我們需要恰當地配置分流規則。\n以使用廣泛的 Mihomo 內核為例，在作為客戶端開啟系統代理模式、使用 Chrome 進行到前文所述的第二步時，內核已知的信息有：\n主機3：example.com 目標端口：443 網絡協議：TCP 發起請求的進程的名稱和具體路徑：C:\\Application\\chrome.exe 入站 IP：127.0.0.1 入站名稱：DEFAULT-MIXED 入站端口：隨機的高位端口 內核不會進行多餘的 DNS 請求，根據已知的信息，內核可以在不發起 DNS 解析的情況下，匹配所有基於域名、端口、進程名稱以及網絡協議匹配的路由規則：\nrules: # 基於域名的匹配規則 - DOMAIN,ad.com,REJECT - DOMAIN-SUFFIX,google.com,auto - DOMAIN-KEYWORD,google,auto - DOMAIN-WILDCARD,*.google.com,auto - DOMAIN-REGEX,^abc.*com,PROXY - GEOSITE,youtube,PROXY # 基於端口的匹配規則 - DST-PORT,80,DIRECT - SRC-PORT,7777,DIRECT # 基於進程名稱的匹配規則 - PROCESS-PATH,/usr/bin/wget,PROXY - PROCESS-PATH,C:\\Application\\chrome.exe,PROXY - PROCESS-NAME,curl,PROXY - PROCESS-NAME,chrome.exe,PROXY # 基於網絡協議的匹配規則 - NETWORK,UDP,REJECT # 不依賴任何信息的匹配規則 - MATCH,DIRECT因此，上述這些種類的規則不會產生 DNS 洩露，因為內核匹配它們的時候根本沒必要發起 DNS 解析。\n對於剩下種類的規則，需要在第二步獲知目標 IP 信息才能讓匹配進行下去：\nrules: - GEOIP,cn,DIRECT - IP-CIDR,127.0.0.0/8,DIRECT - IP-SUFFIX,8.8.8.8/24,PROXY - IP-ASN,13335,DIRECT在默認情況下，為了確保匹配的準確性，進行到第二步時，內核不知道目標 IP，只知道目標主機地址www.example.com，此時內核不得不對www.example.com的 IP 地址進行查詢，這也就造成了 DNS 洩露。如果在規則的末尾加上no-resolve4，則匹配到基於 IP 的規則時會直接跳過，這就使得no-resolve很適合用來分流 Telegram 等軟件的裸 IP 請求。\n透明代理的問題（TUN 模式5） 透明代理顧名思義即被代理的系統/軟件感知不到自己被代理了的代理方式。這種方式非常省事，TUN 模式一開，所有軟件通通都能用，無須繁瑣的逐一配置不遵循系統代理的軟件。代價就是這種省事本身——目標系統/軟件都不知道自己被代理了，他們在正常網絡上該有的行為都會照常進行，其中自然也包括 DNS 解析，可是目標系統/軟件並不知道自己被代理了，他們想要和遠端建立連接，總得要先拿到一個 IP 才行吧。為了解決這個問題，以 Mihomo 為例，有兩種 DNS 劫持模式，redir-host和fake-ip。\nredir-host 模式：\nflowchart TD A1[目標軟件發起 DNS 查詢] --\u003e A2[代理軟件向上遊 DNS查詢真實 IP] A2 --\u003e A3[上游 DNS 返回真實 IP] A3 --\u003e A4[將真實 IP 返回給目標軟件] A4 --\u003e A5[目標軟件用真實 IP 建立連接] A5 --\u003e A6[代理軟件攔截並分流] A2 -.- LEAK[\"⚠️ 真實 DNS 請求洩露到外部網絡\"] classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000; class LEAK danger;fake-ip 模式：\nflowchart TD B1[目標軟件發起 DNS 查詢] --\u003e B2[代理軟件立即返回假 IP如 198.18.0.x] B2 --\u003e B3[目標軟件用假 IP 建立連接] B3 --\u003e B4[代理軟件攔截, 查映射表還原真實域名] B4 --\u003e B5[通過加密隧道轉發請求] classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; class B2,B4,B5 safe;其中redir-host比較老實，既然目標系統/軟件發起了 DNS 查詢，那就老老實實通過上游 DNS 去查，把查詢到的真實的 IP 返回給目標系統/軟件。由於這種模式下系統必定會發生一次真實的 DNS 解析請求尋址過程，存在著先天的結構性缺陷，不可避免地會造成 DNS 洩露。原來的 Clash 核心在後續的版本更新中乾脆直接砍掉了 redir-host 模式。\n不過，繼承了 Clash Meta 核心的 Mihomo 內核選擇了將其保留下來，並且加入了sniffer6對其進行增強。在redir-host模式下，sniffer依靠嗅探數據包中的特徵（比如從 TLS 的 SNI 字段7）嘗試將被解析成裸 IP 的流量恢復成連接域名，再用這個域名走一遍分流規則的匹配，補齊了redir-host模式在分流上的諸多短板。但需要特別注意：sniffer 解決的是分流準確性的問題，並不能消除 DNS 洩露本身——DNS 查詢請求在 sniffer 介入之前就已經發出去了，運營商該記錄的早就記錄了。\n但這裡需要提醒：如果你在透明代理環境下仍然堅持使用redir-host模式，就必須在配置一套無汙染的 DNS，具體的例子可以參考我的另一篇文章，否則你的 DNS 訪問記錄依然會洩露。\n相對而言，fake-ip模式則採用了截然不同的解決思路，不僅完美規避了透明代理環境下的 DNS 洩露問題，甚至還能順帶提升瀏覽器的網頁響應速度。\n如何規避 DNS 洩露 優化餵給代理軟件的分流規則 前面已經提到過，不當的分流規則會讓代理軟件過早地觸發解析。一個典型的反面例子如下：\nrules: - GEOIP,cn,DIRECT - GEOSITE,telegram,Telegram - GEOIP,telegram,Telegram - MATCH,Proxy問題出在第一條 GEOIP,cn,DIRECT。當設備請求 telegram.org 這個域名時，內核從上往下匹配，第一條就是個 IP 規則。可域名不是 IP，要判斷它到底落不落在中國大陸的網段裡，內核只能先把 telegram.org 拿去解析一遍。這一解析，DNS 查詢就發出去了——哪怕下面第二條 GEOSITE,telegram 本來能直接命中，根本用不著知道 IP。\nflowchart TD Start[請求 telegram.org] --\u003e Rule1{第 1 條GEOIP,cn?} Rule1 --\u003e Leak[⚠️ IP 規則遇上域名必須先解析 telegram.orgDNS 查詢就此洩露] Leak --\u003e Judge{解析出的 IP在中國大陸?} Judge -- 否 --\u003e Rule2{第 2 條GEOSITE,telegram?} Rule2 -- 是 --\u003e ProxyTG[走 Telegram 代理但 DNS 已經洩露了] classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000; class Leak danger;解析請求一旦發出，運營商那頭就記下了。後面命中哪條規則或者走不走代理都不重要，反正運營商已經知道你在訪問 Telegram。\n規則匹配自上而下順序進行，內核每收到一個請求就一條一條往下比，直到命中為止。換句話說，一個域名只要被前面的規則匹配到，後面的規則，第二條、第三條、哪怕第一千萬條，都不會再跑。\n正因如此，寫規則時要遵循域名規則在前，IP 規則在後的原則。就算是針對某個服務的專用規則集，也要給裡面靠前的 IP 規則加上 no-resolve 標記，告訴內核這條 IP 規則匹配不上就跳過，別去解析。一個典型的例子：\nDOMAIN-SUFFIX,e-hentai.org DOMAIN-SUFFIX,ehgt.org DOMAIN-SUFFIX,ehwiki.org DOMAIN-SUFFIX,exhentai.org DOMAIN-SUFFIX,hath.network DOMAIN-SUFFIX,hentaiverse.org IP-CIDR,178.175.128.0/21,no-resolve用 GeoSite 和 GeoIP 數據庫時同理，靠前的 IP 規則都要帶上 no-resolve。\nrules: - GEOSITE,telegram,Telegram - GEOIP,telegram,Telegram,no-resolve - GEOSITE,gfw,Proxy - GEOIP,cn,DIRECT - Match,Proxy把這套規則和前面的反面例子對照著看，差別就在 DNS 解析觸發的時機上：\nflowchart TD Start[請求 telegram.org] --\u003e Rule1{第 1 條GEOSITE,telegram?} Rule1 -- 是 --\u003e ProxyTG[走 Telegram 代理✅ 全程未解析] Rule1 -- 否 --\u003e Rule2{第 2 條GEOIP,telegram,no-resolve?} Rule2 -- 是僅匹配裸 IP 請求 --\u003e ProxyTG Rule2 -- 否 --\u003e Rule3{第 3 條GEOSITE,gfw?} Rule3 -- 是 --\u003e ProxyGFW[走 Proxy 代理✅ 全程未解析] Rule3 -- 否 --\u003e NeedIP[到這一步才需要 IP觸發本地 DNS 解析] NeedIP --\u003e Rule4{第 4 條GEOIP,cn?} Rule4 -- 是 --\u003e Direct[DIRECT 直連] Rule4 -- 否 --\u003e ProxyOther[Match,Proxy走 Proxy 代理] classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; classDef warn fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#8a4b00; class ProxyTG,ProxyGFW safe; class NeedIP warn;同樣是請求 telegram.org，這回第一條就是 GEOSITE,telegram，域名直接命中，請求甩給代理，全程沒碰 DNS。訪問其他掛在 GFW 列表上的網站也一樣，會先撞上 GEOSITE,gfw,Proxy，趕在那條非解析不可的 GEOIP,cn,DIRECT 之前就把請求送進了節點。該走代理的早早走了代理，靠後那些基於 IP 的規則壓根沒輪到執行，DNS 也就沒機會洩露出去。\n用 Fake-IP 規避透明代理問題 fake-ip 模式則解決了透明代理下的 DNS 洩露問題，還能順帶提升瀏覽器的網頁響應速度。\n在fake-ip模式下進行透明代理，當目標軟件發起 DNS 查詢時，代理軟件並不會傻乎乎地去本地或遠端上游查詢真實 IP，而是直接在本地瞬間返回一個假的內網保留 IP（例如198.18.0.28）。目標軟件拿到這個假 IP 後信以為真，緊接著就會拿著這個假 IP 嘗試建立連接。\n而在代理軟件這裡，它只需要攔截所有發往自己簽發過的這些假 IP 的請求即可。由於代理軟件內部維護了一張詳細的「假 IP 對應真實域名」的映射表，所以即便目標軟件發來的是往假 IP 發送的包，代理軟件依然心知肚明你其實想訪問的是什麼域名。於是，代理軟件直接提取出原始域名，將網絡請求順著加密代理隧道發往遠端節點去處理。\nsequenceDiagram participant App as 目標軟件(瀏覽器等) participant TUN as TUN 虛擬網卡 participant Proxy as 代理軟件(Mihomo) participant Node as 遠端代理節點 participant Web as 目標網站 App-\u003e\u003eTUN: DNS 查詢: google.com 的 IP 是? TUN-\u003e\u003eProxy: 轉發 DNS 查詢 Note over Proxy: 不向外部發起任何 DNS 請求!從 198.18.0.0/15 池中分配假 IP記錄映射: 198.18.0.5 → google.com Proxy--\u003e\u003eTUN: 返回假 IP: 198.18.0.5 TUN--\u003e\u003eApp: DNS 響應: 198.18.0.5 App-\u003e\u003eTUN: 連接 198.18.0.5:443 (HTTPS) TUN-\u003e\u003eProxy: 轉發連接請求 Note over Proxy: 查映射表:198.18.0.5 → google.com匹配分流規則 → PROXY Proxy-\u003e\u003eNode: 加密轉發: 請連接 google.com:443 Node-\u003e\u003eWeb: 建立真實連接 Web--\u003e\u003eNode: 返回網頁內容 Node--\u003e\u003eProxy: 加密回傳 Proxy--\u003e\u003eTUN: 返回內容 TUN--\u003e\u003eApp: 收到響應 Note over App,Web: 全程無真實 DNS 請求洩露到外部網絡 ✓這一機制解決了redir-host模式下透明代理必然會向外部網絡暴露域名查詢記錄的結構性缺陷。但必須指出的是，fake-ip僅僅是繞過了目標軟件發起 DNS 查詢時的洩露風險。正如前文所述，如果分流規則配置不當，代理內核自身依然會主動向上游發起真實的 DNS 解析，從而導致洩露。在分流規則配置妥當的前提下，fake-ip模式不僅能讓審查者無從窺探你的真實訪問目標，還能因為免去了本地設備等待 DNS 真實響應的時間，順帶大幅度降低網頁訪問的首字節加載延遲（TTFB9），可謂一石二鳥。\n太長不想讀（小結） DNS 洩露本身並不可怕，可怕的是不明就裡地被焦慮營銷牽著鼻子走。理解了機制之後，應對思路其實很清晰：\n系統代理模式：遵循「域名規則在前，IP 規則在後」的原則，為所有 IP 類規則加上 no-resolve，敏感域名在觸發 DNS 解析之前就已經被分流走了。 TUN 透明代理模式：優先選用 fake-ip，從根源上杜絕 DNS 查詢外洩，同時還能獲得更低的 TTFB。如果堅持使用 redir-host，必須搭配無汙染的上游 DNS，且要清楚 sniffer 只能改善分流準確性，無法阻止 DNS 請求本身的洩露。 不要迷信洩露測試網站：測試用的隨機域名根本不在 GFW 封鎖列表內，觸發本地解析是正常且無害的行為，綠燈與否不是衡量配置質量的標準。 被中國大陸防火長城（Great Firewall, GFW）封鎖的域名列表。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSOCKS5 是一種網絡代理協議（RFC 1928），工作在會話層，支持 TCP 和 UDP 轉發，且允許客戶端將域名直接傳遞給代理服務器解析，而非在本地解析後再連接——這正是它在防止 DNS 洩露方面優於普通 HTTP 代理（非 CONNECT 隧道模式）的關鍵特性。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n可以理解為域名。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nno-resolve 是附加在 IP 類規則末尾的標記，作用是告訴內核：當流量的目標是域名而非 IP 時，跳過此規則，不要為了匹配它而主動發起 DNS 解析。但如果流量本身就是直接連接 IP（如 Telegram 客戶端直連服務器 IP），則該規則仍然會正常參與匹配。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n也就是我們所說的虛擬網卡模式\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n流量嗅探（Sniffer）是指代理軟件通過檢查數據包的協議特徵來還原目標域名的技術。例如，HTTPS 連接在握手階段會以明文發送目標域名（即 SNI），HTTP 請求頭中也包含 Host 字段，代理軟件可以從這些特徵中提取出真實的目標域名。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nServer Name Indication，TLS 協議的擴展字段。由於同一 IP 上可能託管多個 HTTPS 站點，客戶端在 TLS 握手的 ClientHello 階段需要以明文告知服務器自己要訪問哪個域名，以便服務器返回正確的證書。這也是為什麼即使使用了 HTTPS，中間人仍然能看到你訪問的域名（但看不到具體路徑和內容）。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMihomo 默認使用 198.18.0.0/15 地址段分配假 IP。該地址段由 IANA 在 RFC 2544 中保留，專門用於網絡設備基準測試，不會出現在正常的互聯網路由表中，因此不會與任何真實的公網地址衝突。整個 /15 段可提供約 131,072 個地址供映射使用。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTime To First Byte，即從客戶端發出請求到收到服務器響應第一個字節所經過的時間。在傳統模式下，瀏覽器需要先等待 DNS 解析完成（通常耗時 20-120ms）才能發起 TCP 連接；而 fake-ip 模式下 DNS 響應幾乎是瞬時的（\u0026lt;1ms），因此能顯著縮短整體的頁面加載時間。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2026-05-17T16:46:00Z","permalink":"/zh-hant-tw/2026/05/dns-leak-misunderstanding/","title":"關於 DNS 洩露及其相關誤解的說明"},{"content":"Terraform 是一款 IaC 工具，所謂 IaC 就是「基礎設施即代碼」，將我們的基礎設施以聲明式的代碼寫出來，隨後使用terraform apply即可完成基礎設施的部署，同一份配置，部署出來的一定是一模一樣的基礎設施（Nix OS 用戶狂喜）。\n為什麼要用 Terraform 傳統的基礎設施管理絕大部分基於人力和各種雲服務商的 Dashboard，這就帶來了下面這些痛點：\n痛點 說明 難以重現 通過 Dashboard 點點點進行配置，容易改錯或者改漏，而且難以復現 環境漂移 手動操作導致生產和測試環境配置逐漸偏離，導致極端情況下測試沒問題生產直接崩 難以擴展 新增一套環境需要重複大量手工操作，耗時且容易出錯 難以審計 沒有變更記錄，出了事不好甩鍋 難以協作 基礎設施由少數「懂的人」掌控，誰想要改都得去找這些人，效率低 為了解決這些問題，「基礎設施即代碼」1的概念被提了出來，Terraform 就是其中一個著名的解決方案。\n假設一個現實的使用場景，例如你每年都會購買新的 GCP 的 $300 試用金賬號，雖然便宜，但是每年都要重新跑到 GCP 的面板裡開機器。而有了 Terraform，想要部署同樣配置的機器，只要在每次更換賬號之後，將 API Token 替換成新的，隨後terraform apply，只需要幾分鐘就能開出和你上個賬號一模一樣的機器、VPC、S3、防火牆配置等等。\n再比如 Cloudflare DNS 和 Tunnel 的管理和遷移，也只需要將原 Tunnel 的 Ingress Rule 複製到新 Tunnel 的 Ingress Rule。即使將來要遷移到 AliDNS、Route 53 等其他服務商，我們也可以原封不動的將數據複製過去2。\n尤其是到了多人協作的時候，配合 Git，每次更改都有跡可循，更不需要擔心合併衝突，PR 可以自動生成更改預覽，出現問題可以立刻回滾到上一個版本，這些都是傳統依賴人力去直接操作服務提供商 Dashboard 的做法完全無法做到的。\nTerraform 的安裝 Terraform 是用 Go 寫的，編譯出來的產物自然也是單個可執行文件，所以安裝起來也非常容易，Windows 下可以直接使用 Winget 安裝：\nwinget install Hashicorp.Terraform如果不想使用 Winget，也可以使用 Scoop 等其他包管理器，或者將預編譯的二進制文件放入$PATH，即可完成安裝。\n如果你在 Linux 環境下，則使用對應的包管理器安裝即可，如果使用將二進制文件放入$PATH的安裝方法，則要記得sudo chmod +x terraform賦予文件的執行權限。\nTerraform 的兩個基本概念 Provider(s) 我們前面已經提到，Terraform 是一個款礎設施即代碼工具，作為一個工具本身，他並不綁定某個平臺，而是通過 Provider(s) 與各個平臺對接，要查看有哪些 Provider(s)，可以瀏覽 Terraform 的 Registry。\n狀態管理 Terraform 將每次執行基礎設施變更操作時的狀態信息保存在一個狀態文件中，默認情況下會保存在當前工作目錄下的terraform.tfstate文件裡3，我們也可以修改配置文件自行指定其他的存儲後端，例如 S3、Postgres。每次我們執行terraform apply時，Terraform 都會將目前配置文件聲明的狀態同現有的狀態文件進行比對，從而計算變動的部分，自動確定調整順序之後操作 Provider 落實狀態變動。\nTerraform 的資源導入難題 現有資源的導入一直是 Terraform 為人詬病的難題，Hashi Corp. 似乎一直在堅持著一個固執且愚蠢的觀點：你所有的基礎設施從一開始就應當是用我們的 Terraform 創建的，所以也不存在什麼資源導入的問題。\n時間 版本 進展 問題 2014–2022 v0.x–v1.4 只有 terraform import，一次一條，而且完全不生成配置 導入完還得自己手寫 HCL4 2023.06 v1.5 引入 import 塊和 -generate-config-out參數，可以生成配置了 然而還是得一條一條寫，而且還得自己提供現有資源的 ID 2024.01 v1.7 import 塊支持 for_each 批量了，但 ID 還得自己搞 2024 下半年 v1.12 引入了 terraform query 和 list 塊，終於實現了自動發現資源的功能 然而這個功能要 Provider 要自己實現，大量 Provider 根本沒跟上 這麼多年的時間，社區一直在罵，然而，「我有一堆現有資源，怎麼導入 Terraform」這個問題一直沒有被認真對待。Terraform 作為「基礎設施即代碼」工具，設計哲學就是聲明式和冪等性5，Hashi Corp. 他們篤信「一切以代碼聲明的狀態為準，就應該用 Terraform 從零開始創建資源」。但現實是絕大多數公司都有大量歷史存量資源，先有資源、後有代碼才是常態。這個矛盾 Hashi Corp. 承認得很晚，v1.12 的 terraform query 才算是官方第一次認真面對這個問題——但 Provider 生態的跟進嘛……真的是一言難盡。\nTerraform 的文件結構 Terraform 的文件結構很簡單，其主程序運行時會無腦讀取工作目錄下所有的.tf文件，只要信息齊全，想給文件取什麼名字都可以，比如我的文件結構就長這樣：\n❯ tree -a -I .git . ├── .editorconfig ├── .github │ ├── dependabot.yml │ └── workflows │ ├── terraform-apply.yml │ ├── terraform-plan.yml │ └── your-fork.yml ├── .gitignore ├── .terraform.lock.hcl ├── cf_dns_zones.tf ├── cf_tunnel.tf ├── dns_example_com.tf ├── dns_example_net.tf ├── dns_example_top.tf ├── dns_example_cn.tf ├── main.tf # 基礎配置（terraform 塊） ├── moved.tf # 移動過的資源 ├── provider.tf # 每個 Provider 的配置 ├── README.md ├── rename_resources.ps1 └── variables.tf # 自定義的變量main.tf用於存放基礎配置:\nterraform { required_providers { cloudflare = { source = \"cloudflare/cloudflare\" version = \"~\u003e 5\" } tencentcloud = { source = \"tencentcloudstack/tencentcloud\" version = \"\u003e= 1.81.43\" } } }provider.tf用於存放每個 Provider 的配置：\nprovider \"cloudflare\" {} provider \"tencentcloud\" {}這裡留空是因為我們可以通過環境變量來傳遞 Credentials，而不是直接將 Credentials 寫在配置文件中，例如 Cloudflare 的 Provider 就接受CLOUDFLARE_API_TOKEN作為api_token這個變量的替代。\nvariables.tf用於聲明自定義的變量：\nvariable \"cloudflare_zone_example_com\" { description = \"Cloudflare zone ID for example.com\" type = string } variable \"cloudflare_zone_example_top\" { description = \"Cloudflare zone ID for example.top\" type = string }這些變量可以通過前綴為TF_VAR_的環境變量傳入，Terraform 也會自動讀取terraform.tfvars文件中的變量，變量的主要用途是在別的配置文件中調用，例如：\nresource \"cloudflare_dns_record\" \"example_cname\" { content = \"${cloudflare_zero_trust_tunnel_cloudflared.Production_Tunnel.id}.cfargotunnel.com\" name = \"example.example.com\" proxied = true tags = [] ttl = 1 type = \"CNAME\" zone_id = var.cloudflare_zone_id_example_com #這裡調用了cloudflare_zone_example_com這個變量 settings = { flatten_cname = false } }有了這些基礎配置，我們就可以運行terraform init初始化 Terraform 環境並鎖定依賴版本，剩下的就都是我們資源的聲明瞭。\n將現有資源導入 Terraform 前文提到過 Terraform 的狀態管理這個概念，狀態管理雖好，但在我們初始化時也帶來了一個問題——在默認狀態下，Terraform 的狀態文件顯然是空的。\n此時我們需要做的是將雲服務提供商上現有資源的狀態導入 Terraform，這樣 Terraform 才能無縫接手並管理我們的基礎設施。相信大家也都看到了前文對 Terraform 資源導入問題的吐槽。以導入 Cloudflare 上託管的 DNS 記錄為例，前文提到過，如果 Provider 支持，可以使用 Terraform 在 1.12 版本之後引入的terraform query，然而大多數情況下，Providers 都是沒有跟進這個新功能的，Cloudflare 就屬於不支持的那一類。\n好在雖然 Hashi Corp. 不認真解決問題，各路高強度使用 Terraform 管理基礎設施的公司就各顯神通。Cloudflare 就維護了名為 cf-terraforming 的導入工具，免去了很多手動導入的麻煩。首先安裝cf-terraforming，這個工具是用 Go 語言編寫的，需要在有 Go 語言環境的情況下安裝，或者將官方編譯好的二進制文件其放入$PATH並賦予其執行權限。\ngo install github.com/cloudflare/cf-terraforming/cmd/cf-terraforming@latest這個工具的用法還是比較簡單的，首先你需要以下環境變量：\n# 如果你使用 API Token export CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j' # 如果你使用 API Key export CLOUDFLARE_EMAIL='user@example.com' export CLOUDFLARE_API_KEY='1150bed3f45247b99f7db9696fffa17cbx9' # 指定需要導入的域名的區域 ID，如果導入的是賬戶資源（例如 Cloudflare Tunnel）則不需要 export CLOUDFLARE_ZONE_ID='81b06ss3228f488fh84e5e993c2dc17' 💡 提示 此處的命令假設你正在使用 Bash，如果使用的是與 Bash 語法不兼容的 Shell，則需要做出調整，例如對於 Windows 上的 PowerShell，導入環境變量的語法如下：\n$env:CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j' 通常我們只需要設置CLOUDFLARE_API_TOKEN和CLOUDFLARE_ZONE_ID就可以了，在控制檯創建 API Token 時，記得賦予這個 Token 必要的權限，本次我們只是導入 DNS 記錄，所以只賦予編輯區域 DNS 的權限即可。\n好了，準備工作全部完成，現在可以開始生成配置文件：\n首先導入賬戶中域名的配置，也就是cloudflare_zone：\ncf-terraforming generate \\ --key $CLOUDFLARE_API_KEY \\ --resource-type \"cloudflare_zone\" \u003e zone.tf這一步會在當前目錄下生成一個名為zone.tf的文件，裡面會有如下格式的內容：\nresource \"cloudflare_zone\" \"REDACTED\" { name = \"REDACTED\" paused = false type = \"full\" vanity_name_servers = [] account = { id = \"REDACTED\" name = \"REDACTED\" } } resource \"cloudflare_zone\" \"REDACTED\" { name = \"REDACTED\" paused = false type = \"full\" vanity_name_servers = [] account = { id = \"REDACTED\" name = \"REDACTED\" } }現在域名資源已經導入了，但是裡面的配置並沒有。接下來，導入域名下的 DNS 記錄：\ncf-terraforming generate \\ --zone $CLOUDFLARE_ZONE_ID \\ --key $CLOUDFLARE_API_KEY \\ --resource-type \"cloudflare_dns_record\" \u003e\u003e dns.tf這一步會在當前目錄下生成一個名為dns.tf的配置文件，裡面會有如下格式的內容：\nresource \"cloudflare_dns_record\" \"terraform_managed_resource_5deb14xxxxxb629bf123xxxxxxxc8f_0\" { content = \"67.24.33.108\" name = \"example.example.com\" proxied = true tags = [] ttl = 1 type = \"A\" zone_id = \"81c7f2de8dfxxxxxx52629xxxxxxfc\" settings = {} } resource \"cloudflare_dns_record\" \"terraform_managed_resource_89xxxxx0bf9cxxxxxx9a_1\" { content = \"35.27.108.33\" name = \"terraform.example.com\" proxied = true tags = [] ttl = 1 type = \"A\" zone_id = \"8xxxxxx7644e428526xxxxxx\" settings = {} }如果有多個域名需要導入，則多次分別設置環境變量CLOUDFLARE_ZONE_ID再重複運行命令即可。\n這裡生成的配置文件可以直接使用，也就是我們之後需要的 Terraform 配置文件。然而，此時我們僅僅只是生成了配置文件，但是目前 Terraform 的狀態依然是空的，這時要是直接terraform apply，Terraform 會不管三七二十一將我們剛剛導入的聲明一律視為新增資源，然後甩出一大堆「Alredy Exists」報錯。所以接下來，我們需要將生成的配置文件導入 Terraform 的terraform.tfstate狀態。\nTerraform 在 1.5 版本引入了import塊，相比以往一行一行輸入命令的方式更加現代。其導入流程是先生成一個包含import塊的.tf文件，下次進行terraform apply時，Terraform 就會自動為我們執行導入操作。\n生成cloudflare_zone的import塊：\ncf-terraforming import \\ --resource-type \"cloudflare_zone\" \\ --modern-import-block \\ --key $CLOUDFLARE_API_KEY \\ --zone $CLOUDFLARE_ZONE_ID \u003e\u003e import.tf生成cloudflare_dns_record的import塊：\ncf-terraforming import \\ --resource-type \"cloudflare_dns_record\" \\ --modern-import-block \\ --key $CLOUDFLARE_API_KEY \\ --zone $CLOUDFLARE_ZONE_ID \u003e\u003e import.tf這一步會在當前目錄下生成import.tf，它包含了所需要的導入信息，作用就是告訴 Terraform 上一步生成的每個resource塊到底對應的是哪一個雲服務提供商的資源 ID。這個 ID 是雲服務提供商內部標記資源的代碼，平常是不會在控制面板上顯示的，只有在用 API 特別請求時才會知道。Terraform 在導入過程中需要用到這個 ID 以確認本地的定義對應的雲端資源，以實現嚴格的冪等性。\n好了，現在我們運行terraform plan：\n$ terraform plan cloudflare_dns_record.minio_a: Refreshing state... [id=xxxxxxxxxxx53] cloudflare_zero_trust_tunnel_cloudflared_config.raspberrypi: Refreshing state... ...... Terraform will perform the following actions: # cloudflare_dns_record.terraform_managed_resource_0 will be imported resource \"cloudflare_dns_record\" \"terraform_managed_resource_REDACTED_0\" { content = \"67.24.33.108\" created_on = \"2026-04-08T10:18:12Z\" id = \"5deb14c21xxxxxxx20f1c8f\" meta = jsonencode({}) modified_on = \"2026-04-08T10:18:12Z\" name = \"example.example.com\" proxiable = true proxied = true settings = {} tags = [] ttl = 1 type = \"A\" zone_id = \"REDACTED\" } # cloudflare_dns_record.terraform_managed_resource_1 will be imported resource \"cloudflare_dns_record\" \"terraform_managed_resource_89c149exxxxxxxxxxxba13xxxxxa_1\" { content = \"35.27.108.33\" created_on = \"2026-04-08T10:17:54Z\" id = \"89cxxxxxxxxxxxxxxxxxx09a\" meta = jsonencode({}) modified_on = \"2026-04-08T10:17:54Z\" name = \"terraform.example.com\" proxiable = true proxied = true settings = {} tags = [] ttl = 1 type = \"A\" zone_id = \"81xxxxxxxxxxxxxxxxxxxxxfc\" } Plan: 2 to import, 0 to add, 0 to change, 0 to destroy. ──────────────────────────────────────────────────────────────────────────────────────────────────────── Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run \"terraform apply\" now.如果需要 Add、Change 和 Destroy 的資源數量都是 0，說明我們的導入操作沒有問題，直接terraform apply --auto-approve，資源就導入完成了。\n$ terraform apply --auto-approve cloudflare_dns_record.push_a: Refreshing state... [id=REDACTED] Terraform will perform the following actions: # cloudflare_dns_record.terraform_managed_resource_REDACTED_0 will be imported resource \"cloudflare_dns_record\" \"terraform_managed_resource_REDACTED_0\" { content = \"67.24.33.108\" created_on = \"2026-04-08T10:18:12Z\" id = \"REDACTED\" meta = jsonencode({}) modified_on = \"2026-04-08T10:18:12Z\" name = \"example.example.com\" proxiable = true proxied = true settings = {} tags = [] ttl = 1 type = \"A\" zone_id = \"REDACTED\" } # cloudflare_dns_record.terraform_managed_resource_REDACTED_1 will be imported resource \"cloudflare_dns_record\" \"terraform_managed_resource_REDACTED_1\" { content = \"35.27.108.33\" created_on = \"2026-04-08T10:17:54Z\" id = \"REDACTED\" meta = jsonencode({}) modified_on = \"2026-04-08T10:17:54Z\" name = \"terraform.example.com\" proxiable = true proxied = true settings = {} tags = [] ttl = 1 type = \"A\" zone_id = \"REDACTED\" } Plan: 2 to import, 0 to add, 0 to change, 0 to destroy. cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Importing... [id=REDACTED/REDACTED] cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Import complete [id=REDACTED/REDACTED] cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Importing... [id=REDACTED/REDACTED] cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Import complete [id=REDACTED/REDACTED] Apply complete! Resources: 2 imported, 0 added, 0 changed, 0 destroyed.狀態存儲和持續集成 IaC 的核心價值之一就在於可以輕易實現基於 Git 的多人協作，以及 CI 的持續集成，但是在此之前，又有一個新的問題需要解決——terraform.tfstate到底放哪裡：沒人想要換一次環境辛辛苦苦導入的狀態就丟一次。\nTerraform 目前支持以下幾種保存狀態的後端：\nlocal remote azurerm consul cos gcs http Kubernetes oci oss pg s3 沒有特殊需求可以像我一樣選擇s3，畢竟 Cloudflare R2 有免費額度，不用白不用。\nterraform { backend \"s3\" { bucket = \"terraform\" key = \"terraform.tfstate\" region = \"auto\" endpoints = { s3 = \"https://REDACTED.r2.cloudflarestorage.com\" } # R2 不需要這些 AWS 的驗證 skip_credentials_validation = true skip_metadata_api_check = true skip_region_validation = true skip_requesting_account_id = true use_path_style = true } }對於 S3 的後端，建議用AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY兩個環境變量來存儲 Credentials：\nexport AWS_ACCESS_KEY_ID='REDACTED' export AWS_SECRET_ACCESS_KEY='REDACTED'配置完成，運行terraform init -migrate-state，配置就成功存儲到雲上了，以後不論在何處修改配置、運行terraform apply都無須擔心 Terraform 的 State 不同步的問題。\n接下來就是 Github CI 的配置，其實很簡單，無非就是每次git push時觸發一次terraform init、terraform fmt和terraform apply，以下是我的.github/workflows/apply.yml：\nname: \"Terraform Apply\" on: push: branches: - main env: TF_IN_AUTOMATION: \"true\" CLOUDFLARE_API_TOKEN: \"${{ secrets.CLOUDFLARE_API_TOKEN }}\" AWS_ACCESS_KEY_ID: \"${{ secrets.AWS_ACCESS_KEY_ID }}\" AWS_SECRET_ACCESS_KEY: \"${{ secrets.AWS_SECRET_ACCESS_KEY }}\" TF_VAR_cloudflare_zone_id_example_com: \"${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}\" TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }} jobs: terraform: name: \"Terraform Apply\" runs-on: ubuntu-latest permissions: contents: read concurrency: group: terraform-apply cancel-in-progress: false steps: - name: Checkout uses: actions/checkout@v6 - name: Setup Terraform uses: hashicorp/setup-terraform@v4 - name: Terraform Init run: terraform init -input=false - name: Terraform Apply run: terraform apply -input=false -auto-approve對於 PR 則應當讓 CI 自動為每次 PR 附上terraform plan的輸出：\nname: Terraform Plan on: pull_request: paths: - \"**/*.tf\" - \".github/workflows/terraform-plan.yml\" permissions: contents: read pull-requests: write env: TF_IN_AUTOMATION: \"true\" CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} TF_VAR_cloudflare_zone_id_example_com: \"${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}\" TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }} jobs: plan: name: Terraform Plan runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: hashicorp/setup-terraform@v4 - name: Terraform fmt id: fmt run: terraform fmt -check -recursive continue-on-error: true - name: Terraform Init id: init run: terraform init -input=false - name: Terraform Validate id: validate run: terraform validate -no-color - name: Terraform Plan id: plan run: terraform plan -input=false -no-color continue-on-error: true - name: Post Plan to PR uses: actions/github-script@v8 with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | const { data: comments } = await github.rest.issues.listComments({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, }); const botComment = comments.find(c =\u003e c.user.type === 'Bot' \u0026\u0026 c.body.includes('') ); const planOutput = `${{ steps.plan.outputs.stdout }}`.substring(0, 65000); const body = ` #### Terraform Plan | Step | Result | | -------- | --------------------------------- | | fmt | \\`${{ steps.fmt.outcome }}\\` | | init | \\`${{ steps.init.outcome }}\\` | | validate | \\`${{ steps.validate.outcome }}\\` | | plan | \\`${{ steps.plan.outcome }}\\` | 展開 Plan 詳情 \\`\\`\\`terraform ${planOutput} \\`\\`\\` `; if (botComment) { await github.rest.issues.updateComment({ owner: context.repo.owner, repo: context.repo.repo, comment_id: botComment.id, body }); } else { await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body }); } - name: Fail if plan failed if: steps.plan.outcome == 'failure' run: exit 1 後續的工作流程 到這一步，Terraform 的「接管初始化」已經結束了，後面就進入了日常維護階段。這個階段其實就三件事：\n創建新資源 修改現有的資源 刪除不再需要的資源 常用的操作就兩個：terraform plan和terraform apply，如果是個人使用，小的改動直接提交就算了；如果是團隊協作，每次修改則應當遵循能 PR 就不直接 Commit 的原則。\n創建基礎設施 假設你現在要新增一條 DNS 記錄，或者新建一個 Tunnel、一個對象存儲桶，流程如下：\nflowchart TD C1[新建分支 如 feat/add-minio-record] --\u003e C2[新增 resource 塊] C2 --\u003e C3[terraform fmt + validate] C3 --\u003e C4[terraform plan] C4 --\u003e C5{僅新增預期資源?} C5 -- 否 --\u003e C6[修正配置後重跑 plan] C6 --\u003e C4 C5 -- 是 --\u003e C7[提交 PR] C7 --\u003e C8[合併後 CI apply]最理想的plan輸出是：\nX to add 0 to change 0 to destroy 如果你只是想加東西，結果出現了to destroy，那就先別衝動，通常是引用寫錯、變量搞錯，或者不小心改了資源地址，仔細檢查是什麼地方出了問題。\n修改與刪除基礎設施 修改流程和創建類似，但要多一步——評估變更是否會觸發重建。\n因為很多 Provider 字段是ForceNew，你以為只是改個字段，Terraform 看完說：「好的，刪了重建。」這在我們修改 DNS 的這個場景並不是什麼很大的問題，但是到了雲實例這種資源，如果刪除重建勢必會造成損失。\n建議按下面這個順序來：\nflowchart TD M1[修改 .tf] --\u003e M2[terraform plan] M2 --\u003e M3{出現 replace/destroy?} M3 -- 否 --\u003e M7[確認影響範圍] M7 --\u003e M8[terraform apply] M3 -- 是 --\u003e M4[暫停並複核變更] M4 --\u003e M5[必要時加 lifecycle 保護] M5 --\u003e M6[安排變更窗口] M6 --\u003e M8對生產環境來說，創建、修改得慢一點並不是什麼很大的問題，最應當看重的是操作的正確性，慢一點，不要出錯。IaC 不是比手速，IaC 比的是可預期性。\n如果是刪除資源（比如下線某個 DNS 記錄、清理廢棄 Tunnel），走下面這個流程6：\nflowchart TD D1[確認資源已廢棄 檢查業務/監控/腳本依賴] --\u003e D2[刪除 resource 塊或調整 count/for_each] D2 --\u003e D3[terraform plan] D3 --\u003e D4{to destroy 是否符合預期?} D4 -- 否 --\u003e D5[回滾修改並繼續排查依賴] D5 --\u003e D1 D4 -- 是 --\u003e D6[準備回滾方案並選低峰窗口] D6 --\u003e D7[PR 審核通過] D7 --\u003e D8[terraform apply] D8 --\u003e D9[刪除資源後的可用性檢查]日常協作建議 把 Credentials 放環境變量或 CI Secret，別寫進.tf和倉庫 對關鍵資源開啟保護策略，防止誤刪 將目錄按資源類型拆分 定期執行terraform plan做基礎設施漂移檢查7和校正，避免在面板誤操作手動修改 雖然這套流程看起來很麻煩，但每一次變更都有記錄、可審計、可回滾，最重要的是可復現，這才是 IaC 最有價值的地方。\n參考 使用 Terraform 管理 CloudFlare 上的 DNS 解析記錄 - Candinya Automate Terraform with GitHub Actions Query configuration files list block reference cloudflare/cf-terraforming Import Cloudflare resources Cloudflare Provider - Terraform Registry Infrastructure as Code，是指採用機器可讀的配置文件定義所需要的基礎設施的部署方法。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n每個供應商的配置文件字段命名和格式都有區別，但這可以很容易的編寫腳本進行轉換。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n需要特別注意的是，狀態文件中可能包含數據庫密碼、API 密鑰等明文存儲的敏感信息，因此絕對不要將 .tfstate 文件提交到公開的代碼倉庫中。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHashiCorp Configuration Language，HashiCorp 自家開發的一種聲明式配置語言，旨在兼顧機器可讀性與人類可讀性。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n冪等性（Idempotence）指計算機系統或接口在接收到同一請求的多次操作時，產生的影響與一次執行的結果相同，不論執行多少次，系統的最終狀態始終保持一致。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n如果你僅僅是想讓 Terraform 不再管理某個資源，而不是真正在雲端銷燬它，應該使用 terraform state rm 命令，而不是在代碼中刪掉資源塊然後 apply，否則雲環境上的真實資源也會被一併銷燬。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n基礎設施漂移（Infrastructure Drift）是指現實中通過控制檯點按等非 IaC 途徑修改了基礎設施，導致其實際狀態與代碼中聲明的狀態不一致的情況。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2026-04-09T07:13:35Z","image":"/2026/04/iac-with-terraform/cover_hu_a8e83f97ed61569c.webp","permalink":"/zh-hant-tw/2026/04/iac-with-terraform/","title":"Terraform IaC 初體驗"},{"content":"工作，工作，至死方休。\n寒假給別人上課，幾乎就沒有停過，春節名義上休息，也只不過是換了一種形式工作罷了——各種應酬，舟車勞頓，回家剛安頓好，又馬不停蹄的投入到上課工作中去。給別人上課也真是不容易，跟我在同一家機構當助教的同學一起交流時，大家都戲稱上課就是「赤石」：死記硬背的是記不住的，算數是不會算的，概念是混淆的，交流是沒辦法正常交流的。這倒也不怪他們，要怪也只能怪他們經歷過的教育環境，畢竟家家有本難唸的經。各種原因導致他們基本上走的都是高職單招，沒有經過高考的洗禮，有的甚至連初中都沒怎麼讀好，現在也只是想找個工作，所以才願意花錢請我們來給他們上一對一課程。\n一開始我在一家機構做助教，後來出來單幹，提高了部分收入，還節省了部分備課的時間。每天的上課是從7:30-11:00,價格是 ¥400。看似時薪過百比較高，實則結合學生的基礎狀況考慮，這錢我是賺得問心無愧，甚至我可以說，這錢真賺得也是不容易。\n回到正題，現在開學了，我又要馬不停蹄的投入到我自己的學業事務中去。真的感覺自己永遠都在忙，所謂的休息，也只不過是換點輕鬆的事情做一做罷了，教學教累了回家就 Vibe Coding 放鬆一下，坐在電腦前煩躁了就把家裡收拾一下打掃衛生。在做事情的動力、以及人的有限總精力這方面，我能真切的感受到人與人之間的差距：有的人天賦異稟，精力非常充沛，成果做了一個又一個，論文發了一篇又一篇，產出很高，好像制約他們的永遠都是時間，而不是他們的精力和動力；而更多人則是像我一樣的凡人，即使想要這種生活狀態，卻也還是心有餘而力不足，可是看到前面一類人的高產，又難免心生焦慮，只能在最大限度下把自己當成一個實際永動機1。\n從小到大接受的中式教育異化了我們，那句湯家鳳經典的「你這個年紀怎麼睡得著的」，雖然本意是訓斥上課睡覺的學生，卻也在某種程度上潛移默化影響著我們這一代，以至於到了一種病態的狀態。人生沒有絕對的「上岸」，小學要去上小升初的岸，初中要去上中考的岸，高中要去上高考的岸，大學要去上考研、讀博、考公、找工作的岸，完成學業參加工作了，還有各種升遷績效、柴米油鹽需要考慮。工作，工作，至死方休。想要上岸而一勞永逸嗎，不好意思，那是不可能的。\n雖然深知這一點，我還是會停下來休息就空虛難受，所以，永遠忙碌，永遠工作。滿足自己身體需要的休息，用鍛鍊身體平衡自己的內分泌，休息就是換一件自己喜歡且比較輕鬆的事情做，由於受中式教育、績優主義的影響太深，這種生活狀態，我想在很長一段時間裡是不會改變了。\n不過往好的方面看，通過這段時間的忙碌，我也是自己把自己這個學期的生活費給賺出來了，還有富餘給我媽準備一臺新手機當生日禮物。突然也覺得，永遠忙碌這件事，好像也沒這麼糟。\n這裡是用理想電流源和實際電流源的區別來類比所謂「理想永動機」和實際永動機的區別——前者是真正意義上的永動機，後者則是我等凡夫俗子用血肉之軀拼勁全力去接近的「實際永動機」\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2026-03-13T15:14:26Z","permalink":"/zh-hant-tw/2026/03/busy-for-eternity/","title":"永遠忙碌"},{"content":"最近在某家民營電網培訓機構給準備國網二批考試的學生一對一輔導，每天晚上上課三個半小時，給 200。\n這家機構給我的錢偏少還不是最嚴重的問題。問題出在他們給學生的收費上：有兩種方案，一種是所謂「卓越計劃」，收費 12 萬，但是一對一課程不限量；另一種是「協議班」，收費 7 萬，但每次上一對一課程要交 450。\n昨天給他們一學生私下開小灶，下午上課三個半小時，本來我想著既然私下找我，那就不經過這個培訓機構，學生直接給我結款 300——我能多賺一百，ta 能少花 150。結果那個學生腦子沒轉過彎，找班主任請假的時候竟然說要找我補課，於是他們就直接「善意地」幫我找家長收了 450。\n這還沒完。最後給我算工時，他們把這次課歸為所謂「額外課時」，說我違規利用了下午的「備課時間」給非卓越計劃的學生上課——三個半小時，只給了 120。\n簡而言之：\n學生付 450 → 機構抽走 330 → 我拿到 120\n本該到我手上的 300 變成了 120，我自然是不爽。但比起我個人少拿的那一百多塊錢，更讓我不舒服的是這件事本身的性質。這些考國網二批的學生很多都是家境不太富裕的專科生，他們平日裡已經飽受歧視，想盡一切辦法想要改變命運，現在下了血本，花上可能是他們一個家庭一年收入的幾萬甚至十幾萬來讀這個國網課程。他們以為自己買的是一劑改命的「藥」，殊不知這藥引子是用自己的血和著吃的——而我辛苦勞動輔導學生，分到手裡的錢佔比卻比坐享其成的培訓機構還要低。\n這根本就是在吃人血饅頭。\n這一單，機構躺著淨賺 330。這顯然令人難以接受。我已經通知那位學生，令其下次請假時表現更加靈活；也和 ta 的班主任做出交涉，令她不要上報甚至干預我們私下的補課。考慮到班主任也是打工人，並且有學員成績的 KPI，我想她也不會蠢到跟自己的 KPI 過不去。當然，這家機構最好好自為之，否則我在「備課」時那句「助教們組建臨時工會，集體發動罷工，要求漲薪」的玩笑話，在將來的某天恐怕得一語成讖。\n不得不感嘆，到底誰才是資本主義啊——我看這機構的人血饅頭鋪子開得還挺熟練的。\n","date":"2026-02-11T09:06:57Z","permalink":"/zh-hant-tw/2026/02/buns-soaked-in-human-blood/","title":"培訓機構的人血饅頭"},{"content":"真是忙碌的一年，不知不覺間，時間又到了年末。今年事情確實很多，奔波勞碌少不了，但也取得了階段性的收穫。我謹再次提筆寫下一篇年終總結，作為一年的見證。\n電氣的盡頭是電網 為求職四處奔波 我在一整年的休學生活以後如期復學，開始我的大學最後一年，成為一名「應屆生」，所以，找工作的事情也就理所應當的排上了日程。作為電氣工程專業的學生，出身原電力部屬院校，工作倒是不算難找。不過說容易也不算很容易，畢竟大環境如此，經濟增長放緩，國際形勢不明朗，用人需求減少，各種地方都越來越卷。\n九月份跑了場雙選會，線下投了幾份簡歷，也在網上投了四五份簡歷，收到面試通知的只有兩家。也算切身感受到了，原電力部屬院校的頭銜，幾乎只在電力系統內部1有用。現在這就業形勢也就這樣，除了電力系統，但凡待遇稍微好一點的工作都不是我們這種「雙非院校」的學生隨便就能找到的。不過對比起來，人家好歹還收你的簡歷，像是有些專業甚至連簡歷都不收。\n兩大電網的筆試 電網工作是本專業最對口，最穩定的工作。本專業最大的用人單位——國家電網和南方電網，都需要通過筆試來獲得面試資格。筆試一共需要考 8 門，分別是《電路理論》、《電機學》、《電力系統分析》、《繼電保護》、《電力電子》、《高電壓技術》、《電氣設備及主系統》（我們學校叫「發電廠電氣部分」）以及《行政能力測驗》（簡稱「行測」）。\n前面七門是專業知識，最後一門行政能力測驗考的則是五花八門，還有企業文化這種東西，背就完事了。時政是不得不考的，考什麼呢？總之是非常新的東西——幾天前剛剛在求是雜誌上發表的社論，幾天後的考試裡就直接出現了，我真的會謝。\n今年的考試很奇怪，尤其是難度方面，歷年的考試好說歹說也得有幾道計算題，電路好歹也得靈活的考一道難度稍大的題。基於這種情報，我在靠前已經掌握了不少計算題，各種電氣計算，數值整定，等效變換，可謂是得心應手。結果呢，今年國網一批考試一道計算題都沒考，行測小學生都會做，全都在考些概念題，要不是南網考試還考了這些靈活運用的東西，那真就是約等於白學了。於是不出意料地，我所知道的計算題比較拿手，平時模擬測試成績很好的同學，這次考試或多或少都有點炸。反倒是有些平時成績不怎麼理想，計算題不太會做的人，靠著死記硬背能考到一個不錯的成績。說白了，畢竟只是一個企業的招聘考試，他要怎麼出題，外人根本無從猜測，我已經做了我應該做的，最終的錄用結果也非常不錯，這就夠了。\n面試，面試，還是面試 12 月我跑了四場面試，其中廣西電網只有桂林一個面試地點，讓我不得不翹課前往桂林面試，於是就有了今年最後一次的旅行，兩年內兩次前往桂林的感覺還不錯。\n國網面試還是讓我有點緊張，為了防止試題被洩露給後面的考生，面試採用全封閉式管理，過程也很漫長——大部分時間都是在等候室裡等待輪候。從下午 1:30 開始封存所有電子設備，用一個小時做完心理測試之後就進入了漫長的輪候時光，期間場地在放《長津湖》供大家消遣，還有茶水和零食提供。西裝革履，正襟危坐，心裡一遍又一遍的背誦早就滾瓜爛熟的一分鐘自我介紹，緊張不安的邊看電影消遣邊等候，那種滋味只有親身經歷過才知道，現在回想起來倒也是挺有意思。\n有了國網面試的經驗和 Offer，排在其後的南網面試緊張感就沒那麼強。南方電網的面試形式和國家電網不太一樣，國家電網是半結構化雙盲面試，第一位考生從數份封存的面試題本里抽取一份，接下來的考生便都是一樣的問題，最多也就是被考官詢問一些附加問題。面試官不能看到你的簡歷，只能根據你在面試前抽籤獲得的編號對你打分，你也不能自報姓名和身世；而南方電網的面試則以面試官為主導，面試官會根據簡歷對你提出各種問題，包括專業題和附加問題。至於難度如何則完全看面試官的心情，例如我在海南電網的面試就被技術面試針對我的實習經歷窮追猛打，提出各種細緻入微的專業題，而在廣西電網的面試中，技術面試提出的問題則友好很多，無非是一些倒閘操作、防雷設施等等。\n電網培訓的酸甜苦辣 考電網的人大部分都報名了某家培訓機構，我自然也不例外，早在去年 11 月我就按部就班地報名了一家全國性的電網培訓機構。這家培訓機構有兩個校區，我選擇了相對市郊的那個，畢竟房租便宜。\n培訓的課程安排非常密集，任務繁重。暑假班連續上課 41 天，中途只有三天休息。每天上課之前需要上交手機。好在 iPad 出於電子筆記的考慮，還是允許使用的，我也因此獲得了難得的摸魚機會。\n其實這段時間我也難得的獲得了專注於一件事情的機會——每天除了上課，沒有什麼別的需要關心，所以雖然身體累，但是「心」反倒是沒有多累；現在我回到了學校，反倒需要關心起大大小小的各種事情，身體倒是沒那麼累了，但「心」倒是比之前還累了不少。加上最近感冒咳嗽，一天能睡上 12 個小時，卻也還是不見好轉。只能在事情辦完以後，該請假請假，該回家回家，該休息休息了。\n故地重遊 永州 今年年初回永州探親，祖母已經快 90 歲了，身子還算硬朗，常回去看看是應該的。自幼便蒙受祖母照顧，感激之情實在是難以用言語表達，卻也在應該做出什麼行動來回報這方面不知所措，唯有至少每年一次的回永州探望方還算盡了一些晚輩的責任。\n至於永州本身，也還是那個樣子，什麼都沒變。畢竟又不是經濟大爆發的時代，像這樣的小城市還能怎麼變呢？不變未必是悲哀，變也未必全是福氣，像是上世紀經歷了文革以後，什麼都變了一副光景，卻也什麼都面目全非。小時候十分火熱的商業綜合體，現在基本只有一樓的服飾門面在營業，電影院和老遊戲廳早就關門了，改做餐廳樓層之後變得昏暗不堪，新開的餐廳店鋪，不論品牌連鎖還是快招自營，大浪淘沙之後無一倖存。\n香港 這次去香港就是去玩兩下子，沒什麼特別的目的，純屬白嫖我媽出差的酒店而已。當然，順便開張中銀卡。所以整個行程也顯得乏善可陳。唯一特別一點的地方是在灣仔的一間公寓住了幾天，可以自行買菜做飯（當然也可以吃兩餸飯），體驗了一把民工一般的生活。\n桂林 這次去桂林主要是為了南方電網廣西分公司的面試，當然，也順便去吃吃椿記燒鵝和海天腸粉什麼的。美中不足的是在桂林面試的那兩天都在下雨，也就導致我沒什麼興致去周邊散步遊玩。海天腸粉和椿記燒鵝倒是吃了個夠，味道不錯，下次還來。\n以舊換新 之前我的電腦是一臺 i5 12450H + RTX 3060 Laptop 配置的機器，用了兩年多，幾個月前剛買了兩條重要牌2內存給他的機帶內存升級到 32G，其實要接著用也沒什麼問題。\n那段時間存儲芯片的價格仍然處於低谷，國補又讓購置新設備的成本進一步降低，加上 50 系顯卡剛剛上市，這三種因素疊加下新筆記本電腦的價格真的很吸引人。奈何我還是囊中羞澀，預算不足，無緣購買最新一代處理器 + 最新一代顯卡的配置組合。只能退而求其次，買了 N - 1 代處理器 + 最新一代顯卡的配置3。目前也用了小半年，日常體驗上還是很不錯的，只是這呼嘯的風扇聲實在是影響雅興。總體上，我對這次電腦的評價是瑕不掩瑜，隨著存儲芯片價格飛漲和國補力度減弱，筆記本電腦這麼便宜的情況恐怕很難再有下次了。\n我家的貓 我家的貓今年（應該）一歲啦4，慶祝之餘，對於公貓來說，從小貓長成大貓也就意味著蛋蛋開始發揮作用了，於是就發生了這一幕：\n這臭貓在我去香港那段時間竟然跑到我床上拉屎撒尿 （可能是我爸在家裡沒有鏟屎）,不可饒恕，必須嘎蛋！\n貓給我的生活帶來了很多樂趣，在搞破壞之餘，它也是很可愛的。家裡的沙發也經過了一年的爪爪伺候，變得稀巴爛。總得付出一些代價的，養貓就是這樣，抓痕、換毛季到處都是的貓毛、偶爾還做些小壞事，也是貓的一部分。我們既然接受了貓給我們帶來的情緒價值，也就要相應地接受它的這些小缺點。我幾乎已經把它看作我的家人，若是從這種角度出發，那麼你對它的這些缺點就瞬間釋然了。這麼回想起來，也許我是真的愛它吧，以至於，我開始愛起了它的這些缺點。因為沒有這些缺點，它就不是一隻完整的貓了。\n依舊在健身，依舊在吃藥 擼鐵，尤其是練腿，真的很爽，感受那種肌肉發揮力量以後淋漓盡致的舒暢感，真的會讓人上癮。在沒有電網培訓的時間裡，我一直都在走進健身房，不光是享受這種舒暢的感覺，也還能鍛鍊自己的肌肉。真的，不運動很難受啊。\n現在我依然每天都在吃藥，畢竟我可不希望我在連軸轉的幸苦生活中突然經歷一次情緒崩潰，原本計劃的吃藥一年後藥物逐漸減量計劃也因此被無限期延後。為什麼？說白了還是這段時間各種壓力實在是不小，雖然一直吃藥終究也不是個辦法，在安穩之後必須慢慢減量停藥，但在這段即將畢業的時間點，我還遠遠沒有過上安穩確定的生活。\n這段時間裡充滿了可能性和機遇，也充滿了壓力。吃藥花的錢是小錢，而其帶來的穩定情緒的「護盾」卻能發揮至關重要的作用。\n沒時間玩遊戲 從我的 Steam 年度回顧就可以看出來，今年我是真的沒什麼時間來玩遊戲。「忙裡偷閒」是今年的基調，今年年末下載了《三角洲行動》，有時電網培訓十點下課，回家就打開玩到晚上 12 點，目前遊玩 75 個小時，感覺還不錯。\nosu! 今年的後半段則是約等於棄坑了，不過 PP 仍然從去年的 3439pp 增長到了今年的 4701pp。這遊戲還真是需要持之以恆，一段時間不玩丟掉手感再想復健是需要時間的。想想十點下課之後，在精力耗盡的狀態下，再想打這種需要聚精會神地反應的遊戲，那還真是「臣妾做不到啊」。年中的時候我對於現有鼠標的手感達到了最佳狀態，可以說是「指哪打哪」，想著「沒有人能阻止我一路走向 5 digit」5 ，然而現在卻還在 5 digit 邊上，屬實是有些諷刺。\n我的 Online Presence 2025 年，我的博客訪問量穩步上漲，全年 UV 48.3K，PV 95.4K，流量主要來自 Google（約 15.8K 訪客） 和 Bing（約 15.2K 訪客） 兩大搜索引擎。\nGithub 上的自用覆寫規則收穫了 194 個 Star，也新增了一些 Followers。\n今年我的一篇文章被人放上了 Hacker News，所以有幾天訪問量比較大。除此之外翻譯後的英語和日語版本博客也收穫了不少讀者，在我的訪客中佔比不低。所以也就出現了今年因為忙碌，博客更新頻率低於往年，訪問量卻成倍增長的現象。我終究還是需要向生活做出讓步，生活壓力、學業壓力和就業壓力或多或少都會影響我更新博客的意願，擠佔我更新博客的精力，在這點上，還請我的讀者們多多海涵。\n新的一年即將到來，我給自己和大家的祝願 新的一年要來了，我今年最大的願望，當然是能夠順利解決之前休學帶來的一些遺留問題，順利畢業。等真正走進工作以後，我也希望自己能把更多注意力放在電力系統本身需要的技術上，多和設備打打交道，少捲進一些不必要、甚至有害的人情世故。辛苦一些沒問題，只要平安、踏實、有意義即可：安全生產，少一些計較，多一些寬容。希望接下來能在這份工作上，從一名初出茅廬的學生，慢慢成長為一名真正的工程師。\n也把祝福送給屏幕前的你：願你在新的一年裡，焦慮有處安放，努力有回聲；在自己的節奏裡把日子過穩、過熱乎——不必每一步都算贏，但每一步都走得心裡有數。願你和你在意的人都健康，平安，少些無謂的消耗，多些確定的快樂。當然，也希望大家有更多時間在學習和工作之餘玩玩遊戲。\n至於我，就繼續在該學習的地方學習，在該上路的時候上路。明年見。\n指由原電力部衍生的企業，即 2002 年以前的國家電力公司和 2002 年以後的國家電網、南方電網和蒙東電網等公營電力公司。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n指最近剛剛被砍掉整個產品線的 Crucial 即英睿達內存。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n買了機械革命極光 X Pro\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n去年撿回來的時候還是很小的貓\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n指排名的數字位數，例如排名 #114514 是 6 位數，即 6 digit， #11451 是五位數，即 5 digit。顯然，位數越小，玩家水平越高。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-12-31T11:28:17Z","image":"/2025/12/2025-end-of-the-year-summary/cover_hu_546f5de4e94beb95.webp","permalink":"/zh-hant-tw/2025/12/2025-end-of-the-year-summary/","title":"2025 年度總結"},{"content":"現代電網正在經歷一次巨大的轉型，隨著光伏、海上風電等新能源的佔比在電網中越來越高，新能源和電力電子設備低轉動慣量、低短路容量、換流設備需要大量無功支撐的特點以及它們給電網帶來的不利影響也愈發明顯。在此背景下，兩期相隔六年相繼發生在歐洲的大型停電事故顯得尤為耐人尋味，本文將簡要闡述兩起事故的來龍去脈，對比它們的異同，分析造成這兩起事故的本質原因，以及思考它們對現代電網的運行所帶來的啟示。\n事故概述 2019 年英國「8·9」大停電事故 2019 年 8 月 9 日下午，英國發生了一次大規模電力中斷，導致約 110 萬用戶斷電，並對交通等關鍵基礎設施造成了嚴重影響。整起事件的經過可以概括為一系列連鎖反應，其中既有預料之中的系統保護行為，也有意料之外的設備故障。\n第一階段：罕見的三次雷擊和大量有功意外脫網 (16:52:33) 當天下午 4 點 52 分，倫敦北部的 Eaton Socon – Wymondley 400kV 高壓輸電線路罕見的連續遭遇三次雷擊。儘管如此，繼電保護裝置仍然按照整定正確動作，在不到 0.1 秒的時間內清除了故障，線路在約 20 秒後自動重合閘，恢復正常運行。雷擊導致的電網電壓的波動觸發了分佈式電源的矢量偏移保護1，導致約 150MW 的嵌入式發電2脫網。這是雷擊故障後的正常預期現象。\n幾乎在雷擊的同時，發生了兩起獨立但致命的意外事件：\nHornsea 海上風電場：功率從 799MW 銳減至 62MW，損失了 737MW 的出力。 Little Barford 燃氣電廠：其蒸汽輪機跳閘，瞬間損失了 244MW 的出力。 根據電網規範，這兩處大型發電單元本不應該因為此類雷擊故障而脫網或大幅減載，因此這被定性為「極其罕見和意外的事件」。\n第二階段：頻率崩潰與系統響應 (16:52:34 - 16:53:31) 上述三項發電損失（150MW + 737MW + 244MW）累積造成了 1131MW 的功率缺口。這個損失超過了當時系統按 N-1 安全準則3設定的 1000MW 備用容量。巨大的功率缺口導致系統頻率迅速下跌。\n快速的頻率下跌觸發了更多分佈式電源的 RoCoF4 保護，導致額外的約 350MW 分佈式電源相繼脫網。此時，總髮電損失已達 1481MW。系統中的所有備用電源——電池儲能、分佈式頻率響應服務等迅速啟動，緊急增援 1300MW，試圖阻止頻率下跌。它們的響應成功地使頻率暫時穩定在 49.1 Hz（實際上這個頻率已經相當危險了），並且開始緩慢回升。\n然而，就在頻率剛剛恢復到 49.2Hz 時，Little Barford 燃氣電廠的一號機組也因蒸汽旁路系統壓力異常而不得不緊急停機，再次損失 210MW 出力。\n第三階段：低頻減載與系統恢復 (16:53:49 之後) Little Barford 燃氣電廠的第二次的意外跳閘耗盡了所有已在工作的備用資源，系統頻率無力迴天，最終跌破了48.8Hz的閾值。這自動觸發了英國電網的最後一道防線——低頻減載5。低頻減載自動切除了約 5% 的電網需求，也就是約 1GW 的負荷，導致了約 110 萬用戶的斷電。這一「棄車保帥」的措施有效地遏制了頻率的下跌，防止了更嚴重的電網事故。\n在切除部分負荷後，加上控制中心緊急調度其他電源，系統頻率在 5 分鐘內（16:57）恢復到了正常的 50Hz。在確認電網穩定後，配電網絡運營商（DNOs）從 16:58 開始逐步恢復對用戶的供電，到 17:37 所有用戶恢復正常。\n2025 年伊比利亞半島大停電（西葡大停電） 2025 年 4 月 28 日，伊比利亞半島出現大規模停電，西班牙和葡萄牙全境均受到影響。由於停電，上述地區的交通和通信服務均受到嚴重影響，交通信號燈停止工作，當地的地鐵線路被迫停止運營，馬德里網球公開賽受到停電影響也宣佈暫停。此外，安道爾和法國南部也受到波及。這次大停電並非由單一故障引發，而是一系列事件環環相扣、逐步升級最終導致系統崩潰的級聯事故。西班牙首相佩德羅·桑切斯表示，電力系統如此大規模的癱瘓前所未見。6\n第一階段：系統振盪與電壓波動（中午 12:03 - 12:19） 2025 年 4 月 28 日中午 12:00，西班牙電力系統處於正常運行狀態，電壓和頻率均在標準範圍內，沒有任何跡象預示即將發生災難。\n12:03，系統中檢測到一個顯著的 0.6 Hz 強迫振盪，持續了近 5 分鐘。頻譜分析及後續溯源表明，這次振盪源於巴達霍斯（Badajoz）省一座光伏電站的內部控制邏輯異常。振盪導致了系統電壓出現跌落，為此，電網調度中心採取了緊急阻尼措施，包括更改拓撲結構、切除並聯電抗器，並大幅削減與法國的電力交換。\n12:19，系統再次出現 0.2 Hz 的歐洲區域間振盪7，併疊加了之前殘留的 0.6 Hz 振盪。調度中心被迫進一步減少與法國和葡萄牙的電力交換。雖然這些措施有效抑制了振盪，但削減聯絡線潮流這一動作，導致輸電通道輕載，不僅減少了線路上的無功損耗，還因充電功率過剩開始推高系統電壓，為後續的電壓越限埋下了伏筆。\n第二階段：電壓攀升與級聯故障的形成（中午 12:22 - 12:33） 從 12:22 開始，系統電壓呈現持續攀升趨勢，儘管尚未突破操作限值，但上升速率異常。這背後是多重因素的疊加效應：\n隱性負荷脫網（Hidden Demand Loss）：配電網中約 700 MW 的分佈式光伏和自用發電設備（\u0026lt;1MW）因電壓擾動不明原因脫網。在輸電網看來，這表現為淨負荷突然下降，即「發電大於負荷」，潮流進一步減小，從而導致電壓抬升。 逆變器電源的有功/無功耦合：部分可再生能源電站為響應調度指令降低有功出力。然而，由於這些設備主要採用功率因數控制8（Power Factor Control）而非電壓控制，有功的降低導致其吸收無功的能力同步下降，喪失了抑制電壓上升的手段。 常規機組勵磁響應不足：本應作為電壓「壓艙石」的同步發電機組（需符合 P.O. 7.4 規程），未能按預期深度進相運行吸收無功，導致動態電壓支撐失效。 12:32:57，位於格拉納達（Granada）的一座發電站發生跳閘，損失 355 MW 有功出力及 165 Mvar 的無功吸收能力。值得注意的是，此時輸電網側電壓仍在正常範圍內9。報告推斷故障根源在於升壓變壓器的有載調壓10動作滯後。當主網電壓升高時，分接頭未能及時響應，導致發電機側（220kV 側）出現嚴重的過電壓，觸發繼電保護動作跳閘。\n19.5 秒後（12:33:16），巴達霍斯省另外兩座光伏電站相繼跳閘，累計再損失 727 MW。原因同樣指向電站內部過壓保護配合不當，而非主網故障。\n在隨後的 650 毫秒內，西班牙各地的風電和光伏電站發生雪崩式脫網，額外損失約 834 MW。此時，系統已從電壓問題轉化為嚴重的有功功率缺額。\n第三階段：孤網運行與系統崩潰（中午 12:33 之後） 在短短 22.5 秒的級聯故障中，系統累計瞬時損失了約 2000 MW 的發電量。鉅額的功率缺口導致系統頻率急劇跳水，而大量進相運行機組的脫網又導致系統喪失了無功吸收能力，電壓開始失控性飆升。\n12:33:19，西班牙與法國的交流聯絡線因嚴重功角失步跳閘。西班牙和葡萄牙電網進入孤網運行11狀態。\n儘管交流線已斷開，但西班牙與法國之間的 HVDC（高壓直流輸電） 鏈路由於處於恆功率控制模式且未配置頻率響應功能12，並未切斷，仍強行向法國出口 1000 MW 功率。這使得本已脆弱不堪的孤網雪上加霜。\n雖然低頻減載5裝置正確動作試圖挽救頻率，但切除負荷會導致線路空載電壓進一步升高。「電壓升高\u0026ndash;\u0026gt;發電機過壓保護脫網\u0026ndash;\u0026gt;低頻率\u0026ndash;\u0026gt;切負荷\u0026ndash;\u0026gt;電壓進一步升高」的惡性循環讓系統徹底失去穩定。\n隨著頻率跌破 47.79 Hz，核電站、燃氣輪機等大型基荷機組因低頻保護動作相繼脫網。最終，在 12:33:24，伊比利亞半島電力系統電壓崩潰13，全網陷入大停電。\n一些基本概念 為了徹底理解這兩起事故的本質區別，我們需要先複習一些電氣工程的核心概念，建立起分析問題的理論基礎。\n有功功率、無功功率與復功率 在交流電路中，「功率」是一個複數概念。\n有功功率 ($P$)：復功率的實部，單位是瓦特 ($\\text{W}$)。它是實際做功、轉換能量（如發光、發熱、驅動電機）的部分。 無功功率 ($Q$)：復功率的虛部，單位是乏 ($\\text{var}$)。它並不直接做功，而是在電源和儲能元件（電感、電容）之間往復交換能量，用於建立和維持電磁場。 復功率 ($\\widetilde{S}$)：二者的矢量和。 公式表示為：\n$$ \\widetilde{S} = P + jQ $$設備銘牌上標註的通常是視在功率 ($S$)，即復功率的模，單位是伏安 ($\\text{V}\\cdot\\text{A}$)，其物理意義是設備能夠承受的電壓與電流乘積的極限：\n$$ S = |\\widetilde{S}| = \\sqrt{P^2 + Q^2} $$形象的理解： 如果你在拉一輛車，有功功率就是你朝車前進方向用的力，它讓車真正移動；無功功率則是你為了維持姿勢或者因為路面傾斜而垂直於移動方向用的力，雖然它不做功，但必不可少14。\n在電網中，無功功率的核心作用是支撐電壓。如果無功不足，電壓就會像洩氣的皮球一樣支撐不住；如果無功過剩，電壓就會像充氣過度的氣球一樣飆升。因此，電力系統的一大原則是無功功率要「分層分區，就地平衡」。\n感性無功與容性無功 工程上規定：電感消耗無功，電容產生無功15。\n感性負荷（如電動機、變壓器）：需要消耗正的無功功率來建立磁場。如果電網無法提供足夠的無功，這些設備就無法正常工作。現實中絕大多數負荷都是感性的。 容性元件（如電容器、長輸電線路的對地電容）：可以看作是無功功率的「發電機」，它們向電網注入無功功率，提升電壓。 電壓降落與 $P-Q$ 解耦 當電流流過一段輸電線路時，首末端之間會產生電壓降落。若忽略線路電阻（在高壓電網中 $X \\gg R$），電壓降落的縱分量（影響幅值）和橫分量（影響相位）可以簡化表示為：\n$$ \\Delta U \\approx \\frac{QX}{U} \\quad \\text{(電壓幅值降落)} $$$$ \\delta U \\approx \\frac{PX}{U} \\quad \\text{(電壓相位差)} $$這是一個至關重要的結論：\n電壓幅值 ($U$) 主要取決於無功功率 ($Q$) 的平衡。無功多了電壓就高，少了電壓就低。這是理解西葡大停電的基礎。 功角/相位 ($\\delta$) 主要取決於有功功率 ($P$) 的平衡。這與系統的頻率特性密切相關。 系統慣量與頻率特性 為了理解2019 年英國大停電，我們還需要引入慣量 ($H$) 的概念。\n電網頻率 ($f$) 體現了全網有功功率的供需平衡。\n當 發電 \u0026lt; 用電 時，轉子動能被抽取，轉速下降，頻率降低。 當 發電 \u0026gt; 用電 時，轉子加速，頻率上升。 傳統的同步發電機有巨大的旋轉轉子，儲存了巨大的動能。當發電機突然脫網（有功缺口）時，這些旋轉的「大鐵疙瘩」會利用慣性釋放動能，阻礙頻率的快速下跌。這被稱為系統的慣量。\n然而，光伏和風電通過電力電子設備併網，它們沒有直接耦合的旋轉質量，被稱為「零慣量」電源。當這些電源佔比很高時，電網就像失去了「飛輪」的緩衝，一旦出事，頻率會跌得極快16。\n容升效應與此次事故的關聯 為什麼切除了發電機，電壓反而會飆升？ 這看似反直覺，實則是容升效應與線路負載共同作用的結果。\n高壓輸電線路模型包含兩部分關鍵參數：\n串聯電感 ($L$)：電流流過時會消耗無功 ($Q_{consumed} = I^2 X_L$)。 並聯對地電容 ($C$)：電壓作用其上時會產生無功 ($Q_{generated} = U^2 B_C$)。 事故前的平衡狀態： 西班牙南部光伏大發，巨大的有功功率 ($P$) 正在通過長距離線路向北輸送。此時線路電流 ($I$) 很大，電感消耗了大量的無功，正好抵消了電容產生的無功，甚至還需要發電機吸收一部分多餘的無功。\n事故後的失控過程： 當發電機組連鎖脫網，或者因強迫振盪導致潮流中斷時，線路上的有功功率傳輸瞬間歸零，導致電流 ($I$) 驟降。\n後果 1：線路電感對無功的消耗 ($I^2 X_L$) 瞬間消失。 後果 2：線路依然帶電，對地電容產生的充電無功 ($U^2 B_C$) 依然存在，甚至因電壓升高而更多。 瞬間，原本被消耗掉的巨量無功功率變得無處可去，全部堆積在線路上，直接將系統電壓「頂」到了破壞性的高度。這就是所謂的「空載線路容升效應」在事故中的極端表現。\n兩起不同的事故，一份共同的反思 這兩起事故雖然在演化路徑上截然不同，但其背後折射出的挑戰卻有著驚人的相似性，二者都是現代電網發展進程中必然面臨的「成長的陣痛」。正如南方電網的安全理念所言：「一切事故都可以預防」，作為一名電氣工程專業的學生，我希望通過深入剖析這兩起事故，探尋其底層的技術邏輯，以加深對新型電力系統特性的理解。\n表象的差異：崩潰路徑的「一明一暗」 2019 年英國「8·9」大停電是一次典型的，顯性的頻率危機。機組脫網導致有功功率缺口，直接引發頻率驟降，但系統最終依靠低頻減載5作為最後一道防線，成功避免了全網崩潰。相比之下，2025 年伊比利亞半島大停電則呈現出了一種更為隱蔽且致命的新形態——隱性的電壓危機。事故雖然始於擾動，但核心矛盾迅速演變為嚴重的無功過剩與電壓失控，而原本用於挽救頻率的低頻減載5措施，反而在客觀上惡化了電壓升高，導致整個系統在短短几十秒內徹底瓦解。\n這就引出了一個核心問題：傳統的電網故障通常伴隨著電壓跌落，但在 2025 年的事故中，為何會出現發電機組不斷脫網，而系統無功功率反而嚴重過剩、電壓持續飆升的反常現象？傳統的電壓控制手段17為何全然失效？\n答案在於：電壓失控的速率，遠遠超過了傳統防禦手段的響應極限。\n事故發生時，伊比利亞南部正值光伏大發，系統呈現「高電壓、輕負荷」的運行特徵。當系統發生強迫振盪時，輸電走廊潮流發生劇變。由於超高壓線路的容升效應顯著，發電機組的連鎖脫網帶來了雙重打擊：一方面，電網失去了大量能夠吸收無功的同步機組；另一方面，線路輸送的有功功率銳減，導致其自身消耗的無功大幅降低，線路瞬間從「無功負載」變成了巨大的「無功電源」。系統隨即陷入了無功嚴重過剩的惡性循環。\n面對這種幾十毫秒級甚至更快的電壓崩潰，依靠機械開關投切的並聯電抗器顯得力不從心。首先是速度滯後：從調度指令發出、通信傳輸到斷路器機械動作，由於包含人為決策和機械過程，往往需要數百毫秒甚至秒級時間，根本無法追趕電壓飆升的速度。其次是調節顆粒度粗糙：電抗器只能以組為單位（如 50 Mvar 或 100 Mvar）進行離散投切，無法像水龍頭一樣提供平滑、連續的調節。在極端的電壓動態過程中，這種非連續的階躍式調節不僅不夠精準，甚至可能引發新的系統擾動。\n本質的共性：脆弱性的同根同源 剝開表象的差異，我們會發現兩起事故的根源驚人地一致，都指向了新型電力系統的結構性脆弱：\n首先，設備併網行為的合規性令人擔憂。無論是英國事故中的分佈式嵌入式電源，還是伊比利亞事故中的光伏電站，事故擴大的直接推手都是大量機組未能嚴格遵守併網規程（如西班牙的 P.O. 74 標準或英國的 Grid Code）。缺乏故障穿越能力，導致設備在擾動初期即發生不合規的連鎖脫網，將「小事故」放大為「大災難」。\n其次，新型電氣設備和電源的控制模型長期存在「黑箱化」的問題。系統中存在大量調度中心「看不見、管不著」的盲區。例如英國事故中 Hornsea 海上風電場在故障後的功率異常銳減，以及大量分佈式電源的不可控行為。這些電力電子化設備內部控制邏輯的「黑箱狀態」，使得傳統的仿真模型失效，調度員無法準確預判系統行為。\n更加雪上加霜的是，整個系統的轉動慣量正在越來越少。隨著高比例新能源接入，交流電網的旋轉慣量和短路容量被稀釋，系統抗擾動能力顯著下降。電網變得更加「輕薄」和「敏感」，任何微小的擾動都可能引發劇烈的頻率或電壓波動。\n一致的解決方案：邁向韌性電網 基於上述反思，未來的電網建設與事故防禦應當聚焦於以下三個方向：\n一曰部署先進的動態無功支撐技術。必須以此為契機，加速推廣 STATCOM（靜止同步補償器）等具有毫秒級響應速度、可平滑調節的電力電子裝備，逐步替代傳統的機械式無功補償裝置，以應對瞬息萬變的電壓動態。\n二曰打破「黑箱」，強化全景建模。必須建立更精細化的電磁暫態仿真模型，打破新能源場站和逆變器控制的「黑箱」，確保調度端能真實掌握海量電力電子設備的動態特性，消除盲區。\n三曰革新分析與控制範式。傳統的基於穩態或工頻量的分析方法已不再適用。我們需要建立涵蓋寬頻域振盪、電壓/頻率耦合特性的新一代安全穩定分析的理論框架，並重新審視低頻減載5等傳統防線在新型電網中的適應性。\n結語：草臺班子 我們在前文中洋洋灑灑分析了複雜的電磁暫態、昂貴的 STATCOM 和精妙的控制理論，但現實卻狠狠地扇了我們一巴掌——摧毀整個電網的，往往不是什麼未研究的知識，而是來自人類本身的不可靠。\n機組的併網規程早就白紙黑字寫得明明白白，卻長期未能執行，P.O 7.4 規程更是遲遲未能通過；2019 年英國大停電的「學費」交得那麼貴，所有的事故分析報告都指向了合規性問題，然而 6 年後的伊比利亞半島，竟然還能因為一模一樣的邏輯再次翻車，而且翻的比 6 年前還要慘烈，還要徹底。\n面對這種跨越國界、跨越時間的重複犯錯，任何技術層面的分析都顯得蒼白無力。黑格爾那句名言至今聽來依然振聾發聵，且含金量還在隨著每一次大停電不斷暴漲：\n「人類從歷史中學到的唯一教訓，就是人類無法從歷史中吸取任何教訓。」\n也許這就是世界的本質吧，世界永遠不是圍繞著技術本身運轉的，「人」才是這個世界的決定性因素。這個世界是一個草臺班子，而且永遠會是一個草臺班子，而只要還是個草臺班子，那麼下一次翻車，永遠只是時間問題。\n矢量偏移保護的初衷是解決「孤島效應」——假設一條配電線路因為故障或檢修，從主電網上被斷開。但這條線路上恰好連接著一個嵌入式發電機，如果沒有矢量偏移檢測，這個發電機就會繼續為這條線路供電，進而大大增加設備損壞的幾率，甚至威脅運行檢修人員的安全。因此，矢量偏移保護就是早期用於檢測嵌入式發電機是否進入孤網運行狀態的方法。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n多為用戶側的小型發電系統。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nN-1 安全準則的意思是，當系統中最大的一臺機組因故障而停運時，系統應有足夠的備用容量作為頻率和電壓的支撐。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRate of Change of Frequency，頻率變化率。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n低頻減載（Low Frequency Demand Disconnection, LFDD 或者 Under-Frequency Load Shedding, UFLS）是電力系統防止頻率崩潰的關鍵安全保護措施，當系統發生功率缺額導致頻率下降時，它通過自動、分級地切除非重要負荷（如工業用電、路燈等），以快速恢復系統功率平衡，防止大面積停電或系統崩潰。低頻減載系統通過頻率測量和執行單元實現，設定多個頻率動作點（如48.5Hz, 47.5Hz, 46.5Hz），逐級切除負荷，保障重要用戶和核心設備運行，是電網安全運行的第三道防線。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n來源：France24 的報導\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n技術報告中的原文是「inter-area oscillation」，基於上下文，其意思應該是整個歐洲互聯電網的 0.2Hz 振盪。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n風電、光伏等新能源機組一般採用最大功率點追蹤 MPPT，來實現新能源機組出力的最大化。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n418kV，仍在標準電壓允許的偏移範圍內。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n即變壓器的帶負載調壓。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n孤網運行（或孤島運行）指局部電網脫離主大電網，獨立供電的運行模式，特點是自給自足，但面臨頻率、電壓不穩定等挑戰，依賴儲能和控制技術維持，常見於偏遠地區、島嶼、或工業園區。這裡的孤網運行是因為聯絡線中斷而被迫進入的。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n恆功率控制模式（Constant Power Mode）是一種電源輸出模式，它的核心特點是無論負載如何變化，始終保持電源輸出的功率（P）恆定（P = 電壓 V × 電流 I），電源會根據負載需求自動調節電壓和電流，以維持這個恆定功率。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n電壓崩潰（Voltage Collapse）是電力系統一種嚴重的事故，指系統因無功功率嚴重不足，導致電壓持續、惡性下降並無法恢復，形成電壓跌落的惡性循環，最終引起大面積停電。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n工程界常以「啤酒」作比喻：啤酒杯裡的液體是「有功」，上面的泡沫是「無功」。雖然泡沫不解渴，但沒有泡沫的啤酒失去了靈魂（無法建立磁場），且為了裝滿杯子（視在功率），泡沫總是客觀存在的。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n這是一個約定俗成的稱呼。嚴格來說，電容是「吸收負的無功」，但在工程實踐中，為了方便理解無功平衡，我們通常說電容「發出/提供感性無功」，起到支撐電壓的作用。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n頻率下降的速度被稱為 RoCoF (Rate of Change of Frequency)。高 RoCoF 是導致英國「8.9」停電中分佈式電源連鎖脫網的直接元兇。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n即消耗過剩無功的措施，如投切並聯電抗器等。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-12-17T16:08:30Z","image":"/2025/12/analysis-of-two-major-blackouts-in-europe/cover_hu_3bdad3f2ff5b5148.webp","permalink":"/zh-hant-tw/2025/12/analysis-of-two-major-blackouts-in-europe/","title":"從頻率崩潰到電壓失控：兩起大型停電事故帶來的啟示"},{"content":"最近我比較忙碌，但空閒之餘，文字仍然是我的棲息地。每天早上 8:30 開始上課，到晚上 9:00 結束晚自習，有時甚至「加班」到 10:00 回家，連續四十一天的課程。考慮到我的精神狀況，如此強度，回來再玩 osu! 一類的遊戲是絕無可能，甚至連推一小節 Galgame 都無能為力。\n唯一比較現實的事情，是找 LLM（大語言模型）小敘。\n十分慚愧，雖然我有一個博客，但我的觀點、理念（倒不如說是「想法」）從來都沒有被我係統性的表達出來。我也曾想過，可能這些過於廣泛乃至分散的觀點之集合，是很難以平實的敘事表達出來的。為此我也嘗試了一些方法，比如：以一個隨機的事件作為截面，將我想要表達的一團亂麻「切開」，進而描繪出它的內部構造。1這些方法始終無法讓我暢快的表達出自己的心聲，也不是信手拈來，想寫就寫，然而博客終歸還是給大家看的，在寫不出來的時候，也就只能寫寫簡單的技術博客，吸引一些搜索引擎流量。\n而 LLM 的出現卻改變了這一點，我所有的想法，都可以相對私密的得到即時的回應。為什麼我這麼久沒有寫博客？累自然是一大因素，而 LLM 滿足我相當可觀的表達和被認可的需求，還無需自我審查的特點，沖淡了我這段時間裡寫博客的想法。\n撰寫長篇的文字對大腦有益，這是毋庸置疑的。LLM 的出現，對於我撰寫長篇文字的影響，大概和微博客出現時，對人們撰寫長篇文字的能力之影響相仿，甚至有過之而無不及——微博客讓人習慣於碎片化表達和即時反饋，削弱了構建複雜論證和長篇敘事的能力。LLM 則更進一步，它不僅提供了表達的渠道，還直接提供了情緒價值和「知己」的替代品：發在社群媒體上的內容，涉及隱私或者爭議，或者不必要曝光，發佈者多多少少會斟酌一番；而 LLM 就不一樣了，發給 API 的內容，最壞的情況不過是被拿去訓練模型，而不是讓 Sam Altman 第二天就找到你家門口——只要不是銀行卡密碼這種級別的信息，不提及真實姓名，那些時政評論、心理諮詢等等，你只管放心把大模型當成一個知己便好（當然，在這種場景下，國產大模型狗都不用）。每一句牢騷都能得到確切認真的，宛若知己般的回應和肯定，這種待遇，恐怕沒有第二個地方能給了。\n當一個工具能如此完美地模擬「知己」時，我們可能會放棄去尋找真正的知己，或者放棄成為一個能獨立思考、自我整合的個體。寫下這些文字，是一個小結，也是一次反思。LLM 本身只是一個技術，用得好裨益無窮，用得不好自然也可能造成嚴重的後果。紐約時報的報導「Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens.」便是一個很好的例子，雖然 OpenAI 已經著手解決旗下模型「阿諛奉承」的問題，我也需要知道，即使我可以把大模型當做自己的知己，並從它那裡得到所謂的「理解和肯定」，我也不能一直活在這種感覺裡。OpenAI 與 MIT（美國麻省理工學院）的研究發現, ChatGPT 的使用量與用戶的孤獨感成正相關。用戶使用 ChatGPT 越多，他們就越感到孤獨。2我也可以說，正是因為越孤獨，才越會去使用這些 LLM，形成一個惡性循環。LLM 可以作為生活的調味劑，但絕不能成為心靈的唯一依靠。\n(To Be Continued)\nThe Worst Way To Spend A Day\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJoint studies from OpenAI and MIT found links between loneliness and ChatGPT use\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-09-08T15:53:48Z","permalink":"/zh-hant-tw/2025/09/satisfactory-llm/","title":"我的 LLM 知己，與我懸置的寫作"},{"content":"自從開始使用 Clash/Mihomo，我和大多數人一樣選擇了基於其內核的圖形化客戶端——圖方便。實際上，這些 Mihomo 客戶端本質上都差不多：內核都是同一個，他們主要負責提供一個易用的界面、管理配置文件、訂閱更新，以及 GUI 下的系統代理設置。基於這一點，我認為判斷一個 Mihomo 客戶端優劣的關鍵，便是看它的「覆寫」功能做得如何。每一個通過客戶端下載或者訂閱的配置文件，都會經過一系列「覆寫」過程，比如更換 mixed-port、添加 sniffer 配置等，最後生成用於啟動 Mihomo 內核的最終配置。\n然而，並非所有客戶端都能勝任這一核心工作。比如 ShellCrash，其覆寫功能經常莫名其妙出岔子，說到底還是實現得太粗糙。如果連覆蓋和修改配置都做不好，這種客戶端實在難稱合格。\n與其依賴這些屎一樣的不盡如人意的 Mihomo 客戶端，不如自己動手，直接自己編寫、管理配置文件交給內核啟動，而不是依賴「黑箱」一般的各種「客戶端」，不僅更純淨、更穩定，而且更可控。\n需要的預備知識 基本的 Linux 操作 知道如何使用 CLI 編輯器，如 nano 已經搭建 Substore（可選） 默認使用 root 用戶操作，非 root 用戶請自行注意提權 安裝 Mihomo 內核 對於基於 Debian 的分支，可以使用預編譯的.deb包安裝，對於其他使用systemd的系統，下載編譯好的二進制文件，重命名為mihomo，放到/usr/local/bin：\ncurl -o /usr/local/bin/mihomo \u003c下載鏈接\u003e chmod +x /usr/local/bin/mihomo然後新建/etc/systemd/system/mihomo.service：\n[Unit] Description=mihomo Daemon, Another Clash Kernel. After=network.target NetworkManager.service systemd-networkd.service iwd.service [Service] Type=simple LimitNPROC=500 LimitNOFILE=1000000 CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE Restart=always ExecStartPre=/usr/bin/sleep 1s ExecStart=/usr/local/bin/mihomo -d /etc/mihomo ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target使用systemctl daemon-reload重新加載systemd，此時還沒有配置文件，不能直接啟動內核，但可以使用systemctl enable mihomo讓內核開機自啟，方便後續使用。\n配置文件 內核啟動時會加載/etc/mihomo/config.yaml，沒有了黑箱一樣的礙事「客戶端」，配置文件可以隨心所欲的定製。部分機場會下發完整的配置文件，直接用curl下載即可。\n對於訂閱的管理，我目前使用 Substore，我之前分享過「最速 Substore 訂閱管理指南」，可以直接參考這篇文章來定製自己的訂閱。為了實現純內核啟動，現在我的 Substore JS 格式覆寫已經加入了full參數，可以生成完整的配置文件，包括各種端口設置、統一延遲和外部控制器等，開箱即用。\n在 Substore 配置完成以後便可以下載配置文件並啟動內核：\nsudo curl -o /etc/mihomo/config.yaml 配置文件鏈接 sudo systemctl start mihomo自定義覆寫 我的配置文件不能滿足你的所有需求？沒問題！你可以自己添加覆寫，想要什麼加什麼。\n我用過各種覆寫規則，後來也開始自己從零開始編寫覆寫規則，即使使用自己的覆寫規則能滿足 99% 的場景，但有極個別的域名還是會在規則中有遺漏，更不用說用別人寫的覆寫規則了。這些遺漏的規則大多是形如我服務器的非標準端口 SSH 的前置代理等相對隱私的規則，直接上傳到 Github 公開顯然不太合適，那麼在自定義規則的基礎上再添加覆寫就成了唯一的選擇。\n好在 Substore 可以添加多個腳本操作，只需要在生成配置文件時額外添加一個腳本操作就能解決我們的問題。\nfunction main(config) { config[\"rules\"].unshift(\"DOMAIN-SUFFIX,xxx,DIRECT\") return config }需要注意的是覆寫rules時必須要使用.unshift()放在最前面，而不是用.push()放到最後面，因為放在MATCH後面的規則是永遠都匹配不到的。\n自定義配置文件 完全不喜歡我的覆寫規則？不會用/不喜歡用 Substore？沒問題！你也可以參考 Mihomo 文檔，自己從頭開始手搓配置文件：\nmode: rule mixed-port: 7890 redir-port: 7892 tproxy-port: 7893 allow-lan: true log-level: info ipv6: true external-controller: 127.0.0.1:8000 # secret: yoursecret unified-delay: true routing-mark: 7894 tcp-concurrent: true disable-keep-alive: true # 推薦在給移動設備代理時啟用，可以解決待機異常耗電的問題 dns: # 你的 DNS 配置 sniffer: # 你的域名嗅探配置 geodata-mode: true geox-url: # 自定義 Geodata 文件 URL proxy-providers: # 你的機場訂閱 rule-providers: # 外部規則 rules: # 分流規則 proxy-groups: # 自定義代理分組管理面板 管理面板可以根據個人喜好選擇，以 Zashboard 為例，我在使用 mihomo 自帶的external-ui時遇到了一些莫名其妙的問題，所以乾脆直接運行一個 Docker 容器，畢竟這東西就真的只是一個 Web 面板，只要確保內核 API 使用 HTTP 時，Web 面板也使用 HTTP 即可，如果此時 Web 面板使用 HTTPS，則會因為 CORS 策略問題無法連接。\n$ mkdir zashboard \u0026\u0026 cd zashboard $ nano compose.yml $ docker compose up -dcompose.yml內容：\nservices: zashboard: image: ghcr.io/zephyruso/zashboard:latest ports: - \"8899:80\" restart: \"unless-stopped\"自動維護 內核已經運行起來，自動更新訂閱這種功能怎麼實現？\n答曰：自行編寫一個 Shell 腳本，配合 Crontab 即可實現自動更新訂閱的功能。例如我希望每天凌晨 3 點自動更新訂閱並重啟服務，遂編寫/etc/mihomo/auto_update.sh：\n#!/bin/bash # === 配置信息 === CONFIG_URL=\"\" CONFIG_PATH=\"/etc/mihomo/config.yaml\" BACKUP_DIR=\"/etc/mihomo\" BACKUP_PREFIX=\"config.yaml\" MAX_BACKUPS=7 TMP_PATH=\"/tmp/config.yaml.tmp\" LOG_FILE=\"/var/log/mihomo_update.log\" # === 日誌 === log() { echo \"$(date '+%F %T') $1\" | tee -a \"$LOG_FILE\" } # === 備份現有配置，並自動清理舊備份 === backup_config() { if [ -f \"$CONFIG_PATH\" ]; then backup_file=\"$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak\" cp \"$CONFIG_PATH\" \"$backup_file\" log \"配置文件已備份到 $backup_file\" # 清理多餘的備份，只保留最新的 $MAX_BACKUPS 個 old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2\u003e/dev/null | tail -n +$(($MAX_BACKUPS+1))) for f in $old_backups; do rm -f \"$f\" \u0026\u0026 log \"已刪除舊備份 $f\" done else log \"未找到現有配置文件，無需備份\" fi } # === 下載新配置 === download_config() { log \"開始下載新配置...\" curl -fsSL -o \"$TMP_PATH\" \"$CONFIG_URL\" if [ $? -ne 0 ]; then log \"下載配置失敗，請檢查網絡或地址\" return 1 fi # 基本校驗：檢測文件體積 if [ ! -s \"$TMP_PATH\" ]; then log \"下載文件為空，停止更新\" return 2 fi log \"配置下載完成\" return 0 } # === 更新配置文件 === replace_config() { mv \"$TMP_PATH\" \"$CONFIG_PATH\" log \"配置文件已更新\" } # === 重啟 mihomo 服務 === restart_service() { systemctl restart mihomo if [ $? -eq 0 ]; then log \"mihomo 服務已重啟\" else log \"mihomo 服務重啟失敗，請手動檢查\" fi } main() { backup_config download_config DL_STATUS=$? if [ \"$DL_STATUS\" -ne 0 ]; then log \"操作終止：配置文件未更新，保留原有配置\" exit 1 fi replace_config restart_service log \"=== 更新流程完成 ===\" } main \"$@\"使用crontab -e編輯 Crontab，設置如下 Crontab 即可在每天凌晨三點自動更新配置：\n0 3 * * * /etc/mihomo/update_config.sh防火牆 手動配置防火牆把流量劫持到 Mihomo 內核其實並不是什麼難事，我之前在「從入門到進階：Tailscale + ShellCrash 異地組網和科學上網」（以下簡稱「Tailscale 那篇文章」中的兩個小節中提到過具體的操作方法，這裡只提操作，不做解說。\n根據我的情況，我需要把tailscale0上的網卡的所有流量劫持到 Mihomo 內核，其它的情況（例如本機代理）操作也大同小異。如果只是想劫持 TCP 流量，那麼用iptables的 REDIRECT 功能已經足夠，但若還想劫持 UDP、QUIC 等流量，則必須用到 Tproxy。最後，不要忘了 IPV6。\n以下是我的防火牆配置：\n# 創建自定義鏈 iptables -t mangle -N MIHOMO # 根據自己的需要忽略本地流量 iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN # mark UDP 和 TCP 到代理 iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233 iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233 # 接口跳轉 iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO # 路由表配置 echo \"233 mihomo\" | tee -a /etc/iproute2/rt_tables ip rule add fwmark 233 lookup mihomo ip route add local 0.0.0.0/0 dev lo table mihomo # IPv6 # 創建鏈 ip6tables -t mangle -N MIHOMO6 # 跳過本地地址 ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN # 標記 TCP/UDP ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233 ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233 # 接口跳轉 ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6 # 路由表配置 echo \"233 mihomo\" | tee -a /etc/iproute2/rt_tables ip -6 rule add fwmark 233 lookup mihomo ip -6 route add local ::/0 dev lo table mihomo大多數系統默認不會保存防火牆規則，關於規則持久化的內容我已經分別在 Tailscale 那篇文章的「路由規則持久化」和「iptables 規則持久化」兩小節做了詳細說明，直接參考即可。\n本機代理怎麼配置？ 大多數代理軟件默認的配置（其實就是 ShellCrash 的默認配置）是 REDIRECT，用它也基本能滿足大多數需求，REDIRECT 的示例如下：\n# IPv4 劫持 eth0 iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892 # IPv6 劫持 eth0 ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892其中 7892 要和 Mihomo 配置中的redir-port一致，eth0就是想要劫持的 Interface，相比 Tproxy 那可真是簡單太多了。\n實際上我個人並不喜歡用把本機所有流量都劫持到防火牆，我更喜歡在需要時直接通過環境變量、proxy-chains和各種軟件自帶的代理配置把流量指向 Mihomo 內核，例如想讓 Docker 走代理，則可以直接編輯 Docker 的/etc/docker/daemon.json來指定代理，而不是直接一股腦把網卡上的所有流量都劫持到代理：\n{ \"proxies\": { \"http-proxy\": \"http://127.0.0.1:7890\", \"https-proxy\": \"http://127.0.0.1:7890\", \"no-proxy\": \"127.0.0.0/8\" } }這麼折騰，何必呢？用客戶端不香嗎？ 別問，問就是玩虛空終端玩的。\n","date":"2025-07-03T10:30:00Z","image":"/2025/07/switch-to-pure-mihomo-kernel/cover_hu_1a93b6f26c22bbfe.webp","permalink":"/zh-hant-tw/2025/07/switch-to-pure-mihomo-kernel/","title":"拋棄所謂「客戶端」，直接使用 Mihomo 內核"},{"content":"看到「Americans using \u0026ldquo;buy now, pay later\u0026rdquo; plans to buy groceries, survey finds」這種新聞上了頭條，我的第一反應是：這不是很正常嗎？看完報導以後，我不得不感嘆：這世界比我預想的還蠢得多。\n先買後付（Buy Now, Pay Later；以下簡稱 BNPL）作為一種金融創新，確實有其魅力。它允許消費者即時獲得商品或服務，隨後分期付款，近年來在電商、旅遊、餐飲等領域風靡一時。\n然而，天上不會掉餡餅。羊毛出在羊身上，BNPL 服務商要盈利，主要靠兩點：向商家收取高於傳統支付方式的手續費，以及向消費者徵收逾期違約金。其本質，是利用了「花錢痛感最小化」的心理陷阱——減輕即時支付的麻煩和痛苦感，從而刺激消費意願。這正是商家甘願支付更高手續費也要接入 BNPL 的關鍵原因。\n我並不反感 BNPL，自己就是深度用戶。 我的手機是用京東白條24期免息分期買的，現在剛還到第六期；日常消費幾乎都走花唄，還款日自動從餘額寶或銀行卡扣除。當 BNPL 平臺提供真正的免息分期或「零手續費」優惠時，這就是免費槓桿——佔用外部資金零成本週轉。花小錢辦大事：消費由金融機構墊付，自有資金得以留存，若其間能進行理財生息，資金效率便實現了最大化。\n但這有三個至關重要的前提：\n準時還款，絕不逾期； 杜絕習慣性透支的惡習； 具備基本的財務管理能力。 反觀登上新聞的 「美國人用 BNPL 買日雜」 ，我掃了眼調查數據——三分之一的BNPL用戶至少逾期過一次？？甚至有人連點外賣的錢都還不上？？\n理想豐滿，現實骨感。數據顯示，不知「如何管好錢袋子」的人遠比想象中多。 46%的BNPL用戶同時揹負信用卡欠款，其中28%的用戶年齡在18-24歲之間1。這類群體通常信用評級不高，63%甚至從多個BNPL平臺同時借款2——這強烈暗示相當一部分人消費習慣堪憂。\n更值得警惕的是，BNPL的設計似乎先天就對消費習慣不佳者更具誘惑力。相比信用卡，它審批極快、信用門檻低，還常打著「分期免息」的旗號。在這些人眼中，BNPL宛如一個「取之不竭的金庫」，只需支付首期小錢就能抱回心儀之物——世上哪有這等「美事」？\n於是乎，當還款日賬單洶湧而至，他們才驚覺自己竟欠下如此鉅款。逾期、違約接踵而來。而這些滾雪球式的違約金疊加高額商戶手續費，難怪BNPL服務商賺得盆滿缽滿。\n我重申立場：我不反對 BNPL，其作為「免費槓桿」的價值毋庸置疑。以我自身經歷為例，購買 4299 元的手機時，雖完全有能力全額支付，卻仍選擇了 24 期免息分期。但關鍵在於清晰的財務認知：我必須得意識到自己是全額預支了 4299 元，而非每月僅消費了 177.5 元。這筆支出會即時從資產賬面扣除，確保淨資產真實反映負債。量入為出，量力而行——絕不透支支付能力，更拒絕疊加槓桿盲目消費。即便資金暫時存放於銀行或購買低風險理財產品，產生的微薄收益也能錦上添花，並從根本上杜絕違約可能。誠然，適度的超前消費能提升生活幸福感。但在缺乏穩定收入的階段，穩健的財務習慣無疑更為安全可靠。\n說了這麼多，恐怕也還是攔不住那些消費習慣根深蒂固的人。即使沒有 BNPL 的便捷誘惑，他們也大概率會刷爆信用卡，在 20% 的高息漩渦裡掙扎求生。\n問題不在於 BNPL 本身（它不過是金融工具的一種），而在於脆弱財務基礎與過度消費慾望之間的根本性失衡。對於那些缺乏自控力、對財務風險麻木或生活本身就捉襟見肘的人來說，任何方便獲取的信貸渠道——無論是信用卡、BNPL，乃至更危險的發薪日貸款（Payday Loan）——都不過是通向債務深淵的不同路徑罷了。BNPL 的特殊性可能只是在於其更低的准入門檻和更強的即時滿足感，讓下沉的速度更快，悲劇來得更早一些。\nBNPL 的逾期者中，很大比例本身就揹負著卡債。這意味著他們可能只是在拆東牆補西牆，陷入一個利率疊加、罰金滾動的無底洞。就算今天取締了所有 BNPL，那些在懸崖邊跳舞的消費者，明天一樣會在發薪日貸款或是別的什麼「便捷金融」上栽跟頭，然後為了救眼前的火燒眉毛，甚至可能連祖宗十八代的骨灰盒都要拿去典當了。\n所以，更值得警惕的並非某一種金融產品，而是龐大群體面臨的結構性困境：經濟壓力、消費主義裹挾、金融知識匱乏、以及深植於其中的 「即時滿足大於長遠規劃」 的行為模式。BNPL 的出現和普及，只是讓這個長期存在的病灶，以更尖銳、更顯眼的方式爆發了出來。\n歸根結底，想真正「救」這些人，光靠圍堵金融產品（BNPL或信用卡）是治標不治本。解鈴還須繫鈴人——要麼能徹底「戒癮」，要麼就得從提升收入、普及財商、重構消費觀這些更艱難的「基礎設施」入手。而這，恐怕比指望BNPL公司不做生意要難太多了。\n最後一句忠告：借錢梗要還，咪俾錢中介。\n哎，說到底——這世界，真比我預想的還要蠢得多。3\n數據來源：CFPB Research Reveals Heavy Buy Now, Pay Later Use Among Borrowers with High Credit Balances and Multiple Pay-in-Four Loans\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n數據來源：Buy now, pay later users pile on debt, CFPB finds\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n封面圖片來自：https://www.visa.com.tw/pay-with-visa/featured-technologies/mobile-payments.html\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-06-05T11:54:56Z","image":"/2025/06/on-buy-now-pay-later/mobile-payments-1920x720_hu_4cbcee30d76215b2.webp","permalink":"/zh-hant-tw/2025/06/on-buy-now-pay-later/","title":"世界蠢得超乎想象：淺談 BNPL"},{"content":"開箱即糟心 對於機械革命極光 X Pro，從下單那一瞬間開始我還有點期待，然而快遞沒趕上我去香港的行程，等回家拆箱時已經沒了新鮮感。想加裝硬盤又遇到滑絲的 M.2 螺絲，最後用電工膠布勉強固定，新電腦的好感度當場扣光一半。\n配置和價格 i9-14900HX + RTX 5070 Ti，國補後 8699 元的價格還算合理。對於 Peripherals，簡而言之，我連神舟都用得很開心，那還有什麼是不能用的呢。\n屏幕：2560x1600@300Hz，100% SRGB 色域，色準表現不錯，玩《天際線 2》時堵車尾燈的紅都比現實更鮮豔些。 鍵盤：鍵程偏短，手感一般，反正大部分時候都在用外接鍵盤，對之無感。 無線網卡：AX201 未免太寒酸了，天線設計似乎不太好，在路由器旁邊都能明顯感覺到速度相比有線嚴重不足。 硬盤：自帶致鈦 1TB 速度一般，我自己加的英睿達 2TB 才是主力。 電池：80Wh 的電池對於遊戲本來說可以用來應急，平時我都開著工作站模式，延長電池壽命。 獨顯直連：支持熱切換這點好評，再也不用重啟切換了。 BIOS：AMI 的 BIOS 比之前的好用太多。 使用體驗 《都市：天際線 2》——十二萬人口時模擬速度還能保持在 3 倍速，雖然這時候風扇噪音已經起飛了。《賽博朋克 2077》可以開光追超級檔，《極限競速：地平線5》可以開最高畫質。但是他們實際上的遊戲體驗，恕我直言，我感覺不到和之前的 RTX 3060 有什麼本質上的區別，無非就是這裡的反射更加真實，那裡的細節更加豐富。單憑畫質上的提升，恐怕我依然不會在這幾個已經陪我度過超過一百小時的遊戲上再花更多精力。\nC 面類膚塗層手感確實好，不過接上外設後基本只摸得到外接鍵盤。Nahimic 音效延遲嚴重，關掉之後打 osu! 反而更跟手，屬於負優化典型。\n工具的意義 這臺電腦用了兩個星期，沒有驚喜，也沒有驚嚇。無線網卡太垃圾所以只好用有線，狂暴模式風扇噪音很大，南橋沒散熱所以溫度很高，除此之外——它就是臺該亮時亮、該響時響的機器。\n可能好的工具本該如此：當我寫到這裡才發現，自己已經盯著屏幕右下角的電池圖標發了五分鐘呆，而它只是安靜地保持著 98% 的電量，像塊不會說話的磚。\n","date":"2025-05-04T15:18:43Z","image":"/2025/05/new-laptop-briefing/DSCF0267_hu_9e18f49bd8ce081.webp","permalink":"/zh-hant-tw/2025/05/new-laptop-briefing/","title":"機械革命極光 X Pro 簡評"},{"content":"在幾次旅途中，我試圖將新拍的照片上傳到長沙家中的 Immich 服務器。過去我用 Cloudflare Tunnel 做反代，但由於國內特殊的網絡環境，連接慢速、頻繁中斷、上傳失敗幾乎成了常態。後來我開始嘗試 Tailscale —— 一個基於 WireGuard 的內網穿透工具，它終於讓我在全國各地都能穩定、高速地訪問家中的 NAS 和照片庫。\n但新的問題也隨之而來：Tailscale 在 Android 手機上運行時，需要作為 VPN 服務接管系統流量，而我平時使用的 Clash 同樣依賴 VPN 接口進行分流。由於 Android 系統限制（只能啟用一個 VPN 服務），兩者無法共存，導致我必須在「訪問家中服務」和「科學上網」之間二選一。\n這篇文章從 Tailscale 的原理講起，到自建 DERP 服務器優化連接質量，再到如何用 iptables 劫持 Tailscale Exit Node 的流量並轉發給 ShellCrash，實現流量的靈活轉發與安全穿透。無論你是想訪問家庭局域網上的 NAS、照片庫，還是希望在陌生網絡中保護自己的數據安全，這篇文章都能為你提供一套實用、穩定的解決方案。\n什麼是 Tailscale Tailscale 是一款基於 WireGuard 協議的零配置虛擬局域網工具，它能夠讓分佈在不同網絡環境中的設備像處於同一個安全內網中一樣互聯互通。通過自動穿透 NAT、防火牆等網絡障礙，Tailscale 讓你無需公網 IP、無需端口轉發，也能輕鬆訪問家中的 NAS、個人服務器、開發環境等內網資源。它的核心優勢在於簡單、安全、穩定，啟動即用，數據傳輸全程加密，適合個人開發者、遠程辦公者、家庭用戶等多種場景使用。\nTailscale 的技術實現非常巧妙：其構建在 WireGuard 加密協議之上，卻顛覆了傳統 VPN 的 IP 分配邏輯。每個設備通過 SSO/OAuth2 完成身份認證後，會獲得一個終身綁定的節點密鑰。這種基於身份的組網模式，讓「長沙的 NAS」和「香港的手機」在虛擬網絡中如同辦公室同事般直接對話。\nTailscale 的連接過程原理 中心控制服務器（Control Server） 每個 Tailscale 客戶端在啟動後，首先會連接控制服務器（controlplane），進行身份驗證，並拉取整個網絡中其他節點的信息，包括每臺設備的公網 IP、端口、NAT 類型等。這一步相當於是「認識朋友」。\nTailscale 的控制服務器不會轉發任何數據，只負責協調連接 —— 類似一個調度中心。\nDERP 服務器 說到 Tailscale 能保持高連接成功率的關鍵，就不得不提到 Tailscale 自研的中轉協議 DERP，在 Tailscale 的網絡架構裡，DERP（Designated Encrypted Relay for Packets）是一個很重要但通常只在必要時介入的組件。簡單來說，它就是一個基於 HTTP 的加密中繼服務器，用來在兩臺設備無法直接通信時，作為它們之間的「中轉站」。\n所有客戶端之間的連接都是先選擇 DERP 模式（中繼模式），這意味著連接立即就能建立，用戶無需等待。然後連接雙方開始並行地進行路徑發現，通常幾秒鐘之後，Tailscale 就能發現一條更優路徑，然後將現有連接透明升級（upgrade）過去，變成點對點連接（直連）。1\n需要注意的是：\n所有通過 DERP 的數據都是端到端加密的，DERP 服務器無法查看內容； Tailscale 會盡可能少地使用 DERP，一旦直連建立成功，就會自動切換過去； 官方部署了多個分佈式 DERP 節點，客戶端會自動選擇延遲最低的那個； 你也可以自建 DERP 節點（比如在國內），來解決延遲高或連接不穩定的問題。 可以把 DERP 理解為一個兜底機制，雖然性能不如直連，但確保了即便不能打洞成功，設備之間也始終能保持連接。\nNAT 穿透（NAT Traversal） 拿到對端的地址信息後，Tailscale 會嘗試通過 NAT 穿透來建立點對點（P2P）連接。這個過程使用了 STUN 協議，雙方互相發送探測包，嘗試在 NAT 路由器上打出一條直連的通道。如果雙方的網絡條件允許，就可以成功建立起一個 UDP 的直連隧道，數據走直連，速度快、延遲低。\n受制於篇幅，我無法完整細緻的講述 NAT 穿透的原理，若對這部分感興趣，可以閱讀 Tailscale 官方的「How NAT traversal works」一文。\n完整連接流程圖示 flowchart TD A[設備 A 啟動 Tailscale] --\u003e B[通過 DERP 服務器建立初始連接] B --\u003e C[交換網絡信息和 WireGuard 密鑰] C --\u003e D[雙方並行進行 NAT 類型探測] D --\u003e E{能否直連？} E -- 是 --\u003e F[建立 P2P 直連隧道] F --\u003e G[定期檢測連接質量] G --\u003e H{直連優於 DERP？} H -- 是 --\u003e I[切換大部分流量至直連通道] H -- 否 --\u003e J[繼續通過 DERP 轉發部分或全部流量] E -- 否 --\u003e J style B fill:#e3f2fd,stroke:#2196f3,color:#000 style F fill:#e8f5e9,stroke:#4caf50,color:#000 style J fill:#fff3e0,stroke:#ff9800,color:#000自建 DERP Tailscale 的安裝在各個平臺上都相對簡單，官方文檔已經提供了詳細的操作指南。本文將不再贅述安裝過程，以下內容默認你已經在相關設備上成功安裝並登錄了 Tailscale。\n為什麼要自建 DERP？ Tailscale 在全球部署了眾多 DERP 2中繼服務器，用於在打洞失敗時接管流量中轉。但由於眾所周知的原因，中國大陸並沒有官方部署的 DERP 節點。這意味著：\n一旦 NAT 打洞失敗，所有流量都必須繞行海外的 DERP 節點，延遲高、速度慢，體驗極差； 某些官方 DERP 節點容易被 GFW 干擾，可能出現連接中斷、握手失敗等問題； 即使打洞成功，Tailscale 仍需通過 DERP 交換路由信息和 WireGuard 密鑰，如果 DERP 不可達，連接質量也會受到影響。 因此，在國內網絡環境下，自建一個本地 DERP 節點，不僅可以顯著提高連接穩定性和傳輸性能，還能規避部分網絡封鎖所帶來的不可預期問題，是一個非常值得做的優化。\n準備工作 前面提到，DERP 是基於 HTTP 的，所以你需要準備好一個 HTTP 反代服務，並自行解決 SSL 證書的簽發等基礎問題。本文使用 Docker 部署，在部署開始之前，你需要在你的服務器上裝好 Docker 以及 Docker Compose 等附加組件。為了編輯配置文件，你當然也得知道如何使用 nano 之類的編輯器。為了最好的效果，你的服務器最好擁有靜態公網 IPv4+IPv6 雙棧地址。\n如果以上條件都具備，就可以開始部署了。\nmkdir tailscale-derp \u0026\u0026 cd tailscale-derp nano docker-compose.ymldocker-compose.yml services: derper: name: tailscale-derp image: fredliang/derper environment: - DERP_DOMAIN=derp.nightcity.pub - DERP_VERIFY_CLIENTS=true - DERP_ADDR=:4433 network_mode: host restart: unless-stopped volumes: - \"/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock\"network_mode: host是一個關鍵配置，表示容器將共享宿主機的網絡棧。如果使用 Docker 默認的 bridge 網絡模式，容器的網絡會經過 Docker 內網轉發，會造成 DERP 的 STUN 服務識別到 Docker 172.17.0.0/16網段下的地址，而 無法識別到客戶端正確的外網地址，導致 Tailscale 客戶端無法正確連接。\nvolumes: - \"/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock\"前面提到所有通過 DERP 的數據都是端到端加密的，DERP 並不知道是誰在使用，這意味著如果不採取措施，任何知道你 DERP 服務器地址和端口號的人都可以使用它。這條配置的作用是掛載宿主機的 Tailscale 套接字文件到容器內，目的是允許 derper 服務通過 Tailscale 的 tailscaled 服務進行身份驗證。配合DERP_VERIFY_CLIENTS=true，可以防止你的 DERP 節點被他人白嫖。\n需要注意的是：\n宿主機必須已經安裝並登陸 Tailscale 客戶端（tailscaled），否則這個文件不存在，容器會報錯； tailscaled 必須以 root 權限運行，才能創建這個 sock 文件。 反向代理 以 Caddy 為例，需要反向代理 4433 端口，併為其部署 SSL 證書。\n{ email webmaster@l3zc.com } *.l3zc.com { encode gzip tls { dns dnspod APP_ID,APP_KEY resolvers 119.29.29.29 223.5.5.5 } @derp host derp.l3zc.com reverse_proxy @derp :4433 }需要注意的是，如果你和我一樣使用 Caddy 配合 dnsproviders 申請泛域名證書，Tailscale 的 MagicDNS 可能會導致 Caddy 本地證書驗證失敗而報錯，需要手動指定resolvers參數解決。\n訪問剛剛反代的節點，如果出現以下頁面，說明配置正確。\n配置 ACL 策略 打開 Tailscale 控制檯的「Access Controls」頁面配置 ACL 策略，將配置好的 DERP 加上。\nTailscale 的 ACL 策略是用 HuJSON3 寫的，想要在 VSCode 中編輯，選擇語言為「JSON with Comments（jsonc）」即可。以下是一個配置示例：\n{ \"acls\": [{ \"action\": \"accept\", \"src\": [\"*\"], \"dst\": [\"*:*\"] }], \"ssh\": [ { \"action\": \"check\", \"src\": [\"autogroup:member\"], \"dst\": [\"autogroup:self\"], \"users\": [\"autogroup:nonroot\", \"root\"] } ], // 自建 DERP 配置 \"derpMap\": { \"OmitDefaultRegions\": false, // 改為 true 以排除官方 DERP \"Regions\": { \"900\": { \"RegionID\": 900, \"RegionCode\": \"sha\", \"RegionName\": \"Shanghai\", \"Nodes\": [ { \"Name\": \"myderp\", \"RegionID\": 900, \"HostName\": \"derp.l3zc.com\" } ] } } } }Tailscale 保留RegionID中的 1-899 作為官方節點，自建節點的 RegionID 必須大於等於 900。\n測試連接 配置好 ACL 並保存，Tailscale 會自動為所有客戶端同步配置，稍等片刻在客戶端用tailscale netcheck測試連接。\n需要注意返回的 IP 是否是自己真實的公網 IP，若返回了172.17.0.0/16網段的地址，說明你 Docker 部分配置錯了。\n與科學上網並存：在 Exit Node 劫持流量到 Clash 內核 聲明 Exit Node 在家中準備一個 24 小時開機的設備，可以是樹莓派，可以是 MacMini。在上面安裝 Tailscale 並將其聲明為 Exit Node，並根據需要在 Tailscale 內網聲明家庭內網網段，隨後在控制檯啟用這個設備作為 Exit Node，你就獲得了一個免費的 VPN，可以讓你在陌生的網絡環境中保持安全。\nsudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24 廣播完成後，無論身處何地，只要能連上 Tailscale 網絡，就能訪問家中所有的內網設備。\n啟用 IP 轉發和禁用 UDP GRO4 啟用 IP 轉發是樹莓派等設備作為 Exit Node 所必須的配置，這裡以樹莓派為例，如果你使用其他設備，請自行查閱 Tailscale 官網教程。\necho 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf sudo sysctl -p /etc/sysctl.d/99-tailscale.conf根據 Tailscale 官方的說法5，禁用 UDP GRO6 可以提升轉發性能，但官方的持久化教程似乎在樹莓派上無效，好在我們可以手動配置。\n# 安裝 ethtool sudo apt update \u0026\u0026 sudo apt install ethtool -y # 關閉 UDP GRO sudo ethtool -K eth0 gro off針對持久化的問題手動編寫 systemd 配置文件：\n# 創建服務文件 sudo nano /etc/systemd/system/ethtool.service文件內容如下：\n[Unit] Description=Configure eth0 GRO After=network.target [Service] Type=oneshot ExecStart=/sbin/ethtool -K eth0 gro off [Install] WantedBy=multi-user.target隨後啟動服務：\nsudo systemctl daemon-reload sudo systemctl enable ethtool sudo systemctl start ethtool在 Exit Node 劫持流量 我的 Exit Node 是一臺樹莓派，在樹莓派上配置好 Exit Node 之後就來到了最後一步，也就是劫持手機發送到 Exit Node 上的流量，實現科學上網。出於穩定性原因，我不希望在家庭主路由上直接運行代理軟件，為了實現這一點，直接在樹莓派上劫持流量是唯一的選擇。\n首先安裝 ShellCrash，請自行根據你的需要導入配置文件、配置自動任務等：\nexport url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' \u0026\u0026 wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh \u0026\u0026 bash /tmp/install.sh \u0026\u0026 source /etc/profile \u0026\u003e /dev/null隨後啟動服務，修改修改防火牆運行模式為純淨模式，我個人建議將 SNI 嗅探打開，並將 DNS 模式從fake-ip切換為redir-host7，同時啟用 IPv6 透明代理。\n設置純淨模式的目的是手動配置 iptables 以實現更精準的流量劫持。我們直接用 iptables 劫持所有 tailscale 網卡作為 Exit Node 轉發的流量，首先用ifconfig查看 tailscale 網卡的名稱，默認情況下一般為 Tailscale 0：\nroot@raspberrypi:~# ifconfig eth0: ...... tailscale0: flags=4305 mtu 1280 inet 100.111.19.50 netmask 255.255.255.255 destination 100.111.19.50 inet6 fd7a:115c:a1e0::3d01:1332 prefixlen 128 scopeid 0x0 inet6 fe80::c0d5:1a1b:2005:48eb prefixlen 64 scopeid 0x20 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 6780155 bytes 958732442 (914.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4811113 bytes 10858316472 (10.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0劫持tailscale0網卡的所有流量到本地 Clash 內核監聽端口7892，這個設置在 ShellCrash 中叫做「靜態路由端口」。以及，如果你不想和我一樣遇到莫名其妙的網絡問題，就一定不要忘記劫持 IPv6。\n# IPv4 劫持 tailscale0 iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892 # IPv6 劫持 tailscale0 ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892進階：用 TProxy 劫持 UDP 流量 iptables 的 REDIRECT 只能重定向 TCP 流量，UDP 沒有連接狀態（無連接協議），所以 REDIRECT 無法保留目標地址，導致透明代理無法知道原始目標地址。\n所以，如果你用如下方式劫持 UDP 流量：\niptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892則這個規則不會生效或代理行為不正常。\n那麼，有辦法代理 UDP 流量嗎？有的兄弟，有的。但前提是：\n核心支持 UDP 透明代理（Clash Premium 和 Mihomo 都支持）； 使用 TProxy 模式，而不是 REDIRECT； 正確配置了 iptables mangle 表和 policy routing； 代理配置文件中啟用了 UDP 代理（如 mode: rule + udp: true）。 假設你已經滿足第一條、第二條和最後一條，則以下是一個示例8：\n# 創建自定義鏈 sudo iptables -t mangle -N SHELLCRASH # 根據自己的需要忽略本地流量 sudo iptables -t mangle -A SHELLCRASH -d 127.0.0.1/8 -j RETURN sudo iptables -t mangle -A SHELLCRASH -d 100.64.0.0/10 -j RETURN sudo iptables -t mangle -A SHELLCRASH -d 192.168.1.0/24 -j RETURN sudo iptables -t mangle -A SHELLCRASH -d 172.17.0.0/16 -j RETURN # mark UDP 和 TCP 到代理 sudo iptables -t mangle -A SHELLCRASH -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233 sudo iptables -t mangle -A SHELLCRASH -p udp -j TPROXY --on-port 7893 --tproxy-mark 233 # 接口跳轉 sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH # 路由表配置 echo \"233 shellcrash\" | sudo tee -a /etc/iproute2/rt_tables sudo ip rule add fwmark 233 lookup shellcrash sudo ip route add local 0.0.0.0/0 dev lo table shellcrash當然，不要忘記 IPv6：\n# 創建鏈 sudo ip6tables -t mangle -N SHELLCRASH6 # 跳過本地地址 sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN # 標記 TCP/UDP ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233 ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233 # 接口跳轉 sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6 # 路由表配置 echo \"233 shellcrash\" | sudo tee -a /etc/iproute2/rt_tables sudo ip -6 rule add fwmark 233 lookup shellcrash sudo ip -6 route add local ::/0 dev lo table shellcrash路由規則持久化 ip rule和ip route創建的規則在重啟後會丟失，所以需要我們手動持久化，最簡單直接的方法就是創建一個腳本，並將其添加至 crontab。\n創建一個腳本：\nsudo nano /usr/local/bin/policy-route.sh編輯為如下內容：\n#!/bin/bash # IPv4 策略路由 ip rule add fwmark 233 lookup 233 ip route add local 0.0.0.0/0 dev lo table 233 # IPv6 策略路由 ip -6 rule add fwmark 233 lookup 233 ip -6 route add local ::/0 dev lo table 233授予執行權限後編輯 Crontab：\nsudo chmod +x /usr/local/bin/policy-route.sh sudo crontab -e在 crontab 文件底部加上如下內容：\n@reboot /usr/local/bin/policy-route.sh原理解釋：TProxy 到底是怎麼轉發 UDP 流量的？ 如果你看到這裡，也許會產生疑惑：為什麼整個流程中，我們沒有在 iptables 裡寫--to-ports，也沒看到目標地址被改寫，UDP 流量就莫名其妙地被代理了？這是怎麼做到的？\n要解釋這個問題，我們先來看 TProxy 和 REDIRECT 的根本區別：\nREDIRECT 模式：\n使用 iptables nat 表； 將目標地址改寫為本地地址（比如 127.0.0.1:7892）； 通常用於 TCP 流量； 不能保留真實目標地址； 需要指定--to-ports。 flowchart TB A[客戶端設備\n通過 Tailscale 發起 TCP 請求] B[tailscale0 接口接收流量] C[iptables NAT PREROUTING\nREDIRECT --to-ports 7892] D[ShellCrash 本地監聽\n127.0.0.1:7892] E[ShellCrash 發起新 TCP 請求\n→ 目標服務器] F[響應從網絡返回\nShellCrash 轉發響應] G[響應回到客戶端設備] A --\u003e B --\u003e C --\u003e D --\u003e E --\u003e F --\u003e G style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000 style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000TPROXY 模式：\n使用 iptables mangle 表； 不修改目標 IP，而是保留原始目標地址； 通過 fwmark 和 policy routing 將報文路由到 lo； 代理程序監聽一個特殊端口（例如 7893），並啟用 IP_TRANSPARENT； 支持 UDP 和 TCP； 不需要 iptables 內指定 --to-ports，因為不是 NAT，而是標記 + 路由。 flowchart TB A[客戶端設備\n通過 Tailscale 發起 TCP/UDP 請求] B[tailscale0 接口接收流量] C[iptables MANGLE PREROUTING\n打上 fwmark 233] D[ip rule: fwmark 233\n使用 routing table shellcrash] E[ip route: local 0.0.0.0/0\ndev lo table shellcrash] F[ShellCrash 在 lo:7893 監聽\nIP_TRANSPARENT 模式] G[ShellCrash 獲取原始目標地址\n發起代理連接] H[響應從網絡返回\nShellCrash 轉發響應] I[響應回到客戶端設備] A --\u003e B --\u003e C --\u003e D --\u003e E --\u003e F --\u003e G --\u003e H --\u003e I style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000 style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000TProxy 不使用 DNAT/REDIRECT，而是通過 mangle 表給數據包打上 mark，然後通過 policy routing（ip rule + ip route）將這些數據包送到 lo 接口。代理程序（如 Clash / ShellCrash）監聽在 lo9 上的端口（例如 7893），通過啟用 IP_TRANSPARENT 選項，可以讀取數據包的原始目標 IP 和端口並進行代理轉發。\n簡而言之，TProxy 模式只需要：\niptables 給數據包打上 mark； ip rule + ip route 將這些包送到 lo； 程序監聽 lo 上的端口並開啟 IP_TRANSPARENT。 所以不需要在 iptables 中指定 --to-ports，因為目標 IP 和端口保持不變，代理程序自己可以感知並處理。\niptables 規則持久化 安裝iptables-persistent：\nsudo apt update sudo apt install iptables-persistent安裝過程中會提示你是否保存當前的 IPv4 和 IPv6 配置，選擇「是」即可。之後如果你添加了新的規則，記得執行保存命令：\n# 保存當前 IPv4/IPv6 規則 sudo netfilter-persistent save保存後的規則文件路徑：\nIPv4：/etc/iptables/rules.v4 IPv6：/etc/iptables/rules.v6 你也可以直接編輯上面的rules.v4/rules.v6文件，按需修改。\n最終效果 這套方案的使用體驗取決於你家的上行帶寬，我家的網絡是下行 500M 上行 60M，目前沒有遇到一次打洞失敗的情況，所以基本都能跑滿，延遲也尚可接受，並且可以在外地隨時隨地端到端加密訪問家中的 Immich 和 OpenWRT 路由器等設備以及實現科學上網，總體來看，我還算比較滿意。\n參考: https://icloudnative.io/posts/custom-derp-servers/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考: https://tailscale.com/kb/1232/derp-servers\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n有關 HuJSON: https://github.com/tailscale/hujson\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考： https://tailscale.com/kb/1408/quick-guide-exit-nodes\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUDP GRO（Generic Receive Offload）是 Linux 內核中的一種網絡優化技術，主要用於合併多個小數據包以提高處理效率。但在設備作為網絡轉發節點的使用場景下，這可能會導致轉發延遲增加和高丟包率環境下的吞吐量下降。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n相較於fake-ip，redir-host兼容性更好，出現問題的概率更低，也不會出現開關代理之後短時間內因為fake-ip殘留而斷網的情況，所以一般情況下我建議使用redir-host搭配 GeoSite 分流規則使用。我這臺樹莓派的 DNS 上游是已經配置好的 SmartDNS，不存在 DNS 汙染的問題，體驗良好。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考: https://blog.zonowry.com/posts/clash_iptables_tproxy/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nlo 是 Linux 系統中默認的「迴環接口（Loopback Interface）」，在透明代理中，它不僅處理 localhost 流量，還被用來接收原本屬於外部世界的網絡連接，實現對外部流量的本地劫持和轉發。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-04-14T10:10:25Z","image":"/2025/04/tailscale-setup-recap/tailscale_hu_62168b00e213c4a1.webp","permalink":"/zh-hant-tw/2025/04/tailscale-setup-recap/","title":"從入門到進階：Tailscale + ShellCrash 異地組網和科學上網"},{"content":" 前言\n文章中提及的部分服務商鏈接為推廣鏈接 (AFF)，如果您通過這些鏈接購買，我會獲得機場的一些餘額。這不僅不會增加你的購買價格，還能幫助我節省開支，感謝大家的支持。\n中國這麼大，每個人的網絡拓撲、系統環境、代理軟件的配置是千差萬別，我這裡用得飛起的線路在你那裡全紅也是非常正常的事情。所以，任何機場，在買之前至少先月付體驗，月付體驗，月付體驗，用著沒問題續費就行。沒有月付套餐的機場就離遠點吧。\n任何機場都有跑路風險，即使是運營數年甚至十餘年的老機場也是如此，請大家在條件允許的情況下儘量月付（至少也先月付覺得好用了再選更長期的套餐），保留自己隨時更換機場的權利，同時也儘量降低機場潛在的跑路風險。\n提筆寫下這篇，本意並非機場評測，而是記錄一下這些年在數字世界裡「穿梭」的經歷。作為一個座標中部的聯通用戶，這是我的主觀和充滿個人色彩的體驗。許多人們曾經耳熟能詳的「機場」也早已成為時代的眼淚，權當一篇個人的雜談與回憶錄吧。\n啟蒙時代 我的故事始於初中時代。那時的網絡環境，與今天相比那還是有點過於寬鬆了，有些事情放在今天甚至根本想都不敢想。工信部剛提及要嚴查VPN，應用商店裡免費的梯子還能隨處下載。當時的我，在 GitHub 上摸索著學會了用一鍵腳本搭建SSR，服務器則是被 AFFMan 忽悠買的 Vultr。\n如今回想，我已經記不清當初為何執著於「出海」——是為了學英語？滿足青春期的好奇？還是沉迷於刷機玩機？原因早已模糊，但結果卻異常清晰：我就這樣踏上了一條「不歸路」。那是一個言論相對寬鬆的年代，QQ 空間可以分享蔡英文勝選的 Facebook 截圖，網絡上流傳著各種習近平的表情包，新聞遠沒有今天這般「清朗」，連QQ群裡都能公開討論哪裡能看片。\n初中的我，課餘生活乏善可陳，唯一的娛樂就是擺弄家裡那臺破舊的電腦。也正是在那時，我一頭扎進了桌面 Linux 的世界，從 Ubuntu 到當年的國產之光 Deepin。在幾個 Linux 交流 QQ 群裡，我頂著隨時可能被沒收手機的風險潛水，也就是在這段時間，我逐漸在網上了解到「機場」這種合租節點的模式，從此開始放飛自我。\n最早的付費體驗 心階雲是我第一個付費的機場。大概在2017年，它剛開業兩年，兩百多元一年的價格在當時已屬中高端。然而，體驗並不算愉快。雖說是中轉線路，卻需要頻繁地手動切換節點，速度時好時壞，有時不更新訂閱就無法使用。一年後，我將它降級為一個幾十塊的年付套餐，正式開啟了我的「主備搭配」時代。後來它改名「自由鯨」，20%的推廣返利也讓我拉了一位同學入坑，這份返現進一步拉低了我的持有成本，讓它穩坐「備胎」之位，直到2023年跑路。\n忍者雲 是我在用過心階雲之後入手的。不知現今狀態怎麼樣，但當年的忍者雲落地質量堪憂，給我印象最深刻的是當時香港節點用的是AWS，刷推都會被風控，這點甚至不如上面的心階雲。核心的使用體驗——速度和穩定性也對不起它不打折時超過四百一年的售價，好在流量給得多，顯得性價比不那麼寒磣。如今它竟也運營了七八年，實屬不易，但估計還是老樣子——落地不行，穩定性欠佳。\n速蛙雲是我心中一段短暫的唯一真神。當時它在 YouTube、Google 上鋪天蓋地地投放廣告，運營相當高調，手筆之大令人咋舌。但不得不承認，他們家的產品力確實很不錯1：晚高峰8K視頻隨便拖，連接穩定，落地 IP 質量出奇地好，註冊 Google 和 Twitter 賬號都能暢通無阻，完全不會出現註冊即風控的情況。這是我第一次真切感到「這筆錢花得值」。\n不僅如此，速蛙雲還附贈共享 PornHub、Netflix 會員和 Shadowrocket 賬號，節點覆蓋全球，連冰島這種小眾地區都有。然而好景不長，在我購入後不久，它便和花捲爆發爭端，隨即在收割一波新用戶後跑路。如今回想，速蛙雲的商業模式本就是個謎：一邊是鉅額的廣告投入，一邊是昂貴的線路和豐富的福利，價格卻不算離譜。或許從一開始，它的結局就已註定。\n長沙黃花國際機場 第一次送人，從停車場出來有個隱蔽的紅綠燈沒看到，直接扣 6 分罰 200，差評。不是航空樞紐，不算繁忙，其他尚可。\n西安咸陽國際機場 感覺國內非航空樞紐城市的機場質量都半斤八兩，咸陽機場動線設計不太合理，平面電梯數量太少，值機 -\u0026gt; 安檢 -\u0026gt; 登機口這條路長到跑斷腿。也許機場把動線拉長有助於塞下更多商鋪來創收，但是近些年生意不好做，機場裡倒閉的店鋪也太多，看著實在有點寒磣。機場 Wifi 質量不錯，其他的就中規中矩。\n高端機場的同質化困境 FlowerCloud 是我在速蛙雲跑路後買的，這幾年兜兜轉轉又回到了它。初體驗不錯，線路飛快。但很快發現，大部分節點都用了 Kirino 和 Eons 的落地（畢竟大家都用他們），加上用的人多，IP 質量自然好不到哪裡去，之前瀏覽 E-Hentai 經常被反爬限制，註冊各類賬號更是奢望。半年 218 元、每月 150G 的價格，即使算上折扣也不便宜，不過好在冗餘比較充分，穩定性和速度在絕大多數時候都是很不錯的。當時似乎存在被人拿來當爬蟲代理池的情況，導致小眾地區節點的 IP 也不那麼幹淨，實測下來該限制的依舊限制，該屏蔽的照樣屏蔽，最終這些小眾地區節點能起到的作用無非就是讓你的 IP 屬地更加酷炫而已，前陣子他們似乎已經意識到了爬蟲氾濫的問題，並且採取了措施，至少現在反爬限制已經肉眼可見的變少了，日常使用已經基本無感。\n📝 備註 最近拔線嚴重，花雲應該是弄了 Anycast，表面上入口變成了境外，實際上流量依然走國內，提升了入口的隱蔽性，參考流量透傳。\n最近他們嘗試了幾個不同的國內機房，但每次都是上線不就就會出現被嚴重 QoS 甚至直接拔線的情況，說明拔線潮仍在繼續，於是只能灰溜溜的用回他們的透傳上游 Cloud Radium。\nYTOO 和花雲給我的感覺：「非常像，特別像，說他們是同一個老闆我都信」。\nGaCloud （現在似乎叫做 WgetCloud）也類似，價格一路從39元/月漲到近60元/月，速度和穩定性都是這個價位應有的水準，但除此之外，他就是一個什麼都不差，但也沒什麼特別突出的特點的機場。也正是這個價格給其帶來了尷尬的定位：貴過大部分機場，但也沒什麼亮點，在其漲價之後我很難再有購買的動力。\nAmyTelecom 被稱為「奶昔青春版」，線路質量和穩定性都很好，審計規則比 CNIX 寬鬆不少。註冊需要手機號驗證，線路和奶昔本站相仿，價格相比奶昔動輒一千多的年付套餐來說親民不少。速度什麼的都沒得說，IP 質量嘛這些大站基本大差不差，唯一美中不足的是落地的地區偏少，基本只有港臺美日這四個地方，不適合在微博上裝 IP 屬地的逼。\nTAG 則與 AmyTelecom 形成了鮮明的對比，這家擁有非常多的落地，各種犄角旮旯地區是應有盡有，當然，真實的服務器位置肯定不會在這些小眾地區，很大一部分都是廣播出來的，不過管他原生還是廣播，能在微博上裝 B 就是好 IP。這家也是這波拔線潮之後為數不多的仍然擁有國內入口的機場，且用且珍惜吧，不要做出像這個 SB 一樣的把訂閱鏈接放到論壇的行為2。他們還提供年付 ¥162/200G 的 Special 計劃，適合用作小流量備用。\n最近用自己的覆寫規則拉取 TAG 的訂閱發現節點全部超時，仔細排查以後發現：他們的節點server首先使用一個隱蔽的域名（甚至可以是別人的），然後通過nameserver-policy定義私有的加密 DNS 來下發線路，這種隱藏線路的方式還真是頭一次見。所以，如果這家發現拉取線路超時的話，就排查一下你的客戶端是否把他們的nameserver-policy給覆蓋掉了，估計他們因為這個原因工單要被開爆，笑死。\n這些年大大小小的機場用下來，你會發現一個殘酷的現實：現在所謂的老牌、中高端機場，體驗其實都大差不差。\n自從運營商開始搞這個極其傻逼的跨省流量 QoS，那些靠著廉價國內機做中轉的平價機場，因為中轉成本飆升基本都死絕了。活下來的大多采用了極其相似的線路方案——比如深港 IEPL 專線，加上 Kirino、Eons、Jinx 這幾家的落地。這就導致了一個很尷尬的局面：既然上游都一樣，大家的落地 IP 質量其實都大同小異。高端機場的價格相仿，體驗也拉不開差距，唯一的區別大概只剩下老闆的運營風格和廣告投放力度了。在追求高端用戶的同時，所有機場都在面臨著同樣的困境：根本無法解決落地 IP 質量不可避免的劣化問題。\n不過，對於這個 IP 質量的問題，其實大可不必過分焦慮。我們追求乾淨的 IP，無非就是為了註冊賬號不被風控，或者少遇到點煩人的反爬驗證碼和 Cloudflare 盾。但你要認清一個現實——既然都拿來開機場賣了，IP 還能有多幹淨？只要用的人一多，再純淨的 IP 最終都會變成下水道。純正的獨享住宅家寬成本極高，日常使用根本不需要、也不值得為了機場 IP 的質量去精神內耗。\n既然大家最終都會淪為下水道，大機場和小機場的區別，僅僅在於對這個下水道的維護水平。體量龐大的大機場，尚有餘力去規管和審計用戶流量：比如限制 BT 下載、屏蔽垃圾郵件端口、屏蔽 SSH 連接以防止腳本小子拿他們去當掃描爆破的跳板。雖然也會犧牲一部分用戶體驗，但起碼能保障 IP 不會徹底爛進各大安全數據庫的黑名單，從而維持住日常上網的舒適度；而那些便宜的低端機場，基本是完全擺爛，大門敞開任由折騰，能連通就行（當然，對於要幹髒活的人來說，這也算是個優點）。\n所以，別再去聽信商家的忽悠，天天拿著 ping0.cc 這種娛樂庫來測去，給自己製造焦慮了。哪怕是那些信誓旦旦標榜美國真實公寓家寬的商家，只要他明確把 IP 質量當成了賣點，你還能指望買這些服務的人不做點髒了 IP 的齷齪事嗎？如果你真有那種極其嚴重的 IP 潔癖，唯一的解法就是自己肉身飛去美國，找當地運營商拉條寬帶來當代理。可就算你真這麼幹了，也不一定能保障分配給你的 IP 就是絕對純淨的——說不定它上個月剛被某個腳本小子放在窯子裡鍛鍊良久，才輪到你接盤呢。\n只要沒這折騰的條件，那就老老實實接受現實，別去追求那些虛無縹緲的東西。選個規矩嚴的大機場，日常夠用、能安穩上網，其實就已經足夠了。\n香港赤鱲角國際機場 很棒的機場。我去的那年還只有兩條跑道，無障礙設施完善，WiFi 給力，還有免費公用電腦。唯一的遺憾是當時正值埃博拉疫情，循環播放的防疫廣播有些破壞心情。後來國泰砍掉港龍航空，長沙再無直飛航班，只能改坐高鐵了。\n桂林兩江國際機場 這個真不太行。我去的時候設施老舊，離市區遠，接駁交通一塌糊塗。海關人員的態度也一言難盡，不知還想不想做世界級旅遊城市了。\n在細分市場裡尋找特色 星島夢、光速雲、極連雲、全球雲 這四家機場出自同一位機場主之手，線路和落地基本一致，實際使用體驗也非常接近。入口根據運營商自動解析，延遲表現很不錯。四家機場線路相仿，區別在於日常打折的時機和活動的力度，每家的性價比算上日常的折扣活動後都還是很不錯的，大家可以來體驗一下。\n星島夢是四家中最早開業的，我從早期測試階段便開始關注，見證了它從最初的摸索，經過機場主熬夜修線路、換落地，逐步達到了可以日用的水準。日常打折後性價比還可以。想吐槽的是之前換來換去的面板地址——老闆喜歡在面板上用香港 CN2 GIA 這類豪華但不耐打的線路，之前一被打就換網址，現在已經套上 Cloudflare，希望能穩定下來。\n老闆人比較實在，雖然他剛開始運營機場可能不如老牌大廠經驗豐富，但勝在態度誠懇、願意花心思去折騰和優化（當然這也會導致有時爆炸）。比如之前因為沒關 IPv6，導致香港節點訪問 Google 時需要過一次 Captcha，老闆收到反饋後很快就給修好了。目前各條線路的流媒體和常用服務解鎖都很正常，具體情況如圖：\n📝 備註 近期工信部嚴格清查跨境專線用於所謂「違規跨境訪問」業務，機房拔線嚴重，這幾家也受到影響，之前一陣子臨時採用過香港中轉。現在開始換到了自己的客戶端，看著像是 FlClash 魔改的，用起來倒是沒什麼大問題。缺點就是我沒法直接拿到訂閱鏈接了，想要玩的當然可以試試 MitM 提取一下實際的訂閱地址。\nCNIX（似乎也叫做薯條）感覺技術實力不錯，當年從合租香港家寬起步，後來憑藉量大管飽的廣港 IPLC 一戰成神。目前定價依然親民，￥239/年，一次性提供 2.5TB 流量，對我而言綽綽有餘（草，漲價到 288 了）。節點繁多，因為有一條大帶寬香港專線，帶寬充足又扛揍，穩定性因此不錯。比較神奇的是，用戶體量明明不小，瀏覽 E-Hentai 卻很少觸及基於 IP 的圖片加載數量限制——只是圖片加載速度會略慢，原因不明。當然，缺點也不是沒有，審計規則是我用過的機場裡相對數一數二嚴格的，ToS 疊甲疊滿，以及「女裝白絲的運維 JK 裙邊料蓋住了進風口導致交換機關機」這種鬼畜運營風格，想知道真實故障原因？別想了。最近他們的線路出現了比較大的變動，有各種針對不同運營商的優化線路（0.5-1倍計費），還有 GoMami 的香港 CN2 GIA（5 倍計費，畢竟這可是針對中國大陸的頂級直連線路）（現在沒了），可玩性還是很高的，可惜審計規則依舊比較繁多。\n良心雲 是我目前用過的直連機場裡體驗最好的，沒有之一。據說是機場主薅各大主流公有云羊毛（「兩塊錢一個月的 AWS」），成本壓得極低，反映到用戶端就是 ¥6/月 1000G 這種幾乎不講道理的定價。速度方面更是沒得挑——晚高峰照樣起飛，這在直連機場裡屬實罕見。主流流媒體解鎖最近也都修好了，性價比直接拉開了和同價位選手的身位。如果非要說隱憂，那就是這種極致性價比本身：過於能打難免樹大招風，DDoS 之類的麻煩恐怕不會少，低成本的公有云薅羊毛模式能維持多久也是未知數。所以，月付、月付、月付，享受一個月算一個月——但只要它還在，那就是廉價直連機場的王。\nWestData 是當初看毒藥評測時發現的，試用下來體驗平平。如今聽說已躋身「二線機場第一梯隊」，對此我深表懷疑，總之不會再續費了。\nIkuuu VPN i坤 VPN ，落地是 Azure（大概率是月拋3的 Azure），線路暫不明確，價格便宜，10 元每月 200G？忘了，總之就是夠輕中度使用。以前晚高峰都能跑滿 500M 的，缺點就是 Azure 的機器風控確實有點太頻繁了，有時候看 YT 都要過一個 Captcha。最近看到別人的測速提到這家因為國內機房的拔線潮體驗降級，拋開這段時間的降級來說，他們的性價比還是很不錯的。\n兩元店 是朋友拉我入坑的，年付 ¥22、每月 1000G 直連，價格確實便宜。節點多為 AWS、Oracle 等月拋機3，速度尚可，審計也比較寬鬆，盧森堡節點就是 BuyVM，可以拿來抗版權投訴下載 BT。這種超低價直連機場日常主力使用並不建議——線路穩定性一般（電信和移動尤甚），月拋機的 IP 質量也實在是不敢恭維。更適合當作備用，或者像我一樣拿來幹些下載 BT、轉發礦池流量的髒活。\nCrush 是我為應對日益頻繁的入口封鎖而找到的一家純 IPv6 入口機場。聯通網絡下體驗還不錯，價格也因 IPv6 入口的低成本而壓到了每月 ¥4 / 150G。當然，純 IPv6 也註定了它無法成為主力——只能在有 IPv6 的環境下發光發熱。\n雅加達蘇加諾-哈達國際機場 \u0026amp; 日惹古冷柏格國際機場 對於雅加達機場我沒什麼特別感覺，回國的時候吃了個和市區同價的 KFC，環境稍髒。而日惹機場中國遊客很多，有中文標識，但國內航班基本沒有廊橋，只能曬曬太陽更健康了。\n治癒「心病」的唯一方法 回顧這趟漫長的「機場漫遊」，我發現自己陷入了一個有趣的循環：總是在追求那個完美的「最優解」，卻又忍不住被下一個「可能性」所吸引。 從最初追求穩定，到後來迷戀大流量，再到對 IP 質量的挑剔……我的需求在不斷變化，而市場上，不論是哪個產品，卻似乎總會在某些方面不盡如人意，讓我每次都不停的換來換去。有時想要節省一些代理開支，可是用著用著發現新鮮的機場，總是忍不住去買個來試試——剛買回來新鮮感十足，每次都覺得這次終於找到了「真愛」，結果用沒多久，又開始懷疑人生，覺得哪裡不對勁了，又想去換，最後是買了幾個機場，計算下來平均每年的花費比高端機場的套餐還要高。\n這種永不滿足的「心病」，讓我積累了一堆小流量套餐，手動管理它們成了一件苦差事。我意識到，市面上現有的工具，已經無法完美安放我那顆愛折騰的心了。它們或者功能不足，或者設計哲學與我的需求相悖。\n於是，一個念頭逐漸清晰：與其繼續尋找，不如親手創造。\n儘管最近很忙，我仍然計劃打造一個全新的、更智能的訂閱管理工具。它並非要顛覆什麼，而是想為像我一樣，擁有多個服務來源、追求極致個性化定製的用戶，提供一個更優雅、更強大的解決方案。\n這不會是一個一蹴而就的項目，更像是我技術探索路上的一個新里程碑。我不確定它最終會走向何方，但我確信，創造的過程，本身就是治癒「心病」的最好良藥。 這段經歷讓我明白，當消費和體驗無法帶來最終滿足時，或許只有一頭扎進這個領域，讓自己的「心病」反過來發光發熱，當心病變成了熱愛，或許才是治癒的開始吧。\n曾經的速蛙雲服務質量非常不錯，基本跑滿帶寬。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n不過這家也對訂閱拉取做了嚴格限制，打開訂閱開關後才會開放 5 分鐘訂閱，所以想做也做不了這種事。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n指的是無法長期續費使用的，非常規價格售賣的雲服務產品。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-04-05T12:18:50Z","image":"/2025/04/proxy-provider-recap/cover_hu_29e3f759cc152b82.webp","permalink":"/zh-hant-tw/2025/04/proxy-provider-recap/","title":"永恆的選擇困難症：那些年我用過的機場"},{"content":"改用自己的 Mihomo 覆寫規則後，手機從 Google Play 上下載應用就會一直轉圈圈，而換用機場的規則就沒問題，非常奇怪。遂調取 Mihomo 內核日誌查看。\nplay-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 靜態資源[🇭🇰 香港 07] play.googleapis.com:443 match GeoSite(GFW) using 節點選擇[🇭🇰 香港 07] play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 靜態資源[🇭🇰 香港 07] play-fe.googleapis.com:443 match GeoSite(GFW) using 節點選擇[🇭🇰 香港 07] services.googleapis.cn:443 match GeoSite(CN) using 全球直連[DIRECT]（以上日誌已精簡）\n國行手機內置的 Google Play 服務使用services.googleapis.cn而非services.googleapis.com域名提供服務，而這個域名在大多數分流規則中都是直連，對，問題就出在這裡，修改規則把這個域名分流到代理就萬事大吉了！\n……萬事大吉了，嗎？\nrr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07] rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07] rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07]等等，為什麼每次從 Play 商店下載應用都會出現這些奇怪的域名？在網上查找一番資料後，新世界的大門就此打開。\n與 Google 截然相反卻又異曲同工的 Ångströ 看到 xn\u0026ndash;ngstr-lra8j.com，熟悉域名的同學肯定知道，這是 PunyCode 編碼，這串字符解碼後就是 ångströ.com。Anders Jonas Ångström 是一位瑞典物理學家，他是光譜學的奠基人。1埃斯特朗（Ångström）是為紀念他而以他的名字命名的長度單位，$ 1 Å = 10^{-10} m = \\frac{1}{10} nm $，通常用於描述非常短的距離，比如原子和分子尺寸或光的波長。其代表極端小的量級，尤其是在物理學和化學中用於精細測量。\n雖然 Google 的名字並不是直接取自「Googol」，但是它的靈感來源於該詞。「Googol」是一個數學術語，表達$10^{100}$，即1後面跟著100個零，是一個極其龐大的數字，常用來表示計算機科學中涉及的巨大數字或信息量。\n在命名哲學上，Google 與Ångströ 這對看似分處光譜兩端的科技概念，卻展現出耐人尋味的對稱美學。前者源於數學概念「Googol」的創造性改寫，後者則脫胎於物理單位「Ångström」的意象重構。這兩個經過藝術化變奏的稱謂，恰似科技文明的雙螺旋：Google 之稱承載著駕馭浩如星海的數字宇宙的雄心，Ångströ 之謂則暗喻著雕琢精微的原子級技術圖景。當這兩個經過創造性變形的專業術語在硅谷相遇，恰好構成了一組完美的認知座標——既指向人類處理信息的尺度極限，也昭示著科技文明同時向宏觀與微觀進軍的壯闊征程。\n入門密碼學：Google 基礎設施域名的規律2 OK，enough。現在讓我們把視角轉回 Google 的基礎設施。先來看一些完整的連接域名：\nrr4---sn-j5o7dn7s.xn--ngstr-lra8j.com rr1---sn-j5o76n7z.xn--ngstr-lra8j.com rr5---sn-i3b7knzs.xn--ngstr-lra8j.com這些看似隨機的字符串，實際上是經過一些簡單的密碼學加密後的結果。讓我們拆解其中的核心部件。\n城市名稱的轉換規則 以rr1---sn-j5o76n7z為例，關鍵的信息段在sn-後面的 8 位：r1---sn-[123][45][6][78]。前三位，也就是本例中的j5o是城市名稱，由該城市主要機場的 IATA 碼通過一定的密碼學變換轉換而來。\n首先構建一張 5 * 7 的數字字母表：\n行0: 1 0 2 3 4 行1: 5 6 7 8 9 行2: a b c d e 行3: f g h i j 行4: k l m n o 行5: p q r s t 行6: u v w x y逆時針旋轉這張表，即從新表格的左下角開始，依次按照原表格「從左到右，從上到下」的順序，把原表的數據在新表上按照「從下到上，從左到右」的順序謄抄。\n旋轉完成後，可以得到下表：\n| 6 d k r y | | --------- | | 5 c j q x | | 4 b i p w | | 3 a h o v | | 2 9 g n u | | 0 8 f m t | | --------- | | 1 7 e l s |表格中間用線條框出來的 5*5 的部分就是最終的密碼錶，一共有 25 個字符，「從左到右，從上到下」依次代表字母a到字母y。例如，上海虹橋國際機場的 IATA 代碼為sha,我們可以通過這張表得到加密後的密文：\ns在字母表中是第 19 個字母，「從左到右，從上到下」依次在密碼錶中數到第 19 個字符，也就是n h在字母表中是第 8 個字母，「從左到右，從上到下」依次在密碼錶中數到第 8 個字符，也就是i a在字母表中是第 1 個字母，「從左到右，從上到下」依次在密碼錶中數到第 1 個字符，也就是5 加密後的密文就是ni5。\n反之亦然，回到一開始的城市名稱j5o，從我們剛剛得到的密碼錶中反推出原文：\nj按照「從左到右，從上到下」的順序是第 3 個字符，也就是c 5按照「從左到右，從上到下」的順序是第 1 個字符，也就是a o按照「從左到右，從上到下」的順序是第 14 個字母，也就是n 翻譯完成的明文是can，也就是廣州白雲國際機場的 IATA 碼，顯然，我們連接到的服務器位於廣州。\n要是谷歌有某個服務器位於蘇黎世，而蘇黎世機場的 IATA 碼是zrh，有一個字母z，可是我們的密碼錶只有a到y啊？別擔心，Google 當然也考慮到了這個問題，z對應密碼錶中的1。\n將這套規則用代碼表示如下：\ntable = \"5cjqx4bipw3ahov29gnu08fmt1\" def iata2cipher(iata): global table iata = iata.upper() cipher = \"\" for element in iata: index = ord(element) - 65 cipher += table[index] return cipher def cipher2iata(cipher): global table cipher = cipher.lower() iata = \"\" for element in cipher: index = table.find(element) iata += chr(65 + index) return iata # print(iata2cipher(input(\"IATA:\"))) # print(cipher2iata(input(\"Cipher:\")))服務器組編號 [45]和[78]位，如76和7z，表示服務器組（接入點）編號，由下表第一列（已經用分隔線隔開）包含的字符組成，7elsz6dkry分別代表0123456789。所以，76的明文是05，7z的明文是04。\n| 1 2 3 4 5 6 7 | 8 9 a b c d e | f g h i j k l | m n o p q r s | t u v w x y z | 0 1 2 3 4 5 6 | 7 8 9 a b c d | e f g h i j k | l m n o p q r | s t u v w x y | z以 Python 表示如下：\ncodeTable = \"7elsz6dkry\" def cipher2code(cipher): global codeTable cipher = cipher.lower() codeString = \"\" for element in cipher: index = codeTable.find(element) codeString += chr(index + 48) return codeString # print(cipher2code(input(\"Cipher:\")))同樣要將數字加密為密文同理，這裡不再贅述。\n支持協議 [6]位表示網絡協議信息：\nn：IPv6（地址段 0x000-0x3FF） u：IPv6（地址段 0x400-0x7FF） m：僅支持 IPv4 例如：\na5mekn7r，IPv6 前綴：2607:f8b0:4007:a::/64，IPv4 前綴：74.125.103.0/24 a5m7zu7r，IPv6 前綴：2607:f8b0:4007:407::/64，IPv4 前綴：74.125.215.0/24 a5mekm76，僅支持 IPv4，前綴：208.117.242.0/24 正確的分流處理 ⚠️ 警告 Google 顯然不會為這些位於中國大陸的，未經 ICP 備案的 CDN 的穩定性和速度背書。如果流量足夠，那還是直接將services.googleapis.cn加入代理列表吧。\n瞭解了 Google 基礎設施域名的加密規律後，我們可以根據這些信息實現更精準的分流策略。目前已知 Google 在中國大陸的 CDN 節點主要分佈在北京（2x3）、上海（ni5）和廣州（j5o），對應的域名特徵可以通過正則表達式識別：\nrules: - DOMAIN-REGEX,^r+[0-9]+(---|\\.)sn-(2x3|ni5|j5o)\\w{5}\\.xn--ngstr-lra8j\\.com$,DIRECT這條規則會匹配所有形如 rr1---sn-j5o76n7z.xn--ngstr-lra8j.com 的國內 CDN 域名，並將其標記為直連。而對於其他未被覆蓋的 Google 域名（如 play.googleapis.com 等），仍遵循原有的代理規則。\n事實上，GeoSite 數據庫的上游 v2fly/domain-list-community 已針對 Google Play 的國內 CDN 節點進行了優化3。只需在 Mihomo 配置中啟用 GEOSITE,GOOGLE-PLAY@CN 規則，即可自動實現國內 CDN 直連與海外域名代理的智能分流：\nrules: - GEOSITE,GOOGLE-PLAY@CN,直連 - GEOSITE,GOOGLE,代理 參考: https://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考: https://github.com/lennylxx/ipv6-hosts/wiki/sn-domains\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n具體的commit: https://github.com/v2fly/domain-list-community/pull/2436/commits/a86c1bf3d9bf577869180874d87c76ddf6282fc1\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-03-15T13:15:01Z","image":"/2025/03/chinese-cdn-used-by-playstore/cover_hu_8e92ca92eba5064b.webp","permalink":"/zh-hant-tw/2025/03/chinese-cdn-used-by-playstore/","title":"Google Play 商店的國內 CDN：從密碼學入門到分流策略優化"},{"content":"當我趁著春節各家機場的促銷訂閱多個機場之後，如何充分利用每個節點就變成了說難不難說簡單也不簡單的問題，我當然可以訂閱各家機場提供的配置文件，然後在他們之間切換，但這樣未免也太麻煩了。更何況我還有自建節點，我可不想為了這一個節點專門去開一個新的配置。\nSub-Store 很好的解決了這個問題，它可以從多個訂閱中抽取節點信息，通過正則表達式或者 JS 整理它們，最後輸出一個整合了所有節點信息的訂閱。\n部署它可以直接使用 xream 打包好的鏡像，這個鏡像整合了前後端，如果在公網部署，記得更改一下後端路徑，否則你的配置文件很可能會被盜用。\nservices: sub-store: image: xream/sub-store container_name: substore restart: always environment: - SUB_STORE_CRON=55 23 * * * - SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path ports: - \"3001:3001\" volumes: - ./data:/opt/app/data反代 3001 端口即可訪問 Substore 的前端，這裡以 Caddy 為例：\nsub-domain.example.com { reverse_proxy :3001 }當然，初次進入前端別忘了新增後端地址，這時的後端地址取決於之前 compose file 裡的設置，在本文的例子中，後端地址為https://sub-domain.example.com/super-random-path。\n組合訂閱的管理 添加所有機場上游和自建節點之後，就可以開始把它們全都加進單個組合訂閱，但各個機場對節點的命名五花八門，默認情況下看起來非常雜亂，甚至不同機場之間的節點還有重名的可能。好在 Sub-Store 有通過腳本對節點進行批量重命名操作的功能，這裡推薦一個腳本，能夠幫我們為所有的機場節點重命名。\n欲使用這個腳本，只需在編輯訂閱時將以下地址粘貼到腳本操作處即可。\nhttps://raw.githubusercontent.com/Keywos/rule/main/rename.js 最後再進行一些你喜歡的節點操作，可以整理出一個統一規範的節點列表。\n生成 Clash 配置 現在雖然已經有了節點列表，但現在生成的配置文件並不包含任何規則，需要自行編寫或者拉取第三方規則。\n轉到 Substore 的文件管理，創建一份新的 Mihomo 配置：\n「來源」選擇組合訂閱，並在訂閱名稱上選擇你的訂閱組 在腳本操作中填入自己的覆寫配置 這是我自己的覆寫規則 powerfullz/override-rules，為 Mihomo/Substore 設計，核心特色如下：\n集成 SukkaW/Surge 與 217heidai/adblockfilters 等優質規則，兼容性強，覆蓋面廣。 針對 Truth Social、E-Hentai、TikTok、加密貨幣等場景，新增專用分流規則，滿足多樣化需求。 精簡冗餘，結構清晰，維護便捷。 深度融合 Loyalsoldier/v2ray-rules-dat GeoSite/GeoIP，分流更精準。 IP 規則默認添加 no-resolve，有效減少本地 DNS 解析，提升速度與隱私。 動態覆寫：自動識別節點國家/地區，僅生成實際存在的分組，節點名稱實時枚舉，配置更智能。 JavaScript 格式覆寫 複製 JavaScript 格式覆寫文件的鏈接https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js，並根據需要在後面附加參數，格式如下：\nhttps://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#參數1=true\u0026參數2=true目前支持如下參數：\n參數 功能 loadbalance 啟用國家/地區節點組的負載均衡 landing 啟用落地節點功能 ipv6 啟用 IPv6 支持 full 生成針對純內核使用場景的完整配置 keepalive 啟用 TCP KeepAlive quic 允許 QUIC 流量1 fakeip DNS 增強模式使用 fake-ip2 regex 各國家代理組改用 include-all + 正則過濾模式3 threshold 國家/地區節點數量小於該值時不顯示分組（默認 0） 例如，若有負載均衡和 IPv6 需求，最終的覆寫腳本鏈接為：\nhttps://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#loadbalance=true\u0026ipv6=true將最終的覆寫腳本鏈接粘貼到腳本操作處，使用 Substore 的生成預覽功能確認沒有問題後即可保存。\nYAML 格式覆寫 YAML 格式覆寫我自己已經不用了，隨緣維護，但歡迎 PR\n寫了個 Github Actions 自動根據 JS 格式覆寫生成 YAML 格式覆寫，所以現在 YAML 格式又開始維護了。\n除了直接引用 convert.js 動態覆寫，你也可以使用倉庫中預先生成好的 32 份 YAML 格式覆寫——它們都放在 yamls/ 目錄裡，由 GitHub Actions 在每次推送後自動重新生成、覆蓋。適用於諸如 Clash Verge 等不支持 JS 覆寫的客戶端和轉換服務。\n文件命名規則：\nconfig_lb-{0|1}_landing-{0|1}_ipv6-{0|1}_full-{0|1}_keepalive-{0|1}_fakeip-{0|1}_quic-{0|1}.yaml示例（開啟 full，其餘關閉）：\nhttps://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/yamls/config_lb-0_landing-0_ipv6-0_full-1_keepalive-0_fakeip-0_quic-0.yamlCI 只是套用一份假的fake_proxies.json來生成覆寫，所以不可能實現 JS 覆寫自動根據節點匹配生成對應代理組的功能，只能把所有地區節點組都放進去。如果你已經搭建 Substore，並且想要「動態識別國家 + 傳參」的靈活性，還是推薦使用 JS 覆寫。\n生成下載鏈接 保存成功後點擊分享按鈕生成分享鏈接，設置分享有效期後點擊「創建分享」，生成的鏈接即最終成型的 Mihomo 配置文件，將其作為訂閱鏈接在你的代理軟件內訂閱就大功告成了。\n部分機場 UDP 性能差，開啟後可能出現體驗降級。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n開啟後可能有助於解決 TUN 模式無法上網的問題。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n各國家代理組改用 include-all + 正則過濾模式，由 Mihomo 內核在運行時按正則動態篩選節點，而非在腳本執行時枚舉節點名稱（默認 false）\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-03-07T10:54:29Z","image":"/2025/03/clash-subscription-convert/image-8_hu_92098803a4bf150d.webp","permalink":"/zh-hant-tw/2025/03/clash-subscription-convert/","title":"最速 Substore 訂閱管理指南"},{"content":"最近在白宮發生的鬧劇，想必大家都知道了。穩定運行數百年政治制度如今卻迎來了川普、萬斯和馬斯克這三個流氓，其道德之敗壞，行徑之惡劣，手段之下作在整個美國曆史乃至世界史上都前所未見。僅僅三週的時間，美國幾百年苦心經營積累的信譽，地位和權力，都被「三人幫」拿去衝了廁所，讓全世界都真真正正看了一回美國的笑話。\n川普的真面目 川普是謊言、腐敗和自私自利的高手，他是被定罪的重罪犯，進行總統選舉幾乎就是為了避免坐牢，現在二進宮，也不改他的罪犯本性——他赦免國會暴力案的罪犯，新聞發佈會上謊話連篇，外交場合公然羞辱他國元首，放任馬斯克訪問政府敏感數據以及大幅削減民生開支，打著保護美國產業的旗號對他國商品加徵關稅，實際上卻是向窮人加稅，對富人減稅。\n他不在乎美國的利益，不惜以犧牲現有的國際秩序和美國的國際信譽與地位為代價，維護他所謂的「朋友」的面子，也許這就是獨裁者之間的心有靈犀，臭味相投。他計劃以法西斯獨裁者的身份統治，而這一次，他得到了足夠的支持來實現這一目標。他本人負責在媒體面前放出煙霧彈，掩護馬斯克帶領的 DOGE 和萬斯繞過國會攪亂政府部門和最高法院。他們以反對 DEI 作為為掩護，實際上正在構建系統性壓迫機制。先製造文化戰爭煙霧彈，再趁公民社會來不及反應的這段時間，削弱民權，強化總統權力，最終從根本上打壓打壓一切政治對手，以犧牲美國人民的利益為代價，維護諸如馬斯克等商業寡頭、億萬富翁的精英白人群體的既得利益。\n在以特朗普、馬斯克等人為代表的 MAGA 運動的影響下，美國社會可能會進一步向右轉。這種趨勢可能為更加保守的議程鋪平道路，並對教育、移民、勞工政策等領域產生深遠影響。同時，這種政治氛圍可能使科學種族主義、性別歧視和優生學思想在主流政治中獲得更大空間，從而削弱美國憲政民主的基礎。至於那些被視為「內部敵人」的群體——所有不是「順從的白人異性戀男性」的人——等待他們的將是被送進納粹集中營、驅逐出境、監禁、針對性的謠言和死亡威脅。\n有時候真的不得不感嘆 I can\u0026rsquo;t believe that the American people are dumb enough to re-elect this man into power.\n","date":"2025-03-03T14:44:08Z","image":"/2025/03/the-worst-guy-to-be-president/cover_hu_6ad90c7eb58493bd.webp","permalink":"/zh-hant-tw/2025/03/the-worst-guy-to-be-president/","title":"The Worst Guy to Be a President"},{"content":"人在中國，用起 DNS 會碰到兩個問題，一個是 DNS 汙染，另一個是 DNS 洩露。想要上網上得痛快，就必須要先解決 DNS 的問題。\n什麼是 DNS 洩露 如果你現在正在開著代理看這篇文章，可以先打開這個網站檢測一下自己的 DNS 請求是否被髮送到了國內的 DNS 服務器上。\n簡單來說，當你在使用 VPN 等代理工具時，你認為你的請求不會被除了你和 VPN 提供商以外的第三方看到，然而主機的 DNS 請求卻被髮送送給了運營商的 DNS 服務器或者是公共 DNS 服務器(阿里、騰訊等)進行解析，而你的真實 IP 地址和請求的域名都會被記錄下來。如果 DNS 請求解析一些敏感網站的域名(比如電報、維基解密等)，就會被監管者注意到，從而被警告或者請去喝茶。1\n因此，正確地配置代理工具的分流策略來避免 DNS 洩露就顯得尤為重要。\nSmartDNS 的配置 防止 DNS 洩露 DNS 作為上網的指路人，排在第一位的要求就是必須要快，在這樣的要求下本地部署 SmartDNS 充當家庭網絡的 DNS 服務器真的再合適不過了。關於 SmartDNS 的作用和配置技巧，以及其如何優選 CDN 加快網絡訪問速度，Sukka 的「我有特別的 DNS 配置和使用技巧」已經講的很好，推薦在繼續閱讀本文之前先去看看這篇文章，其中的內容我在這裡便不再贅述，我的敘述重心將會放在如何在 Luci 界面上實現這些配置。\n如果你和我一樣使用 OpenWRT，SmartDNS 的 Luci App 會在每次啟動時根據面板上保存的配置自動生成新的配置文件，所以，不要直接修改/etc/smartdns目錄下原有的配置文件，所有的更改都應該在 Luci App 裡操作。\n基本上，SmartDNS 上游數量越多越好，因為較多的上游並不會影響 SmartDNS 的性能2，並且多個上游可以增加冗餘。為了防止 DNS 洩露，在配置上游時，應當在默認分組添加國外 DNS 上游（當然，最好是加密 DNS），並將國內的服務器歸入一個單獨的分組（例如domestic），並加上-exclude-default-group的額外參數以將它們從默認分組中排除。\n加速國內域名解析 設置好國外上游，DNS 洩露的問題就解決了，但因為我們在默認分組中排除了國內上游，訪問新的域名時需要等待國外上游返回結果，這顯然會拖慢國內網站的訪問速度，並且還會劣化 CDN。\ndnsmasq-china-list 是 Felix Yan 的項目，目前支持通過 Makefile 生成 SmartDNS 格式的配置文件，目前已經有人做好了現成的 Github Action 每天自動更新，直接下載就可以了，注意這些配置文件只會在國內 DNS 上游分組名稱為domestic時生效。\ncd /etc/smartdns wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf隨後在 SmartDNS 中引入這些配置文件，將下面的內容粘貼到「自定義設置」欄的末尾。\nconf-file /etc/smartdns/accelerated-domains.china.domain.smartdns.conf conf-file /etc/smartdns/apple.china.domain.smartdns.conf conf-file /etc/smartdns/chinalist.domain.smartdns.conf conf-file /etc/smartdns/google.china.domain.smartdns.conf 這樣配置之後，國內域名的訪問速度便不再會受到影響，訪問國外域名時，也不會再有 DNS 洩露的問題了。\n去廣告 DNS 層面的去廣告效果有限，重點應該放在防止誤殺上，所以不要用那臭名昭著3的號稱自己是「致力於成為中文區命中率最高的廣告過濾列表」的 Anti AD，而是使用一些別的規則。個人使用的規則是 217heidai/adblockfilters，這是一個已經整理好的聚合規則，直接拉取即可。\nwget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf最後引入配置文件：\nconf-file /etc/smartdns/adblock.conf自動更新規則 設置如下 Crontab 即可在每天凌晨三點自動更新所有規則。\n0 0 3 * * ? wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf 0 0 3 * * ? wget -O /etc/smartdns/accelerated-domains.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf 0 0 3 * * ? wget -O /etc/smartdns/apple.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf 0 0 3 * * ? wget -O /etc/smartdns/chinalist.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf 0 0 3 * * ? wget -O /etc/smartdns/google.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf旁路由可以用嗎 除非不使用 IPv6，否則最好還是將 OpenWRT 路由器作為主路由。在作為旁路由的情況下，某些系統（說的就是你，Windows）會不遵守旁路由廣播的 IPv4 DNS，而執意使用運營商光貓廣播的 IPv6 DNS 進行解析，我嘗試修改過一些相關的註冊表鍵值，但毫無作用。無奈只好讓運營商上門將光貓改為橋接模式，並將 OpenWRT 用作主路由。\n覆寫 Clash 規則 這時如果你開著 Clash 去跑 DNS 洩露測試，大概率還是會看到你的 DNS 請求被髮到了中國的 DNS 服務器上——幾乎所有機場的默認配置都會使用騰訊、阿里等國內大廠的加密 DNS，雖然不至於明文洩露到運營商 DNS 而導致你接到反詐中心的電話，但總讓人膈應 （強迫症犯了），更有甚者甚至完全沒有相關配置。\n好在如果使用的是 Clash Verge Rev，那麼可以很方便的覆寫機場的配置，這裡分享我的覆寫配置，將其粘貼到全局擴展配置中即可覆寫機場的配置。\ndns: enable: true ipv6: false prefer-h3: true use-system-hosts: true nameserver: - \"https://dns.cloudflare.com/dns-query\" - \"https://dns.sb/dns-query\" - \"https://dns.google/dns-query\" - \"https://public.dns.iij.jp/dns-query\" - \"https://jp.tiar.app/dns-query\" - \"https://jp.tiarap.org/dns-query\" nameserver-policy: \"geosite:cn\": - system fallback: - \"tls://8.8.4.4\" - \"tls://1.1.1.1\" proxy-server-nameserver: - \"https://doh.pub/dns-query\" - \"https://223.5.5.5/dns-query\" direct-nameserver: - system 配置解析 根據 Mihomo 文檔4，其 DNS 請求的流程如下：\nflowchart TD Start[客戶端發起請求] --\u003e rule[匹配規則] rule --\u003e Domain[匹配到基於域名的規則] rule --\u003e IP[匹配到基於 IP 的規則] Domain --\u003e |域名匹配到直連規則|DNS IP --\u003e DNS[通過 Clash DNS 解析域名] Domain --\u003e |域名匹配到代理規則|Remote[通過代理服務器解析域名並建立連接] Cache --\u003e |Redir-host/FakeIP-Direct 未命中|NS[匹配 nameserver-policy 並查詢 ] Cache --\u003e |Cache 命中|Get Cache --\u003e |FakeIP 未命中,代理域名|Remote NS --\u003e |匹配成功| Get[將查詢到的 IP 用於匹配 IP 規則] NS --\u003e |沒匹配到| NF[nameserver/fallback 併發查詢] NF --\u003e Get[查詢得到 IP] Get --\u003e |緩存 DNS 結果|Cache[(Cache)] Get --\u003e S[通過 IP 直接/通過代理建立連接] DNS --\u003e Redir-host/FakeIP Redir-host/FakeIP --\u003e |查詢 DNS 緩存|Cache其中nameserver-policy的優先級高於nameserver和fallback，指定geosite:cn中的網站以系統 DNS 查詢，也就是使用之前配置好的 SmartDNS 查詢，可以享受到局域網級別的響應速度和自帶測速的 CDN 選擇。而不在geosite:cn中的網站則使用nameserver/fallback查詢，使用國外加密上游就可以確保解析結果的可信並防止 DNS 洩露。\n替換 geoip 和 geosite 數據庫 Mihomo 默認使用 V2Ray 官方的 geoip 和 geosite 數據庫，這個數據庫其實不太全，而且更新的頻率也很慢，所以我還是用 Loyalsoldier/v2ray-rules-dat 這個「加強版」數據庫替換了原來的數據庫，只需下載geoip.dat和geosite.dat以後丟進內核目錄即可。當然，也可以新增幾行覆寫配置以實現自動/一鍵更新：\ngeodata-mode: true geox-url: geoip: \"https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat\" geosite: \"https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat\"Clash Meta For Android 對於手機上的 Clash Meta For Android（以下簡稱 Clash），覆寫設置時需要更加考慮手機的實際情況。\n首先手機上的 Clash 覆寫設置選項就不如桌面端的 Clash Verge Rev 這麼靈活，很多鍵值都不能覆寫。另外，手機不像電腦，需要經常切換網絡環境，這就導致系統 DNS 也會換得很頻繁，經測試，在這種情況下，每次更換網絡環境都需要開關一次 Clash 才能讓其更新system所代表的 DNS。於是我們只能退而求其次，固定一個國內加密 DNS 作為國內查詢。\n進入 Clash -\u0026gt;「設置」-\u0026gt;「覆寫」以下是所有覆寫設置：\n「DNS」-\u0026gt;「策略」：強制啟用 「DNS」-\u0026gt;「Prefer h3」：已啟用 「DNS」-\u0026gt;「Name Server」：添加兩個國外加密 DNS 「DNS」-\u0026gt;「Name Server 策略」：在「鍵」一欄中填寫geosite:cn，值一欄填寫https://doh.pub/dns-query 提前從 Github 上下載geoip.dat和geosite.dat，最後進入 Clash -\u0026gt;「設置」-\u0026gt;「Meta Features」，分別用「導入 GeoIP 數據庫」和「導入 GeoSite 數據庫」功能導入它們。\n完成 最後再打開一個 DNS 洩露測試，看一看問題是否解決，如果不再出現國內的 DNS，說明配置正確，好好享受 SmartDNS 和 Clash 帶來的網絡優化和防洩漏吧~\n參考自: https://blog.lololowe.com/posts/8f1e/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSmartDNS 在設計時就考慮到了延遲問題，具體機制可以參考「中場休息：SmartDNS 是如何避免因測速導致 DNS 解析過慢的」。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n有人整理了 Anti AD 的光榮事蹟。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n引用自: https://wiki.metacubex.one/config/dns/diagram/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2025-02-06T09:01:51Z","image":"/2025/02/what-i-have-done-on-my-dns/cover_hu_1bda1c3daad4bc1b.webp","permalink":"/zh-hant-tw/2025/02/what-i-have-done-on-my-dns/","title":"我的家庭網絡域名解析方案"},{"content":"近期進行了一個小測驗，發現了一些我在電力系統分析方面基礎知識的疏漏，遂整理一篇筆記。現在我將這篇筆記中相對通用且有價值的部分分享出來，希望能對正在閱讀這篇文章的你起到一些幫助。\n分裂導線的作用 相較於普通導線，分裂導線後等效的 $r_{eq}$ 增大，從而減小了線路電抗，降低了電暈發生的可能性，提高了整個系統的靜態穩定極限，以下是我整理的分裂導線的作用：\n降低線路電抗 $X$\n$$ r_{eq} \\uparrow \\Longrightarrow \\begin{equation} \\left\\{ \\begin{array}{lr} x_1 \\downarrow = 0.1445 \\lg \\left( \\frac{D_m}{r_{eq} \\uparrow} \\right) + 0.0157 \\mu_r \\, (\\Omega/\\text{km}) \u0026 \\\\ b_1 \\uparrow = \\omega C_1 = \\frac{7.58}{\\lg \\left( \\frac{D_m}{r_{eq} \\uparrow} \\right)} \\times 10^{-6} \\, (\\text{S/km}) \u0026 \\end{array} \\right. \\end{equation} $$因為電納 $b$ 的變化規律與電抗 $x$ 幾乎相反，所以也可以直接得出分裂導線會增大電納的結論。\n提高電暈臨界電壓 $U_{cr}$\n$$ U_{cr} \\uparrow= E{cr} \\cdot r_{eq} \\uparrow \\cdot \\frac{n}{K_{n}} \\cdot \\ln \\frac{D_m}{r_{eq} \\uparrow} $$ 提高靜態穩定極限 $P_{M}$\n$$ P_{M} \\uparrow = \\frac{E_{q}U}{X \\downarrow} $$ 減小線路波阻抗 $Z_{c}$，進而提高線路的最大傳輸功率。\n$$ Z_{c} \\downarrow = \\sqrt{\\frac{X \\downarrow}{B \\uparrow}} = \\sqrt{\\frac{L}{C}} $$自然功率 $P_{natural} \\uparrow = \\frac{U_{n}^2}{Z_{c} \\downarrow}$，而總功率 $P = P_{n} \\times \\frac{1}{\\sin{\\beta} L}$，所以分裂導線可以提高線路的最大傳輸功率。\n變壓器分接頭的選擇 看例題：已知某變壓器變比為 $110(1 \\pm 2 \\times 2.5\\%) / 11\\text{kV}$，容量為 $20 \\text{MVA}$，低壓側母線的最大負荷為 $10.8 + j14.4 \\text{MVA}$，最小負荷為 $4.9 + j5 \\text{MVA}$，歸算到高壓側的變壓器參數為 $5 + j60 \\Omega$，變電所高壓側母線在任何情況下均維持電壓為 $107 kV$，為了使低壓側母線保持順調壓，該變壓器應當選擇哪個分接頭？\nA. 主接頭檔，$ U_1 = 110 kV $\nB. 110(1 - 5%) 檔，$ U_1 = 104.5 kV$\nC.110(1 + 2.5%)檔，$U_1 = 112.75 kV$\nD.110(1 - 2.5%) 檔，$ U_1 = 107.25kV$\n一個公式：$U_{TJ} = U_2\u0026rsquo; \\cdot \\frac{U_{2N}}{U_2}$\n其中 $U_2\u0026rsquo;$ 為歸算到一次側的二次側電壓，$U_{2N}$ 為變壓器二次側額定電壓，$U_2$ 為實際的要求電壓。為了計算得到分接頭電壓 $U_{TJ}$，需要分別求出最大負荷時的分接頭電壓 $U_{TJmax}$ 和最小負荷時的分接頭電壓 $U_{TJmin}$，再將兩者取平均值得 $U_{TJav}$，最後選取最接近 $U_{TJav}$ 的分接頭。題目中，變壓器二次側額定電壓 $U_{2N}$ 為 11kV。$U_2$ 的確定則需要參考知識點「中樞電壓的調整方式」。\n中樞點電壓的調整方式 調壓方式 最大負荷要求電壓（不小於） 最小負荷要求電壓（不大於） 特點 順調壓 $ 1.025 U_N $ $ 1.075 U_N $ 難度最小，適用於供電範圍小，線路不長，供電要求低的場景。 逆調壓 $1.05U_N$ $U_N$ 難度最大。 常調壓（恆調壓） $1.02U_N\\sim1.05U_N$ $1.02U_N\\sim1.05U_N$ 注意這個表格中的 $U_N$ 為低壓側母線的額定電壓。\n題目中要求低壓側母線保持順調壓，且低壓側額定電壓可輕易看出（1.1 倍額定電壓 = 11kV）為 10kV，則最大負荷時 $U_{2max} = 1.025 U_N = 10.25kV$，最小負荷時 $U_{2min} = 1.075 U_N = 10.75 kV$，歸算到高壓側的低壓側額定電壓則需要在高壓側電壓的基礎上減去變壓器的電壓降落，具體計算公式為：\n$$ U_{2max}' = U_1 - \\frac{P_{max}R + Q_{max}X}{U_1} = 107 - \\frac{10.8 \\times 5 + 14.4 \\times 60}{107} = 98.42 kV \\\\ U_{2min}' = U_1 - \\frac{P_{min}R + Q_{min}X}{U_1} = 107 - \\frac{4.9 \\times 5 + 5 \\times 60}{107} = 103.97 kV $$最後將所有數據代入計算：\n$$ \\begin{cases} U_{TJ\\max} = U_{2\\max}' \\cdot \\frac{U_{2N\\max}}{U_{2\\max}} = 98.42 \\times \\frac{11}{10.25} = 105.62~\\text{kV} \\\\ U_{TJ\\min} = U_{2\\min}' \\cdot \\frac{U_{2N\\min}}{U_{2\\min}} = 103.97 \\times \\frac{11}{10.75} = 106.39~\\text{kV} \\end{cases} \\Rightarrow U_{TJ} = \\frac{U_{TJ\\max} + U_{TJ\\min}}{2} = \\frac{105.62 + 106.39}{2} = 106.005\\text{kV} $$選擇距離 $U_{TJ}$ 最近的分接頭，題目中「D.110(1 - 2.5%) 檔，$ U_1 = 107.25kV$」最為接近，所以本題選 D。\n其實這道題有問題…… 最後以選擇分接頭後變壓器的最終變比校驗這個分接頭：\n$$ U_{2max} = U_{2max}' \\times \\frac{11 kV}{107.25 kV} = 10.09 kV \u003c 10.25 kV\\\\ U_{2min} = U_{2min}' \\times \\frac{11 kV}{107.25 kV} = 10.66 kV \u003c 10.75 kV $$可以看到，如果選擇這個變比，校驗是不成功的，但這道題並非出自什麼非常正式的考試，所以大家看著笑笑就完事了。\n調差係數百分比 調差係數為功頻靜態特性參數 $K_{G*}$ 的倒數，符號為 $\\sigma_{*}$，其用百分數表示就是調差係數百分比。\n$$ \\frac{\\sigma_{ *}\\%}{100} = \\frac{1}{K_{G*}} $$極限切除角的計算 先來看一道例題：系統接線如下圖所示，設在一回線路始端突然發生三相短路，已知原動機機械功率 $P_T = 1.5$，雙回線路運行時系統的功角特性為 $P_I = 3 \\sin{\\delta}$，切除一回線路後系統的功角特性為 $P_{III} = 2\\sin{\\delta}$。則故障的極限切除角 $\\delta_m =$ ?\n按照某些教材上的說法，你需要將所有數據代入下面這個公式裡：\n$$ \\cos{\\delta_{cm}} = \\frac{P_T(\\delta_h - \\delta_0) + P_{IIImax}\\cos{\\delta_h} - P_{IImax}\\cos{\\delta_0}}{P_{IIImax} - P_{IImax}} $$求出 $\\cos{\\delta_{cm}}$ 的值之後再代入反三角函數得到最終的角度 $\\delta_{cm}$。先不說這個過程到底復不復雜，這種又臭又長的公式我看到就不想記。所以我們直接用等面積定則來做——如下圖所示，根據等面積定則的定義，可以列出如下等式：\n$$ \\int_{\\delta_0}^{\\delta_{cmax}} P_m - P_{II} \\mathrm{d}\\delta = \\int_{\\delta_{cmax}}^{\\delta{max} = \\delta_k'}P_{III} - P_m \\mathrm{d}\\delta $$ 其中 $\\delta*{cmax} $ 就是極限切除角。根據題目條件，分別列寫加速面積和減速面積的表達式，可以得到如下的等式，其中出於方便以 $ x $ 代替了 $ \\delta*{cmax} $：\n$$ \\int_{\\frac{\\pi}{6} }^{x} (1.5 - 0) \\mathrm{d}x = \\int_{x}^{\\pi - \\arcsin{0.75}} (2\\sin{x} - 1.5) \\mathrm{d}x $$接下來就是微積分的事情了：\n$$ [1.5x]^x_{\\frac{\\pi}{6}} = [-2\\cos{x} - 1.5x]^{\\pi - \\arcsin{0.75}}_x \\\\ 1.5x - 1.5 \\times \\frac{\\pi}{6} = [-2\\cos{(\\pi - \\arcsin{0.75})}-1.5 \\times (\\pi - \\arcsin{0.75})]-(-2\\cos{x} - 1.5x) \\\\ 1.5x - \\frac{\\pi}{4} = -2\\cos{(\\pi - \\arcsin{0.75})} - 1.5\\pi + 1.5 \\times \\arcsin{0.75} + 2\\cos{x} +1.5x \\\\ \\frac{5}{4}\\pi + 2\\cos{(\\pi - \\arcsin{0.75})} - 1.5 \\times \\arcsin{0.75} = 2\\cos{x} \\\\ \\cos{x} = \\frac{5}{8} \\pi - \\cos{(\\arcsin{0.75})} - 0.75 \\times \\arcsin{0.75} \\\\ \\cos{x} = 0.66601 $$最後將 $\\cos{x}$ 的值代入反三角函數可以求得角度大約為 48.2 度，這個角度也就是我們要求的極限切除角。計算過程中，需要注意：\n右邊的積分終點也是故障切除後的功角特性 $P_{III}$ 和原動機功率 $P_T$ 的交點。 左邊的積分是 $P_T - P_{II}$，右邊的積分是 $P_{III} - P_{T}$，本題是三相短路，所以 $P_{II} = 0$，不要搞錯了。 由於推導時所用的值全都以標么值表示，因而式中 $\\delta_c$、$\\delta_k\u0026rsquo;$ 等角度亦需以 rad 表示（$360\\degree = 2\\pi \\text{ rad}$）。 最後一步等式右邊求出來是 $\\cos{x}$ 的值，而不是弧度，不要一著急一股腦直接 $0.66601 \\times \\frac{180 \\degree}{\\pi}$ 求出一個錯誤的角度而前功盡棄。做題要一步一步來，充分發揮草稿紙充當自己第二大腦的作用，不要跳步，不要心急。 不對稱短路電流與正序電流的關係 短路類型 短路電流 單相短路 $I_{fn} = 3 I_{fl}$​ 兩相短路 $I_{fb} = I_{fc} = \\sqrt{3} I_{fl}$​ 兩相短路接地 $I_{fb} = I_{fc} = \\sqrt{3} \\cdot \\sqrt{1 - \\frac{x_{\\Sigma0}x_{\\Sigma2}}{(x_{\\Sigma0}+x_{\\Sigma2})^2} }I_{fl}$​ 潮流計算中節點的分類 節點類型 已知量 待求量 節點數量（總共有 n 個節點） 備註 PQ 節點 有功功率 $P_i$ 和無功功率 $Q_i$ 電壓幅值 $U_i$ 和相角 $\\delta_i$ $m$ 一般是用戶 PV 節點 有功功率 $P_i$ 和電壓幅值 $U_i$ 無功功率 $Q_i$ 和相角 $\\delta_i$ $n-m-1$ 具有電壓調節能力的節點，比如靜止無功補償器 平衡節點 電壓幅值 $U_i = 1$ 和相角 $\\delta_i = 0$ 有功功率 $P_i$ 和無功功率 $Q_i$ $1$ 承擔平衡全網功率任務的大容量機組 靜態儲備係數的計算 例題：在如下圖所示的電力系統中，已知以發電機額定容量為基準的各元件電抗和系統電壓的標么值為：正常運行時，$x_d = 1.8$、$x_{T1}=x_{T2}=0.25$、$U=1.0$、$P=0.8$、$\\cos{\\Phi}=0.8$，若發電機為隱極機，空載電動勢 $E_q = \\text{常數}$，則正常運行時，靜態穩定儲備係數$K_p = $？\n靜態穩定儲備係數的計算公式如下：\n$$ K_p = \\frac{P_M - P_0}{P_0} $$本題中 $P_0$ 已知等於 0.8，所以題目就變成求 $P_M$ ，其計算公式如下：\n$$ P_M = \\frac{E_qU}{X_{d\\Sigma}} $$本題中 $X_{d\\Sigma} = x_d + x_{T1} +\\frac{x_L}{2} + x_{T2} = 2.55$，$U = 1.0$，所以問題又變為求 $E_q$。題目中 $P = 0.8、\\cos{\\Phi}=0.8$，則 $S = 1.0，Q = 0.6$，已知 P、Q、U，求上一級節點的電壓，公式如下：\n$$ \\begin{cases} \\Delta U = \\frac{PR + QX}{U} = \\frac{0 + 0.6 \\times 2.55}{1.0} = 1.53 \\\\ \\delta U = \\frac{PX - QR}{U} = \\frac{0.8 \\times 2.55 - 0}{1.0} = 2.04 \\\\ \\end{cases} \\Longrightarrow E_q = \\sqrt{(U + \\Delta U)^2 + \\delta U^2} = \\sqrt{(1 + 1.53)^2 + 2.04^2} = 3.25 $$其中 $\\Delta U$ 是縱分量，$\\delta U$ 是橫分量。\n關於縱分量和橫分量的定義：這個定義並非以笛卡爾座標系為參考基準，而是以觀察者的視角為基準，前後為縱，垂直為橫。\n現在 $E_q$ 已經求得，最後求出 $P_M$ 進而求出 $K_p$：\n$$ P_M = \\frac{E_qU}{X_{d\\Sigma}} = \\frac{3.25 \\times 1.0}{2.55} = 1.27 \\\\ K_p = \\frac{P_M - P_0}{P_0} = \\frac{1.27 - 0.8}{0.8} = 0.5875 = 58.75\\% $$","date":"2025-02-03T15:32:03Z","image":"/2025/02/recent-ee-notes/image-1_hu_96f07d728663f627.webp","permalink":"/zh-hant-tw/2025/02/recent-ee-notes/","title":"一些關於電力系統分析的筆記"},{"content":"「我累了，我需要休息。」\n辦完休學手續，拖著被繁瑣手續折騰而疲憊不堪的身體走出學校的辦公樓，正式開始了我為期 9 個月的休學生活。兩週之前，我還在和室友開開心心外出吃自助烤肉，當時的我怎麼都不會想到，我的精神狀況會惡化的如此之快。從難以言說的痛苦開始在我身上發作，到去醫院開出處方，再到做出休學的決定，整個過程只用了兩週的時間。而在去辦理休學手續的前兩天，我還買了足夠我用一年的生活用品，現在倒好，搬回家的時候別提有多重了。\n搬空寢室的那一天，天空下著瓢潑大雨，走進寢室，我的桌面上，路由器的燈光依然閃爍，沒喝完的可樂仍在桌邊，外賣送來的番茄醬也仍然和往常一樣隨意的灑在桌子上。「很長一段時間我都不會回來了……」，是啊，這張桌子，可能永遠都不會再有這番光景了。\n和不約而同請假的室友一起，分掉了剩下的一箱可樂，拆掉了剛買不久的人體工學椅，把各種雜物裝箱，冒著雨搬上了車。眼看著我的床位一點一點清空，當時一時間我竟也生出了不再休學，一切照舊的念頭。臨走前，我怔怔地看著空空如也的床位出了神，竟對室友輕拍肩膀的動作毫無察覺。和朝夕相處三年多的室友道別，交還了寢室的鑰匙和在校圖書館借閱的書籍，我終究還是踏上了回家的路。\n即便如此，偶爾聚一聚也還是必要的 就算休學，xdm 一起幹飯的傳統也堅決不能丟，在身體逐漸克服藥物對於食慾的影響後，大夥的飯局也是來之不拒。大家一起出去吃吃喝喝，分享一下最近的生活，互相交換一些信息，最後還能平攤飯錢，多是一件美事。美中不足的是，鑑於我之前酗酒的經歷，醫生自然也特別強調了我需要戒酒，於是出門吃飯，基本也就只能喝點西瓜汁意思意思了。\n11 點睡覺，8 點起床 雖然喹硫平效果有限，但竟然也能一改我 5 點睡覺，9點起床的作息，開始醫生建議的 11 點睡覺，8 點起床，至少，在第一個月確實是這麼回事。當然我也開始光顧健身房，擼鐵真的是一件很奇妙的事情，一邊猛吃碳水和蛋白質，一邊猛加片，不出兩個月，我的體重上漲了足有 10 公斤——其中 9 公斤是肌肉，1 公斤是脂肪，也算是嚐到了新手福利期的甜頭。\n肌肉如果練得太狠，過於興奮，會直接影響到我的睡眠，尤其是練完腿的晚上，堪稱徹夜難眠。為此我不得不做出讓步，減低健身的頻次，畢竟，以我的狀況，對精神健康有益的睡眠是應當照顧的首要目標。\n是遠是近都是旅行 旅行也算是生活必不可少的點綴，今年 9 月份的香港之行和十月份的桂林之行算是今年為數不多的遠行，而譬如蘆溪村七仙殿的近遊則是數不勝數。是遠是近都是旅行，都說讀萬卷書，行萬里路。當從萬卷書內汲獲的知識在現實中找到參照和實踐，心中生現的滿足感和安然是讓人感到自己和世界真實存在的最好慰藉。\n天上不會掉餡餅，但會掉小貓 天上也許不會掉餡餅，但是可能會掉下來一隻小橘貓。當時我正前往健身房的路上，消防通道里的貓叫聲吸引了我的注意，進去一看，就遇見了這隻小貓。\n現在我已經養了它快半年了，它也給我帶來了不少樂趣，當然，還有不少傷疤和一套被抓爛的真皮沙發。小動物終究還是聽不懂人話，曾幾何時，我多次動念想要讓它掃地出門，但最終還是讓它留了下來，養貓就是這樣，也許你會因為它煩人的一面產生一萬次拋棄它的想法，最終卻還是因為它所能帶來的無可替代的情緒價值而選擇留下它。\n綠植是現代人生活的必需品 綠植不光好看，還能吸收甲醛，吸附灰塵，最重要的是，在室內多引入一些大自然的元素，對身心健康多有裨益，因此我認為，綠植是現代人生活的必需品。\n今年我的桌面有了很大的變化，不止硬件上的升級，比如買了新的顯示器和屏幕掛燈，也引入了一些綠植，我選擇的綠植是虎皮蘭，不僅易於養護，也可以在陰暗的環境下做到生長正常，甚至我的兩株虎皮蘭還在恰當的肥料量上長出了新芽。多肉則更好養，需要澆水的次數很少，唯獨一種叫作「錢串」的植物讓我非常困惑，澆水多也不是，少也不是，施肥也幾乎對其毫無效果，看來，在園藝方面，還有很多的知識等著我去發現，去學習。\n我的 Online Presence 我並沒有為了流量去「運營」我的博客，只是單純的寫我所想，所以看我博客的人並不算多。當然，拜搜索引擎所賜，也不至於完全沒有流量。今年我也順便開設了直播間，最大的作用也不過是用來保存我的遊戲錄像，所以自然也沒有什麼觀眾，畢竟也沒有太多人願意看一個名不見經傳的主播玩平淡無味的遊戲吧。\nosu! 在今年之內由 300pp 一路漲到了 3439 pp，目前換了數位板，還處在適應期，短期之內這個數字大概是會停止增長。\n生活的慾望 自很久之前開始，我對生活中的任何事物就開始漸漸失去興趣。其中之一的表現是什麼都不想要，什麼都不想買：衣服除非穿破，否則絕對不買新的；頭髮除非遮住眼睛，否則絕對不會去剪；有什麼新的產品，我也絕對不會想要；直到最近，甚至連性慾都有不再有的趨勢。慾望真的很神奇，它既不能太強，同樣也不能太弱。一個沒有慾望的人是活不下去的，即使人類生存的本能能夠作為一張安全網，防止其過早調入深淵，在世的時候，生活也會毫無意義，生不如死。\n慾望太弱，就會對什麼都提不起興趣，整天渾渾噩噩，反而會更加痛苦。有適當的慾望，每天都為之努力，做自己想做的事情，形成健康的循環，反而會更好呢。\n慾望處理得好，可以推動人前進，「不要相信壓力能夠轉化為動力，你的壓力只會轉化為病歷，人真正的動力，是源自於內心深處對於快樂和興趣的追求。」是啊，以我現在的境地來看，壓力倒是已經卸下。然而壓力卻已經轉化為了病歷，我的內心深處，不再追求快樂和興趣。這些年來，這種感覺變得愈發明顯——不論做什麼事情，都讓我感到一種深層的，無法緩解的疲憊，即使我的身體依舊健康，我的心靈深處，卻早已遍體鱗傷，虛弱不堪。我真的很害怕，我的慾望正在加速消失，我早就已經失去了同齡人所擁有的一腔熱血，失去了同齡人所擁有的對愛情的渴望，失去了同齡人所有的對美好生活的追求……\n2024 年接近尾聲，今年註定將是我大學生涯乃至整個人生中不平凡的一年，在這一年，我重新撿起我對生活的慾望，重新撿起我對未來的信心。今年我所做的這些嘗試，無不是在「找回生活的慾望」這件事情上做出我的努力——誰人不知「做我所想，做我所愛」？慾望與動力的耗盡是無法靠意志力補回的，當「所想」與「所愛」都出現空缺時，又有多少人能給出有意義的解決方案呢。\n","date":"2024-12-26T09:57:10Z","image":"/2024/12/2024-end-of-the-year-summary-public/image-13_hu_5d398f1badf5ff5d.webp","permalink":"/zh-hant-tw/2024/12/2024-end-of-the-year-summary-public/","title":"2024 年的生活"},{"content":"買來一張 5ber SIM 卡，卻發現它意外的挑機器——手上的安卓機器是一個都不兼容。我早就對我原本的備用機——紅米 Note 9 5G 大為不滿，藉此契機，我賣掉了紅米 Note 9 5G，買來了一臺小米10。\n至於為什麼要買小米 10 而不是其他機器，其實也沒有什麼特別的理由：一是因為它在 5ber 明確的支持設備清單裡；二是它很便宜，以 500 到 600 元的預算，可以輕易的買到一臺；三是因為我家裡的米家設備；最後，當然是因為這新一代釘子戶各方面比較均衡。\n我也沒有多看，隨意在閒魚上下單了一臺。其實現在看來，如此草率的下單，著實有些不妥。先說說收來機器的外觀吧，一句話，「千瘡百孔，飽經風霜」。這部手機更換過後蓋，中框早就被原機主摔得不成樣子，充電口也是出現了明顯的磨損痕跡，屏幕的一角出現了無法移除的汙點。現在看來，這臺 8 + 256G 的小米 10，其 619 的價格，顯然有點貴了。\n我對備用機的要求 說到我對備用機的要求，我想了想，其實也沒那麼多，首先是手機最基礎的功能——通信：我需要一臺支持 5G 的手機，還需要支持 5ber 卡的寫入；然後是續航，當然是越長越好，畢竟這是需要承載我外出熱點需求的手機；其次是滿足我偶爾的玩機需求，最好有豐富的玩機資源和活躍的社區，這一點作為「新一代釘子戶」的小米 10 顯然不是問題；最後是必須有高刷屏，因為我實在是受夠了 iPhone 12 系列的 60Hz。\n換電池 原機器的電池出現了很嚴重的衰減，Battery Guru 估計的容量只有 3100 mAh/4780 mAh，也就是 65% 的健康度，你問我為什麼會買一個電池爛成這樣的機器？還不是因為驗貨寶的「電池」那一欄乍一看沒問題可是實際上安卓機都是一個「安卓機無法檢測」？以這臺機器買來時的電池狀況，就算只是刷刷信息流類的應用，也會在四個小時以內沒電，待機續航更是慘到了我不想帶它出門的地步。這臺手機計劃的用途之一就是熱點機，如果連帶都帶不出去那還談何熱點？事到如今，必須要給這臺小米 10 換一塊電池。\n原本我準備直接去售後更換電池，價格隨手在網上一查——159 元包工包料，算了吧，這手機才 619 呢，我還是自己買塊電池來換吧。六七年前我還在酷安上活躍的時候，正好是第一批小米 6 需要換電池的時候，當時我就已經看到「中電」這個詞大行其道。遂直接以 89 的價格買下中電的增容電池，自己動手換。\n換電池的過程在B站上就能看到1，照做即可。在換的過程中，我卻又發現了這臺手機的問題——它肯定被人拆過，而且拆得很粗糙：防拆貼紙已經被動過，更好笑的是螺絲都沒有擰全。雖然我買來時已經知道這部手機換過後蓋，但內部如此粗糙的手法卻沒有影響到手機的任何功能，也是令我嘖嘖稱奇。\n回到正題，換電池的過程倒是挺順利，增容電池也不頂後蓋，套上保護套也就完全無感了。換完之後，續航脫胎換骨，用上一整天完全不是問題。總之，現在我是願意把這臺手機帶到外面去用了。\n解鎖 Bootloader 現在的小米早就不是以前那個富有極客精神的小米。\n解鎖 Bootloader 這麼簡單且基本的要求在 Hyper OS 上竟然可以受到如此大的阻礙：按照系統原本的要求，需要在小米社區至少達到 5 級，之後再參與解鎖內測資格的申請，答題之後方可為設備綁定小米賬號，之後再保持 SIM 卡插入的狀態等待 168 個小時，方可解鎖。\n不是，你們是來搞笑的嗎？？\n好在小米 10 原本搭載的是 MIUI，可以用一些手段繞過 Hyper OS 相較於 MIUI 額外添加的解鎖限制2。MIUI 原本 168 小時的等待是無法繞過的，於是只好還是等一個星期之後再開始玩機，在此之前，我會開始做一些準備工作。\n去廣告 之前熟悉的大聖淨化和李跳跳都因騰訊的律師函而停止更新，於是在網上轉悠著找到了「GKD」，完全開源。只是可惜了我之前買的大聖淨化授權。授權時用到了 Shizuku，感覺現在 Shizuku 的生態也比七八年前好了不止一星半點。\neSIM 當然，小米 10 本身不支持 eSIM，不過我早在之前就已經準備好了一張 5ber SIM 卡。目前 eSIM 功能很好，數據漫遊無壓力。開通的保號套餐也是 OK 的。至於如何開通這些 eSIM，請準備好一張 VISA/萬事達卡，然後自行去網上找滿天飛的教程。\n目前個人覺得比較好用的是 ClubSIM，一年只需消費 6 HKD 就可以保留手機號碼。至於網上滿天飛的烏克蘭 LifeCell，我反倒不是很推薦，因為他們的號碼總是容易被莫名其妙的風控，比如 Telegram 原本的短信驗證會強制變更為電話語音播報驗證，也就是要求在漫遊狀態下接聽國際長途電話，而 LifeCell 的漫遊費用並不便宜，相比於風控更少的 ClubSIM，這張卡只適合去註冊極少量的服務。\n雖然 ClubSIM 保號合適，如果有大量的數據漫遊需求，我建議購買 3HK 的漫遊服務。而我個人只是偶爾才需要原生 IP，其餘時候只需能接收短信即可，於是就直接選擇了 ClubSIM。\n基本滿意的性能和續航 這些年來，我逐漸告別了本就玩得不多的手機遊戲，現在手機能作為我外出空閒時的一個補充就可以了，唯一的性能要求是隻要能保證日常使用流暢即可，至於遊戲，只要能帶得動王者榮耀級別的輕負載就行。這種佛系的性能要求，即使是接近五年前發佈的小米 10 也可以輕鬆勝任。至於跑分，我就不讓這臺老機器在娛樂兔上獻醜了。\n換過電池的小米 10 可以輕鬆應對我出門時的續航需求：導航一整天完全無壓力，即使開熱點也不存在任何續航問題。這個續航表現，我基本滿意。\n「又不是不能用」 接下來就是不太滿意的點，首先是隻有 8GB 的內存，這個內存容量放在幾年前還說得過去，放在今天就顯得有些捉襟見肘。後臺留存的能力就別想了，能保住日常的流暢就已經謝天謝地。因此，我只好自己勤快一些，多進後臺頁面按兩下全部清空鍵。\n然後就是屎一樣的解鎖流程，點名批評 HyperOS。我自己的手機想要解鎖，還需要去你社區水到 5 級，然後答題解鎖嗎？真是搞笑。這種用戶本應有的權利被廠商奪走的感覺讓我對小米的印象變差了不少。\n最後是屎一樣的尾插設計。不同於其他手機模塊化的尾插，小米 10 的尾插是直接焊在主板上的，而它這尾插用久了極其容易磨損導致接觸不良，無法充電，這時要更換卻非常麻煩，需要將尾插重新焊接一遍。目前我這臺尾插已經出現了略微的鬆動跡象，到時候如果需要更換了，也是一個額外的麻煩。\n最後…… 總體上，小米 10 用起來還是不錯的，它滿足了我對備用機所有的需求，在各方面也都均勻水桶，雖然它有如上所述的小問題，但總體上，它依然是一部好手機。我對這次備用機的換機還算滿意，希望這臺小米 10，至少在它被賣掉之前，能伴我度過一段美好的時光。3\n我參考了這個教程\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考 Github 項目：MlgmXyysd/Xiaomi-HyperOS-BootLoader-Bypass\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n題圖來源見水印。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-12-05T11:56:29Z","image":"/2024/12/umi-experience/cover_hu_d7a8279c694f004e.webp","permalink":"/zh-hant-tw/2024/12/umi-experience/","title":"在 2024 年末收臺小米 10 當備用機"},{"content":"不知出了什麼問題，我的電腦的時間從來不會自動和 NTP 服務器同步，雖然短期內並不會對使用造成什麼影響，但倘若放任不管，時鐘的偏移量太多，則可能會造成 SSL 和 TOTP 等依賴時間戳的應用出現問題，再者，手動按同步鍵也很不方便，今天我決定必須要解決這個問題。\nSpecialPollInterval 在網上搜索一番之後，我發現有人提到SpecialPollInterval這個鍵值，其具體位置是HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\TimeProviders\\NtpClient，微軟官方文檔對其的描述如下：\nThis entry specifies the special poll interval in seconds for manual peers. When the SpecialInterval 0x1 flag is enabled, W32Time uses this poll interval instead of a poll interval determine by the operating system. The default value on domain members is 3,600. The default value on stand-alone clients and servers is 604,800.\n對於一般客戶端，這個鍵值的默認值是604800，也就是一個星期同步一次，這個間隔顯然太久，於是我將其設置成了3600令其一小時同步一次。\nw32tm 幾天後，當我再次檢查時間時，卻發現時間仍然沒有自動同步，這一次的偏移量已經達到了 15.8 秒。\n於是查詢「SpecialPollInterval」想要知道其具體的作用和未及預期目的的原因，卻發現了微軟的一篇疑難解答。這篇疑難解答指出：「每次客戶端輪詢時間樣本到 NTP 服務器時，NTP 客戶端都會進入 SPIKE 狀態。 時間服務管理其內部狀態，如果客戶端進入 SPIKE 狀態，則客戶端不會同步其時間。」\n為了解決這個問題，需要將 Windows 時間配置為使用 MinPollInterval/MaxPollInterval 作為輪詢間隔。\nw32tm /config /update /manualpeerlist:cn.pool.ntp.org /syncfromflags:MANUAL服務尚未啟動 執行這一行配置時出現了「服務尚未啟動」的提示，這說明用於時間同步的服務根本沒有啟動。如此基礎的服務竟然不會自動開機啟動，我也不知道這是 Windows 的 Bug 還是我後期使用無意間製造的問題，不管怎樣，首先啟動這個服務：\nnet start w32time w32tm /register # 註冊一些基本的註冊表鍵值和相關服務隨後 Win + R 運行services.msc打開服務管理面板，找到「Windows Time」服務，將其啟動類型設置為「自動」，即可讓其開機自動啟動。\n再次重新啟動電腦，這次打開「設置」\u0026ndash;\u0026gt;「時間和語言」\u0026ndash;\u0026gt;「日期和時間」\u0026ndash;\u0026gt;「附加時鐘」，切換到「Internet 時間」選項卡，如果出現了「下次同步」的字樣，說明這套系統終於是正常運作了。\n","date":"2024-11-18T10:03:47Z","image":"/2024/11/windows-ntp-hiccup/cover_hu_e196169a0c972a34.webp","permalink":"/zh-hant-tw/2024/11/windows-ntp-hiccup/","title":"Windows Hiccup 小日常：處理時間同步服務的問題"},{"content":"銀行卡 滙豐藍獅子 也就是滙豐銀行的 MasterCard 扣賬卡（也就是內地常說的借記卡/儲蓄卡），在香港開好戶之後直接在 App 裡申請一下就行，記得申請之前先改一下用戶資料裡的中文地址。卡片會在一到兩個星期之後郵寄過來。\n這張卡和滙豐的銀聯卡（紅獅子）餘額是互通的，每筆消費會有 0.4% 的返現，這個不設上限的返現的優惠力度甚至超過了很多國內的信用卡，全球取現免手續費，也沒有任何年費，是一張很適合用來消費的借記卡。\n工銀星座卡 工銀專門給有海淘需求的學生量身定做的卡，0 額度，是一張介於信用卡和借記卡之間的卡片，申請它就是中意它的 VISA 標誌。即使這張卡有 VISA 標誌，用起來還是不太方便：海外支付之前需要手動購匯，同時幣種必須正確，任何一環出錯都會導致交易失敗。\n卡面顏值還算不錯，但是非常容易刮花，甚至還會掉漆，基本買回來就只能放在家裡供著，好在這張卡不需要經常去上 ATM。\n興業寰宇人生 \u0026amp; 無界卡 一張銀聯借記卡，從名字就可以看出來，這張卡是專門為有跨境金融需求的人推出的。可以免除前 30 筆跨境電匯的手續費。以及境外 ATM 取現的手續費，這一點對於經常有跨境電匯需求的人來說，這張卡可以省下不少錢。\n無界卡據說是有寰宇人生的權益，但卡面是透明卡面，看起來更有意思一些。這套外觀見仁見智，只要實用，什麼都好說。\n5ber SIM卡 前兩年很火的 SIM 卡，可以讓不支持 eSIM 的手機支持 eSIM，最近才入手。5ber 操作算是所有 eSIM 轉實體 SIM 卡里操作最簡單的了，一般只需掃描 eSIM 二維碼即可。上手以後下載了一張烏克蘭 lifecell 和香港 ClubSIM，都是保號神卡。\n當全世界都在普及 eSIM，國內的運營商卻相繼停止了 eSIM 業務，屬實讓人費解。實名制的問題很好解決，參考香港的方案就可以，然而國內卻瘋狂開倒車，推出了所謂「超級 SIM 卡」，也不知道國內什麼時候才能提供方便便宜的 eSIM。\nWacom 數位板 買數位板來畫畫？別鬧了，正經人誰買數位板就圖個畫畫啊。當然是用來 osu! 啊。最近鼠標打歌上了 3000pp，決定買個數位板來體驗一下，既然是打 osu 嘛那肯定是哪個便宜買哪個，於是就無腦入手了 Wacom CTL-472 這塊入門數位板。\n真正上手之後發現鼠標轉數位板有一段比較難的適應過程，不光能打的歌難度會有落差，手部肌肉痠痛的位置也會不同，嘗試了兩天之後我還是決定暫時回到鼠標……\n小米 10 當年給我爸安利的小米 10 Pro 用了四年依然好用，於是我自己就收了一臺小米 10 來當做備用機。小米 10 也算是某種意義上的新一代釘子戶，性能、續航、屏幕素質等各方面都比較均衡，用了這一段時間我甚至想要把它當做主力機。\n買小米 10 的主要理由其實就是前面提到的 5ber 真·為了一碟醋包了一盤餃子。 5ber 對手機的支持很奇怪，很多我認為會支持的安卓機實際上並不支持，為此我不得不賣掉了原有的備用機，轉而購買了這臺小米 10。\n關於是否刷機的問題，我目前有些猶豫，一方面 HyperOS 已經足夠好，功能豐富，使用流暢。另一方面，眾所周知的隱私問題卻讓我不得不思考到底要不要把這臺手機刷成 Lineage。總之，目前，我打算先用一段時間。這也算是一種隱私方面的擺爛吧。\n虛擬服務器（VPS） 最近我的服務器也快要到期了，於是就需要物色新的機器，目前是嘗試了 Contabo 和 Hetzner，計劃還要嘗試 Netcup。每新購進一臺機器，我都要將其系統重裝之後測試能否跑動我目前數據量日益增長的 Iceshrimp 服務。鑑於目前發現 Cloudcone 性能實在是太差，還是需要找一臺穩定的機器才行。\n其中 Hetzner 我個人覺得很不錯，機器性能很強，SLA 有保障，自研的面板很好看。三網回程質量還不錯，選得紐倫堡機房，移動走的是高級 CMIIN2，其他兩個走的普通線路。價格雖然比不上 RackNerd、CloudCone 這類廉價機器，但在同性能的機器裡算是很低的了，外加更好的防止濫用機制，拿來跑服務是完全沒問題的。\n至於 Contabo，個人認為其性能比較弱，且 SLA 保障過於離譜（95% 的 SLA，也就是一年能壞掉 18 天多），外加限制諸多（比如不開放郵件端口），嚐鮮以後，我不推薦。\n淘寶流量神卡 在淘寶上買便宜的流量卡要做好被套路的心理準備，這一次我買了一張，大致弄清了流量卡的套路：先是在宣傳圖上放一個實際月租 9元/月 的套餐；下單之後以各種原因說無法發貨；最後用各種話術玩文字遊戲，騙你去換到一個更貴更差的套餐。\n我這一張，一開始買的時候宣傳圖上的實際月租是 9元/月，移動 105G 通用 + 30G 定向流量。說無法發貨之後換成了一個聯通 70G 全國流量 + 120G 省內流量的套餐，實際月租似乎也變成了 19（當然實際月租還是得等下個月扣費才知道），而且更加過分的是還有兩年的合約期。不過，儘管如此，這個套餐也依舊還算便宜，先用著吧，反正半年以後就丟了，弄清楚套路漲經驗也是很不錯的回報。\niOS p12證書 很多人認為安卓是玩機的代名詞，其實不然，只要願意折騰，iOS 能夠折騰的項目不比安卓少。p12 證書原本是蘋果為開發者提供用於測試尚未上架 AppStore 的應用的工具，任何應用只需經開發者的 p12 證書籤名，就可以在 iOS/iPadOS 上運行。\n蘋果將非開發者賬戶可以簽名的應用數量限制在了 3 個，只有開發者賬戶才能簽名無限制數量的應用。開發者賬戶訂閱的價格是 99美元/年，對於只是想要裝幾個應用的人來說顯然沒有必要。網上有人售賣已經簽名過的開發者證書，直接購買使用即可。\n目前我就用來裝一個 BHTwitter 和 EhPanda，裝上 Esign 並導入證書之後就可以自由安裝軟件，還可以添加第三方的軟件源，免費軟件源質量相對比較低，收費軟件源質量會相對更好，軟件也會相對更全。所以，我們今天在此體會不到這一點。\n這種證書還可以用於多開應用、遊戲外掛等，可玩性還是很高的，大多證書價格也還算不錯，在 6 - 100 元不等，比起蘋果官方 99 美元/年的開發者訂閱，這筆錢算是物有所值。\n","date":"2024-11-15T10:39:17Z","image":"/2024/11/recent-gadgets/cover_hu_7ec602792c5b9b6.webp","permalink":"/zh-hant-tw/2024/11/recent-gadgets/","title":"近期上手的一些小玩具"},{"content":"桂林小住 又是這一句老掉牙的開頭：「桂林山水甲天下」。\n說起桂林，對這座城有所耳聞以及真正去過的人大概佔大多數。世界級的山水，三線的城建。十多年前，我曾在桂林居住過若干時間：城裡的象鼻山，兩江四湖的遊船；城外的陽朔，灕江竹筏，還有江灘上的燒烤。\n別人的旅遊目的地，我早就失去了興趣。你也許聽過一句調侃：「不到長城非好漢，再到長城王八蛋」，說的就是這種感覺——就像甜膩的飲料，初嘗時宛如天堂般美好，一旦形成味覺記憶，再喝下去便只覺得難受。\n剛從香港回來，還沒幾天，又踏上去桂林的路，實際上，我是不太願意的。香港之行已經讓我覺得壓抑無比，舟車勞頓。感覺非得用整個國慶假期休息不可。\n但是生活總是光怪陸離，莫名其妙。不知怎麼地，我又踏上了一段新的旅程，前往這個我幾乎已經玩遍的城市。\n一座城市就是一種心情 要說長沙是娛樂至死，桂林在我的眼裡，則是相對悠閒的：六塊錢一碗的桂林米粉不限量供應，只要願意，一日三餐都吃，18 塊錢便可解決一天的溫飽問題；淡季時兩江四湖幾乎稱得上人煙稀少，因為其超強的接待能力在淡季形成大量冗餘，酒店的價格會相當地低，旅遊景點同理。所以，之前在桂林時，吃喝玩樂都很便宜，用相對低廉的花費把桂林山水玩了個遍。\n國慶假期住在剛好出門旅遊的親戚家，住宿無花費；我媽的公司補貼所有家用車的油費；加上桂林的日常消費很低，這種換個心情的方式真的很摳門省錢。\n於是就在桂林愉快的住了五天。\n樹莓派和 Cloudflare Tunnel 樹莓派是和我的室友 AA 買來做項目的，做完項目之後就算作我的了。現成的計算資源白在這裡，不用白不用。所以我為這片樹莓派裝上了 Raspberry Pi OS Lite 64bit，接入網絡，把它當作服務器使用。\n畢竟是 ARM 架構，樹莓派運行起來功耗很低，待機功耗不到 5 W，峰值功率 25W，正常情況下極少跑到峰值功率，一年電費最多幾十塊錢。\n最難解決的部分是網絡問題，拜中國大陸特殊的網絡環境所賜，想要把一個放在家中的服務器上的內容發佈到公網十分蛋疼，一是運營商默認沒有公網 IPv4，即使有，也是動態的；而這可憐的動態 v4，80、443 等常用的端口更是想都別想打通；想要靜態的 IP 也不是不行，買企業專線吧，不光需要辦理各種證照，價格也比家寬貴至少十倍。\n本來我對 Cloudflare Tunnel 不報什麼期望，在網上抱怨其經常斷聯、丟包等問題的帖子比比皆是，實際上手之後它卻大大出乎我的意料，除了根文檔加載時間相對偏長，其他的靜態資源皆從 Cloudflare 強大的 Edge Network 中獲益，加載速度飛快。而且，不知是地域差異還是運營商之間的區別，我的 Tunnel 即使在晚高峰時期也依然保持穩定和相對快速。這是我在樹莓派上搭建的測試博客，如果你想要知道具體的加速效果，可以進去看看: https://rpiblog.l3zc.com。\n解決了內網穿透的問題，樹莓派的可玩上限就大大提高，以後可以拿來做很多有意思的事情。只能期望運營商不要無緣無故掐掉我的 Tunnel 吧。\n我的 RSS Feed 加入 Follow，認證我的博客 我第一次聽說 Follow 是看到了 DIYGod 的推文，這是 DIYGod 繼 RSSHub 之後又一個開源項目，目前仍然處於 Alpha 階段，但是完成度已經相對不錯。\nFollow 是一個 RSS 閱讀器，和 RSSHub 、RSS3（For real why??）深度整合。與大多數 RSS 閱讀器不同，Follow 採取的是雲端服務器代為抓取內容，所以有訂閱源數量的限制，同時目前內測階段也需要邀請碼才能使用，好在這在廣大網友的幫助下並不是什麼難事。\n目前我已經使用 Follow 一個星期，整體的體驗還是非常不錯的，功能強大，使用流暢，還有無限量（目前暫時如此）的 LLM 摘要\\翻譯功能。\nFollow 也是一個社區，訂閱源的 maintainer 也可以在 Follow 上認證自己的訂閱源，這樣就可以接收別人的打賞。打賞是以一種名為 Power 的 ERC-20 代幣實現（for real why?? 我就是想讀 RSS Feeds，為什麼我會需要用到區塊鏈呢？），雖然目前這種做法在我看來依舊存在很大的爭議，但 Follow 將這一功能本身打磨得十分到位，體驗良好。\n修正 RSS Feed 閱讀體驗問題 我博客上原有的 RSS Feed 是由 Hugo 默認的模板生成的，正文部分直接使用了.Content變量拉取的內容真就是依託答辯，不僅會包括一堆內置的圖片處理功能生成的不同分辨率的圖片 url，代碼塊部分還會有 chroma 生成的一堆一般閱讀器不能正確處理的代碼行號和高亮標記。所以我加了幾個 Render Hook，修正了一下 Hugo 的這些問題：\n./layouts/_default/render-codeblock.rss.xml:\n{{ .Inner }}./layouts/_default/render-image.rss.xml:\n{{- $url := urls.Parse .Destination -}} {{- if not (or (eq $url.Scheme \"http\") (eq $url.Scheme \"https\")) -}} {{- $result := .Page.Resources.GetMatch (printf \"%s\" (.Destination | safeURL)) -}} {{- with $result -}} {{- end -}} {{- end -}}這樣，就再也不會出現原來糟糕的閱讀體驗了 （應該吧）。\n另外我也對前端進行了一些小優化，現在複製代碼的時候，再也不會出現如下所示的，意外選到旁邊的行號的情況了。字體換成了 Jet Brains Mono，Padding 也進行了一些調整，讓拷貝變得更輕鬆。\n寫博客之餘，修一修博客上的 bug 多是一件美事。這次修改也算是磨刀不誤砍柴工，讓我自己心情變好的同時也讓大家的閱讀體驗變得更好。\n","date":"2024-10-22T18:05:20Z","image":"/2024/10/guilin-raspberrypi-and-rss-feed/cover_hu_9e407f5dddff8939.webp","permalink":"/zh-hant-tw/2024/10/guilin-raspberrypi-and-rss-feed/","title":"近況：桂林，樹莓派，以及我的 RSS Feed"},{"content":"近期遊覽香港，帶回一些紀念品，謹將這些紀念品與在港的回憶編寫成文，以作留念。\n八達通 我在抵港之前就已經開通了八達通。八達通幾乎可以暢遊整個香港，港鐵、便利店、叮叮、巴士、山頂電車、天星小輪……幾乎什麼地方都能用。\nApple Pay 裡可以直接用人民幣開通八達通，需要交 50 港幣押金，說是可以退，但真的去退的又有多少人呢，權當是開卡的手續費了。不過 Apple Pay 不需要手續費就能直接用人民幣開卡和充值，匯率也是相當不錯，這一點好評。\ncsl. 手機卡 香港旅遊最便宜的 SIM 卡是中移香港的 MySIM，然而我卻偏偏選了貴了快一倍的 csl.，不用說，當然是為了保號。\n雖然我之前知道 ClubSIM 可以做到 6 港幣一年保號，然而抵港之後的第一個便利店裡卻並不賣這種卡，無奈只好選擇了 csl. 香港任縱橫，充值 50 港幣可以延長 180 天有效期。掐指一算，這張 csl. 一年 100 港幣才能保號，煩，要是當時能找到一家賣 ClubSIM 的卡就好了。\n當然，這張卡片，自然可以留作紀念。\nSUA 註冊標籤/香港政府公函 抵港的第一件事，便是取走早已申請的 SUA（Small Unmanned Aircraft）註冊標籤。\n根據香港法律第448G章《小型無人機令》，我的無人機屬於甲二類無人機，需要向民航處申請註冊，並貼上民航處的二維碼，同時我也需要在網上註冊「遙控駕駛員」，取得相應的執照。兩者齊備後才算是合法飛行。\n由於長沙沒有直達香港的航班，我只好從香港西九龍高鐵站進關。進關後直奔柯士甸站，坐上屯馬線轉東涌線，直奔機場。本來高鐵進關可以享受到的直達市區的便利，現在全都變成了前往民航處漫長的來回旅程所帶來的雙倍痛苦。\n從東涌線下車之後轉 S1 機場巴士前往「民航處總部；東耀路」站下車，你就會看到這番鳥不拉屎的景象：\n香港是真的很熱，儘管室內的冷氣都開得很足，但這種遙遠的郊外顯然沒有空調。這種地方對於我這種愛出汗的人來說簡直就是地獄，上了一個小坡便已經熱出了不少汗。好在進入民航處的辦公樓以後，終於有了 much needed 的空調。工作人員都很熱心，工作效率很高，很快便幫我取來了這兩個月前就已經打印好候取的標籤。並指導我完成了無人機駕照的考取（就是看一些規矩，不用擔心）。\n於是就愉快的拿到了註冊標籤。\nHSBC 銀行卡 去香港開個銀行賬戶，有很多好處，比如不需要港股 50 萬入場費便可以交易港股，不受制於內地的外匯管制等等。這次抵港我有充足的時間開戶，於是一天大早我便動身前往開戶。\n我的酒店在灣仔，而我想去位於中環的滙豐總行，需要從港島西面到東面。橫貫港島有兩種主要交通工具：一是港鐵的港島線，二是香港著名的電車，暱稱「叮叮」。相較於車費昂貴的港鐵，叮叮是我在香港體驗最好的交通工具之一，無論坐多遠，票價始終親民，僅需3港幣；以如此低廉的價格，就能感受這條已有百年曆史的電車。叮叮擁有專用軌道，幾乎不會被堵，在香港的大街上緩緩前行，不時發出清脆的鈴聲；街道上人聲鼎沸，雙層巴士轟鳴作響，而紅綠燈也為視障人士持續發出聲音，這就是繁華而嘈雜的香港。\n滙豐總行大廈的正門實際上是面向皇后大道中一側的入口，而非皇后像廣場一側的德輔道入口，而德輔道入口卻因為公共交通更便利而被絕大多數人使用。在銀行街下車，對面就是滙豐總行，坐電梯上樓即可。開戶預約？別鬧了，有的分行都已經預約到一個月之後了，這誰受得了啊。就直接 Walk in，和接待說要開戶，現場取號即可。真不知道那些預約的人都到哪裡去了，非高峰期幾乎不需要等，我去的時候只等了一個號碼而已。服務態度還不錯，簡單問了問開卡的目的，現場下卡。\n開好銀行卡就在中環轉了轉，一覽終審法院、皇后像廣場、和平紀念碑、威爾士親王軍營以及添馬的政府總部。能在高樓林立的地方找到如此多文物古蹟和文物級別的建築，可見香港的歷史底蘊深厚。如此多的知名金融機構和政府總部齊聚於此，中環不愧為香港的政經中心。\n《坐困愁城》和《書店有時》 這兩本書其實沒有什麼特別的意義，單純是我在書店裡逛的時候覺得比較感興趣的書。兩本書一共花了我快 300 港幣，香港真的是什麼都貴。\n香港的出版業原本繁榮，自主權移交以來，卻一步步在審查的壓力下變得每況愈下。這次遊覽香港，所到書店，所閱之書，總感覺作者和出版社束手束腳，真是令人難以接受。無奈，選取一本港區國安法生效之前出版的書籍，以及一本中國大陸罕有的豎排印刷書籍，用以閱讀留念。\n山頂電車雙程票 就算我可以直接刷八達通，為了紀念，我還是有意買了山頂電車的雙程票。88 港幣的價格以香港的物價標準來看甚至可以作為日常通勤的交通工具，Hmm，還是我這個內地佬太窮了。\n前往山頂纜車中環總站的路上順道看了看滙豐總行後面的前法國外方傳道會大樓以及聖約翰主教座堂。後者是香港最古老的西式教堂，氣氛莊嚴肅穆，裝飾典雅精美，外觀樸素寧靜。中環真是遍地是寶。\n山頂纜車早在 1888 年就已經開始運作，目前已經更新到了第六代，從中環總站上車的人流絡繹不絕，其中很多是遊客，但也不乏本地人。山頂纜車的設計始終與時俱進，還增加了空調。這一點比起自開通以來從未更換過車輛的叮叮要強得多，當然，票價也貴了 20 倍有餘。\n登上太平山頂，可惜當天並不怎麼通透，拍不出什麼好照片。即使是用無人機拍也是如此。\n只能說由於天氣和設備都不太行，加上光圈開得偏大，最終有這樣的結果，我還算滿意。\n港幣紙鈔 不同於其他地方，香港的貨幣發行制度獨具特色，由香港金融管理局授權並監管下的三家發鈔銀行所發行，包括滙豐銀行、渣打銀行和中國銀行香港。香港政府則發行十元鈔票。這一次沒有拿到有英國女王頭像的硬幣，屬實有點可惜，但這些由不同發鈔行發行的紙幣，還算有點紀念價值 （其實就是紙幣沒花完罷了）\n其他一些照片 寫到這裡，我才意識到，雖然這些紀念品能串聯起我在香港的大部分經歷，但顯然無法涵蓋我在漫步香港的過程中中隨機發現的點滴。既然是作為紀念，關鍵事件就應該盡善盡美地記錄下來。因此，我不得不暫時停止對紀念品的描述，將我在港的其他經歷以照片的形式一一記錄。\n高鐵車票（報銷憑證）\u0026amp; Wrap Up 車票早就全面電子化，現在能取到的實體印刷票都是報銷憑證，並沒有車票的功能。而我不需要報銷，但也取出了車票，自然也是離港前的最後一件紀念品。\n","date":"2024-10-12T03:49:42Z","image":"/2024/10/hk-souvenirs/cover_hu_330bd22de0169088.webp","permalink":"/zh-hant-tw/2024/10/hk-souvenirs/","title":"我從香港帶回了哪些紀念品？"},{"content":"長話短說，最近我開始直播我的遊戲實況，我並不指望有多少人看，Just, Why not? 再者每個直播平臺都會有直播回放。相當於免費保存我每一次遊戲的錄像，何樂而不為？\n扯遠了，如你所見，近期我有了多平臺同時直播的需求，然而 OBS 本身顯然不支持同時推流，同時也因為不支持設置代理的特點和眾所周知的原因，無法推流到 twitch.tv，於是我開始尋找解決方案。\n明確需求 多路平臺同時直播 最好對性能影響小 其中一路需要推流需要代理 多路推流 多路推流有現成的插件可用：Github\n在 Release 頁面下載.exe安裝包，安裝完成後記得在「停靠窗口」菜單裡勾選「多路推流」。這時候默認會彈出一個獨立窗口，可以趁這個機會順便調整一下 OBS 的佈局。\n插件的設置也沒什麼好說的，用在原版 OBS 的填法在這個插件裡如法炮製即可。\nBilibili 直播姬 莫名其妙，B 站小於 50 粉絲的 Up 主只能使用直播姬開播，其他國內平臺做出類似規定者大概也不在少數，啟用第三方推流模式之後，直播面板會顯示推流的配置。此時的不需要按照直播姬給出的推流地址進行配置，因為直播姬莫名其妙的給了一個每次都會變的內網 IP，直接以127.0.0.1或者localhost替換即可。\n推流到 Twitch 推流到 Twitch 則會因為 GFW 多出很多不必要的麻煩。\nOBS 本身並不支持設置代理，起初我打算用 Clash 的 TAP 模式強制代理 OBS 的流量，而 Clash 的 TAP 並不監聽 rtmp 流量，宣告失敗。我決定直接架設一個轉發服務器，這個服務器需要既可以與 Twitch 通信，又可以不受 GFW 的干擾。\n在網上查到一些信息，Caddy 似乎不支持 RTMP 協議，而 nginx-rtmp 插件則專門為 RTMP 協議設計。這幾乎是唯一的選擇。\n部署的前提：\n熟悉基本的 Linux 命令行操作。 服務器已經安裝好docker和docker compose插件。 有合適的命令行文本編輯器，比如nvim或者絕大部分 distro 自帶的nano。 新建目錄：\nmkdir nginx-rtmp \u0026\u0026 cd nginx-rtmp創建docker-compose.yml：\nservices: nginx-rtmp: image: tiangolo/nginx-rtmp:latest container_name: nginx_rtmp ports: - \"1935:1935\" # RTMP port volumes: - ./nginx.conf:/etc/nginx/nginx.conf restart: unless-stopped創建nginx.conf：\nworker_processes auto; events { worker_connections 1024; } rtmp { server { listen 1935; chunk_size 4096; application live { live on; push rtmp://live.twitch.tv/app/{Twitch 主直播密鑰}; } } }啟動編排：\ndocker compose up -d # 老版本 compose 插件則是 docker-compose up當然，別忘了開放防火牆端口。我的防火牆參考了 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置，相應地，開放端口的命令如下：\nufw route allow proto tcp from any to any port 1935配置完成後，OBS 內的推流目標地址填入rtmp://服務器ip/live，推流碼填寫任意值均可。設置完成後即可開始推流。\nNetch 如果沒有服務器，亦可以使用 Netch 代理 OBS 進程進行推流。\n首先下載 Netch 1.9.2 版本，注意一定要是 1.9.2 版本。添加一個進程模式，將 OBS 文件夾加入，隨後啟用該進程模式的代理即可。\n尾聲 這次為了在同時在 Twitch 和 B 站上推流，遇到了很多原本不必要的麻煩。我可以怪 OBS 沒有內置代理功能，也可以怪 Clash Verge 等代理工具不支持 RTMP，轉來轉去，最終要怪的，還得是 GFW。雖然最後的結果還算令人滿意，僅僅為了推流而折騰這些東西的體驗實在是稱不上良好。也許我今後我應該去研究修改 Mihomo 內核，讓其支持 RTMP 協議，亦或是自己寫一套獨立的實現單獨轉發 OBS 的流量，不論如何，在這片土地上，想要暢快的直播，道阻且長。\n最後，歡迎關注我的 Twitch 頻道: https://www.twitch.tv/powerfullz233\n","date":"2024-09-18T06:16:51Z","image":"/2024/09/my-multi-streaming-setup/cover_hu_891493d684eb454d.webp","permalink":"/zh-hant-tw/2024/09/my-multi-streaming-setup/","title":"OBS 多路推流折騰記：那些本不必要的麻煩"},{"content":"某天早上醒來，發現收件箱裡多了封郵件，通知我的郵箱在韓國登錄，當時認為只是偶爾的 IP 誤判，也就沒有多想。可接下來幾天，時不時又有新的郵件進來，而且每次 IP 都不一樣，這下可就有些問題了，再不採取行動，怕不是郵箱真的要被拿去群發郵件。於是趕緊刪掉了域名的 MX、SPF、DMARC 記錄，尋找新的解決方案。\n我原本只是想改改密碼，結果呢，騰訊企業郵箱改密碼的入口真的巨能藏，到處都找不到。算了，遷移，何必受這氣。\n於是就有了這篇文章，從最開始的開放防火牆端口開始，到最後的優化送達率，我將分享我搭建 docker-mailserver 郵件服務器的經驗，希望能幫你少踩些坑。\n搭建 docker-mailserver 郵件服務器前的準備 防火牆的處理 首先先開放防火牆的郵件服務常用端口，分別是25、143、465、587、993，各分支開放端口的操作不同，請自行谷歌或詢問 AI，以 Ubuntu 使用的ufw為例：\nufw allow 25 ufw allow 143 ufw allow 465 ufw allow 587 ufw allow 993我的防火牆比較特殊，用到了ufw和 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置。所以當我想要把 Docker 容器的端口暴露在外時需要做出額外的配置。\n# 開放郵件服務器所需的端口 ufw route allow proto tcp from any to any port 25 ufw route allow proto tcp from any to any port 143 ufw route allow proto tcp from any to any port 465 ufw route allow proto tcp from any to any port 587 ufw route allow proto tcp from any to any port 993驗證你的服務器是否具備搭建條件 很多服務器，尤其是各種廉價的 VPS，並不適合搭建 docker-mailserver，各大郵件服務商為了過濾垃圾郵件，索性將所有曾經有過 Spam 行為的 IP 全部列入黑名單。如果你的 IP 被某個 Spammer 使用過，而恰好又被你的服務器提供商分配給了你，而你折騰了幾個小時的郵件服務器卻愣是收不到郵件，最後發現竟是 IP 被列入黑名單的原因，我不知道你會作何感想。\n有的服務器提供商的 IP 乍一看確實不在郵件黑名單中，但實際上搭建好之後還是無法發送郵件，為什麼？因為服務器提供商擔心 IP 被濫用，索性將郵件服務的端口全都封鎖了。\n使用如下腳本檢測你的服務器是否具備搭建郵件服務器的條件：\nbash \u003c(curl -sL IP.Check.Place) 如果在這一步發現你的服務器不適合搭建甚至不能搭建docker-mailserver，那就趁早打住吧，想辦法換一個更乾淨、限制更少的 IP 再說。\n搭建過程 拉取配置文件 docker-mailserver 需要配置的配置文件有兩個，compose.yaml和mailserver.env，分別拉取配置文件：\nmkdir mailserver \u0026\u0026 cd mailserver sudo apt install wget wget -O compose.yaml \"https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/compose.yaml\" wget -O mailserver.env \"https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env\"根據需求，可以修改不同的配置，下面是我修改的部分：\nPOSTMASTER_ADDRESS=webmaster@l3zc.com TZ=Asia/Shanghai SSL_TYPE=manual SSL_CERT_PATH=/certs/cert.crt SSL_KEY_PATH=/certs/cert.key用 Caddy 準備和自動維護 TLS 證書1 因為我已經在使用 Caddy，所以我這次就打算直接使用 Caddy 來自動維護證書。根據項目的官方文檔，我只需要在 Caddyfile 裡新增一個子域名，Caddy 就可以自動幫我維護證書。\nmail.example.com { tls internal { # ?? 這不是直接生成的內部證書麼 key_type rsa2048 } # Optional, can be useful for troubleshooting # connection to Caddy with correct certificate: respond \"Hello DMS\" }當我更新完 DNS 記錄，實際操作起來發現，我的情況比較特殊：我這臺服務器上並沒有用到 Caddy 的自動申請證書功能，而是使用了15年有效期的泛域名 Cloudflare Origin Certificate。即使我不為這個子域名指定證書文件，Caddy 也會在加載這張泛域名證書後認為無需再申請新的證書。這就很尷尬了，用 Caddy 的時候 Cloudflare Origin Certificate 和郵件服務器只能二選一。只好安裝了dns.providers.cloudflare，並放棄使用 Cloudflare Origin Certificate，轉而讓 Caddy 自動為每個子域名申請和維護 TLS/SSL 證書，反正都是自動的，眼不見心不煩。\n安裝dns.providers.cloudflare後的全局配置：\n{ acme_dns cloudflare {API_KEY} }最後把 Caddy 的證書存儲位置映射到 docker-mailserver 容器內。\nvolumes: - /home/user/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/:/certs/如果 Caddy 以 root 用戶運行，則證書的位置應當為/root/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/，做出相應的修改即可。\n然後就是之前提到過的配置，我將證書存儲位置映射到了容器內的/certs/目錄，所以配置為：\nSSL_CERT_PATH=/certs/cert.crt SSL_KEY_PATH=/certs/cert.key首次啟動容器 首次啟動容器需要立即（120 秒內）創建新的 Postmaster 賬號。\ndocker compose up -d docker exec -it setup email add 優化送達率 DNS 記錄 一條 A 記錄，名稱隨意（假設為mail），指向服務器 IP（Cloudflare 需使用「僅 DNS」） 一條 MX 記錄，Apex 域（@），指向mail.yourdomain.tld 一條 TXT 記錄（SPF），Apex 域（@），可以在這裡生成(可選)。 一條 TXT 記錄（DMARC），名稱_dmarc，可以在這裡生成（可選）。 一條 TXT 記錄（DKIM），名稱mail._domainkey，具體配置在後文（可選）。 DKIM, SPF 和 DMARC2 什麼是 DKIM，SPF 和 DMARC？簡單來說，DKIM 是一個數字簽名機制；SPF 類似於「員工名單」，記錄所有合法的發件服務器；DMARC 則用於指示收件方的服務器如何處理未通過 DKIM 和 SPF 驗證的郵件。3\n首先設置 DKIM，在服務器上生成公私鑰對。\ndocker exec -it setup config dkim生成後的公私鑰對可以在映射的容器目錄./docker-data/dms/config/opendkim/keys/下找到。\n下載 mail.txt（複製其內所有內容粘貼到本地文件也可以），將其導入到 Cloudflare Dashboard 即可完成 DKIM 設置。需要注意配置完成 DKIM 後需要重啟容器才能生效。4\ndocker compose up -d --force-recreate前面提到 SPF 相當於一個「員工名單」，既然我合法的發件服務器只有一臺，那麼 DNS 填寫如下設置即可。\n\"v=spf1 mx ~all\"再就是 DMARC，可以使用前面提到的模板生成，這裡不再贅述。\n如果你的域名服務商擁有自己的設置嚮導（例如 Cloudflare），亦可以使用它們簡化設置流程。\n客戶端設置 客戶端設置相對就很簡單了，IMAP 和 SMTP 服務器都是mail.yourdomain.ltd，開啟 SSL 後端口分別是 465 和 993，登錄即可。\n善用 MailTester 至此我們已經完成了搭建 docker-mailserver 郵件服務器的整個過程，在開始發送郵件之前，我們可以使用 MailTester 測試我們的配置是否正確。如果測試結果是 10/10，那麼我們的 docker-mailserver 郵件服務器應該會擁有漂亮的送達率，好好享受吧。\n如果不是 10/10，也不要著急，認真查看扣分的原因，對症下藥，一項一項解決即可。\nTODO-List 配套 WebUI 參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#caddy\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n更加具體的介紹: https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n在官方文檔中有提及。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-09-06T03:57:18Z","image":"/2024/09/docker-mailserver-deployment-recap/docker-mailserver_hu_a649605529f354c4.webp","permalink":"/zh-hant-tw/2024/09/docker-mailserver-deployment-recap/","title":"docker-mailserver 郵件服務器搭建記錄"},{"content":"我的 Firefish 實例搭建於去年的 11 月，使用的數據庫版本自然不是最新的，確切的說，是 PGroonga 12，一個基於 5 年前的 Postgres 的遠古版本。為了避免今後的兼容性問題和安全問題，同時為了更好的性能，今天這數據庫是非升級不可。\n升級一個用 Docker 跑起來的數據庫和升級其他的 Docker 容器有很大不同，並不是拉取一個新的鏡像就可以宣告結束。因為 Postgres 幾乎每個大版本都有 Breaking Changes，新老版本產生的持久化文件並不兼容，如果直接拉取一個新的鏡像運行，數據庫是無法啟動的，必須要採用一定的手段進行數據的遷移。\nPostgres 有官方的升級工具pg_upgrade1，這一次我不採用，因為我的數據庫跑了一年多，而且用的還是 5 年前的老版本，用這個工具我不確定會不會出問題。這次遷移，大致思路是先導出 SQL，再將導出的 SQL 導入新版本。\n升級前的部署概況 以下是一些升級前需要了解的配置信息：\n項目 配置 實例部署方式 Docker Compose 數據庫容器名稱 firefish_db 升級前的數據庫容器鏡像 groonga/pgroonga:3.1.9-alpine-12-slim 數據庫用戶 example-firefish-user 數據庫名稱 firefish Docker Compose 的數據庫部分如下：\ndb: restart: unless-stopped image: groonga/pgroonga:3.1.9-alpine-12-slim container_name: firefish_db networks: - calcnet env_file: - .config/docker.env volumes: - ./db:/var/lib/postgresql/data healthcheck: test: pg_isready --user=\"$${POSTGRES_USER}\" --dbname=\"$${POSTGRES_DB}\" interval: 5s timeout: 5s retries: 5導出當前數據庫 對數據庫進行升級之前，首先下線 Firefish 的編排：\ndocker compose down單獨啟動數據庫容器，導出當前數據庫為 SQL：\ndocker compose up -d db docker exec -it firefish_db pg_dumpall -U example-firefish-user \u003e backup.sql由於 Firefish 的數據庫比較大，導出過程可能需要很長一段時間，比如我的個人實例就用了十幾分鍾。\n導出文件的處理 可能是由於新版的 Postgres 認證方式有所變更，如果直接向新數據庫導入之前導出的backup.sql文件，就會改變新數據庫的 Authentication Scheme，導致之後 Firefish 連接數據庫時認證失敗。要避免這個問題需要對目前的backup.sql進行一些處理，只抽取出其中的firefish數據庫的部分，而不是直接導入所有數據。2\n#!/bin/bash [ $# -lt 2 ] \u0026\u0026 { echo \"Usage: $0 \"; exit 1; } sed \"/connect.*$2/,\\$!d\" $1 | sed \"/PostgreSQL database dump complete/,\\$d\"編輯一個 Shell 腳本為以上內容，保存至script.sh，用以處理目前的backup.sql：\nnvim script.sh # 或者任何你喜歡的編輯器 chmod +x script.sh ./script.sh backup.sql firefish \u003e\u003e upgrade.sql如果一切順利，當前目錄下就會出現一個名為upgrade.sql的文件，可以打開它看一下，確保其被正確導出。\n向新數據庫導入現有數據 修改docker-compose.yml：\ndb: restart: unless-stopped image: groonga/pgroonga:3.2.2-alpine-16-slim # 最新的容器 container_name: firefish_db networks: - calcnet env_file: - .config/docker.env volumes: - ./database:/var/lib/postgresql/data # 注意這一行的變動 healthcheck: test: pg_isready --user=\"$${POSTGRES_USER}\" --dbname=\"$${POSTGRES_DB}\" interval: 5s timeout: 5s retries: 5注意數據庫目錄映射配置由./db:/var/lib/postgresql/data變為./database:/var/lib/postgresql/data，這麼做是為了給新的數據庫一個 Fresh Start，同時也保存老的持久化數據，即使出現問題，也可以隨時用回老的數據庫。\n拉取並啟動新容器：\ndocker compose pull docker compose up db -d向新數據庫導入upgrade.sql：\ncat upgrade.sql | docker exec -i firefish_db psql -U example-firefish-user -d firefish取決於數據庫的大小，導入過程也會持續較長的時間。\n收尾工作 導入完成，啟動整個編排：\ndocker compose stop db docker compose up導入後的首次啟動不建議帶-d參數，建議不帶參數啟動，確保啟動過程沒有問題後再以-d參數啟動。\n最後，登入剛剛啟動的 Firefish 實例，檢查是否有任何數據損失，沒有問題的話就大功告成啦🎉\n官方文檔：https://www.postgresql.org/docs/current/pgupgrade.html\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考：https://thomasbandt.com/postgres-docker-major-version-upgrade\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-08-30T04:45:12Z","image":"/2024/08/upgrading-firefish-database-docker/cover_hu_c0ecfda1e4670195.webp","permalink":"/zh-hant-tw/2024/08/upgrading-firefish-database-docker/","title":"Firefish 數據庫升級記錄"},{"content":"上一篇文章提到，我搭建了一個基於 Aria2 的 BT 離線下載服務器。為了用 Caddy 反向代理部署好的容器，我把原來偷懶用一鍵腳本部署的 Trojan 給卸載了，問就是因為這腳本把 80 和 443 端口都佔用了，不卸載掉根本沒法繼續。\n於是離線下載服務器是搭建好了，可時不時需要的代理卻不得不下線。仔細一想，之前看到過有人 Cloudflare + V2Ray + WS 復活被牆的 VPS，既然是 WebSocket，還能用 Cloudflare 反代，那用 Caddy 反代又有何不可呢？況且 Caddy 還有自動 TLS，比起 Nginx + Certbot 的組合配置起來肯定更簡單。只要配置成功，我就可以在為 Caddy 留住 443 端口的同時跑代理了。\n安裝 VLESS 和 Caddy 安裝VLESS 可以直接使用 v2fly/fhs-install-v2ray 一鍵腳本：\n# 安裝執行檔和 .dat 資料檔 bash \u003c(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh)Caddy 的安裝請參考官方教程，例如，我使用 Debian 12，則使用以下命令：\nsudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update sudo apt install caddy配置 VLESS 編輯/usr/local/etc/v2ray/config.json：\n{ \"log\": { \"access\": \"/var/log/v2ray/access.log\", \"error\": \"/var/log/v2ray/error.log\", \"loglevel\": \"warning\" }, \"inbounds\": [ { \"port\": 1234, //任意端口 \"listen\": \"127.0.0.1\", \"protocol\": \"vless\", \"settings\": { \"clients\": [ { \"id\": \"super-random-uuid\", //隨機生成一個 UUID 替換即可 \"level\": 0, \"email\": \"example@example.com\" } ], \"decryption\": \"none\" }, \"streamSettings\": { \"network\": \"ws\", \"security\": \"none\", \"wsSettings\": { \"path\": \"/\" // 需要與之後的 Caddy 配置保持相同 } } } ], \"outbounds\": [ { \"protocol\": \"freedom\" } ] }編輯完成後保存退出即可。\n配置 Caddy 在你喜歡的位置創建一個 Caddyfile，或者編輯已有的 Caddyfile，加入如下內容，反向代理剛才在 VLESS 配置文件中設置的端口：\nyourdomain.com { # 用一個 Matcher 匹配所有指定路徑的 Websocket 請求 @websockets { path / # 與前面 VLESS 的 path 保持一致 header Connection Upgrade header Upgrade websocket } reverse_proxy @websockets :1234 }至此，服務端所有配置文件都編輯完畢。\n啟動服務 啟動 VLESS，並設置開機自啟動：\nsystemtcl enable v2ray \u0026\u0026 systemctl start v2ray啟動 Caddy/更新 Caddy 配置：\ncaddy start caddy reload # 更新配置用以上操作全部完成後，Caddy 反向代理 VLESS 就完成了。\n客戶端設置 客戶端方面需要手動設置：\n地址是綁定給 VLESS 的域名。 端口是 443 TLS 打開 傳輸方式選擇 websocket UUID 是之前填入 VLESS 配置文件的 UUID 所有的客戶端設置大同小異，至於 Clash 的配置文件，可以參考 Mihomo 文檔1，以下是我的示例配置文件：\nproxies: - name: \"A Random Name\" type: vless server: yourdomain.com port: 443 udp: true uuid: super-random-uuid flow: xtls-rprx-vision packet-encoding: xudp tls: true servername: yourdomain.com alpn: - h2 - http/1.1 skip-cert-verify: false network: ws smux: enabled: false需要生成 Clash 配置文件可以使用 V2RaySE 提供的工具。\n完成 好了，現在我們已經擁有了一個 VLESS 服務器，Caddy 會自動為我們申請和維護 TLS 證書，非常好用。\n只需要這麼小小折騰一下，我彷彿又找到了當年用一鍵腳本搭建 SSR 時的愉悅，好好享受這種能順利打開 google.com 時的興奮吧。\nTODO List 基本搭建 偽裝 畢竟繼承 Clash Meta 衣缽的 Mihomo 也算是 Clash 正統了。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-08-13T08:24:26Z","image":"/2024/08/caddy-vless-proxy/cover_hu_1cd20ddda32e23a.webp","permalink":"/zh-hant-tw/2024/08/caddy-vless-proxy/","title":"科學上網：用 Caddy 反向代理 VLESS"},{"content":"自從買了一些廉價 VPS 以後，手上就閒置了一臺 Azure 的學生機，除了用來跑個 Trojan 暫時沒有其他的用途。正好最近想要下一些 BT 資源，而國內的 BT 環境懂的都懂，遂決定用這臺接近閒置的機器離線下載 BT。\n首先聲明，所有 BT 下載行為需要自行承擔被版權投訴的風險。\n安裝 Aria2 對於這些不是「基礎設施」的軟件，我更喜歡直接拉取一個 Docker 容器的方案。我採用了P3TERX/Aria2-Pro-Docker1，這套已經修改好的 Docker 容器。Docker 容器部署起來如出一轍：首先編輯docker-compose.yml，docker compose up把所有容器都跑起來，最後反代暴露的端口即可。\n我的docker-compose.yml如下2：\nservices: Aria2-Pro: container_name: aria2-pro image: p3terx/aria2-pro environment: - PUID=65534 - PGID=65534 - UMASK_SET=022 - RPC_SECRET=replace-me # 記得修改這一行 - RPC_PORT=6800 - LISTEN_PORT=6888 - DISK_CACHE=64M - IPV6_MODE=false - UPDATE_TRACKERS=true - CUSTOM_TRACKER_URL= - TZ=Asia/Shanghai volumes: - ./aria2-config:/config - ./aria2-downloads:/downloads network_mode: bridge # 如果你需要用到 IPV6 網絡，也可以使用 host 模式 ports: - 6800:6800 - 6888:6888 - 6888:6888/udp restart: unless-stopped # 防止日誌塞滿硬盤 logging: driver: json-file options: max-size: 1m # 也可以使用其他面板 AriaNg: container_name: ariang image: p3terx/ariang command: --port 6880 --ipv6 network_mode: bridge ports: - 6880:6880 restart: unless-stopped logging: driver: json-file options: max-size: 1m用 Caddy 反向代理 之前的反向代理，我都是用的基於 Nginx 的方案，而在這段時間裡關於 Caddy 的好評不絕於耳，這次的我便換用了 Caddy，當然，主要也是想嘗試一些新東西、新技術。\nCaddy 的使用真的非常簡單，即使對新人也極其友好，例如，常用的反向代理本機某個端口，只需三行 Caddyfile 即可搞定。\ndomain.com { reverse_proxy :1234 }安裝 Caddy 請參考官方文檔，例如，我的服務器使用 Debian，則使用以下命令安裝：\nsudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update sudo apt install caddy安裝完成後記得開放防火牆和從服務商策略組的 80 和 443 端口。\n在域名服務商處將要綁定的域名指向服務器，就可以開始寫 Caddyfile 了。我們需要反向代理三個端口，分別用作不同的用途。我的 Caddyfile 如下：\n# Aria-NG 面板 download.l3zc.com { reverse_proxy :6880 } # Aria2 API arapi.l3zc.com { reverse_proxy :6800 } # Alist downloaded.l3zc.com { reverse_proxy :5244 }看到如此簡潔的配置文件，不由得感嘆，相比於 Nginx，Caddy 用起來真是令人心情舒暢。寫入配置完成後，重新啟動 Caddy3，就可以開始欣賞 Caddy 自動幫你申請 SSL 證書配置好 HTTPS 的絕贊過程。至此，反向代理的部分也就完成了。\n配置 Aria-NG Aria-NG 只是一個前端面板，可以和任何 Aria2 後端通信，為此，我們需要給 Aria-NG 提供配置信息。進入剛剛反代好的 Aria-NG 面板，轉到 AriaNG 設置，填入配置信息。\n其中，RPC 地址是剛剛反代好的 RPC 地址，協議選擇 HTTPS，請求方法選擇 POST，RPC 密鑰是在docker-compose.yml裡replace-me處你所替換的值。\n若「Aria2 狀態」旁出現「已連接」，說明配置正確。\n用 Alist 映射下載目錄 我們通過 Alist 映射下載目錄，以更方便的查看、管理和下載服務器上已經下載好的文件。Alist 同樣也通過 Docker 部署，由於 Alist 本身在容器內運行們，無法訪問容器外的文件，部署時需要將 Aria2 的下載目錄提前 Bind 到 Alist 的容器下。\n我的docker-compose.yml如下：\nservices: alist: image: \"xhofe/alist:latest\" container_name: alist volumes: - \"/etc/alist:/opt/alist/data\" - \"/home/azureuser/aria2/aria2-downloads:/aria2-downloads\" #這裡需要視情況綁定你自己的目錄 ports: - \"5244:5244\" environment: - PUID=0 - PGID=0 - UMASK=022 restart: unless-stopped第一次啟動 Alist 時，Alist 會隨機生成admin用戶的密碼，所以，第一次啟動這套編排時，最好不要帶-d參數，而是直接docker compose up，並把容器啟動後的輸出妥善保存。如果不小心沒有保存管理員密碼，可以用這個命令重新隨機生成一個：\ndocker exec -it alist ./alist admin random成功登錄 Alist 之後就可以開始掛載目錄了。\n驅動選擇本機存儲，掛載路徑需要注意，按照我的編排，我將容器外的/home/azureuser/aria2/aria2-downloads目錄掛載到了容器內的/aria2-downloads，所以掛載路徑應該是/aria2-downloads。\n完成 現在所有的服務都已經部署上線了，打開 AriaNG 可以添加下載任務，下載好的文件可以打開 Alist 看到，下載，以及在線觀看。\n搭建這套服務之前，請仔細查看 VPS 提供商的服務條款，確保 BT 下載行為不會違規。以及，除了盧森堡等少數國家/地區，下載被 DMCA 保護的資源可能會遭到投訴，這些風險都需要你自行承擔。\n反正我這 Azure 的學生機也是白嫖的，被投訴回收了我也無所謂，不管怎樣，現在可以心無旁騖的享受找資源的快樂了。\n當然也可以試一試SuperNG6/docker-aria2\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n參考原作者的docker-compose.yml\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ncaddy stop和caddy start，參考Caddy文檔\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-08-10T07:46:40Z","image":"/2024/08/aria2-downloading-server/cover_hu_935547325c8335d7.webp","permalink":"/zh-hant-tw/2024/08/aria2-downloading-server/","title":"搭建一個 BT 離線下載服務器"},{"content":"長沙可真是個好地方，三面環山，好不容易一面有個開口，偏偏就開在了北面對著洞庭湖，冬天冷空氣很容易深入，夏天熱空氣又很難散掉，再配合南方素有的潮溼，體感溫度更是雪上加霜，冬天冷得要死，夏天熱得要死。\n最近熱得實在是受不了，於是決定去山裡玩水涼快涼快。\n目的地 這次要去的地方名字叫作蘆溪村七仙殿，地處在長沙和岳陽的交界，歸岳陽管轄，離長沙城區 80 餘公里，開車需要兩個小時，前往需要提前留足時間，比如，一個下午。\n在長沙生活了這麼久，城區基本上能去的地方都去過了，唯獨郊區這些野景點的名字我愣是聽都沒聽過一個。這次知道這一處地方，還得多虧我爸刷抖音的時候被推送了這裡。好了，地方有了，挑了一個工作日的下午，吃完午飯，出發！\n駕車從長沙城區出發去七仙殿，一般有兩種路線，第一種是走一段武深高速，第二種則是純粹的走國道和鄉間小路。實際上，因為距離不算太遠而高速路段也不長，走高速單程只能省下約 20 分鐘時間。具體如何取捨就看個人了。目前我在放暑假，時間充裕，走國道和鄉間小路足矣。\n在鄉間小路上穿梭了快兩個小時，畢竟是鄉間小路，大部分時候速度表只能在 50 到 60 之間來回擺動，在我看來，這也是鄉間小路的優點──相對於平整枯燥的高速，小路蜿蜒曲折，風景獨特，在路上一隻手握著方向盤，一隻手握著剛從冰箱裡拿出來的飲料，視野開闊，陽光 毒辣 明媚──冰箱是後期加裝的車載冰箱，車上的點菸器電源驅動它輕而易舉。啜飲冰爽的飲料，欣賞鄉下的風景，駕駛遊刃有餘，好不愜意。反觀高速公路，車流小的時候倒也還好，不過是枯燥了一些，一旦車流一大，就只好聚精會神，毫無閒情逸致可言。\n冷水井 車輛逐漸進入了山區，就在快到目的地的時候，一棟廟宇映入眼簾，牆上匾額「冷水井」，這口井是傳說中的神仙泉水，香火旺盛，久仰這口井的大名，沒想到會在我們去野外的途中如此偏僻的位置遇到，我們立刻靠近停車，拿出車後早已準備好的水桶，在井前跪拜行禮，開始打水。前來行禮打水的人絡繹不絕，井前香火不斷，水桶也早已排起了長隊，好在打水的速度很快，當天的人也算少，並沒有等待太久。\n廟宇內的 LED 屏幕上輪流顯示功德榜1和井水「顯靈」的事蹟，例如某某人在醫院查出某某癌症，系不治之症，在飲井水後如何如何好轉，最後康復。上面的故事是真是假，是真的井水顯靈還是另有原因，這裡不做討論。這是當地的神井，不管真假，我依然入鄉隨俗，恭恭敬敬的行禮，以示我對當地人和當地神的尊重。\n井邊打水是需要付費的，價錢並不高，之前的井水是面向公眾開放，並提供工具，任由公眾取水，而現在需要付費，即使這樣，高峰時期，水桶排出的長隊，可以直到廟宇外頭。排隊的時間，可以延長到五六個小時。\n七仙殿 再向前開一小段，還要越一段野，就到了目的地七仙殿，這裡是一處連環瀑布，每個瀑布下都有水潭，水是山泉水，清涼無比。不過需要注意選路，否則光滑的石頭很容易就會滑倒掉下去。此處特別提醒，要不是我爸滑倒之後摔到了水潭裡，後果不堪設想。\n開了兩個小時車，終於到了，馬上換上游泳褲，去水裡涼快涼快。這個野景點，週末也是人滿為患，大家帶上吃的，在這裡玩水野餐，可以待上一天。然而，他們走之後留下的滿地垃圾可真是煞風景。\n好在水雖然看著不是很清澈，但還是實打實的涼快。下水的時候可真是戰戰兢兢，最後心一橫，一陣寒意過後，可算是下到水裡去了。然後就是玩水，跳水、游泳、洗頭，炎熱煙消雲散。一個意外之喜是這裡竟然有很多小魚，潛下水仔細看之前，都不知道有些小傢伙，見人就跑，既然我非魚，我也就不去瞎猜魚這麼做意義何在了。\n我的手機支持 IP68 級別的防水，理論上面對水下拍攝是沒什麼壓力的，平常我倒是秉持「防水濺不防手賤」的理念，並不會真的拿這部手機去下水。這次倒是破例讓其在水下拍攝了一次 （就是想要換手機了） 。到目前為止，我的手機功能一切正常。\n在這裡還遇到了一對夫婦，我們到的時候，他們說他們已經在水裡泡了兩個多小時，於是我就順便幫他們拍了一段跳水的視頻。\nYour browser doesn't support HTML5 video. Here is a link to the video instead. 這樣遇到同路人還挺不錯的。\n這裡水溫算是比較低的，大概 23 度，不宜在涼水裡待太久，玩久了也要注意補充熱量。\n收工，回家 在水裡泡了兩個小時，真是一次徹徹底底的消暑，在泡得不想再泡以後就直接收拾東西，打道回府，得益於這次消耗的熱量，以及解掉的暑氣，回家胃口大開，窮兇極餓，吃掉了不少飯。\n這幾年給我的感受是每年的夏天都比往年的更熱，從這點上來看，全球變暖誠不欺我。連歐洲人都熱得受不了開始裝空調了，如此嚴重的問題，也許不容小覷。\n吹了幾天颱風的「空調外機」，也希望這幾天的颱風發揮一點正面價值，趕緊過來幫我們製冷吧。\n捐贈者和他們的捐贈金額。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-07-26T09:14:06Z","image":"/2024/07/summer-cooling-off-wild-swimming/cover_hu_b2f1244eb71894a1.webp","permalink":"/zh-hant-tw/2024/07/summer-cooling-off-wild-swimming/","title":"夏日消暑：游水小記"},{"content":"我維護的線上服務裡，大部分都在海外，當時考慮到以後應該要在國內用一些資源，就依舊備案了一個國內域名，平時放一個空殼主頁在這個域名上，一些服務，我的統計服務、評論後端、博客舊圖片的 CDN、以及密碼庫，都放在這個域名上，以求更快的訪問速度。對於博客的一些前端資源，比如評論前端、jQuery（只是個例子，我的博客並沒有用到 jQuery），我也儘可能採用了國內的前端資源庫，像是字節公共資源庫、以及我不久之前還在使用的 staticfile.net。\n看了標題，想必你也知道了，不管是國內的前端資源庫，還是博客舊圖片的 CDN，我都已經棄用，現在你訪問我的博客，所有的前端資源以及博客上的舊圖片都不再將從國內加載。\n前端資源 年初 polyfill.io 被國內公司收購的事情一地雞毛，不久前，polyfill.io 被供應鏈投毒1，超過 10 萬個網站收到影響，安全研究人員發現，植入的惡意程序使用假的 Google 分析域名www.googie-anaiytics.com將移動設備用戶重定向到博彩網站。同時受影響的還有 bootcdn 和 staticfile。\n這件事情影響惡劣，但促成我直接棄用 staticfile 的，是這件事情帶來的連鎖反應，uBlock Origin 因這件事屏蔽了我前不久正在使用的 staticfile.net2，而我自己平時也在用 uBlock Origin，這就直接促成了我將 staticfile.net 替換回了 JsDelivr。\n舊圖片 再就是舊圖片 CDN，這個 CDN 原本採用了騰訊雲 CDN，用以加速中國境內的圖片訪問，大部分圖片經過壓縮，加上舊圖片訪問的人本身就比較少，用了一年有餘，期間平安無事，無非每月花一兩塊錢。直到有一天我打開自己的博客，發現以前的文章很多圖片無法正常加載，才意識到出了問題。登錄控制檯一看，好傢伙，一個山西 IP 刷掉了我 20G 流量，好在我設置了超量停止服務，否則不知道現在要給騰訊雲上供多少：\n於是我屏蔽了這個 IP 段，開了 CC 防護，又在騰訊雲上充值 20 元，重新開啟了 CDN 服務。本以為到這裡就結束了，泡了杯茶，準備休息。\n結果茶還沒涼，騰訊雲的短信又來了：\n這次還換了一個 IP 段：\n目前，網上只要一搜索，遇到類似情況的站長很多，V2EX 上也有相關的討論，大部分網友認為是跑 PCDN 的廠商乾的好事34。\n我懶得跟他們玩，直接把對象存儲和 CDN 全都搬到了 Cloudflare，犧牲一點國內訪問速度就可以了，無所謂，反正看我博客的人大部分都有代理。\n遷移的過程無非就是搬存儲桶，套 Cloudflare，因為在 Cloudflare Dashboard 上傳有最高 100 個文件的限制，搬存儲桶時我用到了 Alist 作為上傳工具，其他就沒什麼好提的。\n後記 就這樣，我所有的服務徹底拋棄了國內 CDN。\n看到近期接二連三的新聞，從 Docker Hub 鏡像被通知關停，到 polyfill.io 投毒，再到自己親歷的被 PCDN 刷流量，這烏煙瘴氣什麼時候才能消散呢……\n不管了，反正在這團烏煙瘴氣消散之前，我的服務就安心待在海外了。\nPolyfill supply chain attack hits 100K+ sites\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nhttps://github.com/uBlockOrigin/uAssets/pull/24285\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nhttps://v2ex.com/t/1055510\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n推測可能與運營商省間結算政策施行後，某些地區的高上傳家寬（例如 PCDN 等）為了躲避運營商封殺，降低“上傳/下載”比例，人為刷下載流量的行為有關。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-07-09T09:54:56Z","image":"/2024/07/abandoning-domestic-cdns/dx2_hu_68be1b4c837e4724.webp","permalink":"/zh-hant-tw/2024/07/abandoning-domestic-cdns/","title":"完全放棄國內 CDN"},{"content":"I just had a terrible day, and I decided to write about it. 既然這個想法是以英語冒出來的，索性我也起了一個英文標題。\n無眠 美好的一天往往開始於一夜好夢，糟糕的一天也往往源於一夜難眠。半夜兩點半徹夜難眠的我總算睡著了，早上九點醒來，掐指一算，最後就睡了六個半小時。昨晚莫名其妙出現的，快要讓我虛脫的苦悶與難過可真是一點都不減。這不，難受的一天開始了。\n喝酒 我打算喝點酒，我真的太痛苦了，莫名其妙的苦悶與難過折磨得我不成人形，我真的得喝點。要帶勁的，越烈越好，越烈越能麻痺我自己。還得大口大口喝，最好直接進入我的腸子全數吸收掉，這他媽的才過癮。啊，正好有威士忌，40度的，還差點意思，勉強吧！杯子，得要大的，來他一大杯，中途喝到一半必須重新斟滿，去他媽的清醒，老子今天就跟你爆了！\n酒入愁腸，沒有化作什麼狗屁相思淚，我的眼淚已經流乾了，再沒什麼好流的。兩口喝一杯，喝了好些酒，那感覺可真不錯！對外界的感知慢慢變得模糊，身體也不聽使喚，雖然難受，但可真過癮！情緒也變得說不上高興的高亢，看到什麼都多少給你敬一杯，敬你們所有人！哈哈哈哈哈哈哈哈！\n俗話說樂極生悲，這所謂的「樂」前腳剛走，「悲」後腳就到。可真是難受啊我滴乖乖，高亢的情緒終究沒能持久，上一秒還在天上飛，下一秒就跟天蓬元帥下凡似摔在地上。隨之而來的可是翻江倒海頭暈目眩啊。扶著牆邁著喝醉的亂步子，好不容易！終於到了廁所，管你中午吃的什麼玉盤珍饈還是草根樹皮，這回一視同仁，全都報銷嘍。\n這還沒完呢，頭暈可不是你說緩解就緩解的。有什麼辦法呢，只好躺在床上。剛剛覺得自己秒天秒地秒空氣，這下一夜回到解放前，躺在床上呻吟乏力。我這人很奇怪，別人喝酒睡得可勁兒香，我喝酒卻和他們喝咖啡沒兩樣。腦袋頭暈目眩，胃裡翻江倒海，睡也睡不著，可真是遭罪啊。\n幫倒忙的家人 可算是把下午熬了過去，你以為這就結束了？我喝得太多，我媽可就不樂意了，邊幫我做蜂蜜水解酒邊罵我，給我講那些不著邊際的道理。要是能講到點上，我是會去聽的，可是，你也猜到了，並沒有。什麼「照顧好自己是愛自己的基本表現」，「不要想太多」，還有一堆不知道從哪個營銷號聽來的東西，毫無邏輯。聽著這些東西可比被酒精折磨更遭罪，我是真的不想聽啊，但我媽卻還是要講。最後不出意外的引發矛盾，我媽開始生悶氣，只剩下我一個人在客廳難受，不對，更難受。晚飯終究沒人做，熱點剩菜也吃不下，回頭一想，這一天的飯，要麼吐了，要麼壓根就沒吃。\n後記 糟糕的一天真的很糟糕，我打算寫些什麼，也許我該寫些什麼，撫慰我被酒精和莫名其妙的苦悶難過折磨的腦袋和身體，頭暈目眩，胃裡翻江倒海，我寫下這篇文章以作紀念，也是對自己的一個告誡，下回，下回可得記住了，千萬別再喝成這樣。\n話說回來，在今天我所承受的痛苦裡，肉體上的痛苦似乎遠遠比不上精神上的痛苦，何其諷刺，I fucked up, but my parents made me feel even worse。這種莫名其妙的苦悶難過也真不好受，鋪天蓋地而毫無徵兆，讓我感到虛脫，也許我真的該找一個靠譜點的醫生看看。\n題圖來自：https://thehardtimes.net/blog/5-signs-your-belligerently-drunk-sobbing-friend-might-need-help/\n","date":"2024-06-01T14:00:05Z","image":"/2024/06/the-worst-way-to-spend-a-day/cover_hu_21c7c974b0d2726b.webp","permalink":"/zh-hant-tw/2024/06/the-worst-way-to-spend-a-day/","title":"The worst way to spend a day"},{"content":"寫博客時，我時常在擬大標題，小標題，寫完以後可能還會補一個副標題。標題有利於讀者快速釐清文章內容和結構，還有利於 SEO，固然有它很好的一面。\n這種幹什麼都先擬寫標題的習慣大概是在初中的語文課上老師強加過來的。常寫命題作文的我們，不知不覺的就開始先擬寫一個標題，然後以此為基點拓展、發散填補文章的內容，讓其成為一片「不跑題」的文章。到了高中，還要開始擬寫框架、提綱，用以確保自己的八股始終有話可講，不至於中道崩殂。人們常說應試寫作是「戴著鐐銬跳舞」。我曾認為，只要離開中學，我就可以「想些什麼，就寫什麼」。隨著時間的推移，這句話愈發顯得可笑。儘管鐐銬早已消失，昔日的籠中鳥卻依舊沒有自由，長期的自我審查已經讓翅膀僵硬，再度起飛變得無比艱難。\n寫文章最基本的目的，是表達作者的內心。沈從文一味的要在散文裡「寫我自己心和夢的歷史」，正是這無憂無慮，無拘無束的表達，讓作者獲得內心真正的自由，「結廬在人境，而無車馬喧」，這種真正意義上的寫作，才是我想要的吧。\n我以往的寫作方法，基本是擬寫一個大標題，開頭之後再通過各式各樣的小標題來展開文章內容。這就帶來了一個問題：新擬小標題後，我常常會停下來構思，對著小標題反覆斟酌，有時甚至會在怎麼起小標題上絞盡腦汁。終於寫下了一段話，不滿意了，還要修改，有時甚至反覆。寫作的暢快感在這個過程中早就消失的無影無蹤。於是半個小時候我便收筆，一看進度，只新增一段耳。\n我手寫我口，我手寫我心。這是我架設博客的原本目的，回想起來，這個目的經和我今天所寫不謀而合。在這兩年裡，為了讓博客做到「有人看」這一點，我做出了一些取捨，這些取捨固然有積極的一面，而這兩年來，我也愈發的意識到，就算有時寫一些技術文章，真正的寫作，終究是不能妥協的。現在這個博客已經上線兩年了。寫得越多，學的也就越多。看似一天天平凡的生活，事實上也在對我產生著點點滴滴的改變。寫下這篇文章，我衷心地感謝那個兩年前的自己開設了這個博客。\n今後我的生活類博客，小標題可能會愈來愈少，大綱也許會難覓蹤影。不論如何，本質上，我都會把那些作繭自縛的元素悉數剔除。「少擬小標題，多寫真文章」，寫出我自己「心和夢的歷史」。\n","date":"2024-05-09T16:01:22Z","image":"/2024/05/2nd-anniversary/cover_hu_3980137ebd8fec38.webp","permalink":"/zh-hant-tw/2024/05/2nd-anniversary/","title":"少擬小標題，多寫真文章"},{"content":"在寫下這些文字之前，其實我是有些想笑的，原因很簡單，且聽我講一段故事。\n清明假期前的下午，我在寢室裡等人，見室友的行李箱有一個海關鎖，出於安全考慮1，我就幫他把鎖釦上了。室友清明節回到家才發現這一點，於是氣急敗壞地在群裡發問：\n雖然確實不應該動室友的箱子，這點我確實做得不對2，但聽聞室友自己竟然不知道自己設的密碼，打不開自己的鎖，我大晚上忍不住笑出豬叫。我也沒有想到，一個原本可以算作無意的善舉的行為，最後的結果竟如此哭笑不得。\n既然室友已經打不開鎖了，那就想辦法幫他打開這個鎖吧。\n海關鎖的由來可以追溯到 2001 年，9·11 事件發生後，行李安檢就被提上日程。但有鎖的行李箱怎麼辦呢？全部撬開就太蠢了吧。於是針對這個問題就有了海關鎖（TSA Lock），這是美國交通部推出的一套鎖具標準，截至目前一共被 69 個國家和地區承認。\n海關鎖的設計初衷是讓海關能在沒有密碼的情況下打開這套鎖，所以設計了兩種開鎖方式，除普通的密碼開鎖外，海關鎖上還有一個鑰匙孔，只需要找到這個鎖具編號相對應的鑰匙，插進去就能打開。海關會撬開一切他們打不開的行李箱，整個過程可能會很粗暴，根據同學分享的經歷，他的行李箱因為沒有海關鎖而被美國海關撬開，即使他設置的密碼是「000」並且附上了一張帶有密碼信息的紙條。\n可是現在我們也沒有對應編號的鑰匙啊，難道就只能窮舉了嗎？雖說室友的海關鎖只有三位，但從「000」一個一個試到「999」可太難受了。對於室友來說，好消息是，自海關鎖誕生以來，行李箱上的鎖就發生了功能上的轉變，成為了一個防君子不防小人，而近乎形同虛設的鎖，不光密碼只有三位，其在設計時也設計了不少防止忘記密碼3的機制。例如，室友的行李箱有觀察窗，只需旋轉撥輪，分別找到鎖軸上的缺口，再將三個數字向前推五次，鎖就可以直接打開。只要掌握一定的方法，就可以毫不費力的打開任何帶有海關鎖的行李箱，其他的具體方法可以在網上搜一搜相關的教程，以前管制不嚴時，甚至還可以在淘寶上買到對應編號的鑰匙。好誒，不用窮舉密碼了！\n好吧，當我搜了一個開鎖的教程發給室友，室友卻早已試出了密碼，這件事情也就告一段落了。當然，下次，我再也不會好心幫你鎖上行李箱了（笑）。\n主要是無聊\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n後面我當然也承認了。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n這也導致任何人都只是「忘記了」密碼。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-04-16T13:20:02Z","image":"/2024/04/suitcase-incident/cover_hu_d588f852c66822ee.webp","permalink":"/zh-hant-tw/2024/04/suitcase-incident/","title":"室友的「行李箱事故」"},{"content":"得益於與 Steam Deck 一同而來的 Proton，在常見的 GNU/Linux（以下簡稱 Linux）發行版上暢玩各類原本在 Windows 上才有的 3A 大作成為完全可行的選擇，最近我也進行了這方面的嘗試，效果已經較為理想，但隨之而來的是一個問題，我總不可能把動輒上百G的遊戲全都重新裝一遍吧？硬盤沒空間了不說，這麼麻煩還不如切回 Windows 玩呢。\n出現$代表是終端命令，下面跟著的是命令執行後的輸出。\n掛載 Steam 庫所在的分區 起初我試圖直接在 GUI 上掛載分區，但這樣會遇到莫名其妙的問題，有這個想法的朋友請不要跳過這一部分。\n找到目標分區的 UUID $ sudo blkid /dev/nvme1n1p8: UUID=\"421a3d00-81a8-4112-a2df-4d234c674a24\" BLOCK_SIZE=\"4096\" TYPE=\"ext4\" PARTUUID=\"84e56276-a585-412c-9bf5-0071b2b4d4da\" /dev/loop1: TYPE=\"squashfs\" /dev/nvme0n1p1: PARTLABEL=\"Microsoft reserved partition\" PARTUUID=\"bbdb2720-6722-42b3-80f5-385332da77c3\" /dev/nvme0n1p2: LABEL=\"Vault\" BLOCK_SIZE=\"512\" UUID=\"DC64DA2064D9FCE8\" TYPE=\"ntfs\" PARTLABEL=\"Basic data partition\" PARTUUID=\"f884fe24-1c4d-4650-9847-d2f83b9a93ba\" ......如果你能在類似「磁盤管理」的應用裡查到目標分區的 UUID，也可以直接使用。\n查詢用戶 ID 和組 ID $ id -u 1000 $ id -g 1000默認狀態下，這兩個值都是1000。\n創建掛載點並修改 fstab $ sudo mkdir /media/gamedisk $ sudo nano /etc/fstab這裡也可以使用任何你喜歡的編輯器。\n在文件的末尾加上：\nUUID=DC64DA2064D9FCE8 /media/gamedisk lowntfs-3g uid=1000,gid=1000,rw,user,exec,umask=000 0 0如果你之前已經掛載過這個硬盤，請刪除之前掛載產生的那一行。\n大小寫敏感可能會導致問題，這裡使用的是lowntfs-3g，掛載後的 NTFS 卷將不會大小寫敏感，以免出現因大小寫敏感而找不到遊戲文件的問題。1\n防止出現 NTFS Read Error ⚠️注意：有報告稱這樣操作可能會造成數據丟失，請自行斟酌並承擔風險。\n由於 NTFS 的特性，如果創建在 Windows 上無效名稱的文件/文件夾將導致 Read Error，進而導致遊戲無法啟動。最常見的問題是文件名中包含:字符，而 Proton 在 NTFS 磁盤上創建的文件名中就包含了這個字符。\n修復這個問題相當簡單：在掛載的 NTFS 磁盤上創建一個/compatdata文件夾，並將其 symlink 到 Linux 分區上的文件夾。\n創建 symlink：\n$ mkdir -p ~/.steam/steam/steamapps/compatdata $ ln -s ~/.steam/steam/steamapps/compatdata /media/gamedisk/Steam/steamapps/如果提示/compatdata已經存在，刪除它並重新 symlink 即可。\n最後，添加 Steam 庫吧 操作完成後，重啟電腦，目標磁盤就會在 Linux 上自動掛載，這時進入 Steam 正常添加遊戲庫即可\n操作完成後，可以正常遊玩 Steam 庫裡所有的 Windows 遊戲，並且可以在任何一邊向庫內添加遊戲。\n本文參考：Using a NTFS disk with Linux and Windows\n來源：Server Fault\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-04-12T10:53:59Z","image":"/2024/04/mount-ntfs-drive-as-steam-lib-on-linux/cover_hu_f197ca1e93d3a83b.webp","permalink":"/zh-hant-tw/2024/04/mount-ntfs-drive-as-steam-lib-on-linux/","title":"在 GNU/Linux 和 Windows 間共享 Steam 遊戲庫"},{"content":"這幾天回學校，愉快的打開我的 Macbook，卻發現引導失敗自動進入了 GRUB 的基本命令行。\n之前用 Ubuntu 的時候也出現過這個情況，當時只需要啟動時按住 Option 鍵選擇啟動 Ubuntu，下次就能正常啟動。於是我就沒有把這次啟動失敗當回事，輕車熟路按下 Option 和電源鍵，而這次卻並沒有啟動成功，而是又進入了 GRUB 的基本命令行。\n修復引導 首先重啟進入 Mac OS，打開終端，diskutil list列出所有的磁盤：\n隨後掛載 EFI 分區：\nsudo diskutil mount disk0s1其中disk0s1可能在不同的電腦上有不同，請根據實際情況掛載 EFI 分區對應的IDENTIFIER。\n掛載 EFI 分區後用 Finder 打開它，將BOOT文件夾重命名為BOOT(Backup)以備不時之需。隨後建立一個新的BOOT文件夾，複製/Microsoft/Windows/Boot/bootmgfw.efi到剛剛新建的BOOT文件夾，重啟後即可解決問題。1\n為什麼？ UEFI 在啟動時默認會尋找名為bootx64.efi的引導文件。用 BootCamp 安裝 Windows 時，Windows 的引導文件被放在/Microsoft/Windows/Boot/bootmgfw.efi，BootCamp 安裝 Windows 時配置了正確的啟動順序，但一旦從 Mac 的啟動順序菜單更改啟動順序，就會出現這種莫名其妙的 Bug。至於進 Grub 的原因，也許是我之前安裝過 Ubuntu。\n後記 蘋果就是這樣，你在它自己的生態裡基本不出問題，一旦因為各種原因跳出它的生態，各種莫名其妙的小問題就會出現。要徹底解決這類問題，也許我應該去試試rEFInd這種第三方 Bootloader。\n雖然目前蘋果已經全面淘汰 x86，但連裝個 Windows 都能遇到這種莫名其妙的 Bug，蘋果的工程師真的有在用心工作嗎……\n方案和頭圖來源：Reddit\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-03-01T11:19:07Z","image":"/2024/03/bootcamp-windows-booting-problem/cover_hu_9d55f848559774c.webp","permalink":"/zh-hant-tw/2024/03/bootcamp-windows-booting-problem/","title":"用 Bootcamp 安裝 Windows 遇到的引導問題"},{"content":"緣起 終於有時間出門轉轉了。\n往年這個時候我們也在路上，當時防疫政策剛剛轉向，旅遊業的狀態基本和封控時期沒什麼區別。今年各大熱門旅遊目的地可謂人山人海，非常熱鬧。見大馬對華免籤，原定去大馬轉一圈，奈何家人工作太忙，沒有時間，而等到家人有時間，機票就漲到了五千多。這個價格，不如另立計劃在國內玩玩，於是初步擬定去廈門、泉州過年。\n在此之前，還得先回一趟我小時候長大的地方，去拜訪一些家人，這一部分是我的私事，暫且不提。\n整個旅行沒有像去年一樣做詳細的計劃，我們只是擬定在江西的某個城市中轉，並草擬了一個大概的日期計劃而已。\n出發 永州：不在江西，但必須要回去 從長沙出發，先上京珠高速（G4）隨後轉泉南（G72），中途經歷了一次小堵車，永州近在眼前。\n七三一九 永州是一個慵懶的小城，生活節奏很慢，想辦什麼事情，提前 15 分鐘出發就行。這個當年全市 GDP 只有幾百億，現在也不過兩千億的地級市，就是我長大的地方。\n這是當年在我家樓頂上拍下的照片，一江碧水，雲淡風輕，隔著一堵牆的樓下生產區滿滿當當的停著剛剛生產的汽車，當時獵豹生產三菱帕傑羅的貼牌車，加上本就是軍轉民，軍民兩邊銷路不愁，日子過得十分滋潤；湘江對岸是永州的中心城區，那時從始發站坐上 12 路公交車，就能一路去到江對岸上學、購物。當年的長豐獵豹是湖南最好的車企，光是永州這一座工廠的產值就一度佔到永州市 GDP 的一半以上，而一連串故事卻讓這家國企在 2021 年正式提交破產申請，但這也是後話了。\n只可惜，這樣的景色已經永遠消失了。這次回去看，江邊本是用作停車場的地皮已經蓋上了三十多層的樓盤，就連這個我原來住的小區都傳出消息，將來可能要被拆掉，或者改做什麼「人才房」、「福利房」。我離開的這段時間，太多東西都悄無聲息的發生了變化。\n濱江公園 濱江公園，冷水灘的中山公園，也是我小時候玩樂的場所。晚上出來散步，順便留下了一些照片，不過就沒有那麼刻意了。現在都有些後悔沒有白天來多拍一些。畢竟也有十多年沒回來看看濱江公園了，公園裡的樹，當年還是小樹苗，如今已經形成了一條林蔭「隧道」，而當年年輕的樹，現在都長成參天大樹。\n沿江還設置了一些 24 小時自助圖書室，環境自然是不錯，風景也很好。只是裡面的書籍可不盡如人意：我從本就只有一個書架的書籍裡隨手拿起一本，翻開一看，哭笑不得——這成本控制，好像有些過頭了。\n零陵古城 畫圖曾識零陵郡，今日方知畫不如。\n——歐陽修\n歐陽修對零陵郡給出了相當高的評價。論旅遊，永州的資源其實一點都不差，只是沒有開發利用好，加上旁邊就是桂林這種重量級選手，各種原因導致今天的永州有些名不見經傳。\n零陵古城是永州近幾年開發的，目前也沒什麼外地遊客，而沒有外地遊客就造成別緻的小店活不下去，氛圍營造不起來，於是外地遊客就更不來了，好一個惡性循環。現在的零陵古城更多的是服務本地人的商業聚集地（甚至不能叫做中心），除一些服裝租賃外就沒什麼供遊客消費的店鋪。不過老街是貨真價實的老街，來拍照也是很不錯的選擇。\n說到這裡我不得不吐槽永州的禁飛區——一個零陵機場的淨空保護區把永州僅有的城建區全部遮住，只要你還在市區，想飛無人機必須事先申請解禁。即使零陵機場的航班量少得可憐。\n柳子廟值得一看，裡面約等於一個小博物館。\n連文革時期都被革委會保護的文物，怎麼也不算是一般文物。當時的永州還是零陵地區，直到 20 世紀 80 年代才轉變成永州市。看到文物保護單位和革委會的落款在同一塊石碑上，總有種違和的感覺。\n零陵武廟 永州武廟是長江以南規模最大、最有地域特色的武廟。武廟供奉的是關羽，這棟始建於洪武年間，最後修繕於光緒年間的古建築，是文革後一片斷壁殘垣中唯一留存下來的珍貴遺產。「其中青石龍鳳柱四根，浮雕雌雄蟠龍，龍頭碩大，張嘴含珠，勢動欲騰，其中兩雌龍懷抱小龍，小龍形態活潑天真，精美絕倫」，是現已存在不多的古代雕刻藝術精品。1\n若不是親眼所見，很難想象當年雕樑畫棟的巧奪天工。\n「不發展就是最大的發展」 千山鳥飛絕，萬徑人蹤滅。\n孤舟蓑笠翁，獨釣寒江雪。\n——柳宗元《江雪》\n當年柳宗元被貶永州，為永州寫下了不少精彩的文字。除了《江雪》，還有《永州八記》中的《小石潭記》，以及《捕蛇者說》都曾作為經典被選入課本。柳宗元對於水、木、魚、石的描寫十分生動細緻。正如他在《愚溪詩序》中所說的「清瑩秀澈，鏘鳴金石」。柳宗元在永州的山水間找到了屬於自己的精神寄託，而他寫下的這些文字，處理得好，完完全全可以成為「桂林山水甲天下」這樣強勁的免費旅遊廣告。\n每當和別人談起永州，我最喜歡說的一句話是：「要工業，工業沒搞好；要旅遊，旅遊也沒搞好」。現在的永州，非常尷尬，空有一城好山好水，奈何旁邊就是桂林這樣的世界級旅遊目的地。原來全市工業的支柱企業現在已經淪落到破產的境地。到現在，永州還剩些什麼拿得出手的東西呢，我真的也想不出來了。\n本地人常有一種言論：永州不發展就是最大的發展——守住一城好山好水，把城市做得精緻、乾淨而富有「閒情逸致」，這便是永州最大的發展。\n南昌：長江中游地區「重要的」中心城市 武漢、長沙、南昌兩兩之間的距離差不多，三足鼎立構成了長江中游城市群。我常駐長沙，武漢也去過多次，唯南昌一次都沒去過。這次也算解鎖了長江中游城市群的所有城市。\n網上流行很多「環江西」的說法，像是什麼「環江西經濟圈」、「環江西 5G 示範帶」。現代江西的經濟確實落後於周邊省份不少。造成這個現象的原因很多，網上有不少視頻、文章解釋得比較詳細2，這裡不提。南昌給我的感覺符合「環江西」的印象——感覺像是 10 年前的長沙。\n比湖南更辣 湖南和江西是全國最能吃辣的兩個省，但要論誰是老大，江西稱第二，湖南絕不敢稱第一。是的，江西真的比湖南更辣。\n湖南人實際上就是江西人，元朝時的「江西鎮湖廣，湖廣填四川」3，導致湖南人的祖籍很多都是來自江西（包括我）。而在辣這件兩省的共同點上，江西人的微辣是真的辣。以我的主觀感覺，江西的微辣的辣量接近湖南的中辣。\n江西省博 博物館作為一個省古代文化的窗口，來到省會，自然值得一看。\n江西省博給我的總體印象是：很大，很氣派，但展出的東西偏少。也難怪，江西既不像湖南有馬王堆漢墓帶來的辛追夫人等世界級遺產，也不像湖北一代是古代楚國的經濟政治文化中心。看過湖南、湖北兩省的博物館，再看江西的博物館，會有種「歷經滄海難為水」的感覺。\n江西省博的展出，除了常規的古代青銅器等先人精美的用品外，還有他們本省特色。江西井岡山作為中央蘇區，留下了大量當時蘇維埃政權活動的痕跡。同時江西作為歷代重要的製陶業中心，也展出了大量古今陶器，都非常有特色。\n滕王閣 Your browser doesn't support HTML5 video. Here is a link to the video instead. 物華天寶，人傑地靈，雄州霧列，俊採星馳。《滕王閣序》將古時江西的輝煌極盡體現，江西古時的繁華，一半都在滕王閣上了。\n不是最「江西」的城市 提到江西最有「江西味」的城市，我第一個想到的會是贛州，而非南昌。南昌的存在感真的太低了，京九鐵路原本規劃的終點是江西九江，而江西最有代表性的古城則毫無疑問是贛州古城，就連江西本省的發展戰略，在不久前也還是著重發展九江和贛州。在「千城一面」的今天，南昌真的「太不江西」。它終究是一個沒有存在感的省會。\n宜春：泡溫泉 我怎麼知道宜春這個地方的？答曰：在高速上看到的廣告。這裡的溫泉名曰「富硒溫泉」，有說全世界唯一，有說全世界唯二，總之，就是泡溫泉，誰管你是不是什麼世界唯一。溫泉據說常年保持在70度左右，每天有兩萬噸溫泉水湧出，富含硒，含硫量低，是個絕佳的溫泉療養度假目的地。\n酒店裡的洗澡水也是溫泉水，有個缺點是容易忽冷忽熱。雖然也不知道是不是真的溫泉水，摻了多少燒的水也說不準。這麼一算，這個帶浴缸的酒店不就有半個私湯了嗎？浴缸的水不知為何小的可憐，況且房間也帶溫泉票，還不如直接下去泡正經溫泉。山頂的所謂無邊泳池當然也是溫泉水，卻因為水位不夠而變成了有邊泳池，讓人有些無語。這裡空氣十分清新，所謂「負氧離子」含量高，也不知道這個說法究竟靠不靠譜。\n溫湯鎮上常年 70 度的古井免費對公眾開放，形成了很有意思的文化——這樣的水溫，最適合拿來……泡腳：鎮上的人們，無分老幼，每天提著桶來到古井，打上一桶溫度恰好的富硒溫泉水，往井邊、往附近的長亭，一起坐下來泡腳、聊天。要是水變涼了，那就倒掉再打一桶，一直泡到滿意為止。要是說這裡有人長腳氣，我是絕對不信的。\n這裡的酒店春節漲價幅度竟然不大，也有可能是本身已經比較貴了，早知如此就應當在此地多住幾天。\n說好的去泉州廈門呢？ 至於為什麼沒去泉州廈門……\n參考了百度百科\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n可以看看這個視頻，https://www.bilibili.com/video/BV1mw411C7RL\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n關於這段歷史可以看看維基百科和湖南日報\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-02-18T06:20:47Z","image":"/2024/02/2024-new-year-trip-archive/cover_hu_13f375941587768a.webp","permalink":"/zh-hant-tw/2024/02/2024-new-year-trip-archive/","title":"計劃外的「不完全江西之旅」"},{"content":"寫下「年度總結」這幾個字的時候，我的心情大概是「獨愴然而涕下」。早就已經完成的差不多的年度總結因支原體感染和考試的壓力差點爛尾，能寫完這份年終總結，也相當的不容易。\n2023 年是艱難的一年，艱難的扛過年初的感染潮，艱難的返校考上學期沒有考完的期末考試，艱難的做課設，艱難的調整自己的心理和精神狀況，艱難的看著世界每況愈下……我艱難的過著自己的生活，支撐著我過完這一年的，恐怕真的只有人類生存下去的本能了。\n我不知道諸君這一年過得如何，但，活著就好。\n學業 生活活生生的給我開了一個大玩笑。\n自進入大學以來，我的學業一直不甚順利，這一年也不例外。\n放了個比暑假還長的寒假的我發現，上學期因防疫政策轉向造成的混亂而推遲的，五門大課的期末考試，鋪天蓋地的壓在我們頭上。可能是由於某種自我保護機制，我的精神還沒有不太正常。我的室友當時已經精神錯亂，足見這種爆炸式的考試安排壓力有多大。而由於這種保護機制，我也只能在巨大的精神壓力下，以很低的效率複習，最後的結果也是相當慘烈。大二下學期我調整狀態，休養生息，恢復精力。通俗的講——不去上課。但這並不意味著我沒有在學習，至少考試成績比上個糟糕的學期要好多了。但這也招來了一些意想不到的事情：嵌入式系統掛科了，簡直匪夷所思，詢問發現是因為我早八點名沒到，卡我平時分。然後我補考考了 80 分，我教的另一個補考的人死記硬背八股文考了 100 分，相當諷刺。\n大三上學期，我在一個暑假以後，深深的覺得自己要「努力」學習。現在看來，這並不是什麼好事。我因為這個想法，加上寢室打遊戲太吵，幾乎天天晚上跑去圖書館。我似乎太過於「努力」，以至於心病舊傷復發，說它痛的刻骨銘心毫不誇張。那幾天我在圖書館裡痛哭不已，回到寢室卻強作笑顏。這樣的心病，加上過分的「努力」，耗盡了我的精力，我再也學不動了。現在我終於知道，以我的精神狀態，在圖書館裡學習，是個錯誤的決定。\n回過頭來看看，我這種做法，像極了大一下學期不懂事的我恢復高中學習做法的那個學期。每天晚上跑到圖書館，真的太痛苦而低效了。兜兜轉轉又回到起點的感覺可並不怎麼好，而這在當時確實也是我能做出的最好的選擇，真不應當重蹈覆轍。\n我也算是發現了，我的精神好像不允許我太用力的學習。而超過那個限度，就會觸發我的某個保護機制，麻痺神經，不允許我繼續用力。目前我並不知道我能否破除這個限制，但這個限制能提醒我休息，也許是件好事。不過，想要全力學習的時候卻出現這種限制，何嘗不是一種悲哀呢。我好像是全世界最倒黴的大學生——臨近期末，遇上支原體肺炎，而逆天的排課卻讓只缺了兩天課的我被迫像之前一樣複習。到頭來努力了，卻什麼都沒有得到。從入學算起來，我也掛了不少科吧。「成績怎麼努力都提不動」的感覺，我從未有如此深切的感受過。或許，這就是之前我某句愚蠢許願的報應吧。而當我這些年來承受的這些苦難，歸根結底，這終究是我作為低階層，作為窮人的報應。為什麼我要為此買單？若上天有靈，可能告我？\n這學期做的電網規劃課設我認為值得單獨講一講，我們一開始嘗試去買一份，但到頭來純粹變成了交學費而已，相當諷刺。我高度懷疑其中一人用 ChatGPT 濫竽充數。於是最後我們用一週的時間做完了別人一個月才能做完的事情，並且為了趕在 Deadline 前交上去，我們一個寢室熬夜到五點半，去做最後的抄寫工作。四十幾頁的課設論文全都手寫，感覺那叫一個酸爽。\n健康 和去年相比，這一年我的健康狀況變化不大，無非是年初的時候從 COVID 中恢復，年末又趕上一個支原體感染。以及去腦科醫院確診的中度抑鬱和強迫症。\n抑鬱時常會發作，而我自認為強迫症對我而言沒有很大的影響。而在抑鬱發作的時候，我除了多喝點酒以及多休息以外真是一點辦法都沒有。心理健康的危機依舊在持續，這一年心裡的舊傷復發在一段時間裡耗盡了我所有的精力。\n陷入迷之狀態：\n娛樂不動，甚至音樂都不想聽\n學習不動，而後面考試一個接一個\n休息不好，覺都睡不好\n也就是想娛樂不行，想學習不行，想休息也不行\n這次的精疲力竭也終於讓我意識到了人的精力是多麼寶貴。我其實清楚，我的行為終究是在自暴自棄。我需要社會支持，這是我幾乎從未有過的。COVID 和支原體也觸發了我的焦慮和抑鬱，我現在的舉步維艱難以言表，卻也毫無辦法，只能硬抗過去。我出現了乾嘔，大概是焦慮症狀加重吧，至少心理醫生建議我藥物治療。\n這一年我不停的嘗試去治療自己，尋求外界支持。說來也怪，生活明明已經如此折磨，人類生存的本能卻一直拖著自己生活下去。這似乎是人類的福氣，但也成為每個個體的悲哀。\n讀過的書 書不會變，人卻會。\n讀書實際上就是在讀自己。2023年，我讀到的有新書，也有一些我十分喜歡的老書。每次讀這些老書，都宛如讀新書一樣。\n每讀到一本書，我都會把這本書的電子版傳到books.l3zc.com。當然也可能有例外，我整理了一下，這一年讀過文學作品有：\n《豐乳肥臀》（莫言） 《私刑》（梁曉聲） 《湘行散記》（沈從文） 《故都的秋（文集）》（郁達夫） 《如果世上不再有貓》（川村元氣） 《失樂園》（渡邊淳一） 《夏天、煙火和我的屍體》（乙一） 《東京夢華錄》（孟元老） 《十錦緞》（方寸光） 《解憂雜貨店》（東野圭吾） 《放學後》（東野圭吾） 《我是貓》（夏目漱石） 《擺渡人》（管他是誰） 除了這些我想得起來的，還有一些網文和輕小說，我不打算將他們放上來。\n可以輕易地發現，這一年我能想得起來的十二本文學絕大部分出自東亞。作為歐美的唯一一本《擺渡人》，讀後也覺得這本書寫得非常一般，甚至可以說很爛。我在《遣詞造句》中提到過，我很羨慕沈從文、郁達夫，甚至《十錦緞》那本武俠色情作者方寸光的國文功力（這作者語文功底是真的好）。而作為翻譯作品，只要原作者、譯者、出版社之中有一個不行，這本書的閱讀體驗就會很差。但東亞文化圈內文化相似性很高，翻譯過來也讀得更自然，更親切。\n即使如此，論我想要的文字功力，現在還活著的譯者裡，我還沒見過像傅雷那樣能將兩國語言融會貫通還帶自己風格的1。這些翻譯作品依然比不過本土文學，這也就是為什麼「原生」本土文學依舊佔了接近一半。\n我喜歡民國作品，喜歡文白過渡時的精煉，喜歡那種樸素而原始的感情。都說中國只有兩個時期出大師，一個是戰國，一個是民國，此言不虛。人們竟可以閒適樸素的腔調寫文章，至少說明兩點：政府沒有管制，收入足以過的舒適。以上兩點，自 1949 年後，從來未曾同時滿足過。可笑的是，現今當局竟還宣傳所謂「舊中國」「積貧積弱」，實在無恥至極也。\n讀完《故都的秋》和《湘行散記》後寫下的話\n（待補充）\n去過的地方 這一年年初進行了一次長途旅行，基本是沿著滬昆高速一路從長沙到麗江，到達沿途很多城市。這次旅行徒步了虎跳峽，在麗江古城待了很久，也算是放鬆了身心，當然，回程堵車 10 個小時的經歷除外。\n8月去了一次武漢，主要是聖地巡禮一些國 Gal。\n十分慚愧，作為一個不怎麼有錢的學生，我是沒有辦法做到高頻率長途旅行的。我也想去看看世界啊，但我沒錢，我的護照也不好用，我還是隻能洗洗睡了。\n聽過的音樂 音樂是我生活中重要的組成部分。鑑於我使用的平臺沒有一家的年度報告是能看的2，我決定自己總結一份年度歌單。\n這一年遇到能讓我眼前一亮的歌手主要有 Camelia 和 TAYORI(可以說就是倚水)，前者是高速戰神，後者是 J-Pop。星塵3在升級後驚豔到了我，自然也就循環了很多遍，在我的年度歌單上留下了這份記憶。\n有一種觀點叫做：音樂是反社交的。我頗以為然。一般朋友聚會時，大家會一起聽音樂嗎？顯然不會。即使遇到少數這種情況，播放的也大多是大家都接受的流行音樂。\n流行音樂能成為流行音樂總是要做出對應的犧牲，相比於所謂的「寶藏」，總會缺少那種獨特。\n這個歌單的每首歌的背後都有一些故事，一段經歷。他們可能是我失落時校園漫步的耳邊陪伴，可能是遊戲時增添趣味的背景音樂，可能是通勤時消磨時光的慵懶旋律……在此我竟一時語塞，無法表達。但看到它們，我依然能想起第一次聽到它們的驚喜與感動。而沒有經歷過這段故事的其他人，可能會只會覺得這首歌很平平無奇吧。\n我已不怎麼聽時下流行的音樂。這一年，我聽到的音樂裡，能給我驚喜的變少了，對比同樣是我手動總結的 2021 和 2022 年度歌單，這一年對歌單的選取顯得格外艱難。是因為聽到的歌質量真的在下滑？還是因為這一年壓力比以往更大，以至於留下了很多不好的回憶？我想兩者都有吧。\n玩過的遊戲 先來看看我的 Steam 年度報告：\n我大部分的遊戲活動都在 Steam 上進行，這份報告我認為十分具有參考性。\n2023年我的大部分時間都花在了和「車」有關的遊戲上：地平線 4 和 5，以及歐卡2，陪我度過了兩百個小時的遊戲時光。都說窮玩車富玩表，那我連個車都玩不起的窮學生豈不是隻能玩玩屌了。\n至於為什麼有的遊戲不在 Steam 上玩，呃，原因複雜。這類遊戲裡我打得最多的是群星，據我估計至少打了150小時。第二名當屬 Minecraft，但這遊戲沒人一起玩就太無聊了，所以大概實際遊戲時間在30小時左右。\n值得一提的是這一年看過的視覺小說/Galgame，我大概讀了 20 部。其中有 Nekopara 這種「經典遊戲」；還有三色繪戀、戀愛綺譚等國產 Galgame；也不乏一些小眾的 Galgame 如《Expression Amrilato》和《夏之鎖》。這些有的是 R18 作品，大部分則是單純的視覺小說。視覺小說就是小說的更高級的表現形式，好的作品在文學性和故事性方面完全實現了對一般小說的超越。\n這一年打完這一圈視覺小說/Gal，我很驚訝國產 Galgame 能做到的程度。\n國 Gal 因「親切」深得我心，這種題材的親切、生活環境的親切，是其他 Gal 無法提供的。正如前面提到，我很高興看到國 Gal 能夠在重重壓力下依然保持自己的追求，為我們帶來優秀的作品。說來也怪，在如此差的環境下，我們依然在一些方面有所建樹。人們總是去歌頌這些建樹，默認苦難的合理性，卻從來無人過問，是什麼造就瞭如此差的環境。\n前面提到優秀的作品在文學性、故事性上超越一般小說，部分我玩到的作品甚至實現了對社會議題的探討，甚至可以為少數群體發聲。這是中國大陸的創作環境下極為難能可貴的。\n這一年我一整年都沒碰原神，現在我回來做做主線，看看逆天策劃都幹了些什麼。\n社交 這一年的社交帶給我的感覺非常糟糕。\n本學期我們更換了寢室，一位原本的室友休學，換進來一個吵的不行的室友。這也是我走進圖書館的間接原因——我需要一個安靜的地方想想自己的問題。\n我可能需要幾個朋友，或者一隻貓。\n真的沒什麼人陪我玩遊戲，Minecraft 自然沒什麼人玩。飆車也沒什麼人陪我，我就只能自己一個人玩一玩。而 FPS 我本來就不玩。\n偶爾寢室幾個人會出去打打羽毛球，這種時候還是比較舒服的。\n其實我倒還挺懷念一個寢室一起打原神的日子，那段時間大夥們都挺快樂的。就像我在7月總結裡寫的一樣：在多年的孤獨後，我好想有點渴望線下的社交活動。我多次搬家，沒有什麼從小玩到大的同學，也沒有什麼住在附近關係還好到可以隨時去家裡玩的人。只能看著時間一天一天的過去，看著那些去找同學玩的人開開心心的來往。忽然發現，有朋友真是一件幸福的事情啊。這麼說來，沒有朋友是一種莫大的悲哀。\n2024年的祝願 這顯然不是一份完美的年終總結，我試著去寫，但總有傾訴不盡的思緒等著我去寫下。而我寫下的文字，也總是與我想要表達的有所出入。起初我以為是自己對中文的 Master 不夠，但現在我也想明白了，那是自己的表達欲被常年壓抑。而找回這份表達欲終究需要慢慢練習，這就是一場修行，我也希望自己能早日追尋到這場修行的真諦。沒有絕對完美的年終總結，我只希望，寫下這篇年終總結的自己，能找到屬於自己的成長與幸福。\n2023 年不由分說的是艱難的一年。在這種每況愈下的情形裡，更不用說去追尋自己了。我時常告訴自己，要直面「慘淡的現實」，但這現實未免太過於慘淡。\n我希望 2024 能更開心，更重要的是，我的付出能收穫到回報。這也是我也理應享受到的回報。一年的難過耗盡了我的精力，而我在這裡也沒什麼想說的了，只能希望，今年會更好。\n推薦去看看傅雷翻譯的《歐也妮·葛朗臺》\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n這是因為我經常因為版權等原因換著軟件聽音樂，而有的音樂甚至只能在 Youtube 上看 MV。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n虛擬歌姬。https://space.bilibili.com/15817819\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2024-01-17T09:09:20Z","image":"/2024/01/2023-end-of-the-year-summary-public/20240117173426_hu_28cd58b804814e66.webp","permalink":"/zh-hant-tw/2024/01/2023-end-of-the-year-summary-public/","title":"2023 年度總結"},{"content":"到底是什麼在支撐著我繼續生活？這些天我一直在問自己這個問題。\n從來不指望能在現實生活中收到真心的愛。我沒有見過純粹的父母，我不想接受他們那所謂的愛。即使這種不純粹的愛，還是扭曲的。我不愛自己，也不敢愛別人，因為我自己就接受過太多扭曲的愛。我很怕這些扭曲的愛壓得別人喘不過氣來。連父母尚且如此，和我沒什麼來往的人不必多說。\n我可以肯定這所謂的愛是不純粹的，每當我出現問題，父母的第一反應並不是給予支持，而是與我冷戰，辱罵，現在看來，更像一種推卸責任。我不過是一種投資而已，現實就是如此慘淡。在我抑鬱發作時，我媽的第一反應是「我以前還對你有要求，後面我只希望你開開心心，結果現在你連這個都做不到了」。噁心透頂，最後還是在「要求」我。到頭來，我還要向給我壓迫的投資人保證我不會自殺。\n我的生活並不算富裕，我也不對改善生活報什麼希望，再者，改善了以後又怎麼樣呢。想做的事情很多，但也沒錢/時間去做。不存在什麼心無旁騖，現實的壓力總能讓人被迫放棄自我。\n小城市長大，野路子出家，這是一種無奈。「寒門再難出貴子」，越是長大，我越能看清那些我與沿海、其他大城市、更高階層的人差距有多大。我讀高中讀得再怎麼累結果也不怎麼理想，而那所高中教給我的學習能力，那種能讓我一生受用的東西，遠不如名校、遠不如富人只耳濡目染就可以帶來的提升。那不是努力程度上的區別，而是維度上的區別。舉個例子，小時的我表現出對計算機的濃厚興趣，並且再三請求、要求家人讓我參加計算機相關的培訓，家人卻漫不經心，即使他們後來想，當時的小城市也找不到任何相關的資源。在我成長的過程中，類似的情況太多了，每一個選擇都可以讓我走上比現在更好，更開心，更充實，也更容易的道路。我很羨慕那些從小就可以浸潤在高質量知識裡的富人孩子，那些知識對他們來說唾手可得，甚至如母乳般源源不斷的喂到他們嘴裡的人（即使他們自己不願意！）。可惜窮人只讀得起普通的書，只能被迫讀書，只能走更難的路。（這種層次上的差距不止是物質上的，即使物質在短暫時間內取得優勢1，這種層次上的差距，終究是短暫的物質優勢無法彌補的）（還遠不止這些）\n現在的生活並不開心，更沒什麼樂子給我找。驅動著我活下去的，大概就只有人類世代保存下來的本能吧。這麼看來，我和沒有親人、一貧如洗的人沒什麼本質上的區別。\n我沒有家，將來更不會有。現實已經把我的心撕得粉碎，我的童年沒有愛，我的餘生也跟著腐爛。別人最美好的年華，在我這裡就只剩那些痛苦。我已經心灰意冷，不再尋求自己的「幸福」。儘管談到這個詞，我卻總是有一種痛徹心扉的衝動。那是一個我本應享有卻從未得到的寶貴財富。而我發現，現在的我，已經沒有辦法正常接受那些「幸福」了。只好回到自己的靈魂所在的那堆破銅爛鐵，喝兩罐便宜啤酒暫時麻醉自己。\n還挺希望自己早點死掉，這樣起碼還有人能埋了我。\n(題圖來自：https://wallhere.com/en/wallpaper/171796)\n短暫時間可能是一代人。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-12-13T14:40:45Z","image":"/2023/12/what-keeps-me-alive/grave_hu_78fbe99fb8f6ec66.webp","permalink":"/zh-hant-tw/2023/12/what-keeps-me-alive/","title":"我死誰埋？"},{"content":"需要的環境 Docker 和 Docker Compose 任意 Web 服務器 最速教程 為 Firefish 準備一個目錄：\nmkdir firefish \u0026\u0026 cd firefish ⚠️注意：近期 Firefish 更新頻繁，本文的docker-compose.yml已經過時，請參考官方倉庫中的docker-compose.example.yml和Notice for server administrators進行配置。\n用你喜歡的文本編輯器創建docker-compose.yml：\nversion: \"3\" services: web: image: registry.joinfirefish.org/firefish/firefish:stable-amd64 container_name: firefish_web restart: unless-stopped depends_on: - db - redis ### Uncomment one of the following to use a search engine # - meilisearch - sonic ports: - \"6666:3000\" # 6666換成需要的端口 networks: - calcnet # - web environment: NODE_ENV: production volumes: - ./files:/firefish/files - ./.config:/firefish/.config:ro redis: restart: unless-stopped image: redis:7.0-alpine container_name: firefish_redis networks: - calcnet volumes: - ./redis:/data db: restart: unless-stopped image: postgres:12.2-alpine container_name: firefish_db networks: - calcnet env_file: - .config/docker.env volumes: - ./db:/var/lib/postgresql/data ### Only one of the below should be used. ### Meilisearch is better overall, but resource-intensive. Sonic is a very light full text search engine. # meilisearch: # container_name: meilisearch # image: getmeili/meilisearch:v1.1.1 # environment: # - MEILI_ENV=${MEILI_ENV:-development} # ports: # - \"7700:7700\" # networks: # - calcnet # volumes: # - ./meili_data:/meili_data # restart: unless-stopped sonic: restart: unless-stopped image: valeriansaliou/sonic:v1.4.0 logging: driver: none networks: - calcnet volumes: - ./sonic:/var/lib/sonic/store - ./sonic/config.cfg:/etc/sonic.cfg:ro networks: calcnet: # web: # external: # name: web你也可以用 Melisearch，但這是最速指南，只講 Sonic。\n創建.config目錄：\nmkdir .config \u0026\u0026 cd .config創建docker.env：\n# db settings POSTGRES_PASSWORD=example-firefish-pass POSTGRES_USER=example-firefish-user POSTGRES_DB=firefish創建default.yml：\n#━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ # Firefish configuration #━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ # After starting your server, please don't change the URL! Doing so will break federation. # ┌─────┐ #───┘ URL └───────────────────────────────────────────────────── # Final accessible URL seen by a user. url: https://你的域名/ port: 3000 db: host: db port: 5432 #ssl: false # Database name db: firefish # Auth user: example-firefish-user pass: example-firefish-pass # ┌─────────────────────┐ #───┘ Redis configuration └───────────────────────────────────── redis: host: redis port: 6379 # ┌─────────────────────┐ #───┘ Sonic configuration └───────────────────────────────────── sonic: host: sonic port: 1491 auth: SecretPassword collection: notes bucket: default # Reserved usernames that only the administrator can register with reservedUsernames: [\"root\", \"admin\", \"administrator\", \"me\", \"system\"] signToActivityPubGet: true回到上一層目錄，創建./sonic/config.cfg：\n# Sonic # Fast, lightweight and schema-less search backend # Configuration file # Example: https://github.com/valeriansaliou/sonic/blob/master/config.cfg [server] log_level = \"debug\" [channel] inet = \"0.0.0.0:1491\" tcp_timeout = 300 auth_password = \"SecretPassword\" [channel.search] query_limit_default = 10 query_limit_maximum = 100 query_alternates_try = 4 suggest_limit_default = 5 suggest_limit_maximum = 20 list_limit_default = 100 list_limit_maximum = 500 [store] [store.kv] path = \"./data/store/kv/\" retain_word_objects = 1000 [store.kv.pool] inactive_after = 1800 [store.kv.database] flush_after = 900 compress = true parallelism = 2 max_files = 100 max_compactions = 1 max_flushes = 1 write_buffer = 16384 write_ahead_log = true [store.fst] path = \"./data/store/fst/\" [store.fst.pool] inactive_after = 300 [store.fst.graph] consolidate_after = 180 max_size = 2048 max_words = 250000全部創建好以後的目錄結構應該看起來像這樣：\n. ├── .config │ ├── default.yml │ └── docker.env ├── docker-compose.yml └── sonic └── config.cfg最後執行docker compose up，綁定域名、反代端口，實例就搭建完成了。\nFirefish 已經自動 Minify 了所有的前端文件，如果你使用 Cloudflare 或其他類似的服務，記得關掉 Auto Minify，否則會出現一些奇怪的問題。1\n以上就是最速教程。\n一些問題 Q：docker.env和./sonic/config.cfg密碼和用戶名不改沒問題嗎？\nA：沒很大問題，因為兩個服務沒有暴露到公網上，僅做個人使用不改也沒什麼大事。\nQ：為什麼 network 要叫calcnet？\nA：因為這個項目本來叫做 Calckey。\nhttps://github.com/misskey-dev/misskey/issues/10328\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-12-04T09:17:56Z","image":"https://blog-img.l3zc.com/firefishlogo.webp","permalink":"/zh-hant-tw/2023/12/firefish-deploy/","title":"最速 Firefish 部署指南"},{"content":"現在已經換成了 Arch，btw。\n現役一臺 MacBook (Retina, 12-inch, Early 2016)，官方最高支持到 Monterey，當時收來的時候我認為，我會 Stick with MacOS。\n這麼說是因為 MacOS 在我賣掉的老 MBP 上給我的印象是穩定好用，當時的想法是出掉 MBP 買入一臺廉價而性能夠用的 Windows 遊戲本和一臺天天帶出去的輕薄本——事實上我也不後悔這個決定。\n好吧我承認我高估了這顆兩核 m5 的性能，目前的狀況是：如果使用 MacOS，必須要開啟「減弱動畫效果」，否則會卡得生活不能自理。這就是 MacOS 的另一個特點：「易卡難崩」。\n於是我給我的 MacBook 裝上了 Linux，就有了現在這篇文章，written on Ubuntu。\nWhy Ubuntu? 我其實並不是很喜歡 Ubuntu，選用 Ubuntu 更多是一個無奈的權衡。\n本次安裝 Linux 的目的是獲得更好的性能和更流暢的體驗，讓我的日常工作更加輕鬆。這臺電腦是我的日常裝備之一，我不太希望選擇一個不夠穩定的分支。之前滾壞過一次系統的經歷讓我直接把 Arch 排除在外。我有太多事情要做，時不時滾壞的系統？ Don\u0026rsquo;t have time for that. I just want a system that works out of the box 。\n本來想裝 Pop!OS——System76 基於 Ubuntu 打造的系統，但安裝器不知為何老是閃退，遂放棄。\n用distrochooser.de選出了 OpenSUSE，並且在虛擬機上裝好 OpenSUSE + Xfce 試用。我非常喜歡這套環境，但 Xfce 似乎不支持 HiDPI，也不優先考慮。YaST 真的很好用，將來我會在別的電腦上用這套系統，但這臺電腦，no。\n在這臺 MacBook 上，Ubuntu 的驅動問題算是最少的。除了上面提到的兩個分支，我也嘗試了一些別的 Debian 系 Distro 比如 Linux Mint、Deuvan，甚至國產 Deepin，沒有一個擁有良好的硬件兼容性。\n在作出這些嘗試以後我認為已經沒有必要再挑三揀四，先用 Ubuntu 權衡才是最優解。\nSoftware：How Ubuntu fits into my workflow 我在安裝時就選擇安裝了 ThunderBird、Libre Office 等軟件。在進系統後也很快就用 apt 安裝好了所有我需要的 CLI 工具以及大部分應用。\n我在 MacOS 下的包管理器是 Homebrew，換到 Ubuntu 就改用了自帶的 apt，也接受了 snap，即使這會影響到我安裝 GTK 主題後的一致性。1與 Homebrew 相比，apt 提供更多的軟件包2，且 Homebrew 終究是作為一個第三方包管理器存在。\n為了安裝一些別的應用，我也安裝了 flatpak 作為額外的包管理器。雖然比較難用，但也確實擴充了軟件的選擇範圍。\nBrowsing Chrome 依舊是我的主力瀏覽器，我難以放棄它的同步功能，Which means I have no choice.\n所有網頁都可以正常工作，就像在 Windows 和 MacOS 上那樣，as expected.\nOffice files 學生要看的 Word、PPT、PDF 等，這些在 Libre Office 上顯示效果超出我的預期——基本都能正確顯示。字體什麼的都是小問題，.doc、.ppt文檔的佈局都正常，渲染也沒有錯誤。\n我從不在這臺電腦上做編輯 Office 的工作，即使在 MacOS 下也是如此。有這些工作我都交給了我的 Windows PC。\n即便如此，在 MacOS 上我卻依舊全量安裝了 Office 365。Office 365 在後臺更新頻繁，我打開 Office 時，經常彈出「正在驗證xxx」的提示，每次都要等很久，非常煩人。相比之下，Libre Office 只在我apt upgrade時才會更新，用起來不知道比 MacOS 舒服多少。我已經在考慮將這臺 MacBook 上的 Office 365 換成 LibreOffice。\nBlogging 我以 VSCode 作為代碼兼文本編輯器，用 Typora 來寫 Markdown 文章，用 PicGo 作為圖床上傳工具，用 Git 把寫好的內容和配置推到 Github 上併發布。我還在本地安裝了 Hugo 用以預覽我的修改，這些工具配置好以後使用起來和在別的平臺上無異。\nMusic 我主要使用 Spotify 和網易雲音樂來串流音樂。其中 Spotify 有 Native 版本，網易雲的 Linux 客戶端早已停止維護，可能網頁版才是更好的選擇。\nYoutube 其實也是個聽音樂的好地方。\nSocial QQ 的全功能 Electron 重構版本 QQNT 原生支持所有主流的分支，還有 Telegram。至於微信，我暫時沒有什麼硬性需求，用手機就可以了，有文件要傳到電腦上可以用 QQ 中轉。\n主流的 Twitter Like 社交平臺和 Fediverse 實例都有網頁版，部分還有 PWA3 可用，這些用 Chrome 就可以解決。\nThunderBird 是非常好的郵件客戶端，我在 Windows 上已經在使用，換到 Ubuntu 的預裝更無需重新適應。\nPassword Management \u0026amp; RSS 我的密碼管理器是 BitWarden，一樣原生支持所有的主流分支。\nRSS 閱讀器有老朋友 Fluent Reader 和 Thunder Bird，Fluent Reader 把 Fluent Design 直接原封不動搬了過來，一樣支持 Fever API 讓我和 FreshRSS 同步。\nNewsFlash 也是很好的閱讀器，原生支持 FreshRSS，稍微有點麻煩的就是必須用 flatpak 安裝，同時滾動時我能感覺到明顯的卡頓和發熱。不知道是軟件自身的優化問題還是 flatpak 的問題。\nProxy 網絡代理我採用 Clash Verge 和 proxychains 的組合，解決了終端和系統代理的問題。除了在打開管理面板的時候 Tauri 很佔資源以外，本身依然是穩定好用。至於 Proxychains 是用來解決部分工具即使設置了環境變量也不遵循的問題而安裝的。我只需要配置好然後proxychains任何一個命令就可以讓這個命令走代理。\nTerminal 終端應用直接採用默認的就好，我並不是 Bash 死忠粉，所以後來我也換到了 Zsh，和 MacOS 上一樣安裝了 Oh My Zsh。最近看到了 Terminology，準備一試。\nAirdrop alternative 傳文件的需求我用到了 QQ 和 Snapdrop。\nMy experience with Ubuntu 在瀏覽器越來越強大，網頁版應用和 Electron App 越來越多的今天，Ubuntu 的軟件生態雖然無法和 MacOS 和 Windows 相比，但也足以讓我有底氣 to make the switch。\nIt\u0026rsquo;s impressive Ubuntu 的性能相比於我在 MacOS 簡直就是一個天上一個地下。在安裝時我直接分了 4G Swap，所有的應用都啟動的非常快，與 MacOS 上彈個半天形成的對比非常強烈，甚至讓我懷疑我到底是不是在用同一臺電腦。對於這個性能表現我非常滿意。\n即使是 CLI 應用，Ubuntu 上跑起來也比 MacOS 上要更快，更利落。以我最常用的 Hugo 來說，hugo server甚至比我的 Windows 電腦要更快，以至於我甚至願意用它接上電腦來繼續寫文章。\n續航是我最滿意的部分：得益於更加乾淨的系統和無風扇的設計，目前這臺 MacBook 一次充電可以連續使用一個下午加一個晚上，相當於超過 8 小時的亮屏時間。但需要注意 Tauri 應用的效率問題，體現在實際使用上就是儘可能少用 Clash Verge 的控制面板。只要使用得當，就可以獲得超過 MacOS 的續航體驗。\n高分辨率支持還不錯，只要整數倍縮放就不會出現應用模糊的問題，但 200% 的縮放未免太大了一點，也許我該直接調調 DPI？\nIt\u0026rsquo;s not perfect 藍牙和揚聲器無法被驅動，我嘗試過打內核補丁，但毫無用處，這意味著外放根本不能用，藍牙耳機、鍵盤、鼠標也想都別想。鍵盤背光幾乎沒法用，想要黑燈瞎火的打字幾乎也是不可能的。前置 Facetime 攝像頭也無緣被驅動，雖然我在 MacOS 上也幾乎不用它。\n觸控板的防誤觸約等於沒有，寫東西時非常容易被觸控板干擾，目前我的解決方案是在寫東西時用TouchPad Indicator4的快捷鍵直接禁用觸控板。但這樣的體驗自然就不如打磨過防誤觸的 MacOS。\n雙指滾動的速度太快，導致我看網頁時不得不使用方向鍵滾動網頁。為了調整滾動速度，我試著從 Wayland 換到 Xorg，並用 Xinput 調整設置，但暫時還沒有看到成效。\n各種驅動上的問題以及體驗上的小問題非常影響體驗。我知道，這些問題中的某一些可能只需要花些時間和精力去做些 tweaks 就可以解決。但要在折騰和生產之間取得一個平衡的話，我想我大概會保持現狀。\nWrap up 我第一次安裝 Linux 時用的是 Ubuntu 16.04 LTS，當時的我苦於 Linux 軟件生態的匱乏而試著去折騰 Wine，許久終於用上了一些必要的 Windows 軟件，最後卻因心累而換回了 Windows。今天，我同樣在安裝 Ubuntu，除了驅動問題外，我幾乎從沒有遇到任何麻煩，並且幾乎全程樂在其中。這次日常使用 Linux 的嘗試無疑是成功的。\n我可以說 Linux 見證我成長。現在的我已經可以擁抱開源生態系統，很顯然，這次，我不再需要換回去了。\nCanonical 維護著一份主流 GTK 主題的 Snap 移植，但每次安裝新的 Snap 應用都要手動切換，非常不方便。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n相比之下，Homebrew 更像是一個命令行形式的 Appstore。當然我最喜歡的包管理器還得是 pacman。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProgressive Web APP，漸進式 Web 應用。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n本質上就是調 Xinput。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-11-07T09:38:50Z","image":"/2023/11/installing-ubuntu-on-macbook/IMG_7558_hu_8b6cb548722da663.webp","permalink":"/zh-hant-tw/2023/11/installing-ubuntu-on-macbook/","title":"受夠了 MacOS，我給 Macbook 裝上了 Linux"},{"content":"看到一篇博文，講到頂級域的問題，感覺很有意思。\n頂級域由其母公司及其所在的國家控制，在民主國家，受法律管轄；如果是威權國家，則受政府隨意控制。沒人會想把 Freedom House 開在 .ae（沙特阿拉伯）上。\n那麼所有民主國家的頂級域都是最好的頂級域嗎？\nEEF1發佈過一篇報告，報告指出：.com，.net這些域名都受 ICANN 控制，所有 ICANN 控制的域名實際上都受美國控制。既然如此，對比它們就顯得沒有必要。至於那些各種組織、公司控制的頂級域就更無必要對比，因為這些域名不需要經過任何程序就可以隨意回收，具體可以去搜索 Freenom 那些無恥的案例。於是，問題就被簡化成了：哪個國家有最好的隱私保護和言論自由法律？\n世界上有四個 ccTLD2 是完全由當地法院控制的：\n.at 奧地利 .de 德國 .ru 俄羅斯 .is 冰島 還有一個 TLD 誰都拿他沒辦法：.onion。\n這意味著要關閉這些域名的唯一方法是法院命令，不受司法系統以外所有干擾。這四個國家裡，前兩個是歐盟國家，至於俄羅斯的司法系統，還是權當他不可信好了。\n歐盟的政策有些過於激進，這就導致歐盟國家的域名都不是特別理想的選擇。鑑於最近歐盟險些被通過的，禁止端到端加密通信的議案，歐盟也變得不可信起來。\n所以我們就只剩下了兩種選擇：.is 和 .onion。但要讓絕大多數用戶都能看到你的站點，就只剩下冰島的 .is 可用。\n這麼看來，冰島的 .is 就是世界上最好的頂級域。但如果想要最強的匿名性和完全控制，還是選擇 .onion 吧。\n選域名甚至可以變成一個地緣政治問題，雖然大多時候選擇什麼頂級域都無關緊要，但知道自己域名的「生殺大權」掌握在誰的手裡依舊是必要的。目前世界上除了.onion外沒有任何一個去中心化且不受任何監管的域名。但這也不完全是壞事，冰島的 .is 域名就是一個範例，只要法律為公眾利益服務，司法公開公正，也可以確保我們的域名得到最大化的保護。\nElectronic Frontier Foundation，電子前線基金會。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCountry Code TLD\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-10-21T09:15:52Z","image":"/2023/10/best-tld/20231021143702_hu_1209cc434fda6c9d.webp","permalink":"/zh-hant-tw/2023/10/best-tld/","title":"最好的頂級域"},{"content":"我最近換到了hugo-theme-stack，However，主題作者似乎並未考慮到中國大陸一些特殊的情況1。我對其進行了一些調整，以適應我的需求。\n部署hugo-theme-stack Github Pages 實在太慢，且鑑於 Vercel 已經被「特殊照顧」過，為了穩定，我還是選擇了其他的託管服務。\n我採用 Github Actions 部署到 Azure Static Web App（Azure SWA），這個服務在中國大陸大部分會使用香港節點，訪問速度還不錯。我只需要按照提示點幾下，這套服務就會自動幫我在倉庫裡生成 Actions 所需的 yaml 文件。隨後刪除作者原有的deploy.yml就大功告成了——只需寫完文章然後 Push 到倉庫，Oryx2 就會自動構建我的博客併發布。\n不得不吐槽免費版的 SWA 邊緣計算要求必須使用 Oryx，而 Oryx 的生成速度又比原生的 Actions 慢多了3，實在是有些浪費性能。\n還有 Azure 一言難盡的面板，請坐和放寬……\n優化hugo-theme-stack 換用國內前端資源 CDN hugo-theme-stack前端資源大量採用了 JSDelivr，然而：\n可以看到，有些地方默認的 JSDelivr 前端資源甚至完全不可用。因此，更換這些前端資源成了當務之急。\n由於我們使用的是模組形式加載hugo-theme-stack，根本就沒有themes文件夾。Hugo 允許主題文件的覆蓋4，只需要將需要覆蓋的文件放在 working directory 即可。例如：我想修改原本在./themes/layouts/partials/head/下的custom.html，只需創建./layouts/partials/head/custom.html然後編輯，這個文件可以從原主題倉庫複製。\nhugo-theme-stack將通過外部加載的前端資源放在了./themes/data/external.yaml，我們在博客目錄下創建./data/external.yaml：\nVibrant: - src: type: script PhotoSwipe: - src: https://lib.baomitu.com/photoswipe/4.1.3/photoswipe.min.js type: script defer: true - src: https://lib.baomitu.com/photoswipe/4.1.3/photoswipe-ui-default.min.js type: script defer: true - src: https://lib.baomitu.com/photoswipe/4.1.3/default-skin/default-skin.min.css type: style - src: https://lib.baomitu.com/photoswipe/4.1.3/photoswipe.min.css type: style KaTeX: - src: https://lib.baomitu.com/KaTeX/0.15.6/katex.min.css type: style - src: https://lib.baomitu.com/KaTeX/0.15.6/katex.min.js type: script defer: true - src: https://lib.baomitu.com/KaTeX/0.15.6/contrib/auto-render.min.js type: script defer: true Cactus: - src: https://latest.cactus.chat/cactus.js integrity: type: script - src: https://latest.cactus.chat/style.css integrity: type: style由於 Vibrant.js 不在lib.baomitu.com上，所以需要自行解決託管問題。\n原項目裡這些前端資源還有個integrity鍵值用來校驗資源完整性，經測試似乎只有 JSDelivr 支持這個特性，這裡引用的 360 前端資源庫保留這個鍵值會報錯，於是一刪了之。實際上有了 https 加持，除非遇到國家級網絡攻擊這種極端的情況，我們也基本上用不到這個特性。\n我還修改了./layouts/partials/helper/external.html，直接去掉了所有的 Integrity：\n{{- $List := index .Context.Site.Data.external .Namespace -}} {{- with $List -}} {{- range . -}} {{- if eq .type \"script\" -}} {{- else if eq .type \"style\" -}} {{- else -}} {{- errorf \"Error: unknown external resource type: %s\" .type -}} {{- end -}} {{- end -}} {{- else -}} {{- errorf \"Error: external resource '%s' is not found\" .Namespace -}} {{- end -}}評論系統也引用了 JSDelivr，因此也要更換。我採用的評論系統是 Twikoo，創建./layouts/partials/comments/provider/twikoo.html，修改文件第一行：\n原主題的 Twikoo 版本是1.16.115，這裡也順便升級成匹配我部署的後端版本1.16.21。\n其他的評論系統也以此類推。\n添加圖片燈箱 原主題有一個「Image gallery」功能，但只支持本地圖片，這對於所有圖片都存在圖床上的我來說顯然不是什麼好消息。於是我只好自己添加一個圖片燈箱。\n我原本準備採用 fancybox，畢竟我最熟悉這個，但 fancybox 需要引入 jQuery，這和我想讓博客儘可能輕量化的初衷背道而馳。於是我找到了zoom-vanilla.js，雖然它也不完美，但論輕量是絕對夠格的。\n首先需要在前端引入zoom-vanilla.min.js和zoom.css這兩個資源，我直接丟進./static/引用，見仁見智。\n將這兩個資源放入./static/imgzoom/後，分別在\u0026lt;head\u0026gt;內和\u0026lt;body\u0026gt;前6引入 css 和 js：\n修改./layouts/partials/head/custom.html：\n修改./layouts/partials/footer/custom.html：\n引入前端資源後需要為所有圖像加上一個data-action=\u0026quot;zoom\u0026quot;。\n修改./layouts/_default/_markup/render-image.html：\n同前面一樣，我也列出了這個文件的一部分，真正修改的部分只有一個else分支和data-action=\u0026quot;zoom\u0026quot;。\n至此，圖片燈箱添加完成。\n變更 RSS 行為 這個其實有點超綱了，不過這個主題確實自定義了 RSS 模板。\nRSS 遇到了兩個問題，一個是輸出了我全部 50+ 篇文章，文件變得特別大，這顯然是不合理的；還有就是輸出了search、about等與 RSS 毫不相干的頁面。\n在配置文件config.toml末端加上：\n[services] [services.rss] limit = 10可以把 RSS 輸出的文章數量限制在 10 篇。接下來處理不相關頁面的問題，其實限制輸出 10 篇文章已經解決了第二個問題的大部分。此時更新後的 Feed 依然會在第一個輸出about，而且輸出日期會隨著構建時間變化，暫不清楚是什麼原理導致的。\n我的解決方案是引入一個新的 Front matter 鍵值nonRSS: true，編輯./layouts/_default/rss.xml的前部分：\n{{- $pctx := . -}} {{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}} {{- $pages := slice -}} {{- if or $.IsHome $.IsSection -}} {{- $pages = $pctx.RegularPages -}} {{- else -}} {{- $pages = $pctx.Pages -}} {{- end -}} {{- $pages := where $pages \"Params.hidden\" \"!=\" true -}} {{- $pages := where $pages \"Params.nonRSS\" \"!=\" true -}}\t//加入這一行 {{- $limit := .Site.Config.Services.RSS.Limit -}} {{- if ge $limit 1 -}} {{- $pages = $pages | first $limit -}} {{- end -}}重新構建就修好了 RSS Feed。\n建議搜索引擎不索引「標籤」頁面 不知道為什麼，搜索引擎總是喜歡把我的標籤頁面編入索引7，我決定給每個 Tag 頁面加上一個noindex標記。並且用robots.txt排除這些頁面。編輯baseof.html，在\u0026lt;head\u0026gt;部分加入如下內容：\n{{ if .Data.Singular }} {{ end }}這樣應該會給每個 Tag 頁面加入一個noindex標記。\n在./static/下創建robots.txt：\nUser-Agent: * Disallow: /tags/這樣就可以把所有 Tag 頁面排除索引。\n作者 JimmyCai 似乎住在西班牙\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAzure 的邊緣計算，https://github.com/microsoft/Oryx。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n通過 Actions 調用 Oryx。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n詳見Hugo官網：Anytime Hugo looks for a matching template, it will first check the working directory before looking in the theme directory. If you would like to modify a template, simply create that template in your local layouts directory.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n現在已經升級成1.16.21，PR#877\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n至少作者是這麼說的，我放在\u0026lt;footer\u0026gt;也照樣用。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n可能是因為站點地圖\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-10-20T08:53:49Z","image":"/2023/10/theme-stack-tweaks/hugo-theme-stack_hu_3b3c2d39a29d982.webp","permalink":"/zh-hant-tw/2023/10/theme-stack-tweaks/","title":"Hugo Theme Stack 針對中國大陸部署優化不完全指南"},{"content":"如你所見，我遷移到了 Hugo。\n這裡曾經跑著 Wordpress，那是在去年 7 月部署好上線的，到遷移的時候用了也有一年有餘。\n為什麼放棄使用 Wordpress？ 遷移並不是因為 Wordpress 不夠優秀，相反，Wordpress 是一套非常好的 CMS：它歷史悠久1、運行穩定、大而全、傻瓜式安裝，這些都是我當時選擇它的重要理由。2\n但既然這麼寫小標題，想必大家都能猜到 Wordpress 也有很多驅動我遷移的缺點。\n過於笨重： Wordpress 真的太重了，一大堆我不需要的功能在那裡擺著。對於個人網站來說， Wordpress 顯然是太多餘。笨重還帶來了嚴重的性能問題，這點也是我當時把它從香港 Azure 遷移到美國的原因——就是因為美國的服務器更便宜。不成想， Wordpress 跑在上面卻依然消耗了超過預期的資源。與其消耗大量資源跑一個博客程序，還不如用這些資源跑些別的。\n易受攻擊： 動態網站的攻擊面很大，尤其是這種用戶基數大的程序，攻擊的收益很高。舉個例子，在我使用 Wordpress 的這一年裡，幾乎每天都有機器人爆破我的/xmlrpc.php。這還不算什麼，即使套上 Cloudflare，相同服務器配置下，Wordpress 能承受的訪問量3也不會很高。\nMarkdown 水土不服： 相對於原生支持 Markdown 的博客框架，Wordpress 對 Markdown 的支持可謂是非常差的，每次我以 Markdown 寫好的文章在 Wordpress 上發佈總要經過一些修改。不要跟我說 Wordpress 是二十多年的老軟件，就可以不兼容 Markdown，只要想做，就絕對不會是現在這個樣子。\n主題不合我胃口： 現有的開源 Wordpress 主題，我用過的有 MDx、Hourglass Twins 和 Argon。這幾個主題幾乎都沒有再更新或者「處於緩慢維護狀態」。既然都不再維護，樣式也或多或少的過時。\n加載速度太慢： Cloudflare 在大陸的直連速度懂的都懂。雖然我自建前端資源 CDN 緩解了一部分問題，但基調依然是加載慢。\n為什麼選 Hugo？ 最開始，我還沒有服務器，我的博客是基於 Hexo 構建的4，之所以放棄使用 Hexo，是因為我當時想要評論功能，以及跨設備編輯文章的能力5。\nHugo 沒有噁心人的node_modules，生成速度比 Hexo 快得多，主題也合我胃口，而且我也學過一點 Go，所以就決定是它了。Hugo 主題不需要學 Node.js 就可以魔改，簡直不要太舒服。\n遷移 之前 Hexo 裡寫好的 Markdown 文件基本可以直接扔到./content/post/裡直接用，不過 Hugo 對文章頭部的 yaml 要求更規範。例如：即使只有一個categories，也必須使用列表。\n永久鏈接這個時候肯定是對不上的，改一下permalinks.toml就可以了：\n# Permalinks format of each content section post = \"/:year/:month/:filename\" page = \"/:slug/\"還有一些文章我打草稿的時間是 n 月，發佈的時候變成了 n+1 月，永久鏈接就變得不一樣，這些文章也要一一處理。\n友鏈沒辦法，只能一個一個手動搬過來，好在本來只有十幾條友鏈，這並不是什麼難事。\n評論就不一樣了，目前沒有找到什麼導出方法，只能全部丟掉，或者日後慢慢搬過來。\n部署的地方？ 本來想 rclone 部署在自己的服務器上，後來發現 rclone 太慢，也不能跨設備編輯文章，遂放棄。\nGithub Pages？免了吧，太慢了6。Vercel？主 CNAME 已經被屏蔽了，感覺隨時要涼6。於是乎我就找到了 Azure Static Web App，速度還行，還免費，就它了。\n然後就遇到了 CNAME 和 Apex 域衝突的問題，這個真沒辦法。CF 的 CNAME 拉平國內容易拉平到美國節點，只好新開了一個子域blog.l3zc.com並重定向了上去，算是解決了這個問題。\n待辦清單 SEO 評論遷移 圖片燈箱 修好 RSS feed 近況 （回憶起近況，實在有些痛苦，我暫時不太想寫這一部分。現在我試著開始寫，看看能不能寫出來）\n現在沒那麼痛苦，卻早已忘記，或許這就是一種自我保護吧。\n說得難聽點就是老古董。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n當時的我也沒有想到，這些理由中的一部分竟也會成為我遷移的重要推動力。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDDoS 的訪問量也算訪問量。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n現在我還留著這個博客，https://hexo.l3zc.com。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n當時我還不會用 Github Actions。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n指中國大陸。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-10-03T11:30:05Z","image":"https://blog-img.l3zc.com/202310152020849.webp","permalink":"/zh-hant-tw/2023/10/migrate-to-hugo/","title":"遷移到 Hugo"},{"content":"2016年11月7日通過的《中華人民共和國網絡安全法》第二十四條規定，「網絡運營者為用戶辦理網絡接入、域名註冊服務，辦理固定電話、移動電話等入網手續，或者為用戶提供信息發佈、即時通訊等服務，在與用戶簽訂協議或者確認提供服務時，應當要求用戶提供真實身份信息。用戶不提供真實身份信息的，網絡運營者不得為其提供相關服務。」\n到了教育部這裡落實，就變成了校園網一人一號。再到運營商這裡，就變成了一人一終端，還不準使用路由器。這顯然已經和合規沒有任何關係，學生的需求也擺在這裡，但限制卻還是這個鳥樣。好一點的大學，比如上海交大這種坐擁華東教育骨幹網的學校可以做到校園網免費，為什麼我們甚至不能放開連接設備數量上的限制呢？\n2015年以來……目前，我校IPV4/IPV6總出口帶寬達到47GB，其中電信25GB、聯通10GB、移動10GB、教育網2GB，校園網總註冊用戶數超過4.34萬、活躍用戶數超過2.43萬。辦公賬戶（免費）帶寬由2MB升到36MB。宿舍區基本賬戶（付費）帶寬由2MB升到12MB，網費不變。……\n這套數據應該不是最新的，2022年寒假校園網又進行了一次大擴容，具體擴容了多少不得而知。如果按照這套數據計算，總出口 47GB，活躍用戶數2.43萬，則人均帶寬是$ \\dfrac{47GB _ 1000 _ 8}{24300} \\approx 15Mbps $。這點可憐的帶寬，還要給學校的官網防 DDoS，加上網安等種種因素，就變成了一人一終端這種限制。\n現在的大學生還有幾人是有且只有一臺上網設備的？室友間的一些操作也需要一套局域網環境（文件共享、聯機遊戲……）指望推動學校在短時間做出這套改變不太現實。但需求總要解決，只能先自己想想辦法，從技術上解決這個矛盾了。\nUpdate 2023/10/7：可能是部署了新設備，經測試，在敏行軒，本文措施失效——即使部署所有措施，依舊會頻繁被檢測。雖然我的腳本可以自動讓路由器重新上線，但上網體驗會變得很差，遊戲更是幾乎不可能。那麼，敏行軒大概率是部署了新的檢測方法，基本只剩加密所有流量這一條路可走。\nUpdate 2023/10/16：現在在敏行軒（其他區塊只會更寬鬆），最有效也最簡單的辦法就是用 Clash 代理所有流量（即使全局直連也可以），具體方法文章後段有詳細說明。\n硬件 需要一臺可以刷入 OpenWRT 的路由器，我採用的是一臺 Nano Pi R2S，最好選擇這種用戶基數大固件多的產品，也最好能自己編譯固件。\n關於如何為路由器刷入 OpenWRT 請自行在網上搜索對應的路由器型號+教程。不建議購買所謂的「校園網路由器」，這種路由器通常價格比同性能路由器貴非常多，而且賣的人還不一定懂技術。\n接入路由器 通過一段時間的觀察，可以得到我校校園網前端的計費系統採用城市熱點的 Dr.COM，這是一套非常常見的計費系統；BRAS 終端是銳捷的設備，採用 POE 方式連接銳捷的 AP，似乎沒有參與認證。\ndaemon.info pppd[8599]: CHAP authentication succeeded: Welcome to Drcom System:我將校園網分為三大類接入方式，無線，辦公區有線，學生公寓有線。\n前兩者都是 DHCP+Portal 驗證，網頁表單提交賬號即可完成驗證。學生公寓區域的有線設備通過 PPPoE 認證，賬號信息就是校園網賬號本身。\n因此路由的接入方式便確定了。宿舍的有線直接 PPPoE 認證就可以正常上網了。對於 Portal 的要麻煩一些，若無法連接外網則判斷 Portal 能否訪問，能訪問的話提交一個構造好的 POST 包登錄即可。\nPortal 認證的腳本校友已經寫過不少：\nhttps://github.com/linfangzhi/CSUST_network_auto_login\nhttps://github.com/eigeen/csust-cn-login\nhttps://github.com/colawithsauce/csust-network-login\n路由器上安好 python 和 requests 庫然後運行這些腳本即可。如果因無網絡不能安裝，重新編譯一個固件就行。再不行就寫一個 Shell 腳本登錄。\n封鎖狀況 此時已經可以通過路由器上網了，但依然不能全寢共享。\n校園網多設備共享很被檢測到會被臨時屏蔽，此時會屏蔽所有的網絡流量，據說還會強制重定向所有 HTTP 請求到http://1.1.1.3/remind/proxy_remind.htm?tm=8，不過我是沒有遇上。\nUpdate: 會強制重定向到以下網頁：\n查閱資料發現，檢測是否多設備共享有兩種思路，一種是通過設備流量特徵識別：\nTTL IPID 時間戳 UA 另一種是侵入式流量審計，這個可能看學校，不過我校肯定是有的：\n增強網絡安全防護能力。……部署出口防火牆、出口行為審計……、IPS(入侵防禦)等安全設備系統，加固學校網絡和信息系統的整體安全。\n通過一次喊人來寢室修網絡得知肯定是深信服的設備。\n通過路由器裸奔一段時間發現如下規律：\n兩臺不同平臺的產品（如 Windows 電腦和 iPad）同時上網會在較短時間內被封鎖 封鎖時用代理可以連出去，B 站也能看，其他的不行，甚至無法 Ping 通校外 IP 被封鎖後重新認證也無法上網，更換 MAC 地址後才能恢復 得出的結論是大概率通過 UA 識別，檢測到後封禁當前 MAC 地址一段時間。\n流量處理 統一 TTL 將這行規則加入路由器的「網絡」-「防火牆」-「自定義規則」（下同），即可統一 TTL 為 65，其中-o br-lan可以視情況更換，如eth0。\niptables -t mangle -I POSTROUTING -o br-lan -j TTL --ttl-set 65這條規則用到了 ipopt 模塊，在官方編譯的固件或其他一些極簡的固件裡默認不會安裝。這種情況下用opkg安裝即可：\nopkg update opkg install iptables-mod-ipopt保存規則並重啟防火牆，在電腦上隨便 Ping 一個網站看 TTL 是否為 65（不要在路由器上 Ping，除非你知道你在幹什麼）。\n統一時間戳 接下來先啟用 OpenWrt 自帶的 NTP 服務器，然後劫持所有局域網內的 NTP 請求到路由器，以達到我們統一時間戳的目的。\n這種方法並不完美，因為手機連接基站時會同步到別的 NTP 服務器，最好的辦法是直接去除 TCP 包的時間戳，但這種方法暫無成熟的實現，只能先採用劫持 NTP 請求的辦法。\n只需要在管理頁面中修改幾個設置就可以了。\n點擊 System -\u0026gt; System（系統） 勾選 Enable NTP client（啟用 NTP 客戶端）和 Provide NTP server（作為 NTP 服務器提供服務）。 NTP server candidates（候選 NTP 服務器）按需設置，可以使用阿里雲的 NTP 服務器：ntp.aliyun.com 點擊 Save \u0026amp; Apply 按鈕。 向防火牆添加以下規則：\niptables -t nat -N ntp_force_local iptables -t nat -I PREROUTING -p udp --dport 123 -j ntp_force_local iptables -t nat -A ntp_force_local -d 0.0.0.0/8 -j RETURN iptables -t nat -A ntp_force_local -d 127.0.0.0/8 -j RETURN iptables -t nat -A ntp_force_local -d 192.168.0.0/16 -j RETURN iptables -t nat -A ntp_force_local -s 192.168.0.0/16 -j DNAT --to-destination 192.168.1.1其中192.168.1.1需要更改成路由器的地址，視固件而定。\n若你的路由器地址不在192.168.0.0/16內，最後兩行都要跟著改，一般的家用路由器都在這個範圍內。\nWindows 下確認效果：\nw32tm /stripchart /computer:baidu.com /dataonly /samples:5如果能正常同步就證明配置成功了。\n統一 UA 網上的解決方案大部分基於代理，比如 Privoxy，甚至 Clash。還有不少是通過XMURP-UA直接在內核層面處理 UA，這幾年又有新的插件出來，比如UA2F。\n方案一：UA2F 編譯固件時自定義加入ua2f和luci-app-ua2f，R2S 可以在這裡下載編譯好的。UA2F 與 Turbo ACC 衝突，即使沒有使用 Turbo ACC 也記得要關掉「全雛形 NAT」和「軟件流量分載」這兩個功能。\n完成後啟動 UA2F 再打開ua.233996.xyz就會發現自己的 UA 已經被修改了。\n方案二：Privoxy 安裝好 Privoxy 並正確配置，然後將所有 HTTP 流量轉發給 Privoxy 代理，並在 Privoxy 中替換 UA。\n安裝 Privoxy opkg update opkg install luci-app-privoxy opkg install luci-app-privoxy-zh-cn配置 Privoxy 點擊 Services -\u0026gt; Privoxy WEB proxy。\nFiles and Directories（文件和目錄）：Action Files 刪除到只剩一個框，填入 match-all.action。Filter files 和 Trust files 均留空。 Access Control（訪問控制）：Listen addresses 填寫 0.0.0.0:8118，Permit access 填寫 192.168.0.0/16。Enable action file editor 勾選。 Miscellaneous（雜項）：Accept intercepted requests 勾選。 Logging（日誌）：全部取消勾選。 點擊 Save \u0026amp; Apply。\n配置防火牆轉發 向路由器防火牆添加以下規則：\niptables -t nat -N http_ua_drop iptables -t nat -I PREROUTING -p tcp --dport 80 -j http_ua_drop iptables -t nat -A http_ua_drop -d 0.0.0.0/8 -j RETURN iptables -t nat -A http_ua_drop -d 127.0.0.0/8 -j RETURN iptables -t nat -A http_ua_drop -d 192.168.0.0/16 -j RETURN iptables -t nat -A http_ua_drop -p tcp -j REDIRECT --to-port 8118在路由器的局域網中打開 http://config.privoxy.org/edit-actions-list?f=0，點擊 Edit 按鈕。Action 那一列中，hide-user-agent 改選為 Enable（綠色），在右側 User Agent string to send 框中填寫 Privoxy/1.0或任意 UA；其它全部選擇為 No Change （紫色）。點擊 Submit 按鈕。\n如果打不開這個頁面，說明之前某個地方配置有誤。\n確認效果 本地瀏覽器調試是看不到效果的，因為經過路由器之前 UA 會保持原樣。\n訪問 ua.chn.moe 以查看 UA 是否修改成功。\n方案三：Clash 這種方法的思路是使用 Clash 代理/阻止所有發往 80 端口的流量。同時 Clash 也直接接管所有流量，這就意味著無需處理 IPID 和時間戳。\n假設你使用的是 OpenClash，方法如下：\n打開 OpenClash 插件面板，進入 覆寫設置 -\u0026gt; 規則設置，勾選自定義規則，將以下規則插入配置：\n- DST-PORT,80,Proxy其中Proxy需要視配置文件的不同而更改，例如我的代理組叫做 HK，也可以直接使用節點名稱。\n對於沒有能力加密的同學，則使用以下規則1：\n- DST-PORT,80,REJECTUpdate 2023/10/31：經測試，即使不加入這條自定義規則，也足以防止檢測。但必須啟用 Clash，至少設置全局直連。\n防止通過 IPID 檢測 各設備的 IPID 起始值不同，並隨著包數量的上升而上升，接近一條直線，若有多個設備長時間使用後會呈現出多條上升序列。這可以用來探測是否是多個設備。23\n由於需要kmod-rkp-ipid，這一步也需要編譯固件。\n編譯好固件後向防火牆添加以下規則：\niptables -t mangle -N IPID_MOD iptables -t mangle -A FORWARD -j IPID_MOD iptables -t mangle -A OUTPUT -j IPID_MOD iptables -t mangle -A IPID_MOD -d 0.0.0.0/8 -j RETURN iptables -t mangle -A IPID_MOD -d 127.0.0.0/8 -j RETURN iptables -t mangle -A IPID_MOD -d 10.0.0.0/8 -j RETURN iptables -t mangle -A IPID_MOD -d 172.16.0.0/12 -j RETURN iptables -t mangle -A IPID_MOD -d 192.168.0.0/16 -j RETURN iptables -t mangle -A IPID_MOD -d 255.0.0.0/8 -j RETURN iptables -t mangle -A IPID_MOD -j MARK --set-xmark 0x10/0x10即可修改所有包的 IPID 為單一遞增曲線。\n老辦法 設置如下 crontab 即可在每天凌晨三點重新撥號以打斷檢測過程：\n0 3 * * * ( ifdown wan; sleep 5; ifup wan )侵入式流量屏蔽 向路由器防火牆添加以下規則：\niptables -I FORWARD -p tcp -m tcp --sport 80 -m u32 --u32 \"5\u00260xFF=0x7F\" -j DROP iptables -I FORWARD -p tcp -m tcp --sport 8000 -m u32 --u32 \"5\u00260xFF=0x7F\" -j DROP iptables -I FORWARD -p tcp -m tcp --sport 8080 -m u32 --u32 \"5\u00260xFF=0x7F\" -j DROP iptables -I FORWARD -p tcp -m tcp --sport 80 -m u32 --u32 \"5\u00260xFF=0x80\" -j DROP iptables -I FORWARD -p tcp -m tcp --sport 8000 -m u32 --u32 \"5\u00260xFF=0x80\" -j DROP iptables -I FORWARD -p tcp -m tcp --sport 8080 -m u32 --u32 \"5\u00260xFF=0x80\" -j DROP以屏蔽侵入式流量，以上規則來自 V2EX 網友。\n這些規則用到了iptables的u32模塊，大多數固件都不會默認安裝，亦需要通過opkg安裝：\nopkg update opkg install iptables-mod-u32隨後屏蔽學校的「共享提示」頁面：\niptables -I FORWARD -p tcp --sport 80 --tcp-flags ACK ACK -m string --algo bm --string \"src=\\\"http://1.1.1.\" -j DROP iptables -I FORWARD -p tcp --sport 80 --tcp-flags ACK ACK -m string --algo bm --string \"value=\\\"http://18.20.18.\" -j DROP在Openwrt防火牆的流量規則設置如下規則：\n源區域WAN，源地址1.1.1.3，目標區域設備，動作拒絕\n源區域WAN，源地址1.1.1.1，目標區域設備，動作拒絕\n這些規則來源於校友的博客（找不到來源，可能已經關閉了）\n意外封鎖處理 前面提到學校會封一段時間的 MAC，想要重新上線就需要更換 MAC 地址重新上線。為此我寫了一個 Shell 腳本：\n#!/bin/sh DATE=$(date +%Y-%m-%d-%H:%M:%S) interface=eth0 current_mac=$(ifconfig ${interface} | grep \"HWaddr\" | awk '{print$5}') new_mac=$(dd if=/dev/random bs=1 count=3 2\u003e/dev/null | hexdump -C | head -1 | cut -d' ' -f2- | awk '{ print \"34:36:3b:\"$1\":\"$2\":\"$3 }') tries=0 while [[ $tries -lt 3 ]]; do if /bin/ping -c 1 223.5.5.5 \u003e/dev/null; then echo --- exit --- exit 0 fi tries=$((tries + 1)) done echo ${DATE} block detected, replacing mac address \u003e\u003ewatchdog.log ifconfig down ${interface} sleep 1 ifconfig ${interface} hw ether ${new_mac} sleep 1 ifconfig up ${interface} echo ${DATE} old address ${current_mac} has been replaced with ${new_mac} \u003e\u003ewatchdog.log將這個腳本保存到路由器的 home 目錄下（用vim粘貼保存以下就可以了），設置如下 Crontab 每分鐘執行一次：\n* * * * * sh /root/net_watchdog.sh路由器就會自每隔一分鐘檢測是否在線，如果掉線，則隨機更換 MAC 地址並重新上線，日誌將會記錄在同目錄下的watchdog.log中。\nDNS 內網解析處理 接上路由器之後，校外資源可以正常訪問，反倒是校內資源全都無法訪問了。經排查發現是路由器下的設備無法解析出正確的 IP 地址，但路由器本身又沒有問題。\n暫時不清楚是什麼原因導致的，但解決起來很簡單，可以直接把已知的內網地址 dnsmasq，但我推薦安裝 SmartDNS 來解決。\nSmartDNS 的安裝可以參考官方教程。\n開啟 SmartDNS 並讓其接管路由器的主 DNS 設置 SmartDNS 上游為學校內網提供的 DNS，我校是10.255.255.25和10.255.255.26 設置別的上游，可以參考這篇博客 這樣設置下來，內網資源就可以正常訪問了。\n參考 https://www.mr-cn.net/2021/06/15/Share-your-network-in-CSUST/ https://catalog.chn.moe/%E6%8A%80%E6%9C%AF/OpenWrt/%E5%9C%A8%E5%8E%A6%E5%A4%A7%E5%AE%BF%E8%88%8D%E5%AE%89%E8%A3%85%E8%B7%AF%E7%94%B1%E5%99%A8/ https://catalog.chn.moe/%E6%8A%80%E6%9C%AF/OpenWrt/%E4%B8%BA%E5%95%A5%E6%88%91%E7%9A%84%E8%B7%AF%E7%94%B1%E5%99%A8%E4%BC%9A%E8%A2%AB%E6%A3%80%E6%B5%8B%E5%88%B0/ https://superuser.com/questions/451018/how-can-i-query-an-ntp-server-under-windows https://github.com/krabelize/openwrt-random-mac-changer/tree/master https://github.com/CHN-beta/rkp-ipid https://www.sunbk201.site/posts/crack-campus-network 這個配置會自動拒絕所有發往 80 端口的連接，對上網體驗影響很大。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n具體可以參考這篇論文\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n這個方法可行性比較低，沒有已知的部署案例。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-09-23T21:49:21Z","image":"/2023/09/csust-network-guide/20231011111126_hu_205eb763ec973318.webp","permalink":"/zh-hant-tw/2023/09/csust-network-guide/","title":"長沙理工大學：校園網共享指南"},{"content":"Recently, I took a 28 km bike trip.\nI usually enjoy short bike trips. While 28 km might not seem like much to some, it’s enough to showcase how bike-friendly Changsha is.\nLet’s dive into the details.\nOverall Impressions Changsha isn’t designed for bikes.\nThe city was originally intended to be car-centric. In the past, people were too poor to own cars and used bikes instead, making it appear more bike-friendly. As wealth increased and more people bought cars, problems arose. Now, the city is trying to balance its development by improving public transport and becoming more bike-friendly.\nToday, Changsha blends American-style car-centric design with Western European human-centric elements: wide roads built for cars with little space for bikes on older streets but newer roads often include dedicated bike lanes.\nInfrastructure Road quality is generally good but many are under construction due to public transport projects. These areas can be dangerous and poorly maintained with chaotic traffic.\nMost roads lack dedicated bike lanes; you’ll need to share the road with horrible traffic. Some roads have blue arrows indicating bike paths, it\u0026rsquo;s better than nothing , but still, not actual bike lanes\nIn most cases, the roads are suitable for cycling. If sharing the road feels unsafe, you can use the sidewalk.\nParking a bike here isn\u0026rsquo;t easy; theft is common so ensure your lock is strong and reliable.\nDrivers Most drivers pay attention to cyclists but always stay alert as accidents can happen due to careless drivers or parked cars blocking paths—a frequent annoyance caused either by poor road design or inconsiderate drivers.\nClimate Changsha\u0026rsquo;s climate is harsh—hot and humid summers that cause sweating or heatstroke and mild yet still cold winters unsuitable for cycling. Locals joke there are only two seasons here in Changsha: Summer and Winter. Comfortable spring and autumn weather has become rare in recent years likely due to climate change.\nConclusion Currently, Changsha isn’t very bike-friendly: the infrastructure needs improvement, some drivers aren’t considerate of cyclists, and the climate poses challenges. The city aims to improve its conditions for both bikers and pedestrians but progress has been slow.\nDespite these shortcomings, I’m glad Chinese cities are evolving positively over time—I hope our city continues this trend towards greater happiness and better living conditions.\n","date":"2023-09-19T23:13:28Z","permalink":"/zh-hant-tw/2023/09/is-changsha-bike-friendly/","title":"Is Changsha a bike friendly city?"},{"content":"江城武漢，國 gal 最高城也。\n這次去武漢，巡禮三個國產 Galgame：《三色繪戀》《戀愛綺譚》和《高考戀愛100天》。\n於是乎挑了一個早上開車一路從長沙狂奔到武漢，到取水樓那訂好的酒店住下了。\n當時三伏天還沒過去，看了下天氣，最高35℃，其實已經很熱了。但對於在長沙這種天氣極度抽象的地方熬了這麼多年的我來說，武漢的天氣反倒是可以接受的。（再次證明了長沙的氣候就是依託答辯）\n不浪費時間，隨便找了家店吃午飯就往中山公園裡懟，聖地巡禮正式開始！\n三色繪戀 應該是2021年接觸到的這部 Gal，劇情是真的胃疼，每次推一小段就會因為不忍心看後面的劇情而關掉這個遊戲，加之這遊戲在 Steam 裡叫 Tricolor Lovestory，自然的就按照字母順序排到了後面，也相應的減少了我打開它的次數。於是直到最近我才把這個遊戲給推完。\n遊戲本體非常優秀，百萬字的劇情文本，加上幾百張高質量的CG和全程配音，定價卻只要11塊，還時不時的打折。後面製作組搞事情弄出來的 Trash End 就毀了這麼好的一個 IP，實在是可惜了。\n師貳高級中學 這是主催的母校，在遊戲裡竟然是媲美華師一附中的存在，然而現實裡就是一所很普通的高中，特色就是這個很誇張但沒卵用的拱門。順帶一提，這所學校正在改建，看宣傳圖似乎是要改的面目全非了，再晚幾年可能就完全無法辨認。\n邱誠和墨小菊的上學路 現實中的航天路，由於店面已經面目全非，而且一側的店鋪已經完全拆除了，已經幾乎無法辨認。找了一圈這裡大概是比較像的地方。\n據說是文芷家原型 現實中是電業新村，門的造型和遊戲裡非常相似。\n邱誠和墨小菊所在的小區 現實中是地質家屬小區：\n順便在旁邊那家副食店買瓶水，證明我來過（\n中山公園 這裡我拍的都是視頻，為了不耽誤加載，只好用截圖代替。\n沒碰上噴泉表演真可惜了。\n利北社區 遲菓住的小區，u1s1確實比較老舊了，名字的由來應該是利濟北路。但在這麼市中心的位置，價格也真不便宜啊。順帶一提，只要從這個社區出來過一條馬路就是邱誠和墨小菊住的地方，真有夠近的。\n遊戲中完全是 1:1 還原了這個小區：\n江城市第六十八初 遲菓讀的初中，遊戲裡也是1:1的還原，甚至連旁邊的劉記腰花面都沒有落下。\n漢街上的「稻當勞」 別問了，我沒有在這裡買草莓新地。\n輕軌「循禮門」站 根據遊戲中的報站，下一站是江漢路，可以確定是二號線，但實際上武漢輕軌應該是一號線，並不經過遊戲中出現的場景，有點出戲。\n江城市風景 那張CG我找不到了，並且這個還是夜景，這是在長江一橋的江中心位置拍攝的，當然，是用無人機。\n和武漢官方的宣傳視頻不太一樣的是，很多建築的燈光是關著的，導致現在拍出來畫面沒有官方拍的時候燈光拉滿來的好看。\n戀愛綺譚 戀愛綺譚是我在暑假前才接觸到的遊戲系列，當時玩過以後，實感相見恨晚，也很高興能看見國 Gal 在鋪天蓋地的壓力和江河日下的大環境下，仍能保持自己的那一份相對崇高的追求和社會責任感。\n戀愛綺譚的場景設定其實都和現實差距很大，沒有像三色繪戀「利北社區」那種1:1還原的場景，但依舊能看出原型，巡禮是值得的。\n蘋果湖中學總校 戀愛綺譚主要場景之一，蘋果湖中學，原型是水果湖高中。這所學校就在湖北省委旁邊，所以是禁飛區，我甚至沒法飛無人機進去航拍一下。既然在湖北省委旁邊，自然少不了那些官二代、紅二代，這所學校在網上可謂是流言四起，顯得非常神秘。\n充能國安路 官方設定集裡的原型是鳴笛1988商業街，在現實裡是一條非常冷清的商業街，入駐的商戶沒有幾家，也看不到除我以外的任何一個顧客，當然也沒有遊戲裡「充能國安路(CNGal)」那樣的二次元周邊店。我想知道製作組是怎麼找到這麼小眾的商業街的。而且這條商業街特別小，附上航拍圖：\n就是那個不規則的四邊形。而且從遊戲裡的圖來看，製作組還混合了日本某個商店街（也不知道是哪一個）的樣式進行了二創，簡直是一點都不像。\n關於在遊戲第二部裡出事的奶茶店，在這個位置倒是有一家茶顏，我進去點了杯箏箏紙鳶，證明我來過，順便點亮「武漢」徽章：\n蘋果湖中學分校 設定集裡的位置在現實中是菱角湖公園，完全就不是一個東西嘛……\n這是蘇半夏（用怪異）就讀的學校，位置就在鳴笛1988的旁邊，符合蘇半夏和顧偉從分校出來就能到充能國安路的設定。\n孱陵路 現實裡是公安街，這條街道是一個典型的「老破小」街區，很髒，很亂，但地段其實特別好，生活也很方便。\n我到公安街的時候已經十點半了，在武漢跑了一天，拖著疲憊的身子從大智路地鐵站出來，走了一陣，一進到公安街，一股陰森的感覺撲面而來。輔以遊戲中的故事，代入感極強。這裡一定要晚上來，白天來，這種感覺就會盡數失去。\n個人覺得最像遊戲裡的一處是這裡：\n簡直就是遊戲裡潺陵路33號的入口，可惜旁邊沒有賣魚頭湯的店，要不然代入感還能更強。走進這種地方，我其實覺得特別親切，我小時候，也天天要經過這樣的街區，也曾住過一段時間像潺陵路33號這樣的房子。總覺得繁華的街區皆是幻境，在幻境中呆久了，便會愈發的分不清幻境與現實，而偶爾看看這種地方，卻可以讓我感到無比踏實。\n江城大橋 原型是武漢長江二橋，據製作組稱，選擇武漢長江二橋是因為一橋畫出來太平平無奇了。當時是中午，拍的時候光線實在是太差，湊合著看看吧。\n也不知道鍾齊北救起顧唯的地方是武昌江灘還是漢口江灘，但好像只有漢口江灘這邊有蘆葦叢，所以姑且算作是漢口江灘。那麼下面就是顧唯被救起的地方：\n高考戀愛100天 這遊戲一共有61個結局，我只解鎖了其中5個，這次來巡禮很大程度上只是順便。\n不過說迴游戲，這確實是個很優秀的作品，既有遊戲性劇情也很豐富，國 Gal 最大的優勢便是題材和場景對於本土玩家的「親切」感，這部就把這兩個優勢發揮得淋漓盡致。有點像是「中國式家長」劇情更豐富、CG 更多的微操版。\n唉，我高考的時候怎麼就沒有「木馨的護身符」和「1977年的回憶」這種神仙道具呢。\n武漢長江大橋 這個場景其實還挺iconic的，尤其是對面的電視塔，遊戲裡經常出現。\n華懿高級中學 原型是華中師範大學第一附屬中學，由於戒備實在森嚴，只好飛個無人機進去拍一圈走人了，屬實有點遺憾了。\n要是他們真有老宿舍那我翻圍欄都要翻進去找一本「1977的回憶」\n最後…… 在武漢的三天過得非常紮實，基本上去了所有我想要看到的地方。但無奈時間的問題，像是「雨娘傳說」的公交站，江景別墅的原型……還是有些地方沒能去成，時間緊的時候，做些取捨終究還是很無奈的。\n國 Gal 因「親切」深得我心，這種題材的親切、生活環境的親切，是非本土 Galgame 永遠無法企及的。正如前面提到，我很高興看到國 Gal 能夠在重重壓力下依然保持自己的追求，為我們帶來優秀的作品。說來也怪，在如此差的環境下，我們依然在一些方面有所建樹。人們總是去歌頌這些建樹，默認苦難的合理性，卻從來無人過問，是什麼造就瞭如此差的環境。\n希望未來能看到更多優秀作品，也希望我們能早日看到我民族真正解放之日。\n","date":"2023-08-19T18:28:26Z","image":"/2023/08/wuhan-trip/cover_hu_57906180d5388760.webp","permalink":"/zh-hant-tw/2023/08/wuhan-trip/","title":"江城武漢聖地巡禮：《三色繪戀》《戀愛綺譚》《高考戀愛100天》"},{"content":"不知從什麼時候開始，我的生活就慢慢的被推薦算法淹沒，推薦視頻、猜你喜歡……，幾乎每天，我都或多或少的被他們所影響。我曾半開玩笑：「網速越快，其傳遞的信息就越少」，甚至有些一語成讖。這並不是互聯網能傳遞的信息變少了，而是越來越快的網速、越來越準的推薦算法養廢了我們，奪走了我們從網上獲取信息的能力與主動權。\nRSS 已是信息獲取手段中的老古董了，但它的體驗真的一點都不老古董：相反，用它來獲取信息，體驗極佳——不光無廣告，還能讓那些分散在一個一個網頁上的信息自動跑到你面前，豈不美哉？我沒有經歷過那個時代，但聽聞當年的大家，人人都拿著 Google Reader（Google 打造的 RSS 閱讀器）讀他們想讀的內容，倒也真想回到那個年代體驗一番。\n可惜 Google Reader 這一產品早就關停了，曾經大多數網站都提供的 RSS 訂閱源也悉數消失，想要重新拾起 RSS，就需要一點折騰了。\nRSSHub：萬物皆可 RSS GitHub 倉庫 這是 DIYDogDIYGod 大佬發起的項目，就和它的標語一樣，萬物皆可 RSS，這個項目能通過爬取網頁內容的方式生成 RSS 信息流，從而通過 RSS 訂閱本不支持 RSS 的網站。\n由於是爬取，難免會受到目標網頁反爬取策略的影響，而有的目標網頁（比如大陸的政府網站）會屏蔽他國 IP 的訪問，亦或者屏蔽掉風險 IP。這些因素就比較考驗機房了，但只要不是被特別「照顧」的 IP，一般問題不大。出於這些原因，我在分別在洛杉磯和上海部署了 RSSHub。\nDocker 部署 RSSHub 非常簡單，首先拉取已經寫好的docker-compose.yml：\n$ mkdir rsshub \u0026\u0026 cd rsshub $ wget https://raw.githubusercontent.com/DIYgod/RSSHub/master/docker-compose.yml然後檢查有無需要修改的配置：\n$ vim docker-compose.yml我最終修改完成後，配置如下：\nversion: \"3\" services: rsshub: image: diygod/rsshub:chromium-bundled restart: always ports: - \"1200:1200\" environment: NODE_ENV: production CACHE_TYPE: redis REDIS_URL: \"redis://redis:6379/\" depends_on: - redis redis: image: redis:alpine restart: always volumes: - redis-data:/data volumes: redis-data:為什麼要新建一個 Redis 鏡像？主要是懶得配置容器互聯，而 RSSHub 用 Redis 佔不了多少資源，遂直接寫進一個docker-compose.yml裡，省去容器互聯的麻煩。\n啟動編排：\n$ docker compose up\t# 老的寫法是 docker-compose up隨後使用 Nginx 反代localhost:1200至域名，部署 SSL 證書，RSSHub 就全部搭建完成了。\n反爬嚴格網站的部分解決 前面已經提到由於 RSSHub 的工作原理是爬取，其勢必會受到不同網站反爬策略的影響。以 B 站為例，如果僅僅部署 RSSHub 而不採取任何措施，當你訂閱時，大概率會出現「521 - 風控校驗失敗」的提示。\n這時，先去查找 RSSHub 的文檔，看看相應的網站是否有 Cookie 可以被設置為容器的環境變量，對於大部分需求，只要環境變量配置正確，就可以有效緩解反爬問題。\n還是以 B 站為例，查閱 RSSHub 文檔，可以發現有一些額外的環境變量需要配置。1\n按照文檔，打開對應的網頁，按下 F12 打開開發者工具，轉到「網絡」面板，刷新網頁，就可以找到 dynamic*new 請求，複製整個 Cookie（或者 SESSDATA=xxx；字段），修改docker-compose.yml文件，將BILIBILI_COOKIE*你的B站UID: \u0026quot;SESSDATA=xxx\u0026quot;添加到environment部分，即可完成配置。\n配置好的docker-compose.yml看起來像下面這樣：\nversion: \"3\" services: rsshub: # two ways to enable puppeteer: # * comment out marked lines, then use this image instead: diygod/rsshub:chromium-bundled # * (consumes more disk space and memory) leave everything unchanged image: diygod/rsshub:chromium-bundled restart: always ports: - \"1200:1200\" environment: NODE_ENV: production CACHE_TYPE: redis REDIS_URL: \"redis://redis:6379/\" BILIBILI_COOKIE_你的B站UID: \"SESSDATA=xxx\" depends_on: - redis redis: image: redis:alpine restart: always volumes: - redis-data:/data volumes: redis-data:修改文件並保存，重啟編排：\n$ docker compose up -d --force-recreate # docker-compose up -d --force-recreate配置完成後，即可正常訂閱 B 站 Up 主投稿等相關路由。\nRSS 閱讀器推薦 RSSHub 可以解決掉大多數訂閱源的問題，接下來推薦幾個 RSS 閱讀器，解決的是最後一步如何呈現到設備上的問題。\nWindows Fluent Reader 我目前在用的 RSS 閱讀器，開源小巧，遵循 Fluent Design，如果需要 Windows 上的免費 RSS 閱讀器，那麼大概率就是它了。需要注意的是，這是開源軟件，但在應用商店裡需要付費才能下載，不想付費則可以直接在 GitHub 上下載其安裝包安裝，當然，如果喜歡，鼓勵大家支持這個項目。\nGithub倉庫 ThunderBird 這個不是 RSS 閱讀器，但也提供了 RSS 功能，比較適合打造郵件 RSS All in one。\nThunderBird 是由 Mozilla 基金會開發的一款開源郵件和新聞聚合客戶端，已經有快 20 年的歷史。\n官網 MacOS 和 iOS NetNewsWire 開源，Swift UI 原生編寫，幾乎完美的 RSS 閱讀器，說實話我很驚訝這位作者維護這個項目的時間跨度。\nNetNewsWire 是由 Brent Simmon 出於愛好和支持 RSS 發展開發的 RSS 閱讀器，遺憾的是，由於是 Swift UI 編寫，只支持 Mac OS 和 iOS。\n官網 Github倉庫 Reeder 這個就是收費 App 了，但功能做的很不錯。作為「骨灰級」應用，Reeder 一度被人稱為 iOS 與 macOS 上最好用的 RSS 閱讀器。不光設計精緻，還支持如桌面小組件等各種 Mac OS 和 iOS 上原生的功能，如果你的預算充足，可以考慮。\n官網 Fluent Reader 又是之前提到的 Fluent Reader 也提供了 Mac 版本，實測在 Mac OS 上體驗也還不錯，在 iOS 上雖然看起來是原生 UI，但實際上是 React 寫的跨平臺版本，而且還需要收費，如果想要支持這個項目，可以考慮購買。\n鏈接：\nGithub倉庫 Github倉庫（Fluent Reader Lite） Linux NewsFlash NewsFlash is a program designed to complement an already existing web-based RSS reader account.\nIt combines all the advantages of web based services like syncing across all your devices with everything you expect from a modern desktop program: Desktop notifications, fast search and filtering, tagging, handy keyboard shortcuts and having access to all your articles for as long as you like.\n這是一個很現代化的 RSS 閱讀器，一般用 flatpak 安裝，也有人為其製作了 Snap 封裝的版本，不過幾乎不怎麼更新維護。它的界面很好看，對在線服務2支持的很全，而且是原生運行，非常推薦。\nGitlab 倉庫 Flathub頁面 Fluent Reader 又雙叒是 Fluent Reader，跨平臺這麼容易嗎。\n有人給它製做了 Snap 封裝的 App，Ubuntu 可以直接去應用商店下載使用。官方倉庫裡提供了 AppImage 給其它分支使用。\n安卓 Fluent Reader 又雙叒叕是 Fluent Reader，在安卓上，Fluent Reader 依然是貼合 iOS 的 UI，用起來有點牛頭人的感覺，若不在意這一點，體驗倒還不錯。\nGithub倉庫 FeedMe 評論區網友的推薦，FeedMe 支持的服務繁多，功能齊全，界面也較為現代化，一樣支持 FreshRSS 等在線 API。\nGithub 倉庫 如果有其他好用的 RSS 閱讀器歡迎在評論區留言。\n總感覺還缺點什麼？ 理論上來說，解決了訂閱源的問題，還解決了呈現在設備上的問題，我們已經還原出 Google Reader 的體驗了，但我在實際使用中，總是覺得缺少了一些特性，體驗並不完整。\n這個特性就是「同步」。我所希望的，是我在 A 設備上閱讀，閱讀進度可以同步到 B 設備上，在 A 設備上收藏的文章，打開 B 設備，能原封不動的呈現在我眼前。\n同時，還有一個體驗上的要求：我希望我在拉取 Feed 時更加快速，不需要等待 RSSHub 抓取網頁。\n於是，一個自託管的 RSS 聚合服務就很有必要了。\n以 FreshRSS 完善體驗 FreshRSS 是一個免費，自託管的 RSS 聚合器，相似的項目還有 Tiny Tiny RSS（TTRSS），選擇 FreshRSS 是因為它提供兩種 API，和各個 RSS 客戶端配合的更好。\nGithub倉庫：https://github.com/FreshRSS/FreshRSS\n部署 部署 FreshRSS 的過程也很輕鬆。\n創建目錄：\n$ mkdir freshrss $ cd freshrss創建docker-compose.yml：\n$ vim docker-compose.yml\t# 或者任意編輯器編輯docker-compose.yml如下：\nversion: \"3\" services: freshrss: image: freshrss/freshrss:latest container_name: freshrss restart: unless-stopped ports: - \"9999:80\" # 將9999更改成需要的端口 volumes: - ./data:/var/www/FreshRSS/data - ./extensions:/var/www/FreshRSS/extensions environment: PUID: 0 PGID: 0 CRON_MIN: \"1,31\" TZ: \"Asia/Shanghai\"最後執行：\n$ docker compose up\t# 老的寫法是 docker-compose up隨後反代端口，部署 SSL 證書。初始設置時，數據庫選現有的數據庫類型，如果沒有部署數據庫，直接選 SQLite 即可。至此，FreshRSS 部署完成。\n如果之前有訂閱源，將其以 OPML 格式導出，然後導入 FreshRSS 就可以獲得幾乎無縫的體驗。\n![FreshRSS](截屏2023-07-18 15.17.39.png)\n如果有現成的 PHP 環境而不想用 Docker 部署，還可以像安裝 Wordpress 一樣安裝好 FreshRSS。\n設置 FreshRSS RSSHub 充當的是提供訂閱源的中心，而 FreshRSS 充當的是一個閱讀訂閱源的「Hub」，幫助我們集中管理訂閱源，同步各設備間的閱讀進度。現在訂閱源已經集中管理起來，同步個設備間的閱讀進度就需要 FreshRSS 提供的 API 了。\nFreshRSS 提供 GReader 和 Fever 兩種 API，具體的啟用方法如下：\n登入 FreshRSS 進入「設置」-\u0026gt;「認證」開啟「允許API 訪問」 進入「賬戶」在頁面底部設置一個 API 密鑰 編輯./freshrss/data/config.php中的base_url，改為你的域名根目錄地址，比如我的就需要改成https://rss.l3zc.com/ 轉到https://example.com/api/查看檢測是否通過 設置各設備上的客戶端 NetNewsWire 部署完成後，在手機上和電腦上支持的應用裡使用設置好的用戶名和 API 密鑰登陸，就可以享受到全程絲滑的 RSS 體驗了，下面以 NetNewsWire 為例：\n打開NetNewsWire添加賬號的選項卡，NetNewsWire貼心的集成了FreshRSS，可以很方便的添加賬號：\nNetNewsWire 要求 Greader 的 API，直接在 /api 上覆制就可以了。\nFluentReader 在設置中選擇 Google Reader API：\n然後填入相關信息：\nAPI端點直接從/api網頁上覆制 Google Reader API 的 API 端點即可 用戶名填寫安裝 FreshRSS 時設置的用戶名 密碼是前文設置的 API 秘鑰 即可設置完成。\n其他的客戶端設置大同小異，無外乎上面兩大類，可以參考上面的方法進行設置。\nRSS 訂閱什麼呢 我們已經裝好了 RSSHub，這極大的方便了我們的訂閱以及豐富了我們的訂閱源。RSSHub 的官方文檔中維護著一份詳細的支持列表，支持的項目不可謂不繁多：媒體、博客……甚至大學通知，Twitter 更新都能覆蓋。\n以訂閱「湖南省政府採購網」的「採購公告」為例，首先需要在 RSSHub 的文檔中找到「湖南省政府採購網」以獲取其訂閱的「路由」：\n查詢文檔可知我們所需要的路由是/gov/hunan/notice/:type，其中:type是一個必選參數，我們需要獲取的是「採購公告」所以:type應該是cg，最終需要的路由就是/gov/hunan/notice/cg。將這個路由附加在我們部署（反代）RSSHub 的網址後，即可得到完整的訂閱地址，例如：部署rsshub的網址是https://rsshub.app，則最終的訂閱地址為：https://rsshub.app/gov/hunan/notice/cg，將其加入 FreshRSS 的訂閱即可。\n需要注意的是，FreshRSS 似乎不支持自動轉換訂閱鏈接裡的非 ASCII 字符，如果你的訂閱鏈接裡含有這些字符，如https://rsshub.app/sspai/tag/派早報，則建議在瀏覽器內先訪問一下，再將轉換後的鏈接粘貼進 FreshRSS 以轉換鏈接中的非 ASCII 字符。\n對於原本就有 RSS 的網站，推薦使用 RSSHub Radar，這是一款瀏覽器插件，可以實現 RSS 訂閱源的自動嗅探，而不必在網站上四處尋找。推薦它是因為，它不光可以嗅探 RSS 鏈接，如果目標網站可以用 RSSHub 訂閱，這個插件可以自動匹配支持的 RSSHub 路由。\nGithub 倉庫 最後…… 經過了這一番折騰，基本體驗到了當時人人都用著 Google Reader 的樂趣。即便如此，屬於 Google Reader 的時代終究還是過去了，那個人人都可以從網上收穫純粹的知識與快樂的時代，也已然一去不復返。這些年來網速越來越快，但給我的上網體驗卻越來越差。大多數人都開始上網的時候，內容農場，推薦算法……只要有利可圖，互聯網精神，那個曾經作為互聯網基石的精神，就全被這些追逐利益的資本和官商勾結的政府拋在腦後。我甚至可以說：至少在中國，那個曾經「互聯網」的理想已死。\nRSS 的沒落只是大環境的縮影，「技術」固然需要進步，但沒有與之相匹配的「人文」，這種進步就會成為一場災難。以我們現在的狀態來看，賽博朋克真的離我們不遠——技術進步，不但不能消除不平等，反而會加劇壓迫與控制。\n即使大環境再怎麼黑暗，我們依然能看到一線生機，依然會有人去發揚幾乎被大環境拋在腦後但彌足珍貴的互聯網精神，散發光和熱，通過自己的方式捍衛互聯網的開放與自由。\n感謝所有這些開源項目的貢獻者，也向所有熱愛分享的同路人致敬。\n參考 https://sspai.com/post/63202\nhttps://docs.rsshub.app/\nhttps://typecho.l3zc.com/archives/20/\n以及這篇文章裡所有提到的鏈接。\n近期 RSSHub 經歷了一次大重構，相應地，新增的路由所需的環境變量配置可以在路由對應文檔處找到，而不需要翻閱「部分 RSS 模塊配置」這一部分。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n無論是自託管還是非自託管。\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-07-17T20:33:00Z","image":"/2023/07/rsshub-freshrss-information-flow/20231011105121_hu_fe5d2177608978ac.webp","permalink":"/zh-hant-tw/2023/07/rsshub-freshrss-information-flow/","title":"重新撿起 RSS：RSSHub + FreshRSS 建立我的信息流"},{"content":"音樂是我生活中不可缺少的一部分，每次聽自己想聽的音樂，心情都會變得無比舒暢。\n我喜歡隨機播放音樂，給自己尋找一些新鮮感。為了聽到自己「想聽」的音樂，隨機到我不喜歡的音樂時，我自然會選擇性的跳過，直達契合自己先下想聽的那首曲子。\n時間一長，我發現：有些曲子，似乎不是什麼想不想聽的問題——幾乎每次聽歌遇到這些曲子，我都會選擇跳過，很多都是第一次收藏以後就再也沒有聽過了。即使如此，我也不忍心將他們移出我的歌單，因為，那至少是我曾經「喜歡」過的曲子。思來想去，我依舊還是遇到他們就選擇性的跳過，即使這樣更加麻煩。\n這些所謂「喜歡」的音樂也影響到了推薦算法，很快，我的「每日推薦」「每週新發現」等歌單，被那些「似乎喜歡」的音樂充斥。每次聽算法推薦的歌單，都有一種在逛 CSDN 的感覺，可以算作是「屎裡刨金」吧。面對這種情況，我常常對推薦算法失望透頂，卻又不得不承認，那些「似乎喜歡」的音樂，影響了推薦算法的成果。\n是我對「喜歡」這首歌的概念定義錯了。對於那些聽了一次就不再聽的歌，我終於明白了，終究還是我「不喜歡」他們啊。給那些根本就「不喜歡」的歌按上紅心，收藏起來，越積越多，甚至越發影響自己聽那些真正「喜歡」的歌。這不是敝帚自珍，本末倒置嗎？\n是時候清理那些「似乎喜歡」的歌了。\n","date":"2023-07-12T14:03:21Z","permalink":"/zh-hant-tw/2023/07/really-a-loved-song/","title":"真的「喜歡」這首歌嗎"},{"content":"中國向有鬥士和隱士兩類散文家，其最大的區別在於鬥士把散文當利劍，隱士拿散文當雕刀。鬥士慣有特立獨行，寧為玉碎的血性，也許他的劍術並不高明，卻一定刺中要害。「特殊的時代一定會產生特殊的文體」，魯迅式與茅盾式的散文的現實性和戰鬥性，實在是他們當時所處大時代的造物。要在他們的散文裡尋覓矯情自飾的小情調，「小擺設」，則不免徒費無益。他們是把散文當「投槍」與「匕首」的，才不會把它變成高逸人士手裡的小玩意，去「專論蒼蠅之微」。正如阿英所說：「在中國的小品文活動中，為了社會巨大目標而探索的作家，在努力的探索著這條路的，除了茅盾、魯迅以外，似乎還沒有第三個人。」\n因而，正當大時代而一味的「品賞」「幽默」與「閒適」，就顯得十分不合時宜了。不是嗎？曾幾何時，「幽默」的老舍就遇到過難堪的尷尬，他怎麼會想到「幽默」竟會給他帶來「危險」！他那篇《「幽默」的危險》既是一次辯白，也是在為一己的幽默正名。這自然起因於魯迅對林語堂所辦《論語》半月刊的批評，而老舍當時常給《論語》寫稿。當國家身處內憂外患之際，林語堂倡導「幽默」、「性靈」，「以自我為中心，以閒適為格調」，自然便有了專事玩弄之嫌。眼裡從不糅沙子的魯迅，批評林語堂將幽默導向「將屠戶的兇殘，使大家化為一笑，收場大吉。」也就順理成章。可要是單從魯迅 1934 年 6 月 18 日寫給臺靜農的那封信來看，他當時對老舍的幽默是更看不上眼的。他說：「文壇，則刊物雜出，大都屬於 ‘小品’。此為林公語堂所提倡，蓋驟見宋人語錄，明人小品，所未前聞，遂以為寶，而其作品，則已遠不如前矣。如此下去，恐將與老舍半農，歸於一丘。其實，則真所謂‘是亦不可以已乎’者也。」這實在有點冤枉了老舍，因為即便當時來說，老舍與林語堂的幽默路數也畢竟是有區別的，「林語堂的文章是幽默而帶滑稽，老舍則幽默而帶嚴肅。」\n與魯迅比，郁達夫要豁達許多，他認為，「清談，閒適，與幽默，何嘗也不可以追隨時代而進步呢？」可見，在他眼裡，一個作家是否追隨時代而進步，並不在乎他的「文調」是「性靈」、「閒適」、「幽默」的，還是道文壯行、揮戈反日的。其實，魯迅也並不像有些人出於逆反心理想象的那樣，是隻會「橫眉冷對」的「鐵板」一塊。在散文寫作理念上，他還是蠻「前衛」的。他認為散文只要達到了真情實感的流露，寫作上「是大可以隨便的，有破綻也不妨。」同時，魯迅的深刻犀利卻也是旁人所望塵莫及的，他一針見血地指出，散文的幻滅在於「模樣裝得真。」換言之，在魯迅看來，散文最貴在「真」，尤忌「瞞」和「騙」的裝腔作勢。\n散文寫作又實在是多元的，遠非「鬥士」「隱士」兩類可以囊括。恰如梁實秋所說，「有一個人就有一種散文。」以魯迅、周作人雖為血緣兄弟，卻「文調」迥異，即可見事實也是如此。一個人的散文寫成什麼樣，或他會如何來寫，跟他的散文觀，其實也就是性格，是血脈相連的。所以，梁實秋強調，散文的「文調就是那個人。」「文調的美純粹是作者性格的流露。」他以為「散文是沒有一定格式的，是最自由的。」要「美在適當」。周作人則率先提出，現代散文是「記述的，是藝術性的，又稱作美文，」且「須用自己的文句與思想。」朱自清主張「意在表現自己」，崇尚寫「獨得的秘密」。\n再比如，沈從文一味要在散文裡「寫我自己的心和夢的歷史。」並特別強調，「把文學附庸於一個政治目的下，或一種道德名義下，不會有好文學。用文學說教，根本已失去了文學的意義了。」堅持文學的純藝術性，像他的同道何其芳、李廣田、蕭乾，直至他的弟子汪曾祺，均如是；章依萍則代表「海派」作家直言不諱地表示，「所謂文人的著作，在高雅之士看來，誠為不朽之大業，而在愚拙之我看來，在資本主義之下，一切的著作，無非皆是商品而已。」堅持文學的商品性。像與之歸於一派的張愛玲、蘇青等，也都明確地說，他們是為生活、為錢而寫作。在今天看來，即便是為稻糧謀，卻寫得一手好文章，已無可厚非，不太再會輕易指摘為思想格調不高或人品低下了。\n正是從這個角度也說明，誠如梁遇春所說，「自從有小品文以來，就有許多小品文的定義，當然沒有一個是完全對的。」可我還是最心儀他以 26 歲年輕生命留下的那份灑脫與率真，以及只能是天賦的靈性與悟感。他以為，散文就是「用輕鬆的文筆，隨隨便便地來談人生。」而且，比起詩來，散文「更是灑脫，更胡鬧些罷！」我頗以為然。\n其實，追蹤 20 世紀中國現代散文的腳跡，無論是早期的「語絲派」，「論語派」，讚美母愛的「冰心體」，「跑野馬」的徐志摩散文，還是被一度奉為新經典的楊朔、秦牧、劉白羽三家散文，直至海峽對岸立志要「剪掉散文的辮子」的余光中，甚或近來的「大文化散文」也好，「小女人散文」也罷，至少在一點上是一致的，即「我手寫我口」。不管何種「文調」，無論向雜文傾斜的硬邦邦抨擊時政的，還是抒情感懷到軟綿綿無病呻吟的，或觸景生情得悲歌哀怨、如泣如訴的，散文在某種程度上，是可以作為靈魂的避難所或精神的棲息地而存在的。藝術是獨立的，散文須是個性的。\n2005 年 5 月 23 日於中國現代文學館\n","date":"2023-07-11T17:16:36Z","permalink":"/zh-hant-tw/2023/07/repost-gan-wu-jing-dian/","title":"轉載：感悟經典"},{"content":"由於馬一龍最近的吐血操作，Twitter 用戶又一次大量出逃，我願稱之為「Twitter Exodus」。見此情景，隔壁的小扎坐不住了，連夜提前自家的競品的發佈日期，7月6日10點我們就能看到它了。\nMeta 家的競品名叫「Threads」，乍一看介紹就是個文字版的 Instagram，繼承所有 Ins 上的 Followers 和 Followings。「又是一個平平無奇的產品，全靠同行襯托……」——這是我當時粗看介紹給它的評價。\n可是 Threads 沒這麼簡單。\nThe new standalone app will be based on Instagram and integrate with ActivityPub, the decentralized social media protocol. That will theoretically allow users of the new app to take their accounts and followers with them to other apps that support ActivityPub, including Mastodon.\n據報導，Threads 將會在未來以接入 ActivityPub 的方式接入 Fediverse，消息一出，許多（ActivityPub）實例的站長都表達了不滿，或直接聲稱將會在自己的實例上屏蔽 Threads，或在站內發起投票以決定是否屏蔽之。\n什麼是 Fediverse？ Fediverse 即 Federation 和 Universe 的組合，中文譯名叫「聯邦宇宙」。顧名思義，「聯邦宇宙」就是由多個相對獨立的實例組合而成，這些實例的互通方式和電子郵件比較相似，實例加入或者離開這個網絡對其餘的實例以及整個網絡都沒有影響，你還是可以和這個網絡上其他所有人互通。基於這個特性，與其叫做「聯邦」，叫「邦聯」更合適。\n只要在一個聯邦宇宙的實例上註冊賬號，比如一個 Mastodon 賬號，理論上你就可以和聯邦宇宙內其它任何實例上的任何賬戶通信（包括那些非 Mastodon 實例，GNU Social, Friendica, Hubzilla, Diaspora, etc.）\n為什麼要集體抵制 Threads？ Masto zealots: We’re open, federate with us!\nInstagram: Great, we’re building a new thing to join you.\nMasto zealots: Not that kind of open!\n各實例之所以集體抵制 Threads，最主要的理由便是擔心 Threads 會「奪舍」：先是倚仗大公司的資源優勢，提供比其它實例更好的早期體驗，等到壟斷了內容創作者，再斷開與 Activity Pub 的連接。Threads 本身就有 Instagram 的用戶群打底，想要這麼做，是很容易的。\n即使上述的想象沒有發生，下面的問題，就涉及到了聯邦宇宙本身：\nAdmins who are planning on federating with Threads, what is your plan when Libs of Tik Tok sends thousands of far right users to harrass one of your users?\n——@siege@octodon.social\n@StarKiller 你好！目前，Threads與Fediverse尚未連接，長毛象中文站不會立即屏蔽Threads的域名。然而，一旦開始聯邦，如果發現Threads對用戶體驗造成了不可接受的影響（例如無法控制攻擊性言論和濫用、向外部站點投放廣告、不遵循遠程嘟文刪除請求、大幅增加服務器負載等），我們將考慮立即在實例級別隱藏或封禁Threads。\n對於Mastodon用戶數據流向Threads的擔憂，請參考以下嘟文中的第2條。 https://m.cmx.im/@strawberry/109437505\n——@strawberry@m.cmx.im\n聯邦宇宙設計的理念之一就是賦予大家平等的社交權力，為了實現這一點，在設計之初，甚至犧牲自己的體驗，刻意弱化了自己的一些功能，現在 Meta 進軍聯邦宇宙，帶來大量的名人和社交媒體影響者，與聯邦宇宙連接，Meta 完全可能執意自己的商業價值，破壞這種平等，補全聯邦宇宙缺失的體驗，仗著這種優勢給予那些「Far right users」隨意攻擊聯邦宇宙上他人的途徑。\n對於實例的管理員們，草莓縣的管理員幾乎已經闡述清楚了他們的擔憂，和一般的惡意實例一樣：向外部站點投放廣告、不遵循遠程嘟文刪除請求、大幅增加服務器負載……，Meta 畢竟是一家商業公司，如果這有利於他們利潤最大化，那麼這些情景完全可能發生。\n最後就是大家都要擔心的隱私和數據流向 Meta 的問題。在隱私方面，Meta 並不是一家聲譽很好的公司。相反，Meta 就是因為隱私問題才淪落到今天這個地步，至於我們能看到的隱私有多糟糕，這兩張圖就可以形成鮮明的對比：\n2018 年美國總統大選時，當時還叫 Facebook 的 Meta 爆出了Facebook-劍橋分析數據醜聞，其在未經用戶同意的情況下獲取數百萬Facebook用戶的個人數據，這些數據主要用於政治廣告，也就是說，左右選舉1。商業公司之所以能提供免費的服務，就是因為我們的數據所能創造的價值（比如干預總統選舉）遠超開發維護產品的成本。現在 Meta 接入聯邦宇宙，不就相當於把我們的數據（帖子，用戶名這些雖然公開但還是很有價值的數據）讓 Meta 不費吹灰之力免費拿走嗎？而 Meta 甚至不需要徵得我們的同意。\n抵制可能帶來的副作用 對人們的去留起決定性作用的，不是花裡胡哨的功能，不是大部分人不會細看的隱私政策，而是這個平臺所創造的社區，更本質的說，就是這個平臺上的人。\nI have to keep posting on twitter because that\u0026rsquo;s where my audiences are.\n為什麼馬斯克如此胡作非為卻仍能讓人們留在 Twitter 上？就是因為 Twitter 的王牌——十幾年的用戶和內容積累。Threads 同理——成千上萬的，有趣的人都在使用這個服務，因為 Meta 的問題把這些人拒之門外，對於他們來說是極為不公平的。\nThreads 的潛在好處 Threads 掀起了一股很大的熱度。這對普通用戶接觸到聯邦宇宙顯然是一大利好，想想新人大量湧入聯邦宇宙實例時的困惑，或許 Threads 真的可以 Make their life easier。\nActivity Pub 的初衷，是像電子郵件一樣，把社交媒體去中心化。電子郵件就可以作為 Threads 的參照，如果經營得法，Threads 完全可以成為 Gmail 一般的服務，而 Gmail 即使發展到現在，電子郵件這一協議既沒有消亡也沒有變成 Gmail 內部專屬的協議，而 Gmail 的出現也讓普通人更容易的接觸到電子郵件，某種意義上降低了電子郵件的使用門檻。\n總結 Threads 尚未正式上線，對於其功過不可過早的蓋棺論定。目前來看，Gmail 大概是最能窺見 Threads 未來的產品，Threads 也大概率會走上類似 Gmail 的發展路線。無論現在如何分析，都只是對 Threads 的預測，我很期待 Threads 將來會怎麼發展，那麼現在，就等它上線了。\n延伸閱讀 Not that kind of \u0026ldquo;Open\u0026rdquo;：本文的一個參考。\nIs Gmail killing independent email?：講到 Gmail 扼殺獨立電子郵件的現狀，可以一窺 Threads 的未來。\n詳見https://zh.wikipedia.org/wiki/Facebook-劍橋分析數據醜聞\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"2023-07-05T13:12:05Z","image":"https://blog-img.l3zc.com/20231216110724.webp","permalink":"/zh-hant-tw/2023/07/opinions-on-meta-thread/","title":"一些關於「Threads」的看法"},{"content":"今天在圖書館借了一本沈從文的《湘行散記》，其中的一段很有意思：\n在那旅館中住下，一面聽他詈罵傭人，一面使我就想起在北京城圈裡編《國語大辭典》的諸先生，為一句話一個字的用處，把《水滸》、《金瓶梅》、《紅樓夢》以及其他所有元明清雜劇小說翻來翻去，剪破了多少書籍！若果他們能夠來到這旅館裡，故意在天井中撒一泡尿，或裝作無心的樣子，把些瓜果皮殼髒東西從窗口隨意拋出去，或索性當著這旅館老闆面前，作點不守規矩缺少理性的行為。好，等著你就聽聽那作老闆的罵出稀奇古怪的字眼兒，你會覺得原來這裡還擱下了一本活生生的大辭典！\n連學者都不曾聽過老闆罵出的古怪字眼，肯定也沒能放在今天的漢語詞典裡，更不用說當時湘西的客棧老闆，沒有受過良好的教育，之所以能罵出這些稀奇古怪的字眼，除了當地的口口相傳，歸根結底，還是中國人從無到有，造詞和遣詞造句的智慧。\n前些天我做過一個中文詞彙量測試和一個中文識字量測試，識字量的結果可能還行，詞彙量測試的結果實在不是非常好：\n（By the way，這倆加起來可能還沒我英語詞彙量大）\n（這玩意不準啊，剛又去測了兩遍結果都是8000個詞彙量）\n之前我一直很好奇，為什麼一些文字功底深厚的作家，總能給出讓我眼前一亮的遣詞造句的手法呢？現在我算是理解了——和英語一樣，只要詞彙量和識字量達到一定程度，碰到自己需要的場景就能夠融會貫通，從而徹底的從單純的使用這門語言昇華為「Master」這門語言。\n在我的回憶裡，從幼兒園到高中，給我們用來打好漢語基礎的時間並不多，學生們總是疲於奔命，幾乎沒有什麼機會能夠啟發學生們體味漢語的魅力。或許，給予學生們足夠的時間與適當的引導，讓學生們自己熱愛上語言的魅力，讓興趣成為學生們最好的語言老師，就是語文課最理想的解決方案吧。又想到我高中的語文學習狀態，所剩下的，只有哀嘆矣。要是我回到語言最本真的地方，盡情感受這語言的魅力，提升自己的文字功底，該有多好！到頭來，我高中三年學的語文，大多是一些我從未擅長過的應試技巧，只剩下一點點可憐的語文素養提升罷了。\n我試著去寫，然這篇文章所傳達出的意思，始終和我想要表達的意思有所出入，也許這正是我對中文「Master」的不夠深吧。可惜那終究是過去，我能做的，也只能從現在開始，是時候好好的重新審視這一門語言，提升自己的詞彙量和遣詞造句的能力了。\n","date":"2023-06-29T17:16:57Z","permalink":"/zh-hant-tw/2023/06/qian-ci-zao-ju/","title":"遣詞造句"},{"content":"Clash 內核是開源的，我在搜索 Clash for Windows 時，遇到託管在 Github 上的項目，自然也會認為其是開源的，並且我還用它用了相當長的一段時間。\n雖然託管在 Github 上，但沒有開源版權申明，也沒有源代碼。這種做法十分具有誤導性，很容易讓人誤以為這是一個開源項目而放心的下載使用，直到看到空空如也的倉庫才會猛然醒悟。\n這個項目擁有超過 55k 的 Stars，不知裡面有多少是和我一樣，被託管在 Github 上這一做法誤導的呢？我想數量絕對不會小。\n為了節省成本和提高知名度，託管在 Github 上無可厚非。但對於上網代理這種敏感的工具，我會選擇多留一個心眼，這種不開源的軟件，我是不敢用了。\n","date":"2023-06-10T15:06:36Z","permalink":"/zh-hant-tw/2023/06/clash-for-windows-is-not-opensourced/","title":"Clash for Windows 不是開源軟件"},{"content":"我大概從2013年開始接觸到了 Minecraft ，算下來，今年正好是我接觸 Minecraft 的第十個年頭。\n熟悉 Docker 以後，我著手開始把我現在跑的服務容器化，從某種意義上，這非常「優雅」——可以很方便的管理各個服務，還不用擔心各種環境不兼容的問題。\n暑假將至，為了方便和朋友們聯機玩 MC，遂自行搭建一個服務器，順便進一步熟悉 Docker 和 Docker Compose。\n服務器選擇 服務器有兩個要求，一是性能要足夠強，二是距離要足夠近，目前我手頭有三臺機器，分別位於香港和洛杉磯，不是性能不夠就是距離太遠，延遲太高。所以，都無法滿足需求。\n最近恰逢618，各大雲主機廠商都有活動，遂購入一臺某大廠輕量服務器，位於上海，2C4G5M，對於一個入門 MC 服務器來說完全足夠。當然，買了這一個服務器不可能只是跑跑 MC，別的一些對帶寬要求不高的服務我肯定也會放在上面。\n那麼直接 Deploy，似乎用的還是 AMD 的新 EPYC，還行。\n安裝 Docker 相比於一鍵腳本，我個人還是偏好手動安裝 Docker。個人為了方便直接用了 Root，這不是最佳實踐，儘可能用普通用戶並在必要的時候用sudo。\n添加 PGP 密鑰:\n$ curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg向source.list添加軟件源：\n$ echo \\ \"deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \\ $(lsb_release -cs) stable\" | sudo tee /etc/apt/sources.list.d/docker.list \u003e /dev/null更新軟件包緩存並安裝 Docker：\n$ apt update $ apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin啟動 Docker:\n$ systemctl enable docker $ systemctl start docker至此 Docker 已經安裝完成，順遍裝好了 Docker Compose。\nDocker 換源 國內服務器這點非常蛋疼。\n換源還要有一個命令行的文本編輯器，於是我決定先裝個 Vim：\n$ apt install vim編輯/創建/etc/docker/daemon.json：\n$ vim /etc/docker/daemon.json編輯成如下內容:\n{ \"registry-mirrors\": [\"https://mirror.ccs.tencentyun.com\"] }https://mirror.ccs.tencentyun.com是某大廠的內網鏡像，內網拉取速度極快，還不計流量，不在內網裡的服務器無法使用，應當換成下列鏡像：\nhttps://hub-mirror.c.163.com https://ustc-edu-cn.mirror.aliyuncs.com https://mirror.baidubce.com 隨後重啟 Docker 服務即可完成換源：\n$ systemctl restart docker粗略部署 我部署服務的原則是先 Get it to work，再 Polish。\n對於 MC 這種 community driven 的遊戲來說，社區的力量是強大的，基本上什麼樣的需求都能在社區裡找到對應的解決方案。我直接採用了 itzg/docker-minecraft-server。\n不得不吐槽的是，這個項目的文檔寫得實在是沒有那麼友好，摸索了一下，總算是把這個服務基本的跑起來了。這時我的docker-compose.yml如下：\nversion: \"3\" services: mc: image: itzg/minecraft-server ports: - 25565:25565 environment: EULA: \"TRUE\" tty: true stdin_open: true restart: unless-stopped volumes: # attach a directory relative to the directory containing this compose file - ./minecraft-data:/data這樣的 Docker Compose 配置能以最新的版本把一個基礎的 Vanilla Server 跑起來，只能勉強滿足幾個人的聯機需求，肯定也沒幾個人會將這樣的配置用到生產環境。\n進一步調整 要進一步調整，要先確認調整的方向，否則就是無頭蒼蠅，誤打誤撞，沒有目標，十分痛苦。實際感受一番後，我大致整理出了此時配置的問題，有些是 Vanilla 客戶端的問題：\n版本不固定 缺少基本的性能數據 圖標和 MOTD 需要調整 沒有白名單 不能裝插件 有正版驗證(無所謂，我有正版) 有了這個方向，我就可以有目標的去調整這個 Server 的配置。接下來要做的，就是查閱這個項目的文檔，做出自己需要的修改。\n固定版本 說實話 MC 的版本更新還挺頻繁的，前一個版本尚未體驗下一個版本就會出現。我暫時先固定這服務器的 MC 版本為1.19.4，日後充分遊玩再慢慢升級。\n同時 Vanilla Server 實在是太垃圾，順便將其換成 PAPER 豈不美哉？分別設置VERSION和TYPE兩個環境變量即可。藉由 Paper 的優點，這樣也同時解決了服務器插件和性能數據的問題。\n白名單 設置ENABLE_WHITELIST和ENFORCE_WHITELIST兩個環境變量，即可強制服務器核查白名單。同時，不要忘記將自己加入白名單，由於服務器的 OP 會被自動加入白名單，只需要將自己提前設置為 OP 即可，設置OPS即可做到這一點。\n圖標和 MOTD 設置ICON和MOTD兩個環境變量即可自定義服務器的圖標和標語。\n正版驗證 設置ONLINE_MODE變量即可控制正版驗證的開關。\n需要注意的是，關閉ONLINE_MODE後，服務器會根據玩家的離線 UUID 判斷身份，離線 UUID 和在線 UUID 不同，此時添加 OP 和黑白名單都需要改用離線 UUID 進行。\n最終的 docker-compose.yml version: \"3\" services: mc: image: itzg/minecraft-server ports: - 25565:25565 environment: EULA: \"TRUE\" TYPE: \"PAPER\" VERSION: \"1.19.4\" VIEW_DISTANCE: 8 ENABLE_WHITELIST: \"TRUE\" ENFORCE_WHITELIST: \"TRUE\" OPS: \"\" ONLINE_MODE: \"TRUE\" SERVER_NAME: \"Pub of NightCity\" MOTD: \"Want to have a drink?\" ICON: \"\" OVERRIDE_SERVER_PROPERTIES: \"TRUE\" tty: true stdin_open: true restart: unless-stopped volumes: # attach a directory relative to the directory containing this compose file - ./minecraft-data:/data一些雜七雜八的事情 RCON 的連接 服務器運行後，若要在不進入遊戲的情況下管理服務器，就需要用到 RCON。方法很簡單，使用這個項目綁定的 rcon-cli 即可：\n$ docker exec -i rcon-cli注意將\u0026lt;name_of_container\u0026gt;換成自己的容器名。\n作者還推薦了一個叫做rcon-web-admin的項目，打算過一陣子嘗試。\n安裝插件 Paper 支持 Bukkit 的插件，還有自己的插件，插件數量上完全無需擔心。\n我們在配置docker-compose.yml時，已經做了 bind 操作，會在docker-compose.yml所在目錄的相對路徑下創建一個叫做minecraft-data的文件夾，並綁定到容器的data目錄，將下載好的插件.jar文件丟進./minecraft-data/plugins目錄就完成了插件的安裝。\n我選用了 World Edit，Grief Prevention 和 Dead Chest 三個插件，保證原汁原味的生存體驗。\n最後 如果你有開服經驗並且偏向手動修改server.properties，將OVERRIDE_SERVER_PROPERTIES設置為FALSE即可將server.properties的控制權交還到我們手中，這也是一種配置的手段。\nDocker 開服還是相對容易的，社區已經造好了輪子，免去了很多不必要的麻煩。稍後我會繼續 play around with the server，繼續探索這個遊戲無限的可能性。\n","date":"2023-06-09T13:52:54Z","image":"https://blog-img.l3zc.com/Moby-Minecraft.webp","permalink":"/zh-hant-tw/2023/06/build-a-mc-server-with-docker/","title":"Docker Minecraft 開服記"},{"content":"何為博客？\n廣義上的博客，便是當人們將自己原本留在心裡，寫在日記本，取自書上的東西加以整理加工，寫成一篇文章時，就自然而然的形成了博客。一開始還不叫博客，甚至還沒有公開發表，公開發表了，便是博客的雛形。\n自互聯網出現，這套過程被搬到了網上，就成了標準意義上的「Weblog」。\n再回頭看看我寫的這個標題，連我自己都忍俊不禁，為自己不假思索起的標題感到些可笑——沒有上網，怎麼能叫 BLOG 呢？十分荒唐，但也不全無道理。之所以把標題起的不假思索，大抵是因為郁達夫的行文風格令我不由自主的將其與博客聯繫起來。在我看來，郁達夫發表的這些文章，無論怎麼看，都太像是一個博客。\n以下節選自郁達夫的《記風雨茅廬》：\n自家想有一所房子的心願，已經起了好幾年了；明明知道創造欲是好，所有欲是壞的事情，但一輪到了自己的頭上，總覺得衣食住行四件大事之中的最低限度的享有，是不可以不保住的。\n……\n自搬到杭州來住後，於不意之中，承友人之情，居然弄到了一塊地，從此葬的問題總算解決了；但是住呢，佔據的還是別人家的房子。去年春季，寫了一篇短短的應景而不希望有什麼結果的文章，說自己只想有一所小小的住宅；可是發表了不久，就來了一個迴響。一位做建築事業的朋友先來說：“你若要造房子，我們可以完全效勞。”。\n……\n四面一湊，於是起造一個風雨茅廬的計劃即便成熟到了百分之八十，不知我者謂我有了錢，深知我者謂我冒了險，但是有錢也罷，冒險也罷，入秋以後，總之把這笑話勉強弄成了事實，在現在的寓所之旁，也竟丁丁篤篤地動起了工，造起了房子。\n……\n卻也塗上了朱漆，嵌上了水泥，有點像是外國鄉鎮裡的五六等貧民住宅的樣子了；自己雖則不懂陽宅的地理，但在光線不甚明亮的清早或薄暮看起來，倒也覺得郭先生的設計，並沒有弄什麼玄虛，和科學的方法，仍舊還是對的。\n看到郁達夫「從發表文章到找到“知音”」的過程，不禁覺得倍感親切，換而言之，博客的初衷，不就是如此嗎？不得不感嘆：原來我們今天在做的事情，至少一百多年以前，甚至更早，人們就已經在做了。倘若郁達夫能上網，這篇文章肯定會出現在他的博客上吧。\n","date":"2023-06-08T18:52:26Z","permalink":"/zh-hant-tw/2023/06/yudafus-blog/","title":"郁達夫的博客"},{"content":"從某一天開始我的睡眠質量忽然急轉直下，正好一直想要 Apple Watch，遂直接下單一塊來監測睡眠。\n這是我的第一塊 Apple Watch，在此之前，小米手環、卡西歐、AmazeFit以及小米手錶都在我的手腕上戴過一陣。但這塊手錶不一樣，買了它我就相當於被蘋果生態綁架，唉（bushi）。\n下單 5月11號在蘋果官網下的單，選的銀色鋁金屬錶殼，耐克雪峰白配黑錶帶，顯然不是標準配置，於是訂單被送到上海保稅區的工廠組裝。\n一天用來組裝，一天用來清關，清關後終於到了 EMS 特快專遞，而且還是航空件。「這下應該馬上到了」，果然，郵政的效率從來沒讓我失望過——南京飛到長沙用了 11 個小時，怕不是用車拖著飛機在地上走？\n總算，四天，我的快遞，經過「特快專遞」「空運」到了我的手上。\n開箱 當天是一個溫和的天氣，郵政送到校內驛站，正好我的另一個快遞也到了，於是就屁顛屁顛的跑過去取快遞。\n當了一下久違的愛撕機膜人，開箱撕膜真的有一種特殊的喜悅和魅力，讓人上癮。不管怎樣，簡單設置一下以後 Apple Watch 就這麼戴上了。\nApple Watch 的整個設置真的簡單，掏出 iPhone 掃一掃手錶上的圖案，剩下的全都交給設備完成就好。頭一次見到手錶設置的時候會把手機裡所有的 App 對應的手錶版裝上去的，難怪用了這麼久才把設置圓環跑完。Anyway that‘s good。\n在蘋果官網上買，最大的原因是為了定製這隻表的外觀。官網上看不覺得，直到線下才發現不鏽鋼和鋁金屬的質感完全不是一個量級，難怪要把不鏽鋼邊框的版本買貴這麼多，真有你的，廚子。話說回來，鋁金屬邊框也有好處，劃傷沒有不鏽鋼那麼明顯，要說質感的話，也勉強能算是別具一格吧，搭配某些錶帶可能會更好看。第一次帶這種表，鋁金屬依然是最佳選擇，只是以後有機會再買 Apple Watch，我肯定會買成 Ultra 或者不鏽鋼的版本。\n這幾天的體驗 先說結論，Apple Watch 是唯一能比小米手環還讓我滿意的可穿戴設備。我對穿戴設備的要求無非就是這些：穿起來舒服是剛需，這是讓我願意將之長期佩戴的基礎。外觀漂亮不是那麼重要，但也是一個長期佩戴的加分項。功能上最基本的是健康監測與和手機的互聯，不那麼重要的就是系統流暢度和應用的豐富程度了。\n穿戴體感 \u0026amp; 外觀 不論是智能手錶還是別的手錶，戴在手上或多或少都有一種「存在感」。我之前戴在手上的東西里，除了一個很輕的裝飾品，唯一令人滿意的是小米手環。Apple Watch 在這點上令人滿意，雖然錶盤很大，但戴在手上幾乎感覺不到什麼異樣的感覺，讓我願意長期將其戴在手上。這點上它和我之前戴過的小米手錶形成的對比非常強，明顯感覺到 Apple Watch 在這點上下了功夫。\n外觀上就不贅述了，畢竟是 Apple Watch，帶出去至少不會丟人，小米手環我尚覺得不錯，Apple Watch 更無需多言。\n健康監測 \u0026amp; 與手機互聯 健康監測是 Apple Watch 最大的賣點，也算是我買它最大的理由事實上 Apple Watch 默認狀態下監測的數據就是全天候無感的，非常舒服。但我也不得不吐槽其中一個數據——睡眠檢測，不光睡前要先按睡眠專注模式不說，起來掐掉鬧鐘繼續睡還直接不記錄鬧鐘之後的數據，這樣的體驗真就是依託答辯。\n與手機互聯上 Apple Watch 是所有設備裡做的最好的，沒有之一。所有數據全程無感同步，應用會自動喚起相應的手錶版，可以和手機互相解鎖，進入手機的連接範圍內就從來沒有連接失敗過……，這些都是隻有 Apple Watch 上才有的體驗。\n系統流暢度 \u0026amp; 應用的豐富程度 畢竟是 S8 芯片，系統是真的流暢，怎麼用都感覺不到卡頓，況且蘋果的優化也很讓人放心，也無需多言(iPhone 除外，要吐槽這咖喱味拉滿的 iOS 我能專門寫一篇文章）。\n關於應用的豐富程度，我其實不怎麼用第三方應用，蘋果就是這樣，你在它自己的生態裡，保證你用得很舒服，一旦你想跳出他那個生態，那可能就會「生不如死」。本著這個理解，我只是裝了少量的第三方應用，本身也用不著這些應用，何必要去裝上呢？而我裝的第三方應用裡，甚至大部分都是手機裡應用的 Watch 版。\n","date":"2023-05-18T15:45:33Z","permalink":"/zh-hant-tw/2023/05/apple-watch-series-8-hands-on/","title":"Apple Watch Series8 初體驗"},{"content":"一年前，網上多了一個給自己寫字的地方。過了一年，也算是寫了不少字了。回想起從當時還是初中生的我懵懵懂懂的開設自己的第一個博客，到現在我真實的在博客上記錄內容的第一年，不由得感嘆，時間過得真快。\n為什麼開站？ 旅程總有個開始的理由，但也不排除說走就走。\n這得問問當初在 Github Pages 上笨手笨腳嘗試部署我的第一個靜態博客的我：沒有什麼理由，Because that\u0026rsquo;s cool.\n於是我學了點 HTML、JS 和 CSS 。然後花了點時間搞清楚 Hexo 的主題到底是怎麼運作的，跌跌撞撞拿著一個 Hexo 主題修改，竟然也勉強改出了我想要的版本。當初不知 Webpack 為何物的我竟然對著一堆 .min.css 和 .min.js 一個一個改了半天，回想起來只能一笑了之。\n做一件事情不需要理由，只要沒有顯著的反對理由，那就放手去做吧。\n這一年發生的一些事 2022.04：\n開站，在 Github Pages 上發出一聲 Hello World。\n19歲\n~~（跟別人）~~參加一些競賽：挑戰杯，創青春，創新創業\n2022.06：\n六級出分，雖然成績不太漂亮，但大一下就能過也算不錯了\n參加了個形式主義的院學代會\n2022.07：\n拿到 Azure 學生服務器，博客框架換成 Wordpress\n早上五點起床搬到新校區，累死我了\n2022.08：\n拿到駕照\n開學，看新兵蛋子軍訓咯\n2022.09：\n接手學長祖傳的一個團隊收拾爛攤子\n院學生會里當了個副部長\n2022.10：\n給新兵蛋子新同學們辦開學典禮\n核酸、核酸，天天核酸\n校運會被抓壯丁\n2022.11：\n弄了臺新電腦，原來的 1715 暫時可以休息了\n11.24，逝者安息，不要沉默，不要麻木\n2022.12:\n為了防止出現更大規模的抗議，政府把我們請回家了\n陽了一次\n2022.01:\n長途旅行，徒步虎跳峽，玩麗江……\n過年部門微信群裡沙雕紅包接力\n2022.02：\n買了個新的顯示器和手柄，這下電競寢室了\n統計數據 我一共更換了三次統計平臺，所以沒有連續的統計數據，只能湊合著看看了\n由於Google Analytics很容易被屏蔽，所以只能大致的估計一下數據，先借由 Umami一個月的訪問量，再大致估算一下自己的訪問量，大概能得出過去一年，自己大概收穫了 8000 個左右的訪客，以及大約 10000 的 PV。\n對於一個剛開設一年，沒有備案且沒有被百度收錄的網站，這已經算是不錯了。\n這一年，我一共寫了 27 篇文章，新增評論 18 條，平均下來，每個月寫了 2.25 篇文章。\n我經歷的轉變 開站早期，我為了博客的 SEO 和規避敏感話題，發表的全都是些半吊子的技術博客。而現在看來，真是有些委屈了自己。\n關於自我審查，我寫過一篇文章，從此之後，我不再自我審查，這下，這個博客終於發揮了它原本的用意——不是為寫而寫，而是有感而發，若是連自己有感而發的衝動都要被自我審查磨滅，那就更別提寫別的了。\n私以為，語言的意義，在於用最精煉的話，傳遞最準確的信息。寫文章是一場修行，寫得詳略得當，條理清晰，語言儒雅，是這場修行的終點。從前我寫博客一定要寫出字數的執念，在寫了很多的囉嗦話以後，終於也放下了。\n……\n其他一些話 這一年我的博客從 Hexo 換到 Wordpress，最近又想換到 Hugo 了，但苦於已經運行了這麼久，SEO 業已做了一年，再換一套博客系統實在是太過於折騰，也就 Stick with Wordpress 了。\n博客託管的地方也嘗試換了很多，香港 Azure，Cloudflare，Racknerd，BandWagon。兜兜轉轉一圈，踩了不少坑，又回到了香港 Azure，果然平平淡淡才是真嗎。\n我很後悔我沒有在一開始嘗試更多的技術棧，這也是我今年要做的事情。為了改出好看的主題和需要的功能我去學了怎麼寫 PHP，為了部署 Umami 我去學了怎麼用 Docker Compose……搭建博客本就是一個學習的過程，學的越多，寫的越多；寫的越多，學的越多。\n最後 回顧這一年，總有一種“我怎麼才做了這麼點事”的感覺。\n我真的把太多的時間耗費在了公事上，於自己提升之事卻做的太少。我已經對於學生會這個東西越發失去興趣。剛剛進入大學一心想服務同學、提升自己的激情也在一次次毫無意義的形式主義活動下被磨滅，回想起來，也許當時的我真的太天真了……即使我很想在學生會有所作為，這個大學處處充斥的形式主義、官僚主義卻會把每一個激情四射的人變得憂鬱而只想混吃等死的行屍走肉，用現在的話來說，叫“躺平”了。\n窮則獨善其身，達則兼濟天下。以我現在所處的境地，我真的應該好好的考慮獨善其身的問題。\n","date":"2023-05-02T22:28:18Z","permalink":"/zh-hant-tw/2023/05/1st-anniversary/","title":"開站一週年"},{"content":"Stable Diffusion 是去年就出來的東西了，我沒有去早點玩這個東西是因為當時我的電腦算力真的不夠，我直接用 Mid Journey 的 Discord 群組湊合體驗了一下，換了新電腦自然要玩玩這個東西。\n部署 我直接部署stable-diffusion-web-ui，畢竟這已經是一個成熟的方案了。\nClone 倉庫\ngit clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git修改webui-user.bat：\n@echo off set PYTHON= set GIT= set VENV_DIR= set COMMANDLINE_ARGS= --xformers --medvram call webui.bat我用的 RTX 3060 Laptop 有6G顯存，所以選用--medvram參數。\n執行用戶，注意這套腳本要使用普通用戶（非管理員）執行。\ncd stable-diffusion-webui webui-user.bat這套東西只在 Python 3.10.6 上測試過，當時用 Python 3.11 時安裝過程出現了報錯，如果現在用的是 Python 3.11 記得換成 Python 3.10.6，修改環境變量，然後重啟電腦。\nDiffusionWrapper has 859.52M params 正常情況下，這套腳本會自動下載所需要的依賴。記得我當時在部署的時候是半夜，掛著終端代理，這個腳本跑了半天。第二天起來，依然卡在昨天晚上的地方，也就是DiffusionWrapper has 859.52M params。\n上課回來，在網上一搜索，才發現遇到這個問題的人還真不少，Github 上也有人在stable-diffusion-webui的官方庫裡提了 issue，看起來是hugging-face的file-download.py出現了bug，而非stable-diffusion-webui本身的問題。這是解決方案：Github上的解決方案。\n定位到\u0026lt;INSTALL_FOLDER\u0026gt;\\stable-diffusion-webui\\venv\\Lib\\site-packages\\huggingface_hub\\file_download.py的 1262 行，將其修改為：\nblob_path = os.path.join(storage_folder, \"blobs\", etag[3:])重新運行webui-user.bat，這次 webui 順利啟動了。\nstable-diffusion-webui跑在本地默認的端口號是7860，訪問http://localhost:7860就可以看到這套 Web UI 了。\n找模型 部署工作至此已告一段落，但stable-diffusion-webui部署下來自帶的模型生成的圖片並不符合我的需求和口味，我相信大部分人也不會只用這個默認的模型，那麼隨後的一件事就是找模型。\n去哪找？ 起初我也不知道去哪找，於是就傻乎乎的 Google 了一下：stable diffusion anime model。別說，還真奏效了。搜出來的結果裡立刻就出現了Hugging face和Civit-AI。Civit-AI還能直觀的看到每個模型的預覽圖。\n除此之外，Reddit 等論壇上，像我一樣的個人博客上，都可以看到網友們的模型推薦，用這種方式找模型也很不錯。\nProblem solved.\n找到的模型 就這麼去了 Civit-AI 的首頁，第一眼就被counterfeit模型吸引了。\n除此之外，Anything也是非常流行的模型，也被我收入囊中。\n可以自己訓練模型嗎？ 先說結論：理論上來說，可以。但我這個 3060 Laptop……還是算了吧。\nStable diffusion 有幾種主要的訓練方法，Textual Inversion, Hyper Network, Dream booth, Lora。即使是配置要求最低的 Lora，也要求至少 8G 的顯存，而 3060 Laptop 只有 6G 顯存。既然如此，就不折磨自己了，還是直接用訓練好的現成模型吧，感謝社區。\n開始用 一開始我在 CivitAI 上下載下來Counterfeit-V2.5模型，CivitAI 上只有一個 4.1G 的CounterfeitV25_25.safetensors文件。我將其下載下來丟進了\u0026lt;INSTALL DIR\u0026gt;\\stable-diffusion-webui\\models\\Stable-diffusion文件夾，刷新一下Web UI的模型列表就看到了這個模型，於是我就很順利的加載了這個模型開始用了。\n這……不對啊 先來看看這個時候的生成效果：\n這……不對啊。怎麼感覺我被這個模型的樣圖給騙了？\n來看看作者生成的樣圖：\n我們用的真的是同一個模型嗎？可以看到我和作者生成了一張大體十分相似的圖片，那是我用和作者相同的 Prompt 和種子生成的，作者生成的圖片，不論是畫面細節，還是色彩，都和我一開始用這個模型的時候生成的幾乎完全不是一個東西，難道我是下錯模型了？\n找問題 我在論壇裡翻找遇到相同問題的帖子，發現其實遇到同樣問題的人還真不少，大多數人都抱怨生成的圖片細節不夠，色彩不夠鮮豔。根據我的經驗，肯定是少裝了些什麼東西。\nEasyNegative EasyNegative 可以被看做一個 Super Prompt，用於改善模型生成圖片的質量。\n谷歌 EasyNegative 第一個出來的就是為counterfeit-v2.5模型設計，於是我便下載下來使用了。鏈接附上：gsdf EasyNegative\nThis is a Negative Embedding trained with Counterfeit. Please use it in the \u0026ldquo;\\stable-diffusion-webui\\embeddings\u0026rdquo; folder. It can be used with other models, but the effectiveness is not certain.\n這套 EasyNegative 同樣適用於 AbyssOrangeMix2，anything等模型，我願稱之為必備。\n到了這一步，我總算是知道為什麼所有人的 Prompt 裡總要有個EasyNegative了，原來是個 Super Prompt。\n裝好 Easy Negative，生成的圖片就正常多了。\n但總感覺色彩還是不好看啊……是不是還缺了什麼？\nVAE 我在 Hugging Face 上看了一下，這裡模型作者提供了遠遠不止一個的文件。\nVAE 的全程是 Variational Autoencoder。旨在幫助用戶更好的渲染圖像，其中也包括了色彩的部分。而不知出於什麼原因，作者只在 Hugging Face 上提供了他的 VAE。\n裝好 VAE，再次生成圖像，這下的圖像終於完全正常了。\n這幾天生成的圖片 這是我挑選的一些圖片\n陰間的圖片 其實上面最後一張圖的手指已經是有生成問題的，而生成的圖片裡還有更陰間的圖片。\n玩玩插件 這套 WebUI 還有插件可玩，這幾天又心血來潮玩玩比較出名的插件。\n至於怎麼安裝插件，都是在這套 Web UI 的 Extensions 裡。一是從官方倉庫里拉取插件列表，二是自己找到插件的倉庫鏈接拉庫下載即可。\n我們來玩玩插件。\ncontrolnet controlnet 可以通過草圖控制畫中人物的姿勢，理論上可以解決上面生成的人物陰間的問題。\n","date":"2023-04-12T12:48:34Z","permalink":"/zh-hant-tw/2023/04/play-around-with-stable-diffusion/","title":"玩了幾天 Stable Diffusion"},{"content":" 我有出門散步的習慣，每當累了，我就出門到處轉悠。\n說到散步，這也算是一種冥想吧，慢慢走在路上，不需要考慮任何事情，感受時光流逝，四季更迭，感受這個世界真實存在的東西。\n這三年來，我身邊曾習以為常的很多東西，大多是防疫相關的各個東西都慢慢消失。一開始是自然的，再到後來，就是被強行抹去了。為了防疫，這套圍欄存在了三年。三年來，我們對不能從這裡出去習以為常，當最近一次散步經過，我卻發現，這些圍欄已經化為時代的眼淚——被拆除了。\n我自高中以來就擠時間在學校散步，到了大學，這種校園內的漫步就成了常態。\n在學校裡待的時間長了，總有出校門的衝動，新校區遠離市中心，自然不如老校區周圍繁華，但也有在市中心見不到的東西，顯得更加的真實。\n這個核酸檢測點，自我搬到新校區來就一直存在。它在新校區旁邊不遠的一個繁華的商業廣場邊上，只要我們要去那個商業廣場，就必然要經過這裡。現在這個核酸點早已不再做核酸，這個過去我們司空見慣的條幅，竟也成為了這不堪回首之時代的僅存的記憶。\n陰天適合騎車，從新校區出來沿著車少的路一路騎行，鐵欄後的廠房，路邊停滿的卡車，新鮮的紅土地，從小到大熟視無睹的蘇聯式住屋——離市中心這麼遠，自然就是工業區了。看到這番景象，想起我小時候住的地方，登時感到懷念不已。這些學習蘇聯建起的建築，見證了中國的工業化。\n再往前走到了一條大路上，車並不算多，這也算是我專挑車少的路走的回報。一直往前騎，在一個小區後拐彎，就能碰到一條長長的斷頭路——在六車道的公路上，沒有一臺車的干擾，可以在路中間自由馳騁。路邊零星能看到為公交預留的停靠港，只是站臺並沒有建好。或許是當時經濟發展勢頭好，城市做了自己的擴張規劃以後興建了這條路吧。只可惜，現在想要城市發展到用上這條路，恐怕要比計劃的晚上10年了。\n路邊上有一個小村，沒有被周邊的寬闊馬路分割成幾個部分，還保持了相當不錯的森林覆蓋率。村口農家樂院裡有一顆樹，長勢很好，以樹幹的粗壯程度來看，至少也有兩百歲了吧。這麼看來，這顆樹逃過了大大小小的戰火和政治運動，還躲過了旁邊的公路和兩條高鐵的建設。要是城市真的發展到這裡而砍掉這棵樹，也得比計劃的晚上十年吧。而十年過去以後又會是一副什麼樣的光景，這棵樹能否活下去一事，突然就變得充滿希望了。這麼看來，這棵樹竟也有不少福氣。\n星期二的下午是學校的公休，用於給教師做“統戰”，是工作日難得的休息時間。這難得的休息時間，領導卻還開會搞形式主義，我當然嗤之以鼻。\n從這種會議上逃走，類似於曠課做自己喜歡的事。平日裡整日的在學校裡忙得頭昏腦漲，即使放假也捨不得抽上半天時間出去玩，哪有這麼好的機會能讓我心安理得的出去玩？就像從喧囂的凡塵裡逃走——若是不逃出學校，恐怕我就得被迫去參加這次會議了吧。\n一路乘地鐵“出逃”，原本心情的喜悅被難受取代——人太多了，多到我喘不過氣來，經過侯家塘，我實在支撐不住出站，終於看到了與此前不同的景象，相對較老的摩天大樓，六七十年的老社區……我終於沒有被禁錮在那個牢籠裡。\n從侯家塘站一路走到白沙古井，再走到天心閣——長沙幾乎沒有百年社區，為了抵抗日寇的侵襲，文夕大火焚燬了這裡的一切。無厘頭的走著，但我並不覺得空虛，甚至一路走到了黃興路步行街，方才打道回府。\n之所以如此鍾愛散步，是為了尋回“自我”。在經歷了軍事化的中學教育，好不容易來到大學，卻沒有發現期待中知識的殿堂。疫情之後，大學把自己圍了起來，昔日校園裡隨處可見的社會人士全無蹤影。這不是一種保護，而是一種囚禁。現在的大學，像中學一樣，通過圍牆輕而易舉的扼殺了大學本應有的無限的可能性，扼殺了“希望”。之所以如此喜愛散步，之所以會有逃出校園的慾望，就是想要在散步中，尋找無限的可能性，尋找“希望”，讓自己知道“原來，除了按部就班的上課、開會，還有無限的可能性，無限的希望等著我去探索，去發現。”\n大學教育中學化，中學教育軍事化，我幾乎不能再找到比這更適合的形容現在教育的句子。每一次散步回來，我都感到欣慰和一種發自內心的平靜，讓我能更有力，更積極的去應對各種困難，即使深處這江河日下的社會，在中學化的大學校園裡，我已經感受到了自己的存在和對自己的掌控。在這日漸乾涸的土地上，我仍能堅守最後一片綠洲。\n久旱的甘霖，何時才能降臨？\n","date":"2023-03-30T15:47:59Z","image":"https://blog-img.l3zc.com/20231011110255.webp","permalink":"/zh-hant-tw/2023/03/disappearing-public-memories/","title":"散步小記"},{"content":" 《廣西大叔一招把酸果變香甜 一年賺百萬》\n《廣西夫婦做片狀腐竹 一天收入七八百》\n《山東大哥全年供應鮮嫩韭菜 年銷售額3個億！》\n\u0026hellip;\n這些是央視新聞最近的標題，明顯可以看出來央視是在針對最近嚴重的失業問題以及“孔乙己文學”做宣傳。\n關於這則買土豆的新聞，它的真實性是存疑的，1天賺9000？你真的賣過土豆嗎？我本想看看網友們有才的評論，打開評論區卻發現評論早已被精選，並不意外。\n且不論這則新聞的真實性，忽然如此高強度的輸出這些所謂的“勵志”新聞，明顯就是政府面臨如此嚴重的失業問題不作為而借官媒開脫的產物：你們失業都是你們自己不努力，關我屁事？\n當時我看到這些新聞的標題，總覺得似曾相識，我初中時做過一些歷史題目，其中有兩個給我留下的印象特別深刻：第一個題目引用了上面這張人民日報在 1958 年 8 月 13 日的頭版頭條；第二個題目則是引用了這個時期的新聞，單憑印象的話，大概是“廣西農民成功將蘋果樹與小麥嫁接”之類，並令我們反思為什麼會出現這種新聞。當初不覺得有什麼，才幾年過去，現在想起來，這種題目竟是無比的開放、大膽，不經感慨道：這種題目是否還能出現在今天學生們的試卷上呢？\n關於為什麼這兩個時期的新聞如此相似，主要便是如下幾點：\n都是有目的的政治宣傳 都非常浮誇而不切實際 所謂有目的的政治宣傳，前者是為了轉移政府製造了失業問題而解決失業問題不力的矛盾，後者則是營造“革命形勢一片大好”的氛圍；所謂非常浮誇而不切實際，前者相比後者倒是有了一些進步，聽起來至少比 1958 年的新聞真實多了。當然，這也至少證明公眾的總體認知水平相比六十多年前還是提升了。但這依然不影響他們是同一個東西的事實。\n“在社會主義制度無比優越！只要努力，早稻就能畝產三萬六千九百多斤！不能畝產三萬六千九百多斤？那是因為你反革命！”；“社會主義制度無比優越！只要努力，每個人都能年入過億！不能年入過億？那是因為你反革命！”。社會主義制度怎麼會出問題呢？出了問題那也是你的問題。取得了一些成就？那是因為社會主義制度無比優越！跟你有什麼關係？\n為什麼一則 2023 年的新聞，和 1958 年的新聞竟然如此相似？\n若不容忍不同的意見存在，那麼這個唯一存在的意見必然錯誤。而這個錯誤若持續得不到修正，造成的後果將是災難性的。大躍進的後果我已無需多言，而今天，我們不論是宣傳機器的作為、輿論環境的高壓，還是其折射出的社會本質，都越來越接近於 1958 年的狀態。今天的中國，不論是人口數量還是經濟體量，與 1958 年的中國相比都高出好幾個量級，若是對現狀持續視而不見，一旦導火索被引燃，造成的後果與 1958 年相比絕對有增無減。\n兜兜轉轉六十多年，本以為是新時代，殊不知新時代的外衣下，還是那個荒唐的敗絮。\n","date":"2023-03-25T20:59:31Z","permalink":"/zh-hant-tw/2023/03/new-great-leap-forward/","title":"早稻畝產三萬六千九百多斤"},{"content":"這一陣子，我將我的博客服務器遷移到了美國，然後採用了 Cloudflare 作為我的全球（除了中國）CDN。\n我的博客原本架設在香港微軟雲上，而且服務器是我以學生身份免費領取的，可最近，這臺服務器的表現越來越不盡如人意。香港地理位置非常好，網絡也發達，理論上把博客架設在這裡，可以給中國大陸的訪客非常良好的體驗，事實上，在我的博客開設初期，中國大陸的訪客體驗確實很好。\n之所以說體驗良好，主要是因為這三個方面：性能夠用，大陸直連，免費。\n所謂性能夠用，但僅僅是勉強夠用的水平。微軟雲針對學生免費的 B1S 實例，1C1G，硬盤 IO 經過實測只有幾十mb/s，不說是金剛盤，也可以算是石頭盤了。就這個性能，跑個 Wordpress 都費勁，我將博客緩存後方才勉強應付了架設初期的訪問量。\n所謂大陸直連，其實這僅適用於電信。在我剛拿到這個服務器的時候，實測 Traceroute 全程 59.xx 開頭的 IP，妥妥的 CN2 線路。至於其他兩個運營商就沒那麼好了，全都走東京 NTT 線路。\n這麼看下來，免費反而是最貨真價實的優點了。微軟雲免費的學生額度有 100 刀一年，據官網介紹，這 100 刀用完，並且你還是學生，那麼第二年可以再次申請。相當於是免費承包了學生時代的服務器。\n當時剛拿到服務器的時候，微軟雲的這三個優點讓我沒有不選擇它的理由，但隨著我的博客運行半年多，這臺服務器的問題就慢慢開始突出了。\n首先就是讓人非常難受的性能問題：如果說1C1G還能勉強說得過去的話，那麼這個石頭盤就真的太難受了。隨著我的博客訪問量逐漸增加，也就自然而然的引來了各路 Bot 的騷擾。這臺服務器的綜合性能甚至弱到了，只要有人用 1 秒一次的頻率爆破我的後臺，我的網站就會接近癱瘓。即使不癱瘓，TTFB 也會比正常情況下多1秒以上。\n性能問題甚至已經影響到了我的 SEO ：我已經多次收到郵件，提示我網頁的打開速度太慢，需要優化，與此同時，我博客上來自谷歌的流量也顯著降低，大概是因為搜索權重因為打開速度降低了不少。\n即使性能如此糟糕，在相當長的一段時間裡，我也還是通過緩存等辦法勉強維持了網頁體驗的整體質量。但微軟雲隨後進行了一波令人吐血的操作：換線路。原本電信直連的香港直接併入了東京 NTT（剛去看了一下竟然變成繞新加坡了？），Traceroute 一下全都變成了 AS4134，CN2 直接變成 163。真有你的，微軟雲。這下，Azure 的網絡優勢也幾乎盡數失去。\n就算不好用，但是它免費啊，要什麼自行車？\n免費真的那麼好嗎？微軟也不是慈善機構，能在香港這種熱門的地方提供免費的服務器屬實已經非常良心了。我還能要求什麼呢？**我還能要求什麼呢？**通過前面的換線路事件，我大概也見識到了，對於免費的產品，我們真的無法要求什麼，甚至連最基本的要求都不行。不光如此，只要微軟政策一換，我就立馬無法繼續白嫖。\n在我的博客上線半年多以後，我發現，我已經沒有理由再選擇白嫖微軟雲學生機了。\n那麼，物色一個新的機器，成為了必要的選擇：\n起初我想尋找一個香港 CN2 直連的 VPS，但看了看價格，還是算了吧。最經典的搬瓦工，香港 CN2 要 899 刀一年，這顯然不是我這個小破站能承受得起的。即使是更便宜的美國 CN2，僅僅 1C1G 的配置，也需要 49刀一年。換算成人民幣需要 350 元一年。\n更要命的是，CN2 網絡因為承載量小，防禦能力幾乎沒有，這就意味著我的博客要是遭到 DDOS 攻擊，幾乎完全無法防禦。要是硬是想要防禦，就得上 Cloudflare 這一類 CDN，但這樣，CN2 線路的優點就不復存在。\n實現快速似乎需要投入太多成本。這時我開始問自己，我真的需要很快的速度嗎？我的訪客，大部分都有掛代理的能力，即使是搜索引擎流量也大部分來自 Google。這樣一來，Cloudflare 帶來的直連速度的劣勢得到了很大的緩解，而且，我還可以藉助這一點過濾一些低質量的訪客。\n犧牲大陸直連的速度，加速掛代理訪問的速度，卻又不完全被大陸封鎖，同時不需要帶著狗牌自我審查，這不正是我想要的嗎？\n","date":"2023-03-18T19:23:55Z","permalink":"/zh-hant-tw/2023/03/why-i-moved-to-cloudflare/","title":"我為什麼遷移到了Cloudflare"},{"content":"前些天看到了阮一峰老師的舊文章，不由得感嘆江河日下。\n當時阮老師的評論尤為犀利，再看看今天的阮老師，博客變成了《科技愛好者週刊》的發佈地，再也不見這些犀利的評論。我並不覺得科技愛好者週刊有什麼問題，相反，我個人也是阮老師博客的訂閱者，我也很喜歡阮老師的博客。只是，阮老師從寫真正的博客變成專注《科技愛好者週刊》，幾乎意味著其不再發布令人眼前一亮的、富有創造力的個人觀點與感想，而只是按照一個模板，半機械性的堆砌內容。\n從這個意義上來說，阮老師的博客已死。\n回頭一想，我自己進行自我審查也已經有了相當長的一段時間，小到上網評論，大到高考作文，只要涉及敏感問題，我的第一反應是避而不談，如果不得不談，我也會盡力炮製一個“安全的”觀點，替代我的真實觀點。這種做法在我讀高中時最為常用，我將其理解為“明哲保身”。\n可怕的是，在經歷了多年的自我審查後，我為時間如此長的自我審查付出了沉重的代價：我似乎失去了對社會事實評論的勇氣，甚至能力——高中時的我很少在寫作文時發表自己獨到的見解，因為那些見解涉及敏感問題；微博上，我從不為任何時事發聲，因為我擔心這會為我帶來不必要的麻煩；即使在不受審查的平臺上，我也需要在發表自己的觀點時鼓足勇氣，因為我擔心被大陸的警察“開盒”。\n久而久之，我的高中作文變成了死板的套式，再也不見任何亮點。無論在何處，我不再拋出獨到的見解。\n這不是因為我不想，而是時間足夠長的自我審查後，我對於這些事情評論的能力已經喪失。即使我已經放棄自我審查，短時間內我依然無法寫出一針見血的評論。這種“失能”甚至如癌細胞一般，不受控制地擴散到了我更多的領域，這些領域涉及的方面非常廣，從學習到生活，幾乎無孔不入。\n審查是一件非常可怕的事情。\n有的人認為，審查只是確保社會穩定，防止“有害”內容產生的必要手段。而真相是，當人們進行了足夠多的自我審查，人們就失去了沒有被審查時的創造力和勇氣。\n當戴了一生鐐銬的人忽然被釋放，他看似自由的步伐也不會超過昔日鐐銬的束縛。\n別再自我審查。\n","date":"2023-03-11T20:47:50Z","permalink":"/zh-hant-tw/2023/03/no-longer-prosper/","title":"別再自我審查"},{"content":"眾所周知，Azure 的服務器在部署的時候只會分配一個動態的 IPv4 地址，在其上架設的網站自然也不會支持 IPv6。為什麼花這麼大的勁折騰網站的 IPv6 支持？這是一種必然趨勢，當然，也是為自己的網站 Future Ready。\n為服務器申請一個公網 IPv6 地址 於是我們首先要為服務器申請到一個公網 IPv6。\n微軟對 IPv6 的重視程度似乎沒有那麼高，在不久前，為服務器添加 IPv6 還需要動用 Powershell 部署 Load Balancer 實現，具體有多複雜可以看看這篇文檔，屬實是非常勸退。\n好在現在微軟已經為 Azure 引入了原生 IPv6 支持，但部署起來依然相對繁瑣，而且相當的不友好，之前甚至連文檔都沒有，不過現在終於把文檔給補上了。\n添加 IPv6 地址空間和子網 根據文檔，首先為現有的虛擬網絡分配一個子網空間：\n登錄到 Azure 門戶。 在門戶頂部的搜索框中，輸入「虛擬網絡」。 在搜索結果中，選擇「虛擬網絡」。 在「虛擬網絡」中，選擇你自己的虛擬網絡。 在「設置」中選擇「地址空間」。 選中「添加其他地址範圍」框。 輸入「2404:f800:8000:122::/63」。 選擇「保存」。 在「設置」中選擇「子網」。 在「子網」中，從列表中選擇子網名稱。 在子網配置中，選擇「添加 IPv6 地址空間」框。 在「IPv6 地址空間」中，輸入「2404:f800:8000:122::/64」。 選擇「保存」。 申請一個公共 IPv6 地址 在搜索欄裡搜索「公共 IP 地址」，然後按以下配置新建一個 IP：\n設置 值 IP 版本 選擇「IPv6」。 SKU 選擇「標準」。 IPv6 IP 地址配置 名稱 隨意 空閒超時(分鐘) 保留默認值「4」 訂閱 選擇你自己的訂閱 資源組 選擇你的資源組。 在本示例中，資源組的名稱為 myResourceGroup 位置 選擇你服務器所在的位置，例如我的 East Asia 可用性區域 選擇「區域冗餘」 將 IPv6 添加到機器上 打開機器的管理面板，停止服務器。轉到網絡選項卡，在「網絡接口」邊上打開你的網絡接口。\n然後，在網絡接口的設置裡選擇「IP配置」選項卡，選擇添加一個 IP 配置。並在彈出的選項裡填入以下內容：\n設置 值 名稱 隨意 IP 版本 IPv6 專用 IP 地址設置 分配 保留默認值「動態」 公共 IP 地址 選擇「關聯」 公共 IP 地址 選擇你新建好的 IPv6地址 完成後確定保存就可以啟動服務器了，這時你的服務器已經擁有並可以使用 IPv6 地址。\n修改 Nginx 配置 如果這時使用純 IPv6 網絡環境訪問部署在這臺服務器上的網站，發現還是無法訪問，就需要修改 Nginx 配置。\n將以下兩行插入到 Nginx 配置的 Server 塊中實現監聽 IPv6 的功能。\nlisten [::]:80; listen [::]:443 ssl http2;插入正確的Nginx配置文件看起來應該類似這樣：\nserver { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name wordpress.l3zc.com www.l3zc.com l3zc.com; index index.php index.html index.htm default.php default.htm default.html; root /www/wwwroot/wordpress.l3zc.com; if ($server_port !~ 443){ rewrite ^(/.*)$ https://$host$1 permanent; } ssl_stapling on; ssl_stapling_verify on; #省略以下部分 ...... ...... }修改網頁內容 此時託管在這臺服務器上的網站已經可以通過 IPv6 訪問了，但此時使用純 IPv6 打開這個網站很有可能會得到一個不完整的頁面。這是因為你的網站上還有外掛在 CDN 上的資源：例如圖片和一些前端文件，而 CDN 不支持 IPv6 訪問。這時就要根據具體情況替換網頁內容上的外掛資源。\n我這裡的實際情況是：\nCDN 前端資源庫支持 IPv6 訪問，無需作任何修改。 大部分圖片託管在騰訊雲對象存儲並外掛在網頁上，經測試這項服務默認並不支持 IPv6。 其它資源均通過服務器本身加載。 搜索得知騰訊雲對象存儲有一個雙棧域名，使用這個域名即可達到目的。於是就開始了批量替換：登進 WP 後臺，每個文章打開代碼編輯器，把圖片的鏈接批量替換，更新文章。一氣呵成。再次打開文章測試，所有的資源都正常加載。\n更簡單直接的方法？ 如果你的網站在大陸已經備案，那麼添加 IPv6 支持的最簡單辦法就是全站 CDN，上述內容全都不用考慮。\n不過這種辦法還需要想到其它的問題，例如，怎麼設置緩存刷新週期，不過這就不是這篇文章考慮的問題了（才不是因為我沒有備案用不了大陸的 CDN）。\n","date":"2023-02-02T14:40:19Z","permalink":"/zh-hant-tw/2023/02/enable-ipv6/","title":"為Azure服務器上運行的網站啟用IPv6支持"},{"content":"這是我 2023 年第一次旅行，準確的說，是這三年鬧劇過去以後的第一次真正意義上的旅行。\n這次旅行從長沙出發，最遠到達麗江，來回實際行駛的里程超過 4600 公里。什麼概念呢？作為對比，從哈爾濱到海口的總里程是3800公里。\n規劃 這麼長的行程，自然要仔細規劃。\n關於國內的地圖不好用這件事我幾乎無力吐槽。2010 年時，我曾踏上一次長途旅程——從海南到三亞，當時我們使用還在大陸運作的谷歌地圖規劃路線。而今天使用百度地圖規劃路線，規劃的體驗卻和十幾年前的谷歌地圖相差甚遠。谷歌地圖因為失去在大陸採集數據的資質停止更新，甚至想用都用不了。無奈只能使用勉強用手機規劃一條路線。\n一開始我對這條路線應該怎麼走並無頭緒。於是我請出了 ChatGPT 為我獻上旅行計劃一則：\nChatGPT 還真就給我制定了一個看起來像模像樣的旅行計劃：\n看起來是不是非常靠譜？要真靠譜我早就把這一部分一筆帶過了。\n第二天直接從鳳凰開車開到大理？然後在雲南和各市之間反覆橫跳？我嚴重懷疑 ChatGPT 對中國地理的瞭解程度。不管怎樣，這份旅行規劃過於離譜，肯定是不能用的。不過，其中列出的景點倒是算有參考價值。\n用 ChatGPT 規劃行程的計劃泡湯，無奈只好自己慢慢摸索。本次旅行的主要目標是去雲南度假，避開長沙的寒冷。所以，趕在下一輪寒潮之前到達雲南是很有必要的。駕車從長沙到昆明有兩種大體方案：大體上貼著滬昆高速，以及先走一段杭瑞高速。由於杭瑞高速正好經過鳳凰，一個不錯的歇腳點，並且後面的行程更好安排，選擇這條線路作為大體上的行程顯得更加合適。\n於是根據這條路線，我大致規劃出了這次到達雲南之前的行程。\n出發前 2022 年的夏天，我頂著酷暑拿到了駕照。\n考完駕照以後一直在開車，但開過的路況卻僅限於市內路況。無可奈何於學業和這三年來疫情防控的鬧劇，我們一直在忍受。\n當時還處在感染大潮轟轟烈烈的時期，各種新聞與小道消息與社交媒體，無一不在反映一件事：那就是很多人都染病了，多到能夠讓街上的人甚至比所謂的“放開”之前都少上不少。人們都在家裡養病，誰有心情出去旅遊？\n不過那時我和我的家人都已慢慢從感染中恢復過來，我們感到的已經不再是肉體上的疲倦，更多疲倦來自精神上。趁著這一輪感染潮消退之前，也就是三年以來最大的一波旅遊潮到來之前，我們應當儘快將計劃付諸實踐。\n後來的事實證明，這是一個正確的選擇。\n買點東西隨後出發 出發前的物資補給很簡單：\n3桶泡麵 3盒自熱米飯 一箱礦泉水 6瓶紅牛 其他一些零散的零食 以及最後的把油加滿，直接走人。\n出發 鳳凰古城 這是我第一次開上高速，當然，實習期內只能在經過實習期的老司機陪同下上高速，好在高速上並不是很堵。第一次上高速很容易累，於是乎在開了一個小時的時候進服務區換人了，在換人以後邊聊天邊開的時候。高速上忽然堵車，還好雷達起了作用踩了一腳急剎。在吃完午飯簡餐後一口氣到達鳳凰古城，很累，住在一家還不錯的店子裡，只可惜這家店位置不是很好，離景區有15分鐘路程，只能在晚上去吃晚飯以後順便看看夜景。儘管之前來過一次，夜景沒有讓我失望，雖然鳳凰的店在3年時間裡倒閉了不少，但很多不以盈利為目的，底子紮實的小店還是保留了下來。文藝氣息很濃，很多有趣的店藏在深深的角落，文靜，安寧。我很後悔，我沒能抓住機會，去其中之一喝幾杯杯咖啡或酒，坐在一個角落裡慢慢休息，慢慢去感受這座古城。\n吃飯的時候喝了點，晚上在古城裡散步，繁華的 Tourist Attraction 旁，喧鬧的古城商業，安靜的小巷裡，時不時可以發現店鋪轉讓的公告。上一次來鳳凰古城是在2015年，當時正值勞動節，城內人山人海，一眼所及的店鋪無不生意紅火。現在同是旅遊高峰期，人流卻不到2015年時的一半。\n鳳凰古城在2015年前後經歷了兩次較大的挫折：第一次是2013年時臭名昭著的古城收費事件，在2016年結束。第二次便是這一次的三年疫情了。\n兩次事件都對鳳凰古城的客流量造成了毀滅性的打擊，其中以2013年古城收費事件為甚，這次人禍造成的客流驟減甚至直接導致鳳凰古城內爆發示威遊行。這是當時的一篇報導：\n當時的報導還真是正常且真實得多，不過這都是另一個話題了。\n好在現在生活正在慢慢恢復正常，鳳凰的客流量也得以恢復的機會。總讓我想起一句來自 Cytus 2 背景圖的一句話：\nKeep moving on.\n即使天塌下來，生活也還要繼續。生活無論如何都要恢復正常，人們努力的將塌下來的天支撐起來，在第二天早上，大家起床，喝到了早晨的第一杯咖啡。\n鎮遠古城 從鳳凰出發，不久便進入了貴州銅仁，轉眼間所有的車牌都變成了“貴C”開頭，這對我們來說還有些不習慣。雖然自我們從長沙出發以來海拔一直在緩慢上升，但因幅度不大，我們並沒有明顯感受到。不過，自進入貴州以來，由於北風被山脈擋住，天氣逐漸放晴，這才讓我們意識到，我們已經穿越了省界。\n鳳凰到銅仁的路程比較順暢，到了中午飯點時，我們趕到了銅仁。\n這是銅仁解放路上的一個步行街，只要在中國生活過，都知道一個城市的解放路是這個城市最繁華的地帶，然而導航依然無視堵車的風險，將我們帶到了這裡，正值中午，我們也決定在此歇腳吃飯。\n銅仁的車牌以“貴C”開頭，其在貴州省內的地位與桂林於廣西、湘潭於湖南的地位類似，在城市建設方面，銅仁自然不會差。銅仁原名“銅人”，相傳元朝時有漁人在銅巖處潛入江底，得銅人三尊。《大明一統名勝志·貴州名勝志》卷四銅仁府：“元置銅人大小江等處蠻夷軍民長官司。蓋境西南有大江，西北有小江，當其合流之處，崖高數十仞，挺然立於中流，相傳有漁者沒其底，見三足如鼎，得銅範儒、道、釋三像，故以銅人名崖。及置長官司，始易‘人’為‘仁’。” 張澍《續黔書》卷三：“元始置銅人大小江等處，其曰銅仁者，則明洪武初改之之誤也。”\n銅仁有相對悠久的歷史，順理成章成為了一座旅遊城市。其周邊的梵淨山，思南石林都是值得一看的景點。奈何梵淨山乃避暑勝地，而這次來的時間是冬天，並非一個好的參觀時間點，遂放棄參觀。\n如果你想在銅仁解放路上找到一傢俱有當地特色的餐館，可能會有些失望。和許多城市一樣，解放路上大多是商業店鋪，老字號飯店由於承擔不起高昂的房租，已陸續搬至租金更便宜的地方。這條路上唯一醒目的飯店居然是麥當勞，無奈之下，我只好進去買了點東西填肚子。\n在銅仁短暫停留後我們再次出發了，然而，這一次的行程可就沒有那麼順利了。在我看來，從銅仁到鎮遠，才算真正的進入貴州。這一段路十分顛簸，像是原本想要提質改造成寬闊的公路，但因資金鍊斷裂而停工，最終被過路的大車壓得坑坑窪窪。在這段路上，我們的平均車速不超過每小時10公里，其難走的程度可想而知。\n只要最終看到的風景足夠好，再難走的路都不虛此行。然而，鎮遠並沒有給我驚喜。我可以明顯感覺到這裡原來只是一個普通到不能再普通的小鎮，將蘇聯式的房子加上馬頭牆，刷上白漆，貼上“青磚”，就包裝成了一個古鎮。鎮上的人文氣息少之又少，完全不能給人一種沉浸感，沒有大城市的繁華，卻依然非常浮躁和喧囂。這不禁讓我想要以這一句話評論這個古鎮：取了大城市糟粕，卻未能學到大城市的精華。\n唯一值得看的，是環繞在這個“古鎮”周圍的山水。\n鎮遠畢竟地處偏遠的貴州，其景色、文化底蘊、旅遊氛圍完全不能與湖南鳳凰相比，奇怪的是，鎮遠古城竟然被評為5A景區，而鳳凰古城僅僅被評為 4A 景區，難道是因為鳳凰古城的收費事件？\n鎮遠縣位於貴州東部，屬黔東南苗族侗族自治州。從地圖上看，東鄰的湖南湘西中部有一凸出部分，恰像一個楔子，插入貴州東部凹處。鎮遠縣就處在這個凸凹結合部上。不知哪朝哪代哪位先生稱鎮遠為湘黔門戶，這一點上，與湖南鳳凰無二。據史書記載，鎮遠古稱“豎眼大田溪洞”，屬“鬼方”。從夏到商，世居著荊、梁二州的西南，泛稱“荊蠻”。追本溯源，古代的鎮遠，地處歷史上“五溪蠻”和“百越人”聚居的結合部。宋紹定元年，公元1226年，賜名鎮遠州，“鎮遠”這一名稱從此沿用至今。鎮遠有被譽為有“長江三峽之雄偉，桂林山水之秀麗”的國家風景名勝區舞陽河三峽景區，也有可同四川九寨溝媲美而被古人驚歎為“或不得遊則有為恨者矣”的鐵溪風景區,有廣為歷代名人盛讚的鎮遠二十奇景，還有野趣神韻堪與湖北神農架相比的高過河幽地。除此，鎮遠還有眾多千奇面怪、千姿百態的溶洞兀峰、奇石奇景薈萃。\n看到這一段話，我自然的聯想到我的出生地永州。永州擁有豐富的文化底蘊，柳宗元被貶永州時，永州的美景待他不薄，“千山鳥飛絕，萬徑人蹤滅。孤舟蓑笠翁，獨釣寒江雪。”。歐陽修遊覽零陵時，亦曾寫下“畫圖曾識零陵郡，今日方知畫不如。”的吟詠。不僅如此，永州的自然美景也毫不遜色，九嶷山乃屬國家森林公園，而其中的炎帝陵更是極富競爭力的景點，加之永州毗鄰桂林，有世界級的頂級旅遊目的地為伴，發展旅遊業不說不費吹灰之力，也絕非難事。\n小城永州自有小城的格調，泛舟瀟湘，每天下午在河邊悠閒釣魚的人不計其數。富有文藝氣息的小店散落在此，藏在永州的各個小巷。這是一個生活節奏緩慢的慵懶城市，活脫脫一個逃避凡塵的絕佳地點。\n奈何，永州並未能抓住這些絕好的發展機遇，錯過多次發展旅遊的風口，在毫無區位優勢的前提下，發展的重心竟然落在工業上，淪為一個不倫不類的城市。\n鎮遠與永州相比，並不是什麼好地方，既沒有永州古時零陵郡的建制，也沒有永州湖廣要道的區位。甚至不久前還僅僅只是一個普普通通的小縣城，在相對短的時間內卻成為5A級景區。相比之下，永州的旅遊體驗比鎮遠有過之而無不及。\n這趟旅途讓我充分的體會到一點：衝著5A景點去旅行，還不如抽籤決定去哪個景點，旅遊體驗決不比5A景點差。\n貴陽 一大早離開鎮遠古城後我們趕往貴陽。銅仁到鎮遠的爛路令人印象深刻，在走國道還是高速的問題上算是讓我們堅定的選擇了全程後者。\n於是我們很順利來到了貴陽。\n作為省城，貴陽自有光鮮亮麗的一面。但也免不了“千城一面”的單調。這是我在貴陽黔靈山頂的景觀亭拍下的貴陽城景，其實，在嶽麓山上鳥瞰長沙，你也會看到大同小異的景色：光汙染的摩天大樓，大道平整寬闊，小道穿城而過。無非如此。\n從酒店到黔靈山的路上遇到幾個施工地點。這也是在別的城市能夠看到的：不統一的城市規劃導致每三五年，城市道路挖了又填，填了又挖。不光阻塞交通，切斷人行道，還有噪聲和煙塵汙染。總讓我感覺回到了前幾年長沙地鐵還在興建時，我家周邊的環境。\n貴陽在網上給我留下的另一個深刻印象是花果園，號稱是全亞洲最大的住宅區。於是，即使在貴陽只能停留一天，即使開車一上午累的只想趴在酒店休息，我還是在從黔靈山返回酒店後不久搭公交車前往了花果園。\n花果園亞洲最大住宅區的名號名不虛傳，可以說簡直就是黑壓壓一片。\n摩天大樓實際上是反人類的，它並不宜居，同時會造成非常多的額外問題。然而在貴州花果園，這樣黑壓壓的摩天大樓數以百計。堪稱世界上最大的“人造災難”。\n以色列 Isaac Meir 教授曾經寫過一篇文章，系統地總結摩天大樓的各種缺點，簡單的總結下來有如下幾點：\n能耗巨大，摩天大樓是天然的溫室，加之內部人員與器件所散發的熱量，致使其必須依賴大型空調散熱 成本太高，建造摩天大樓所需要的成本比一般高樓多得多。 安全問題，如果發生緊急情況，電梯無法使用，高層的人員如何撤離到地面？ 社會問題，摩天大樓會對基礎設施造成巨大的挑戰，下樓的麻煩也減少了人們出門的頻次。 既然明知摩天大樓有如此多的缺點，為什麼人們還是熱衷於摩天大樓？為什麼一棟棟摩天大樓總能得到足夠多的資源拔地而起？顯然不是因為中國和沙特阿拉伯一樣錢多到沒處花。\n不只是在貴陽，而是全國各地，尤其是近幾年經濟不景氣，爛尾樓從來是不缺的。上面圖中出現的花果園雙子塔，雖然看上去光鮮亮麗，實際上已經淪為一個爛尾花瓶。\n2015年封頂的建築，下面的商業層卻是完全的廢棄狀態，充斥居無定所的遊民，場面一度讓我認為我在賽博朋克的爛尾樓下。而旁邊供開發商高層享樂的花果園白宮，則是外表上就恢弘大氣，內部據透露亦極盡奢華。\n倒是大樓的另一邊，開著一家類似酒店的場所，讓我還能找到這棟大樓的一點實際用途。\n遠看一棟大樓，近看敗絮其中。\n政府支持求政績，開發商們飽私囊。\n銀行放貸有恃無恐，來日崩盤有人來救。\n那麼究竟是誰來救？只有政府的鉅額稅收。\n建設摩天大樓需要耗費的大量資源，一切都因為腐敗而被腐蝕成一個空殼。只有那些開發商們賺足了錢，政府也因此獲得了政績，銀行也收穫了利息。只有我們，要為這一切荒謬的投入買單，卻享受不到實際的好處。\n黃果樹瀑布 從花果園回來以後，一夜無話。\n第四天是趕路的一天，這一天的趕路還算順利。由於冷空氣加速南下，我們決定趕在冷空氣之前加速前往下一站。這樣一來，這一天就需要直接從貴陽趕到昆明。\n貴州大部分是山區，旅遊資源實際上非常豐富，自然風景有前面提到的梵淨山，黃果樹瀑布等，人文資源一樣也不缺，西江千戶苗寨等地在來貴州之前我就已經耳熟能詳。如果只是在貴陽住一晚上，相當於直接略過了貴州的旅遊資源，即使時間很趕，我們還是決定去黃果樹瀑布看看。\n一大早從酒店出發，邊開車邊啃麵包，一路無事到達了黃果樹瀑布景區。碰巧趕上為了恢復旅遊，貴州全境景區門票免票。花了三個小時在黃果樹景區遊玩。\n從景區出來時碰到了一位景區工作人員，他給我介紹了黃果樹景區極盛時的狀況：黃果樹景區本身就有完善的接待設施，接待能力很強。旅遊高峰期時，一天的接待量可達到六萬遊客。此時，景區內觀光巴士車來車往，棧道上人山人海，水洩不通。黃果樹景區內著名的景點水簾洞，甚至需要排隊1小時才可遊覽。我在參觀時，發現去往水簾洞的路上，出現了一個標示牌，上書“因最大安全承載量問題，水簾洞景區需要排隊進入，預計需等待一小時”。而今天的黃果樹景區，遊客稀少，進入水簾洞完全無需排隊。據稱，即使免門票，目前的遊客接待量也只有每日三千。\n從黃果樹景區出來時會經過一段有意設計的路線，引導你經過景區的紀念品商店區。這個商店區非常龐大，從其使用的痕跡依稀可見往日的繁榮，如今到處都是關門歇業、門面轉讓的告示，只有寥寥數家商戶苦苦支撐，盼望政策放寬後的人潮，只可惜，折騰了這麼久，大家口袋裡真的還有錢來消費嗎？\n之後便是與寒潮賽跑快馬加鞭趕往雲南。貴州與雲南交界的山區本身就對寒潮起到了很好的阻隔作用，又因為焚風效應，實際上幾乎完全抵消了寒潮的影響。\n所謂雲南有所謂“彩雲之南”的稱呼，進入雲南，真的就如換了一片天。天空很藍，而且是以周計算的，連續的藍。\n雲南的日照時間很長，可以算作是“中國的陽光地帶”，從長沙到昆明，感知相當強烈。在長沙生活的人盼著出太陽的時候，昆明人大抵在盼著下雨。\n下午五點，我們還在路上，太陽依然很高，實際上我們不光在和寒潮賽跑，也在和太陽賽跑。\n我們幾乎全程在向西開，跨越的緯度幾乎足以製造一個小時的時差。地球是傾斜轉動，北半球正值冬季，越往南走，白晝就越長。昆明的下午5點，幾乎是長沙的下午三點。\n撫仙湖 撫仙湖是雲南第三大湖，和省會昆明只有一山之隔，水質非常清澈，是昆明人的度假勝地。\n《地理·中國》曾拍過一期節目講解撫仙湖，鏈接附上：https://tv.cctv.com/2015/05/30/VIDE1432970526664662.shtml\n撫仙湖周圍不乏開設小吃攤的本地人，藉由撫仙湖連續的好天氣，以及周圍寧靜的氛圍，小吃和音樂總能讓我忘卻很多生活中的瑣事。若是要我給這種氛圍一個評價，我將回答：還會再來的。\n這是拿不拿在當天發佈的新歌，氛圍真的是可以影響心情的魔法，而心情是能讓歌變得無限好聽的魔法。\n虎跳峽 虎跳峽是世界上最深最大的峽谷之一。\n網上能找到的關於虎跳峽的評價裡，很大一部分人自述來的動機是因為國家地理的安利，然而我在網上搜了一圈，並沒有找到國家地理相關的文章，也許是某期節目吧。\n虎跳峽的高路徒步線路是世界級的徒步線路——強度不大，風景很好。\n這條徒步路線相當成熟，幾乎是每逢岔路，必有路牌。路牌通常是客棧老闆所設，其上也是他們客棧的名字，簡單來說，就是廣告。當好幾個客棧，乃至十幾，幾十個客棧在同一個地方打廣告時，這些廣告竟然也像是被施了魔法，變得有趣了起來。\n虎跳峽中途有一客棧，名曰 Halfway。疫情之前諸多國際友人來到這裡，欣賞其觀景平臺的“日照金山”，久而久之，這裡就變成了世界著名的觀景平臺。而因其位置非常好，在這裡蹲廁可以看到雄偉的虎跳峽絕壁山巒，於是大家都給它一個笑稱，曰“天下第一廁”。\n在湖南生活了這麼久，幾乎不知道乾冷是什麼感覺。每逢湖南降溫，其必然是又溼又冷，氣溫還沒降到零度，溼冷所帶來的“魔法攻擊”就能讓人趕到寒冷無比。直到這次徒步，路已結冰，一看天氣，才察覺溫度已到零下，我方才體會到乾冷的感覺——原來，乾冷是隻需要穿點衣服就能擋住的。\n麗江 Fun fact：虎跳峽在香格里拉，不是麗江！\n麗江是全國旅遊發展很早的城市，畢竟是江澤民時代就已開始發展。\n麗江本身的城市建設，我是覺得沒什麼問題的。本身沒有高樓大廈，規劃也還算整齊，活脫脫一個宜居的城市。而麗江古城，商業化氣息就非常嚴重了，甚至有肯德基和麥當勞。\n此地氣候非常好，我們在此遊玩的時間裡，天氣非常適宜：在高原上，天空都矮了下來，蔚藍無暇。空氣適宜，因為汙染被高山阻擋——作為一個旅遊城市，麗江幾乎沒有什麼高汙染產業了。\n麗江古城內有一些自古城成為景點就一直開下來的老店，味道和環境都屬於上乘。不知怎麼的，高原的食材就是比平原上產量少，質量卻比平原上的視頻高不少。在麗江古城，沐浴在陽光下，享用高原醇美的食材。抑或在夜晚到來，在古城熙熙攘攘的氛圍裡慢慢用餐，都是不錯的選擇。\n古城總是有一種魅力，看見古城的繁華，總能讓人忘卻一切現代社會的糟粕，令人回到過去，享受當年美好的繁華。\n在這裡，你會發現，時間並非總是線性發展。\n城內之精華是木府，顧名思義，即木家府邸。木府是當年木氏土司修建的府邸，崇禎十二年（1639年），徐霞客遊至麗江時，曾在其遊記中描述木氏土司府“宮室之麗，擬於王者”，足見其規模壯大。\n木府的規模壯大，得益於當年中原王室的支持。處處都是“敕造”，足可見到木氏土司和中原王室的關係良好。\n土司的地位約等於藩王，皇帝坐的是龍椅，藩王就坐一把“虎椅”\n1996 年，木府在主要來自世界銀行的貸款下被修復。能夠在當時的經濟水平下修復成如此水平，已經非常不容易。\n登上高處，可以欣賞到幾乎半個麗江古城。\n在麗江古城，能明顯感覺到來自國外的客流正在慢慢恢復，起碼，你能在街上看到前來參觀遊覽的外國人了，雖然肯定不如三年前的水平，但至少正在慢慢恢復。\n聽本地人說，麗江古城相當於麗江的市中心，是夜生活的好地方。我特別留意了這一點：夜晚來到麗江古城，只見夜店、酒吧到處開張，十分損害古城的氛圍。雖說酒樓瓦肆和迪廳夜店本質上並無區別，但我相信來到這裡的外地人，都是受夠了大城市的喧囂，想來感受古色古香的氛圍的吧。可惜，晚上經過迪廳密集的古城街區時，人們便會感受到這種格格不入，大失所望。\n大理 雲南曾經有過一段政權叫做“大理國”，在兩宋時期存在。疆域落在今天，遍及中國、老撾、緬甸、越南，當然，大部分在中國。大理即是大理國的首都。\n（圖片來自維基百科）\n首都的建制自然豪華，而我們到達大理時，過年的人流已經將大理擠得水洩不通，在大理歇腳的計劃只好作罷。\n古城周圍停車總是非常緊張，就拿我們在大理短暫停留的時間來說，吃了箇中飯，花了大概半個小時，卻被迫在每小時10元的停車場停車。這個價格，已經比肩鬧市中心的緊俏停車場了。也許是我們趕到大理時已經接近新年吧。\n大理三塔，佛教建築也。就在214國道旁邊，還是非常著名的景點。這裡在大理國時期擴展為890間屋子、11400尊佛像、三閣、七樓、九殿及百廈，被稱為“佛都”。大理國22代國王中，就先後有9位到崇聖寺出家為僧。\n你大概也在網上聽過“雖不信佛，但敬佛”的人，我大概也算其中之一吧。此次參觀，也算讓我更加敬佛了。\n回程 在昆明過年 趕到昆明的那一天正好大年三十，於是我們順理成章的在昆明過年了。\n省城的接待能力普遍不會很差，昆明也不例外，加上非常多的人在春節時實際上會離開省城回到自己的家鄉過年，省城的接待壓力反而會有所減少。於是我們便可以一個相對便宜的價格住下來。\n前面提到過昆明是全國全年日照時數最多的城市之一，現在看來，名不虛傳。我們在此過年，很大一部分原因是這裡的氣候——夏無酷暑、冬無嚴寒、氣候宜人，具有典型的溫帶氣候特點。現在，這個春城的名號，是我們留在這裡的最大理由。\n昆明是中國的戰略大後方，抗日時期，即使日寇再兇猛，也未能攻下昆明城。當時，中國最好的大學——北大，清華，南開，在此共組國立西南聯合大學，昆明一城，就薈萃了全國最精華的教育資源，如果昆明有意識，也一定會受寵若驚吧。\n大年初一在官渡古鎮，人潮湧動，完全覺察不到是大年初一——幾乎所有的店鋪都照常營業，人們也享受這裡的生活。這裡剛好在舉行什麼“美食文化交流節”，看到老長沙臭豆腐的攤位前人滿為患，我甚至有些想笑：這東西真有這麼好吃嗎。\n百色 花了兩天時間到百色，中間曾經去過一個叫做普者黑的破地方。我的評價是，吸引的來人，但留不住人。反倒是百色，打破了我對其之前的印象。\n從昆明一路向西下高原，就會到達廣西，到了廣西，第一站便是百色。\n進入百色，市容整齊，氣候宜人，倘若是拋棄那些熱門的“養生”城市，百色倒是一個非常不錯的住家的地方。畢竟靠近海洋，緯度也低，氣候終年不會太冷，溼度也是無需擔心的。\n翻看百色建制的歷史，就會發現百色的建制幾乎是一路綠燈——從直隸廳到縣，從縣到市，不斷升級。百色是革命老區，除開城市自然發展的因素，這大概也是革命老區的專屬待遇吧。\n在黎平待上最後一晚 黎平是我們此行的最後一個駐留的地方，為什麼要在這裡再停一個晚上？其實沒有什麼特殊的原因，若是打開地圖，規劃百色到長沙的路線，你就會發現黎平剛好就在這兩個地點的中點。黎平地處湘、貴、桂的交界，看上去也像一個很好的中轉站。\n至於風景，我們無暇觀看。儘管黎平有各種侗族大寨等，我等也只能在酒店附近轉轉。於是我們看到的人文景觀便只有翹街了。\n黔東南人有一特色菜名曰牛癟，具體就是將牛宰殺後，把牛胃及小腸裡未完全消化的內容物拿出來，擠出其中的液體，加入牛膽汁及佐料放入鍋內文火慢熬，煮沸後將液體表面的泡沫過濾後食用。至少，我這個外地人是覺得難以接受的。\n近期香港流行起“兩送飯”，黎平人其實也有自己類似的兩送飯——炒好的牛癟以食品袋裝好直接帶回家，就是一道現成的菜，價格和同樣份量的食材差不多，還不用洗碗，何樂而不為？我體驗了下，其實味道很不錯，只是不論是燒菜店面的衛生環境，還是什麼措施都不採取，直接用普通的塑料食品袋盛裝這一做法，實在是讓人擔心，第二天自己會不會拉肚子呢（苦笑）。\n滬昆高速上的大堵車 第二天早上出發，本以為只要6個小時我們就能趕到長沙，沒成想，這成了我們這次旅途中最難熬的一段。\n每逢新年，像是滬昆高速這種全國高速的大動脈就會擁堵不堪，從前覺得沒什麼，直到自己體驗過一遍，才知道擁堵有多嚴重。從前有一錯覺——高速堵車再怎麼也沒城市堵車嚴重。上到高速才發現，過年高速上那種水洩不通的堵車，顯然不是一般人可以接受的。具體有多堵呢？看看就知道了。\n從早上10點出發，一直到凌晨兩點，一直被卡在高速上，我看，幾乎是沒有什麼別的情況能讓我們（輪換）開這麼久的車了。回來之後我才發現我的腳已經淤青——踩剎車踩的。\n旅行總覺得學之甚少 都說讀萬卷書，行萬里路，這一趟行程滿打滿算也接近空間距離上的“萬里”了。但每次行程下來，我總覺得，我學到的甚少。每個自然、人文景觀，對我來說，似乎更多意義上是一個過眼雲煙，甚至連放鬆身心的作用都沒有起到很多。現在想想，為什麼行萬里路之後，收穫如此之少呢？也許就是因為讀書沒有破萬卷吧。\n在虎跳峽，壯觀景色之外，其中蘊含的地理知識也許更能讓人迷醉。在麗江古城，除了古時的繁華，歷史近在眼前的感覺或許更讓人心生滿足。行萬里路之前需要讀萬卷書，或許這句話也有這樣的意義吧：當從萬卷書內汲獲的知識在現實中找到參照和實踐，心中生現的滿足感和安然是讓人趕到自己和世界真實存在的最好慰藉。\n這篇遊記從1月開始撰寫，一直到4月中旬才接近完成。回看我最初寫下的文字，總是對我那近乎流水賬的文筆感到羞愧。這3個月的時間裡發生了不少事，有一段時間我也經受巨大的壓力，壓力卻也不總是帶來壞處，它沒有擊垮我，反而讓我更加成熟。\n這不是一篇完美的遊記，也永遠不會是一篇完美的遊記，在撰寫它的過程中，我學會了精煉文字，學會了更加成熟的語風，學會了在不那麼理想的環境下寫作……。這篇遊記對於我來說，已經超越了一篇遊記的意義——它一直在見證我的成長，即使這並非我原本的目的。\n為什麼要旅行？也許我已經有了答案。\n","date":"2023-01-11T22:57:34Z","image":"https://blog-img.l3zc.com/202304021408390.webp","permalink":"/zh-hant-tw/2023/01/2023-new-year-trip-archive/","title":"長沙到麗江，2023年的第一次旅行"},{"content":"Traceroute 是一個很常用的網絡 debug 工具，它（應該）會列出你的數據包在到達最終目的地的路上經過的所有路由節點，如果你 traceroute 我的網站，你會得到看起來像這樣的內容：\ntraceroute通過 Time To Live或者 IPV6 下的 Hop Limit實現追蹤的效果\n這個數值的用意是通過限制數據包能通過的最長「邏輯距離」（最多能通過幾個節點），防止數據包在網絡故障的情況下在網絡上被無限循環廣播。每當數據包經過一個節點，這個數值就會減少，這個值減小到0時，路由節點就會丟棄這個數據包：舉個例子，網絡故障的情況下，一個 IPV4 數據包的 TTL 為65，經過64個節點時，其TTL會等於65-64=1，經過第65個節點時，TTL 會降為0，那麼，第66個節點在發現這個數據包的 TTL 為0時就會將其直接丟棄。\n但做到這一步並沒有解決所有問題：出於禮貌原因，當一個數據包丟失了，我們還要想辦法通知發送這個數據包的人——既然一個數據包能夠從發送者到達丟棄它的服務器，那麼丟棄它的服務器和發送者之間一定是可以通信的。\n那麼 traceroute 的設計思想是：首先設置一個極低的 TTL，並向目標服務器發包，小幅增加這個 TTL，再次向服務器發包，重複這個步驟，直到可以到達目標服務器為止，通過這個做法，traceroute就可以通過前面提到的，數據包被丟棄後的「回執」向我們展示我們與目標服務器之間的「路徑」。\ntraceroute 工具通常還會貼心的幫你查詢好對應 IP 的反向 DNS，便於我們查看途徑節點的相關信息。儘管設置 IP 的反向 DNS 並非必須，大多數運營商都會設置反向 DNS 以方便用戶或者他們自己 Debug。\n重要的是，如果買下一個 IP 區段，你便可以將這個區段內的 IP 的反向 DNS 改成 Whatever you want。於是乎，一位仁兄突發奇想，買下了一個 IP 區段，於是就有了下面的 TraceRoute 民謠:\nPS C:\\Users\\l3zc\u003e tracert -h 100 bad.horse 通過最多 100 個躍點跟蹤 到 bad.horse [162.252.205.157] 的路由: 1 \u003c1 毫秒 \u003c1 毫秒 \u003c1 毫秒 192.168.0.1 2 2 ms 1 ms 1 ms 192.168.1.1 3 5 ms 4 ms 4 ms 100.66.128.1 4 4 ms 4 ms 4 ms 58.20.125.137 5 5 ms 4 ms 4 ms 119.39.126.117 6 * 27 ms 27 ms 219.158.98.69 7 32 ms 30 ms 30 ms 219.158.5.158 8 29 ms 30 ms 31 ms 219.158.16.66 9 172 ms 175 ms 174 ms 219.158.98.10 10 179 ms 175 ms 174 ms ix-xe-8-2-5-0.tcore1.sqn-sanjose.as6453.net [63.243.205.93] 11 226 ms 225 ms 236 ms if-ae-1-2.tcore2.sqn-sanjose.as6453.net [63.243.205.2] 12 222 ms 222 ms * if-ae-51-2.tcore2.ct8-chicago.as6453.net [64.86.79.14] 13 224 ms 225 ms 225 ms if-ae-22-2.tcore1.ct8-chicago.as6453.net [64.86.79.2] 14 223 ms 223 ms 223 ms if-ae-8-2.tcore2.tnk-toronto.as6453.net [66.110.48.1] 15 223 ms 223 ms 223 ms if-ae-2-2.tcore1.tnk-toronto.as6453.net [64.86.33.89] 16 225 ms 224 ms 225 ms 64.86.33.58 17 223 ms 223 ms 223 ms 67.223.96.90 [67.223.96.90] 18 225 ms 224 ms 224 ms bad.horse [162.252.205.130] 19 228 ms 228 ms 229 ms bad.horse [162.252.205.131] 20 239 ms 237 ms 235 ms bad.horse [162.252.205.132] 21 244 ms 245 ms 248 ms bad.horse [162.252.205.133] 22 243 ms 243 ms 243 ms he.rides.across.the.nation [162.252.205.134] 23 248 ms 249 ms 249 ms the.thoroughbred.of.sin [162.252.205.135] 24 263 ms 259 ms 261 ms he.got.the.application [162.252.205.136] 25 267 ms 268 ms 267 ms that.you.just.sent.in [162.252.205.137] 26 266 ms 266 ms 266 ms it.needs.evaluation [162.252.205.138] 27 267 ms 266 ms 267 ms so.let.the.games.begin [162.252.205.139] 28 275 ms 274 ms 274 ms a.heinous.crime [162.252.205.140] 29 280 ms 280 ms 280 ms a.show.of.force [162.252.205.141] 30 292 ms 293 ms 292 ms a.murder.would.be.nice.of.course [162.252.205.142] 31 293 ms 290 ms 290 ms bad.horse [162.252.205.143] 32 301 ms 302 ms 302 ms bad.horse [162.252.205.144] 33 297 ms 296 ms 297 ms bad.horse [162.252.205.145] 34 308 ms 307 ms 307 ms he-s.bad [162.252.205.146] 35 309 ms 309 ms 308 ms the.evil.league.of.evil [162.252.205.147] 36 314 ms 314 ms 313 ms is.watching.so.beware [162.252.205.148] 37 322 ms 323 ms 322 ms the.grade.that.you.receive [162.252.205.149] 38 327 ms 326 ms 326 ms will.be.your.last.we.swear [162.252.205.150] 39 327 ms 329 ms 330 ms so.make.the.bad.horse.gleeful [162.252.205.151] 40 331 ms 331 ms 331 ms or.he-ll.make.you.his.mare [162.252.205.152] 41 339 ms 339 ms 339 ms o_o [162.252.205.153] 42 345 ms 346 ms 346 ms you-re.saddled.up [162.252.205.154] 43 348 ms 348 ms 348 ms there-s.no.recourse [162.252.205.155] 44 351 ms 350 ms 350 ms it-s.hi-ho.silver [162.252.205.156] 45 363 ms 363 ms 361 ms signed.bad.horse [162.252.205.157] 跟蹤完成。 PS C:\\Users\\l3zc\u003e這是這首民謠的原曲：\n某位仁兄甚至用這個做了一份他的簡歷：\n如何實現？ 看起來很美好，但是這如何實現？\n我們可以輕鬆的更改 Reverse DNS 的設置。最大的問題是，如何讓數據包按照我們希望的路線穿行。\n在物理上將節點按順序連接顯然不現實，現在能被想到的有兩種辦法：要麼在單個節點上將很多虛擬的接口按順序分配 IP 並串聯起來並將他們用作「節點」，要麼在用戶網絡層上做手腳，生成假的「超限」消息，憑空生成一條不存在的路由線路。\nhttps://github.com/benjojo/traceroute-haiku\n這個倉庫是 benjojo 進行實驗的項目，利用了第二種方法，用GO語言寫一個TUN/TAP，接管所有的網絡流量，並生成假的「超限」消息。\n自己動手 我們來寫一個程序，徹底理解這個項目。\n我之前沒有使用過 Go 語言。已知的 Go 項目裡我最熟悉的是 Clash 的 Mac 版本。Clash 有強大的分流功能，以及為了兼容性，編寫了一套 TUN 模式。用來作為切入點學習非常合適。\n參考 https://blog.benjojo.co.uk/post/traceroute-haikus\n","date":"2023-01-10T12:11:29Z","permalink":"/zh-hant-tw/2023/01/traceroute-haiku/","title":"Traceroute俳句"},{"content":"也許你曾經嘗試過使用諸如滴答清單、Notion 的軟件來構建一套 Todo List 系統，但實際操作起來卻發現：心血來潮時，就往清單裡丟幾個任務，過了一會，心情不好了，就對這份自己構建的 Todo List 束之高閣。\n是的，清單軟件很棒，但若是你真正的去使用他時，會發現清單軟件總有一些缺點讓你感到不適——每個人的使用習慣不一樣，商業化的產品不可能去專門配合每個人的使用習慣。\n不幸的是，即使你從0開始，自己開發一套屬於自己的工作流系統，完美的Todo List也是無法實現的。如果你遇到了上面所提到的問題，那麼這是一個不爭的事實：這些應用程序都要求遠高於你期望的，持續的投入。沒有一個Todo List能夠減少對某種程度的自律的需要。\n我很抱歉，非常抱歉。\n","date":"2023-01-08T22:41:16Z","permalink":"/zh-hant-tw/2023/01/%E6%B2%A1%E6%9C%89%E5%AE%8C%E7%BE%8E%E7%9A%84todolist/","title":"沒有完美的Todo List"},{"content":"安裝Electron SSR很簡單，下載好deb文件安裝就可以。\nsudo dpkg -i electron-ssr.deb由於Electron-SSR作者已經刪除了這個項目的倉庫，故目前只有Fork來的備份可用。\nhttps://github.com/qingshuisiyuan/electron-ssr-backup\nReadme這一部分只提到了libsodium等少量依賴，於是直接執行安裝命令時dpkg提示有依賴問題。所以，安裝所必要的依賴：\nsudo apt install libcanberra-gtk-module libcanberra-gtk3-module gconf2 gconf-service libappindicator1 libssl-dev libsodium-dev實際上apt提供了自動解決依賴問題的選項：\nsudo apt --fix-broken install在安裝需要依賴的deb包後執行即可解決依賴問題。\nElectron-ssr在解決依賴問題後成功運行，可以正常顯示圖形界面，訂閱、更新節點。但無論怎麼調整Ubuntu的網絡設置都無法魔法上網。查看electron-ssr的.config目錄發現其後端使用的是python版本的ssr，調取錯誤日誌發現其竟然提示沒有安裝Python。\n怎麼可能沒有Python？Ubuntu肯定自帶Python。經過排查發現：\n輸入python3可以正常調用python3.10 輸入python會提示未知命令 electron-ssr默認調用的是python而不是python3 上網一查才發現，Ubuntu自22.04版本開始不再將Python加入$PATH。故手動創建symlink：\nsudo ln -s /usr/bin/python3 /usr/bin/python再度打開Electron SSR測試，發現可以正常魔法上網，問題解決。\n別忘了將Ubuntu網絡設置中的代理設置調成自動。\n可以學到什麼？ 不帶版本號調用python命令是一個壞實踐，以後應當避免這種行為。\n","date":"2022-11-04T15:32:37Z","permalink":"/zh-hant-tw/2022/11/ubuntu-22-04-electron-ssr-troubleshoot/","title":"Ubuntu 22.04 Electron SSR Troubleshoot"},{"content":"1960年，誰也不會想到美蘇冷戰時期軍用的 ARPANET 會發展成為現在世界上最重要的基礎設施之一。互聯網從少數人手裡的玩具變成了每日生活中必不可少的工具。中國政府的數據顯示，截至2022年8月31日，中國網民數量達到10.51億，是世界上最大的互聯網用戶群體。\n這是網民？ 是的，沒錯，這些人是中國網民。\n是\u0026hellip;\u0026hellip;嗎？\n我們只不過是一群用上了 iPhone 的秦朝人罷了\n——網友\n90%的中國“網民”，只不過是一位用上了網絡的大清子民而已。而淘寶，用一種直截了當的說法，地位堪比——賽博供銷社。\n互聯網技術成功的普及到了全世界，與之相應的價值觀——互聯網精神，卻不得不向傳統價值觀妥協。我們前腳邁入了烏托邦，後腳卻還停留在那個混沌而矇昧的舊世界。\n互聯網精神？ 互聯網精神，來自互聯網的最初設計：對等、開放、容錯、共享、去中心、自組織、非商業，等等。\n我很懷念十年前的互聯網，那時候包容共享開放還是主流，Censorship 並沒有現在這麼極端，大家在各大論壇、貼吧以及當時欣欣向榮、並未被禁止的個人博客上分享自己高質量的經驗見解，和諧共處的討論。流氓軟件、內容農場、假冒網站沒有充斥在搜索引擎上。那時候上網，不說受益匪淺，也至少能發現有價值的信息，以及在討論中收穫純粹的快樂。\n看看現在，垃圾內容和審查制度大行其道。製造各種狗屁不通全靠編文章的自媒體與內容農場，低俗降智的直播短視頻平臺，脫胎於電視購物洗腦汙染的直播帶貨，充斥著內容農場、沙雕小編生產的文字垃圾的搜索引擎，各路巨頭打造自己的 All in One Apps，開展新時代的“圈地運動”，將曾經自由的網民們看作價值的載體，大肆圈定自己的勢力範圍，恨不得擠佔用戶所有的上網時間。\n人們上網的時間越來越多，但從網上獲得的卻越來越少。再難看到到有趣的故事讓人靈魂共鳴，再難聽到獨到的見解讓人醍醐灌頂，再難學到有用的經驗幫你解決各種各樣的問題。互聯網越是發展，發展到彷彿每個人都在當下充沛的信息流衝擊下大量獲取信息，但你所獲得的只是所謂“獲取信息”的快感，只是在緩解互聯網奶頭樂毒癮而被迫做出的舉動。推薦算法的出現甚至讓你所看到的、所想到的，只是權力想要讓你看到、想到的。\n互聯網早已經不是一個讓所有人平等、自由、快捷的提升自己獲取知識收穫快樂的渠道，只是一個更加黑暗的現實世界，披著互聯網的外衣，收割更多人的韭菜。\n技術？人文？ 技術終究只是技術，他就擺在那裡，沒有人文屬性。20世紀，人們驚呼電視會毀了下一代，可這並沒有發生。21世紀，人們驚呼電腦會毀了下一代，可這也未曾發生。現在，人們驚呼手機會毀了下一代，可以預見到，這也絕不會發生。技術從不會毀掉任何一個人，真正會毀了一個人乃至全人類的，乃是屬於人文因素的，人們自甘墮落的，頹廢。\n為什麼要限制未成年人只能在週末每天玩手機遊戲一個小時？是為了讓那些家長認清就算沒有遊戲你的孩子照樣是個廢物。\n互聯網並不要求每個人具有互聯網精神，但，互聯網精神才是讓互聯網能夠被稱為互聯網的核心所在。\n這樣的網絡，只配被稱為“賽博” 沒有互聯網精神的互聯網不能被稱作互聯網，而只是現有內容的另一種表達形式。把原本放在櫥窗和貨架上的商品搬上屏幕，再做一個配送服務？把原來大家在線下討論問題搬到線上，現在拉一個群？把原本衣錦還鄉的典故舊貌換新顏，變成衣錦發微博微信小紅書？\n我們只不過是一群用上了iPhone的秦朝人而已。技術進化了，推動社會進步的關鍵人文因素卻沒有進化，每每找一本描寫古代社會生活之著作，看看古代的社會生活，其與現在之相似無不讓我有一種恍若離世之感，在中國幾千年的歷史裡，儘管技術更新迭代，社會生活從沒有改變，我們的社會也從未允許過這樣的改變。中國雖然引進了互聯網的技術，卻一如既往的頑固，從未讓這種技術改變社會生活。這樣的網絡，只能被稱為“賽博”，而不能被稱作“互聯網”。這樣的網民，只能被稱作“賽博原始人”。\n真正的網民？恐怕1億都是樂觀估計 蘋果官網在哪看\n淘寶嗎\n……\n在中國，真正的網民又有幾何？政府和巨型企業聯合，個人網站和私人論壇了無生存之地，ICP牌照制度擠壓個人網站的生存空間，只有大公司的網站能夠生存。近期傳出的中國大陸互聯網白名單的試點，雖然令人擔憂，可悲的是，人們已經不再在乎了。\n平時上網的時間基本都花在了 BAT 三大巨頭的APP上，即使開啟了白名單制度，也沒什麼吧。\n這是一種悲哀。1994年，中國正式接入互聯網。2022年，中國卻在打造自己的網絡，與互聯網精神背道而馳，離互聯網越來越遠。中國的網民們呆在與局域網沒有差別的小圈子裡，瀏覽著幾家大公司與政府的網站，使用他們的服務，過著高級版的朝鮮局域網生活。\n這更是一種無盡的黑暗，我們看似接入了互聯網，更多的人在實質上卻只接入了賽博，我們何嘗不像是賽博朋克2077的世界，將自己孤立成一個個與世隔絕的封閉子網。\n按照互聯網的定義，真正遵循互聯網精神的民眾可能具有如下的行為：\n運營自組織的網站 使用真正遵循 P2P 精神的下載器 經常在網上分享自己的見解與想法，抑或是git commit等 \u0026hellip; 這樣的網民，在如今的中國，可謂是少之又少。即使有，也很難在簡體中文圈子裡抱團——這樣的人太少了，與其這樣，我們不如使用通用的英語與全世界的同路人交流，享受互聯網的樂趣。\n賽博朋克真的離我們很遠嗎？ 這就是賽博朋克，巨型企業和政府通過技術監控著人們的一舉一動，更好的技術沒能用於造福眾人，而成為了金字塔頂端一小撮人的斂財工具。權貴們運用技術鞏固他們的地位，玩弄他們的權力。而普通的人民卻只能在這種絕望的陰影下懷揣著希望努力生活，人們無法反抗，無法打破鋪天蓋地的絕望。\n變革？ ","date":"2022-10-05T17:22:22Z","permalink":"/zh-hant-tw/2022/10/%E4%B8%AD%E5%9B%BD%E7%9C%9F%E7%9A%84%E6%9C%8910%E4%BA%BF%E7%BD%91%E6%B0%91%E5%90%97/","title":"中國真的有10億網民嗎？恐怕連1億都不到"},{"content":"1949年，哈佛語言學家齊夫（George Kingsley Zipf）做了長篇小說《尤利西斯》的詞頻統計。該書的長度是260,430字，總共用到了29,899個單詞。它是單詞量最大的文學作品之一。\n他發現，單詞的出現頻率有規律地下降。詞頻第二名的單詞的出現頻率，是第一名的二分之一，第三名的出現頻率是第一名的三分之一，第四名是四分之一，第十名是十分之一，第1,000名是千分之一，以此類推。\n這被稱為 Zipf 定律，即任何單詞的詞頻，與該單詞在詞頻表中的排名保持一個固定比例。\n這個定律有兩個重要推論。\n一種語言的常用詞彙只包含少數單詞。例如，在英語中，單詞 the 佔所有文本的7%，最常見的10個英語單詞佔到了所有文本的23%。 對於當今世界的大多數語言來說，僅僅100到150個常用單詞，就佔所有文本的一半左右。在希臘語的《聖經新約》中，319個單詞佔全書近80%的內容。\n當你掌握了這些高頻常用詞以後，遇到的所有詞彙幾乎都是低頻詞。 還是以希臘語的《聖經新約》為例，319個單詞佔文本的近80%，但剩下的20%包含了5118個不常用的單詞，其中大部分單詞只使用了一次。\n推論二註定了精通一種外語是一件麻煩事。學習者入門以後，就不得不花大量時間，記住那些出現頻率很低的詞彙。以布朗大學語料庫為例，該語料庫一共包含了53,076個單詞，其中36,135個單詞在語料庫的所有文獻中出現次數不超過三次，它們佔了詞彙量的68%，但是僅僅在5%的場合使用。\n更麻煩的是，這些不常見的詞往往很重要，能夠提供句子的關鍵信息。越少見的詞對於瞭解句子含義越重要。\n學習者遇到不認識的單詞，可以通過上下文去猜測含義。但是，一項研究表明，如果要從上下文中正確猜中單詞含義，閱讀者必須能夠理解文本中至少95%的內容。\n對於布朗語料庫來說，15,851個單詞可以覆蓋語料庫97.8%的內容。這差不多就是英美大學生掌握的單詞數量。這意味著，如果你記住了15000個單詞，再遇到不認識的單詞，就可以較有把握得猜出它的含義。\n但是，對於外國人來說，想要通過幾年學習，掌握15000個左右的英語單詞，絕非易事。\n即使按照每天記憶30個單詞，全年無休的速度計算，從零開始記憶15000個單詞也需要500天也就是比一年半還要多的時間。事實上，在實際操作中，能達到這個速度的學習者非常罕見，以我為例，進入高中時，我的詞彙量在3000到4000，讀高中的時間裡，由於我的詞彙量對我的英語成績並不構成瓶頸，我在任何時候都沒有刻意去記單詞。高中畢業時，我的詞彙量僅6000到7000，這意味著高中三年裡，在不刻意記單詞的情況下，平均下來我每天新增的詞彙量不足三個。按照這個速度從零開始記憶15000個單詞需要花費15年時間。\n","date":"2022-09-08T23:58:49Z","permalink":"/zh-hant-tw/2022/09/why-it-takes-so-long-to-learn-a-foreign-language/","title":"為什麼學習一門外語這麼難？"},{"content":"自從把博客系統換成 Wordpress 以後，又是緩存，又是精簡，又是各種替換，為了優化網站的速度不可不謂花了一番心思，然而在 iPhone 上，我的網站的打開速度卻依然時快時慢。在之前兩個月裡，我一直認為是服務器的性能問題所致。直到有一天我看到並且為網站部署了 OCSP Stapling。\n為什麼偏偏在 iPhone 上就打開慢？ 你可能已經注意到我使用了「打開」而非「加載」，如果你調用 iPhone 上 Safari 的開發者模式查看一個網頁的 Handshake 時間，你就會發現一個不容忽視的 1 秒，至於這一秒都花在了哪裡，我們先來看看 OCSP 究竟是什麼。\nOCSP 的概念 先從 SSL 證書的有效期說起 曾經我有一個困惑，為什麼沒有永久有效的 SSL 證書？難道是單純因為商業原因？其實並不是，主要原因是為了安全。每次簽發機構（CA）簽發 SSL 證書時，CA 都會為這個 SSL 證書生成一個私鑰。就像家裡任何一把鑰匙一樣，HTTPS 證書的私鑰有丟失、洩露的風險，當網站的私鑰丟失時，網站應該向證書 CA 申請將他們的證書加入到證書吊銷列表（CRL）裡。當用戶訪問 https 站點時，瀏覽器會自動向 CA 請求吊銷列表，如果用戶訪問的站點提供的證書在 CRL 裡，瀏覽器就不信任這個證書，因為私鑰洩漏後，攻擊者可能擁有同樣的證書。\n所以，如果證書永久有效，隨著越來越多的私鑰丟失，吊銷列表也越來越大（因為只有加進去的，沒有剔出去的），這既給 CA 的服務器增加流量壓力，也會增加瀏覽器需要下載的數據量。而一旦有效期只有一年或幾年，那麼CA就可以將那些已經過期了的證書從 CRL 裡剔除，因為反正瀏覽器也不信任過期證書。這種問題也就隨之消失，於是，今天看到的證書，有效期都隨著安全等級的提高而加長，但除非自籤，沒有永久有效的證書。\n這和 OCSP 有什麼關係？ OCSP 即 Oline Certificate Status Protocol，是用於替代 CRL 的協議，解決了一些 CRL 協議存在的問題，以下信息來譯自 Wikipedia：\nOCSP 響應通常比典型的 CRL 響應更小，這意味著對於客戶端和服務器更小的網絡負擔。\nOCSP 響應中需要解析的數據更少，因此客戶端需要的運行庫比解析典型的 CRL 響應更少更簡單\nOCSP 中，服務器可以記錄主機在何時驗證過特定的證書，由於請求不強制加密，相關信息可能被第三方獲取。\n簡單來說，OCSP 做的就是 CRL 的事——驗證這個網站的 https 證書是否處於被吊銷的狀態。\n所以為什麼打開慢？ 我們搭建個人網站時大都沒有很高的預算，例如我的網站原本託管在免費的 Github Pages 上，預算能省則省，更別提動輒幾千一年的 SSL 證書了。於是你看到的非商業性質的個人網站大都採用了免費的 Let\u0026rsquo;s Encrypt 證書。而 Let\u0026rsquo;s Encrypt 的 OCSP 服務器 ocsp.int-x3.letsencrypt.org 線路非常垃圾，實測中部地區聯通 traceroute 以供參考：\n可以看到服務器在香港，線路卻繞美國。這導致 一個很簡單的 OCSP 查詢請求需要 1 秒的時間來返回結果。這意味著無論你的服務器性能有多強，網絡延遲有多低，只要部署的證書是 Let\u0026rsquo;s Encrypt，網站在 iPhone 上的加載時間就絕對不會快過一秒。這還不是最壞的情況，因為各種莫名其妙的原因，Let\u0026rsquo;s Encrypt 的 OCSP 服務器域名會時不時的被 GFW 通過 DNS 汙染等方式阻斷，這就導致客戶端在一部分時間裡根本無法查詢 OCSP。\n但為什麼只有 iPhone 會加載慢呢？ OCSP 協議有一個很要命的問題：用 https 的人越來越多，驗證證書有效性的需求自然會越來越大，OCSP 服務器難道硬扛訪問量？當然不是，不同瀏覽器都會有不同的 OCSP 驗證超時時間，超時就先默認證書有效繼續進行訪問。但是有些\u0026quot;「注重用戶體驗」 的瀏覽器，比如 Chrome，自己在瀏覽器內部做了個本地列表，通過每次瀏覽器更新實現列表更新。直接查本地的列表速度就非常快了，當然也不存在什麼 CA 的 OCSP 服務器被屏蔽的問題。缺點是並非實時更新。但並非所有瀏覽器都是所謂「注重用戶體驗」的瀏覽器，比如 Safari 就默認開啟 OCSP 驗證。自然無法避免這種中國特色的問題。Chrome 在全球有超過 70% 的市佔率，而受 Chromium 開源項目的影響，國內一眾「安全」「極速」瀏覽器都不存在這種問題，這幾乎覆蓋了國內桌面端所有用戶群體。而蘋果要求包括 Chrome 在內的所有 iOS 應用都要使用 Webkit 內核，這直接乾死了所有的 iPhone 用戶。\n怎麼解決？ 總不可能要求所有 iPhone 用戶都自己關掉 OCSP 吧？那麼解決方法就是——換證書。怎麼可能，要是我真換了證書你也就看不到這篇文章了。雖然換證書，比如 Trust Asia 證書的確可以解決問題。但我不想因為換一個證書而告別 Let\u0026rsquo;s Encrypt 自動續期和支持泛域名的特性。\n終於可以談到 OCSP Stapling 了，即 OCSP 封裝，想要開啟 OCSP Stapling 非常簡單：首先到亞洲誠信提供的 https 檢測服務檢測自己的證書鏈是否完整，若是不完整則修復證書鏈後將修復好的證書重新部署，完成操作後在 Nginx 配置里加上如下兩行：\nssl_stapling on; ssl_stapling_verify on;然後重啟 Nginx 服務，大功告成。由於我自己使用的是 Nginx，Apache 請自行搜索相關方法。\n然後，iPhone 用戶也能愉快的訪問你的網站而無需忍受惱人的 GFW 干擾 Let\u0026rsquo;s Encrypt 的 OCSP 服務器。\n那麼效果如何呢？\n可以看到，開啟 OCSP Stapling 後，查詢驗證結果所需要的時間大幅縮短，反映到網站打開速度上是非常明顯的感知。\n什麼東西這麼牛逼？ OCSP 封裝，顧名思義，即服務器緩存 OCSP 服務器的驗證結果，並且在與客戶端 SSL 握手時直接發送緩存結果。\nOCSP裝訂，是TLS證書狀態查詢擴展，作為在線證書狀態協議的替代方法對X.509證書狀態進行查詢，服務器在TLS握手時發送事先緩存的OCSP響應，用戶只要驗證該響應的時效性而不用再向數字證書認證機構(CA)發送請求，可以加快握手速度。\n我的服務器線路雖然亦非很好，但比 Let\u0026rsquo;s Encrypt 的弟中弟線路好到不知道哪裡去了。開啟 OCSP Stapling 後，客戶端只需要驗證服務器事先緩存的 OCSP 查詢結果的有效性，免去了向“神優化”的服務器發請求的痛苦，速度自然會快上一大截，在有 OCSP 強制驗證的瀏覽器上初次打開網頁的效果尤為明顯，統計數據顯示，在開啟 OCSP Stapling 後，新訪客量明顯有所提高，大概是拜 OCSP Stapling 節省的大量握手時間所賜。\n為什麼不默認開啟 OCSP Stapling？ 聽上去 OCSP Stapling 簡直就是完美的萬金油優化——每個網站都開啟 OCSP Stapling，既提升用戶的訪問體驗，也為 OCSP 服務器減輕負擔。那為什麼新的 Nginx 配置文件不默認開啟 OCSP Stapling 呢？其實這是一個很簡單的問題。\n不是所有網站都有 SSL 證書 OCSP Stapling 並非在所有情況下都能提供更好的訪問體驗 現存方案中 OCSP 並不是唯一的證書驗證方案 引入新功能時通常是需要謹慎的，Nginx 用戶群體非常複雜，不同用戶不同需求 參考 為什麼https證書要設有有效期？ 找不到了 Wikipedia 玩個機吧 頭圖來自：KeyCDN\n","date":"2022-08-17T13:19:36Z","image":"https://blog-img.l3zc.com/202310112239503.webp","permalink":"/zh-hant-tw/2022/08/%E6%B5%85%E8%B0%88-ocsp-stapling/","title":"淺談 OCSP Stapling"},{"content":"最近想要解放設備們的 CPU，讓科學上網的體驗變好一點點，順手實現一些雜七雜八的功能滿足折騰欲。在學校裡我有一臺 OpenWRT 的普通路由器，用起來非常不錯，OpenWRT 基本可以實現所有我想要的功能，但畢竟是普通路由器，CPU 性能太弱，所以我的需求就定在了一款 CPU 性能更強的，能運行 OpenWRT 的 ARM 軟路由，於是 Nano Pi R2S 進入了我的視野。\n要是軟路由有排名，那 R2S 絕對是經典中的經典。小到無論如何都可以塞進弱電箱的體積，足夠強大的性能和上手的容易程度都是軟路由裡數一數二的。雖然價格可能是49入國軍，就不放出來了，但是隻要我對這玩意有需求，那也不是不能接受。\n上手 好了，現在我們搞到了這 R2S，簡單來上個手：\nR2S 外觀非常簡潔，沒有多餘的 IO，雖然原本不是作為軟路由設計，但在設計上卻給人一種天生為軟路由而生之感：一個 WAN 一個 LAN 兩個 RJ45 網口，一個 Micro SD 卡插槽，一個 USB 2.0 接口，完美覆蓋軟路由幾乎所有使用場景。\nR2S 原本是作為邊緣服務器設計，被我們硬生生的玩成了軟路由。\n一體成型的金屬外殼，非常有高級感，很有工業風，手感不錯。由於 R2S 挑卡，挑電源（看到後面你就知道了）在購買機器時我直接買了已經經過測試的 Micro SD 卡和電源組合套餐，理論上來說，我不會遇到 SD 卡、電源與機器不兼容的問題。\n刷個 OpenWRT 跑起來！ 先來看看這玩意兒的硬件規格：\nCPU: Rockchip RK3328, Quad-core Cortex-A53 DDR4 RAM: 1GB Network： 10/100/1000M以太網口 x 1 USB3.0轉10/100/1000M以太網口 x 1 USB2.0 Host: Type-A x1 MicroSD Slot x 1 MicroUSB: 供電和Slave功能 Debug Serial Port: 3.3V TTL電平，3Pin 2.54mm間距排針 PC Size: 55.6 x 52mm Power Supply: DC 5V/2A Temperature measuring range: 0℃ to 80℃ OS/Software: U-boot，Ubuntu-Core，OpenWrt 這個硬件規格，裝 Ubuntu 當服務器還是免了，但是跑個 OpenWRT 當路由器使綽綽有餘。\n由於使用 Micro SD 卡作為啟動介質，R2S 的刷機非常容易：取出 SD 卡，用讀卡器接上電腦，把鏡像燒寫進 SD 卡，再把 SD 卡裝回 R2S，完成。對於用 Ultra ISO 刻過 Windows 系統盤的老油條來說全都是熟悉的操作，完全沒有任何難度可言，即使是新手也能很輕易的學會。讓我們快進到登入 OpenWRT 的後臺：\n（此處應有Nice）\n狗都不用 R2S 官方編譯的 OpenWRT，不僅沒有中文翻譯，沒有好看的主題，各種插件還需要自行安裝。懶得在官方固件上瞎折騰則可以直接選擇別人打包好的固件。我使用了 BigDongDong 打包的帶 Docker 固件，能滿足我的所有需求。\n讓這玩意加入我的家庭網絡 要想讓 R2S 加入我的家庭網絡，有兩種大致的方案：第一種，也是最直截了當的辦法，即直接拿 R2S 當主路由使用；第二種方法稍微複雜，用 R2S 當旁路由，將原來主路由的網關指向旁路由。這兩種方案各有優缺點，將 R2S 當主路由配置簡單，只要你想，只需要將 R2S 接入光貓和原來的路由器之間，然後啟動路由器，什麼都不需要配置，直接開始上網。代價是這會讓網絡架構多一重出故障的概率，雖然這個概率很小。將 R2S 用作旁路由配置稍微複雜，但能實現某些設備直接走主路由，其餘設備走旁路由的效果，缺點就是某些只有作為主路由才能實現的功能（比如你要建站而你原來的主路由不支持端口轉發）無法實現。\n我無法接受讓 R2S 作為旁路由的行為，想到數據包在兩個路由由之間來回竄個兩次才能被髮出去情景，我還是選擇了第一種方案——我不需要那麼穩定的網絡，大不了多重啟幾次。於是這就是新的網絡拓補圖：\n圖片懶得自己畫所以來源於網絡，無線路由器那裡那個 WAN 請自行腦補成 LAN。\n為了讓 R2S 能儘可能的與我的設備交互（比如控制某個設備是否啟用科學上網），以及儘可能的減少 NAT 和網段的套娃，我們需要對原來的路由器進行一些設置，首先查看路由器是否有類似 AP模式（無線接入點模式）的功能，如果有那麼直接啟用這個模式就行。如果我的路由器有這個選項那我就不需要寫下面這個部分了，只可惜，這 TP-LINK 電子垃圾並沒有。\n手動把原來的路由器設置成交換機 我不得不手動設置這個路由器，不過還好這並不是一件難事：首先把原本接在路由器 WAN 口的網線插到 LAN 口裡，你沒看錯，LAN 口。然後登入原路由器的後臺，關掉原路由器的 DHCP 服務器，打開原路由器的 LAN 口設置把原路由器的 LAN 口 IP 設置成與 R2S同一網段下的一個IP，例如：我的 R2S 的 IP 是 192.168.2.1 ，所以我將原路由器的 LAN 口 IP 設置成 192.168.2.2 。設置好以後重啟路由器，所有設備就和 R2S 同一個網段了，在 R2S 的後臺也可以看到這些設備。這些操作的本質是把路由器變成一個帶無線功能的交換機。\n至此，基礎的網絡配置已經全部完成了，本來就很亂的弱電箱更亂了。\n終於可以正式開始折騰了 現在折騰的基礎已經有了，那就開始折騰吧。\nPasswall 科學上網 其實原本想用 Clash，不過 Clash 有多吃資源上網一搜就知道。\n關於 Passwall 怎麼使用網上一搜一大把，這裡我直接寫我的用法：\n導入機場的訂閱開啟自動更新訂閱，每天一更新 選擇一個位於香港的節點作為主節點 開啟自動切換，設置新加坡和美國的節點為 Fallback 節點（故障轉移） 開啟 ChinaDns-NG 過濾被汙染的 DNS 結果 最後把之前所有設備上設置的 DoH 和 DoT 取消，讓他們的 DNS 服務器直接指向 R2S，萬事大吉，所有設備都可以科學上網了。出於強迫症我將家用攝像頭排除在代理列表外，搞定。\n青龍面板 既然這固件自帶 Docker，那總得用起來吧？Docker 能幹嘛？青龍面板安排。操作其實也很簡單：把青龍面板的鏡像拉取到 SD 卡上，然後部署啟動容器啟動就行。\n另外需要額外安裝一些依賴，例如 Python 的 requests 庫，Node.js 的 base64 庫等，這裡我隨意貼一份依賴列表，可以自行取用：\n# Node.js 下的依賴 crypto-js prettytable dotenv jsdom date-fns tough-cookie tslib ws@7.4.3 ts-md5 jsdom -g jieba fs form-data json5 global-agent png-js @types/node require typescript js-base64 axios moment # Python3 下的依賴 requests canvas ping3 jieba PyExecJS aiohttp至於其他依賴基本可以看腳本運行的錯誤日誌對症下藥地安裝，這裡就不貼出來了。\n那麼現在青龍面板有了，拿他幹什麼呢？\n目前只是拿它跑跑腳本拿京豆，佛系看到什麼功能就加上，雖然用的是家用 IP，被風控的概率比較低，但我還是儘量不多開腳本，且不說會不會被風控，畢竟這東西還是主路由，總不能一天到晚太佔性能導致我的上網體驗變差吧？如果真是這樣那就捨本逐末了。\n至於腳本從哪裡來，可以自行在 Github 上搜索依賴庫拉庫安裝，說不定以後還要去 Gitee 上再找找，只能說，但願 Github 不要被完全阻斷導致一部分大佬往 Gitee 上跑。這裡貼一個我用的庫\nhttps://github.com/okyyds/yydspure/tree/master\n直接用定時任務拉庫就行。\nql repo https://github.com/okyyds/yydspure.git \"jd_|jx_|gua_|jddj_|jdCookie\" \"activity|backUp\" \"^jd[^_]|USER|function|utils|sendNotify|ZooFaker_Necklace.js|JDJRValidator_|sign_graphics_validate|ql|JDSignValidator\" \"master\"穩定性、效果和問題 為了穩定，暫時就折騰這麼多了。\n那麼穩定性怎麼樣？目前來看很好，沒有遇到網上的各種燒壞，重啟之類的問題，設置 Crontab 每週重啟一次，非常穩定，這裡有一個坑點： R2S 使用 Type-C 接口供電，卻不支持 PD 協議。並且，雖然官方的技術規格里只需要 5V2A 的電源，但實際上需要儘量選擇高於這個規格的電源，比如我的電源是 5V3A 的非 PD 協議電源，這就導致 R2S 的配套電源選擇範圍很窄，儘量選擇店家 R2S 套餐裡配好的電源。以下是一些網友的情況：\n前面也提到了 R2S 挑卡的問題，出於一些原因，R2S 與某些SD卡的兼容性欠佳，可以去 R2S 官方 Wiki 上找找兼容的 SD 卡列表。\n效果如何？不需要多說，因為家裡的寬帶只有 100 兆，任何一個軟路由都可以輕鬆跑滿。因為我的機場屏蔽了意義不大的測速，晚高峰（大概是晚高峰，週六下午六點半） Youtube 的話可以輕鬆跑到 12 萬。\n這個速度和機場有比較大的關係，不過，只要5萬以上，4k 就能隨便拖著看，再往上意義不大。再就是青龍面板的效果，前面大家也都看到了。\n那麼問題？其實問題主要集中在 IPV6 上，換上 R2S 後，哪怕我將所有 IPV6 相關的服務全都設成中繼模式也沒有辦法正常使用 IPV6，而原來的路由器只要設置成橋模式即可，這個問題暫時沒有找到解決方案。\n最後 總體上，R2S 達到了我的預期，基本滿足了我的需求，是一件我相對滿意的產品。折騰樂趣無窮，但切莫上頭，軟路由這種東西，搞清自己的需求，不要忘記折騰原本的目的，夠用就好，否則就是一個痛苦的無底洞。至於這個尚未解決的 IPV6 問題，佛系解決，實在不行看看能不能用 IPV6 NAT。\n","date":"2022-08-16T17:22:19Z","permalink":"/zh-hant-tw/2022/08/nano-pi-r2s-hands-on/","title":"Nano Pi R2S 上手，小小升級一下家庭網絡環境"},{"content":"我從未去過漫展，並且可能在今後相當長的一段時間裡也不打算去了。看到一位推友發送的廣州漫展的情況後，我的心情卻不比當年 Pixiv 被牆更加簡單。\n我們到底需要什麼樣的漫展？ 在維基百科上搜索“漫展”，你會發現這個詞條之中文版是一個年久失修的詞條。所以我們來看看英文版：\nAn anime convention is an event or gathering with a primary focus on anime, manga and Japanese culture. Commonly, anime conventions are multi-day events hosted at convention centers, hotels or college campuses. They feature a wide variety of activities and panels, with a larger number of attendees participating in cosplay than most other types of fan conventions. Anime conventions are also used as a vehicle for industry, in which studios, distributors, and publishers represent their anime related releases.\n最初的漫展在1975年舉行，是位於東京舉行的 Comiket。上面這段話大致的翻譯是：漫展是將焦點放在動漫，漫畫以及日本文化上的展覽。通常分多日在會議中心、酒店、校園等地舉行，分為各種活動。漫展中參加 Cosplay 的人數遠比參加其他活動的人更多。漫展也被當作二次元商業活動的載體，籤售等各種商業活動都可以通過漫展進行。\n可以看出，漫展在中文和英語環境下都是一個較為冷門的詞彙。就連在編輯戰頻發的維基百科都少人問津。在我的印象裡，漫展是一個傳播ACG(Anime, Cartoon, Gaming)文化之地。雖然這類文化大抵起源於日本，但像英文維基百科片面的將其歸結於日本文化顯然非常偏激。\n漫展在官僚主義、形式主義、和沙文主義三座大山的夾縫中求生存、圖發展，漫展的墮落是中國畸形的文化現象的縮影。\n審查並非一定是政府行為，亦可以是民間自發行為，過度的審查讓原本正常生長的文化變成了畸形的文化，這已經不是第一次：民國時期的散文詩作者抒情之地，建國後大部分卻變成了刻意拍馬屁的垃圾；京劇是我國國粹，文革時期極端的審查與文化專制讓京劇畸形發展出了面目全非的樣板戲；藏傳佛教本是至美的純粹信仰，過分的審查卻將其變成了政治意味濃厚的工具。毫不誇張的說，過分的審查本質上是在同化文化，是對多元文化的不容忍，簡單來說，這就是在破壞文化。\n我們到底需要什麼樣的漫展？我們需要的，只不過是未經汙染的一片淨土，是一片原汁原味的文化，可是在極端的審查下，連對多元文化基本的保留，基本的原汁原味都成了奢望。\n你不是不看漫展嗎？ 若是問及這在現實世界中對我的影響，可以說是幾乎為零。我雖然喜愛二次元文化，但就我痴迷的程度而言，我甚至不配被稱為ACG愛好者。我一苦逼大學生的生活狀態，直截了當的說，與那些花天酒地的大學生相比，我過得可能更接近於苦行僧。畢竟從第一句話我就說了：我從未去過漫展，在夏日祭事件後環境每況愈下的情況下更加不打算去。\n在我的意識裡，一種聲音告訴我：等某一天我喜愛的某個東西，比如最近在玩的 Cytus 2 被拉清單，或者說發生更加難以接受的事國內進一步封閉互聯網，我才會站出來發聲。現在的事對你沒什麼影響，事不關己，高高掛起？但我卻不得不提到這首著名的墓誌銘：\n在德國，起初他們追殺共產主義者，我沒有說話，因為我不是共產主義者；\n接著，他們追殺猶太人，我沒有說話…，因為我不是猶太人；\n後來，他們追殺工會成員，我沒有說話…，因為我不是工會成員；\n此後，他們追殺天主教徒，我沒有說話…，因為我是新教徒；\n最後，他們奔我而來，卻再也沒有人站起來為我說話了。\n這是一位牧師的墓誌銘，相信很多人都看過。對於每況愈下的沉默是可怕的，不在沉默中爆發，就在沉默中滅亡。不如我來仿寫一下這首詩墓誌銘：\n起初他們打壓“娘炮”，我保持沉默，因為我不是“娘炮”。\n接著，他們打壓明星，我保持沉默，因為我不追星。\n後來，他們審查遊戲，要求遊戲必須拿到版號，我保持沉默，因為我玩的遊戲沒有受到影響。\n此後，他們藉著莫須有的“夏日祭”事件對漫展施壓，我保持沉默，因為我不看漫展。\n最後，他們只允許高唱讚歌，整個民族卻不再容忍其他文化了。\n別再洗白文化審查 Freedom of speech is that you could say anything you want, but it doesn\u0026rsquo;t mean I have to listen to it.\n言論自由的意思是：你可以發表任何你想要發表的言論，但這並不代表我一定要聽。社會文化同理，我們的社會可以有“正能量”的主流文化，但並不代表我們的社會不能有其他文化。畸形的文化審查就是對文化的破壞。在中國，審查並非單純的一種制度，而是一種現象，中國的審查現象是官僚主義、形式主義和沙文主義互相結合的產物。為什麼會有人為這種畸形中的畸形現象洗白？長期只接受單一的文化，人的思想就會愈發偏激，愈發地不能接受其他文化，不能容忍文化多樣性的存在。當一個國家，一個民族不能容忍多樣性時，勢必造成災難性的後果。想想納粹德國是如何發動二戰以及他們在二戰中的各種反人類行為，你就能明白這一點。\n及時行樂。情況雖然不容樂觀，但我們依舊可以掌控當下。與其等待文化被閹割，不如儘早的感受多元文化。前面已經反覆提到，中國的審查現象是一種十分畸形的現象，與其擔驚受怕不斷自我審查，不如趁早、趁更加開放的時候感受文化。不得不說，現今社會在倒退，Totally reversing all the progress we\u0026rsquo;ve made，讓人看不到希望，我們能看到的，只有黑暗，一眼望不到頭的黑暗。\n歷史的車輪滾滾向前？ 剛被歷史的車輪碾過，好不容易爬起身來，卻發現歷史在開倒車。\n我們本應在上世紀80年代迎來一個更加開放的社會，可我們沒有。我們本應在20世紀初加入WTO後逐漸轉型，我們亦在20世紀初呈現了短暫的繁榮，沒有畸形的政治正確，沒有過分的審查，青年一代朝氣蓬勃，躊躇滿志，整個社會呈現出變革的態勢。現在回想起童年時的社會生活，雖然亦有審查，但絕無現在的壓抑之感。我們能明顯的感覺到，當時的社會正在進步，理論上來說，十幾年過去，我們應當迎來一個更為進步、開放的社會。十幾年後的今天，社會卻事與願違，正加劇著偏激與極端。\n最黑暗的時候\u0026hellip; 雖然正在陷入無盡的黑暗，但人們還是努力生活，努力在生活中尋找幸福感。在1940年，也就是第二次世界大戰最激烈，法西斯看上去就要征服世界的時候，人們依然會憧憬戰後的生活。即使生活在絕望裡，人們還是會以這句話安慰自己：\nThe darkest hour is before the dawn.\n最黑暗的時候往往是清晨第一絲曙光前。即使黑暗看上去無盡，但總有一天，它會到頭，即使生活在絕望中，也切莫放棄對生活的信心。在每況愈下，充滿無力感時，這是我們能做且唯一能做到的。\n最後\u0026hellip; 我想看到我們的社會是包容的，而不是越來越偏激，越來越有攻擊性。當然，這也沒那麼容易。社會變革是痛苦的，山雨欲來風滿樓，這是變革前的陣痛嗎？我們究竟何處去？是更加光明，還是更加黑暗？也許現在我不該考慮這個問題，要下雨了，趕緊收衣服去。\n","date":"2022-08-11T11:44:17Z","permalink":"/zh-hant-tw/2022/08/my-thoughts-on-anime-shows-in-china/","title":"在中國，漫展已經失去了靈魂"},{"content":"出於種種原因，Gravatar 在國內的訪問極其不穩定，而 Wordpress 和 Typecho 都使用 Gravatar 作為頭像源，這導致網站的上文章出現評論時，頁面會因為幾個 Gravatar 頭像而一直處於加載狀態。為了解決這個問題，我嘗試自行搭建 Gravatar 鏡像並將其更換到 Wordpress 和 Typecho，徹底而完美的解決了問題，並且水出了一篇文章。\n為什麼不直接關了 Gravatar？一句話：沒有靈魂。Gravatar可能是世界上使用範圍最廣的通用頭像，若是直接關了 Gravatar，評論裡的人就失去了“靈魂”，只剩下一個冷冰冰的人物模具。\n回到正題，想要替換 Gravatar 源，首先你得有一個 Gravatar 源。在一開始的時候，我在網上找了一圈 Gravatar 源，並對它們進行了逐一測試。結果就是發現他們不是太慢就是早已失效，例如網上滿天飛的 V2EX 源 https://cdn.v2ex.com/gravatar/ 在國內就已經被封鎖。於是我決定自行搭建一個 Gravatar 鏡像。\n更新：使用 Cravatar 實際上，Gravatar 有一個完美的本土化方案——Cravatar，Cravatar 的 API 將會按照 Cravatar 頭像 \u0026ndash;\u0026gt; Gravatar 頭像 \u0026ndash;\u0026gt; QQ頭像的順序為用戶匹配頭像。並且，Cravatar 的 API 調用方式與 Gravatar 完全兼容。\n並且，Cravatar 官方也給出了一份簡明的指導：\n你可以很方便的為 WordPress 集成 Cravatar 頭像服務，只需要將以下代碼加入你的插件或主題的 functions.php 裡即可。\nif ( ! function_exists( 'get_cravatar_url' ) ) { /** * 替換 Gravatar 頭像為 Cravatar 頭像 * * Cravatar 是 Gravatar 在中國的完美替代方案，你可以在 https://cravatar.cn 更新你的頭像 */ function get_cravatar_url( $url ) { $sources = array( 'www.gravatar.com', '0.gravatar.com', '1.gravatar.com', '2.gravatar.com', 'secure.gravatar.com', 'cn.gravatar.com', 'gravatar.com', ); return str_replace( $sources, 'cravatar.cn', $url ); } add_filter( 'um_user_avatar_url_filter', 'get_cravatar_url', 1 ); add_filter( 'bp_gravatar_url', 'get_cravatar_url', 1 ); add_filter( 'get_avatar_url', 'get_cravatar_url', 1 ); } if ( ! function_exists( 'set_defaults_for_cravatar' ) ) { /** * 替換 WordPress 討論設置中的默認頭像 */ function set_defaults_for_cravatar( $avatar_defaults ) { $avatar_defaults['gravatar_default'] = 'Cravatar 標誌'; return $avatar_defaults; } add_filter( 'avatar_defaults', 'set_defaults_for_cravatar', 1 ); } if ( ! function_exists( 'set_user_profile_picture_for_cravatar' ) ) { /** * 替換個人資料卡中的頭像上傳地址 */ function set_user_profile_picture_for_cravatar() { return '您可以在 Cravatar 修改您的資料圖片'; } add_filter( 'user_profile_picture_description', 'set_user_profile_picture_for_cravatar', 1 ); }自建Gravatar鏡像：Nginx 反代 Gravatar 官方源 注意：這一部分僅適用於服務器在海外的同學，如果服務器在國內請直接繞道去看後面的部分\n首先聲明，為了方便管理網站，我使用了寶塔面板。在寶塔面板裡使用你想要的域名新建一個網站，純靜態，數據庫和FTP都不需要。完成後，轉到這個網站的設置，找到反向代理選項，新建一個新的反向代理，填入目標 URL 為 https://secure.gravatar.com提交保存即可。到了這一步，嘗試訪問指派給網站的域名，別忘了加上/avatar，如果出現了默認 Gravatar 頭像即代表配置成功。\n配置成功後，除非你想看到 Chrome “不安全”的提示，否則別忘了給剛剛搭建好的鏡像申請一個 SSL 證書。通常情況下直接使用 Let\u0026rsquo;s Encrypt 即可，打開網站的 SSL 選項，用 DNS 驗證的方式申請一個 SSL 證書後開啟強制 HTTPS 即可。到這一步，我們自己的 Gravatar 鏡像就搭建完成了。\n更換博客上的 Gravatar 源為國內可訪問源 Wordpress 對於 Wordpress，Google 上搜索到的相關文章大部分都通過修改主題的functions.php文件，加入如下的函數來實現。\nfunction getV2exAvatar($avatar) { $avatar = str_replace(array(\"www.gravatar.com/avatar\",\"0.gravatar.com/avatar\",\"1.gravatar.com/avatar\",\"2.gravatar.com/avatar\"),\"cdn.v2ex.com/gravatar\",$avatar); return $avatar; } add_filter('get_avatar', 'getV2exAvatar');實測在 MDx 主題上這種方法無效，故使用了另一種方法：打開網站目錄，找到/wp-includes裡的link-templates.php，在這個文件中搜索“gravatar”，大約在這個文件4378行的位置就可以發現 Gravatar 的鏈接，替換鏈接為國內可訪問的鏡像源即可。\n至於插件，暫時沒有找到還在更新且能完美實現這個功能的插件，如果有歡迎評論。\nTypecho 對於 Typecho，方法與 Wordpress 大同小異，找到網站根目錄，打開/var/Typecho/目錄下的Common.php文件。大約在 836 行左右的地方可以找到 Gravatar 官方源的地址，替換為國內可訪問源即可。\n不過，某些 Typecho 主題可能不會調用 Typecho 的模板函數，而是使用主題內的函數，這時需要對主題文件作額外的修改。回到網站根目錄，打開/usr/themes/下你的主題根目錄，主題獲取 Gravatar 的相關代碼一般在comments.php裡，打開comments.php搜索\u0026quot;avatar\u0026quot; 找到 Gravatar 官方源的地址替換為國內可訪問源即可。\n推薦的Gravatar源 目前只推薦自建源和七牛雲源，後續可能會尋找新源，如果有歡迎評論。\nhttps://gravatar.l3zc.com\t#自建源，已停用 https://dn-qiniu-avatar.qbox.me/avatar/\t#七牛雲源，很快，推薦需要注意的是 你可能已經注意到，在 Typecho 自帶的模版函數里，調用 Gravatar 源時不需要加/avatar，這是因為 Typecho 自帶的函數里已經自動為之加上。同理，有的源調用avatar的路徑可能是/gravatar，應用到網站上時需要做出相應的修改。\n","date":"2022-07-23T22:26:34Z","permalink":"/zh-hant-tw/2022/07/replace-gravatar-source-on-my-blog/","title":"替換Wordpress和Typecho的Gravatar源為國內源實現國內加載Gravatar"},{"content":"我愛城市，但不是我現在所居住的這個片區。冷冰冰的高樓大廈摻入煙火氣，若即若離的人情味，這才是我心目中理想的城市該有的樣子。我愛這些光鮮亮麗的大樓，更愛這無情與有情的反差——當冷冰冰的技術將 What makes us human 一點一點的剝奪時，那些讓人是人的元素顯得愈發可貴和美麗。\n是的，我說的就是賽博朋克。高技術，低生活，以及由此衍生的人們之間的聯繫。現在的我們正生活在賽博朋克的城市裡，與未來只不過是程度的高低。當人們需要靠著生活中的“小確幸”來獲得一點幸福，眾人就已經淪為行屍走肉，在大多數時間，狀態與機器並無差別。飆車、泡吧……你可以在大都市活的很痛快，卻很難在大都市活的幸福。技術的發展讓人們活的更痛快，卻在某種程度上剝奪了人們活的幸福的權利。\n城市的核心，是人。我望著我周圍的一片光鮮亮麗的鋼筋水泥森林，以及鋼筋水泥下那些為了蠅頭小利而破口大罵的人們，我真的感到呼吸困難。\n城市的核心是文化，是人，而非嶄新卻散發著有害化學味道的鋼筋水泥森林。\n高樓林立，光鮮亮麗卻鮮有人跡的城市是可怕的。\n我所在的這個片區，甚至可以稱得上光鮮亮麗,可生活在這裡的人們大都疲於奔命。我希望感受城市的美好，卻只能在這浮躁裡迷失漂流。我們何去何從？\n我真的生活在真實的世界嗎？還是一直被周圍的幻象欺騙？當 AI 能夠 24 小時比真人更加卓越的滿足你的一切情感需求，真人還有存在的意義嗎？當人們完全依賴 AI 提供給我們的便利和情感的滿足，當真實不再能帶給我們快樂，當我們的一切需求都由別人說了算，由巨頭公司，威權政府控制，說斷就斷？真的到了那時，我們怎麼拯救自我？\n我們在科技上越來越強大，富有，在精神上，甚至在物質上都變得越發荒蕪。\n","date":"2022-07-20T20:26:24Z","permalink":"/zh-hant-tw/2022/07/when-we-are-closer-to-cyberpunk/","title":"當我們愈發接近賽博朋克"},{"content":"眾所周知，我閒的蛋疼為了對比不同的博客系統並找出最適合我的那一個，我的博客設立了三個版本，一個是 Hexo、一個 是Typecho、一個是Wordpress。這三個版本的博客各有特點，寫作和發佈文章的方式是各有千秋，功能的多少和輕重也互不相同。因此，儘可能的減少文章“移植”到不同的博客系統的工作量成為了剛需。\n用 Markdown 寫作 自從第一次使用 Hexo 搭建博客而第一次使用 Markdown 寫作以來，我的寫作變從未離開過 Markdown。不光不需要考慮排版的問題，不需要時不時就操作一下鼠標的感覺體驗過了就真的離不開。再者，我還在使用 Hexo 作為我的一套博客框架，必須使用 Markdown 寫作，寫好的 Markdown 直接發佈在 Hexo 博客上，不需要任何的二次修改。因此，肯定是用 Markdown 寫作了。在確定了寫作的主題後，我會用 Hexo 生成一個 Markdown 文件。\n之後，我會使用 Typora 編輯這份 Markdown 文件，寫好文章。\n發佈到 Hexo 文章寫好以後，下面就是刻進骨子裡的操作:\ncd blog hexo g export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890 hexo d直接將文章發佈到 Hexo 博客。為什麼在有了 Typecho 以後我還是在使用看上去不那麼方便的 Hexo？就像 Markdown，只要配置得當，Hexo 對 Markdown （Github Flavoured Markdown）近乎完美的支持可以讓我更專注於寫博客本身，不需要考慮任何關於格式方面的問題。\n發佈到 Typecho 現在還是相對簡單的部分。Typecho 雖然支持 Markdown，但對於 Github Flavoured Markdown 支持的程度顯然沒有 Hexo 好，例如- [x]在使用 Hexo 時就可以正確渲染，但 Typecho 就不能識別。這時我們便不得不用 HTML 替換掉原本的 Markdown 代碼。\n這裡我使用了 Markdown 要是你在黑土地看這篇文章，你可能會發現上面的 Checkbox 並沒有被正確渲染，如果直接以 HTML 代碼替換掉這個 Checkbox，顯示的效果如下：\n這裡我使用了 HTML 替換好以後文章方可正常顯示。\n發佈到 Wordpress Wordpress 的編輯器真的是個大麻煩。不光默認沒有代碼高亮，也是個連 Markdown 都不支持的東西。不過好在 Wordpress 的編輯器支持插入自定義的 HTML 內容。經過簡單的嘗試，在將 Markdown 文章轉換成 HTML 格式直接粘貼在 Wordpress 的 HTML 內容編輯器後切換回可視化編輯器會直接變為 Wordpress 經典編輯器，這使得我想要進一步編輯文章添加一些 Wordpress 特有的區塊時很不方便。所以，在 Typora 裡直接複製文章粘貼到 Wordpress 的默認編輯器裡，隨後更改渲染錯誤的地方替換為自定義 HTML 代碼塊。\n對 Typecho 和 Wordpress 的小修小補 你可能會注意到，我寫文章的時候時常需要添加代碼塊和 Mermaid 流程圖，hexo-theme-cactus自帶代碼高亮，而我又通過修改主題加入了mermaid.js，但 Typecho 和 Wordpress 默認都無上述兩個功能。為了儘可能的減少文章“移植”到不同的博客系統的工作量，我對這倆貨進行了一些小修小補。\nWordpress 我採用的 Wordpress 主題是 MDx，並不帶有代碼高亮功能，因此我使用了 enlighter.js 官方提供的 Wordpress 插件。安裝這個插件後，Wordpress 編輯器裡會多出一種名叫 Enlighter 的區塊，使用它作為代碼的載體即可實現代碼高亮的功能。這款插件提供的自定義樣式選項不足，這個區塊本身的樣式又過於稜角分明，與 MDx 圓潤的邊角格格不入。好在這款插件的 CSS 文件能夠被找到，只要學過 CSS ，修改出一個圓潤的邊角也不是什麼難事。\n打開博客的安裝目錄，找到/wp-content/plugins/enlighter/resources/enlighterjs裡的enlightenjs.min.css文件，編輯這個文件，找到其中的enlighter-default類，修改padding參數為10px，添加border-radius參數為10px後保存，就可以得到一個圓潤的高亮代碼塊。\n說到 Mermaid，雖然 Wordpress 原生不自帶 Mermaid，但只要裝一個插件就能實現支持 Mermaid 流程圖，直接在 Wordpress 的應用商店裡搜索 Mermaid 即可。\nTypecho 我採用的 Typecho 主題是 Story，代碼高亮功能是自帶的，但很遺憾，Typecho 並不支持 Mermaid，同時我似乎沒有找到為Typecho 添加 Mermaid 的插件。這意味著我們只能自己去添加這個功能。\n給我等著，我先去學一會 PHP，這事沒完！\n","date":"2022-07-12T14:34:06Z","permalink":"/zh-hant-tw/2022/07/my-blog-workflow/","title":"同時發佈三個版本的站點？我的博客工作流及對每個版本的優化方案"},{"content":"從安卓手機換到 iPhone 就想要改掉清理後臺的習慣，查閱了一些資料，知道 iOS 後臺機制不需要用戶介入，在使用中也實行了這一點，奈何心裡總有幽靈作祟，總是會感覺到不清理後臺續航會降低，手機會發熱，進而管不住清後臺的手。\nLet me be as clear as I can be: the iOS multitasking bar does not contain \u0026ldquo;a list of all running apps\u0026rdquo;. It contains \u0026ldquo;a list of recently used apps\u0026rdquo;. The user never has to manage background tasks on iOS.\nFraser Speirs\n在網上搜索到的大部分中文內容會引用 Fraser Speirs 在他的一篇博客裡很明確的指出的內容：iOS 的 Multitasking bar 實際上是 A list of recently used apps，所以，你不需要清理後臺。但當我順藤摸瓜找到這篇博客的原文時，卻發現這篇博客發表時間在 2012 年。10 年過去了，這篇文章的內容自然是經不住滄海桑田，早已過時，情況早已發生了微妙的變化，蘋果早就加入了各式各樣的後臺機制。這就衍生出了兩個問題，蘋果的後臺機制是否真的會影響 iPhone 的續航和發熱？殺後臺是否有助於提升使用體驗？\n有趣的是，作者在某個時候關閉並存檔了他的博客，在他的存檔裡卻並未出現這篇文章，這意味著作者可能刻意刪除了它。既然這種流傳已久的說法是基於一篇早已過時的文章，結果自然是不可信的，根據這篇文章得出結論，是一個不負責任的營銷號行為，我能做的唯有查找更新的資料以及親身實踐。\n查找資料 Some apps perform work for a short time while in the foreground and must continue uninterrupted if they go to the background. Other apps defer that work to perform in the background at a later time or even at night while the device charges. And some apps need background processing time at varied and unpredictable times, such as when an external event or message arrives.\nApple Developer Docs\n蘋果不會也不能一刀切死後臺，相反，針對不同應用對後臺運行的需求，蘋果舉了五種場景的例子。\nContinue Foreground Work in the Background\nDefer Intensive Work\nUpdate Your App’s Content\nWake Your App with a Background Push\nRequest Background Time and Notify the User\n為了用戶體驗，蘋果對應用的後臺限制非常嚴格。針對這五種場景，蘋果設計了多樣且易於使用的 API 來滿足不同的需求，在默認情況下，當一個 App 進入後臺時，系統會給 App 最多5秒的時間來進行回寫數據等操作，隨後系統便會將這個 App 掛起（Suspend），5秒的時間對於大多數 App 來說已經足夠。當 App 需要在後臺完成更多操作時，可以參照蘋果給出的 5種場景設計 App 的後臺策略。例如：一個新聞類 App 可以在收到新聞時被系統喚醒到後臺接收這則新聞，調用application(_:didReceiveRemoteNotification:fetchCompletionHandler:)，App 便可以取得至多 30 秒的時間完成接收新聞的操作。同時，App 完成操作後必須要調用endBackgroundTask(_:) 以告知系統自己完成了操作。否則在超過30秒後，系統便會殺死（Kill） App 的進程。得益於 AppStore 嚴格的審核，上架的 App 基本都經過了規範的編寫。\n又例如：某網盤需要備份用戶今天新拍攝的照片，這是一個密集且工作量大的工作（不知道怎麼翻譯，原文是 Intensive Works），那麼調用BGProcessingTask以計劃一個備份工作，系統會自動根據用戶充電的時段、睡覺的時段等信息訓練出來的模型自動選擇最佳的時段來執行計劃好的 Intensive Works。\nSchedule these types of background tasks using BGProcessingTask, and the system decides the best time to launch your background task.\n如你所見，得益於蘋果給開發者提供的一套強大易用的 API 以及 AppStore 對於應用在上架前嚴格的審核，iOS 的後臺機制在保持對應用嚴格限制的情況下卻沒有增加開發難度，在開發文檔裡，出現的最頻繁的一句話是。\nThe system decides the best time to launch your task.\n蘋果將自己用心開發的優質 API 提供給開發者，這些 API 看似簡單，實則需要有大量的技術沉澱，看似簡單的“選擇最佳時間”，背後卻充斥著大量的機器學習算法，既然開發者直接調用現成優質的 API 就能將用戶體驗提升幾個層級，那麼何樂而不為呢？在同一個開發者付出相同的工作量的情況下，開發 iPhone App 能夠實現同功能 Andriod App 高出幾個層次的質量，這也難怪早期 iPhone 在搶佔市場份額時，App Store 能夠在審核如此嚴格，抽成如此高的情況下湧現大量優質應用。AppStore 裡應用調用後臺的規範程度也就不必多言了。完全可以像谷歌一樣用1倍的努力把體驗做到90分，卻還是要花10倍的努力把體驗做到極致，這很蘋果。\n殺後臺是否有助於提升使用體驗？ 我們已經知曉蘋果的後臺機制是十分智能的，可後臺機制再智能也依舊有失靈的時候。這就是第二個問題，殺後臺是否有助於提升使用體驗？\n可以說，除了能讓心裡更好受，以及可能在這幾個咖喱味十足的iOS版本提升滑動桌面的順滑度以外，殺後臺無助於提升使用體驗，甚至會降低使用體驗。\n滑動關閉後臺應用程序可能會降低iPhone的續航時間，除非是無響應的情況，否則不應該強制關閉應用。\nCraig Federighi\n當應用程序被從“後臺”劃掉，其會被移出RAM，這樣，應用程序將不會再運行。按照蘋果的邏輯，前面所提到的一系列智能的後臺機制都不會運作。不僅如此，重新從閃存載入APP會增加電量的消耗且徒增發熱，比從直接從RAM“解凍”APP更加費時。這麼一看，Craig說的是不是很有道理？是的，在Craig所處的環境裡，這句話絕對可以稱得上是“金玉良言”。\n可惜在中國，情況有些許不同。第一種情況是流氓應用，以中國第一產品經理的微信為例，在之前很長一段時間裡（可能現在也是）微信會通過某種手段儘可能延長自己的後臺存活時間，甚至於後臺活動超過前臺使用的時間。這自然會使耗電量增加。從後臺列表，準確的說，是最近使用的應用列表強行殺掉微信，的確可以避免這種情況的發生。但微信在國內的地位不必我多說，從後臺劃掉微信會大幅增加微信的啟動時長，每次打開微信看到“連接中……收取中”轉圈轉個老半天可比耗電更煩人。再者，沒有人會希望為了省電而錯過女朋友或者上司只打一次的微信電話。這種時候，停用微信的後臺刷新可能是一個更好的選擇。\n類似的情況發生在國內被牆的服務上，在沒有代理的情況下，除非開發者專門對此作過優化，國內被封鎖的服務、應用會出現一個較為尷尬的問題：按照計劃，這些應用需要更新內容，但因遭到GFW的封鎖，一直收不到服務器的回應，於是一直運行，直到觸發系統的時間限制。前面已經提到過，這種情況下，APP會被系統“殺死”。對於第二種情況，解決方法有二：一是做好分流，24小時掛代理。二是和微信一樣，停用這些應用的後臺刷新。但無論如何，不要從後臺直接殺死這些應用，因為直接殺死這些應用造成的體驗遠比耗電更糟。\n寫個總結 在寫這篇文章時，我發現，越是寫下去，越是背離了寫這篇文章的初衷，即“提升使用體驗”。技術為人文服務，智能手機歸根結底只是我們手邊的一個工具，與其費盡心機省電，不如按照自己覺得舒服的方式使用手機。耗電也好，卡頓也好，都由技術的進步解決。我們可以因興趣使然研究這些技術問題，但絕不能讓這些技術問題成為我們生活的全部，放下手機，放下這些技術問題，我們還有很多更有意義的事可以做，很多人可以聚，很多地方可以去玩。\n參考 Choosing Background Strategies for Your App\nBackground Tasks\nbeginBackgroundTask(withName:expirationHandler:)\nExtending Your App\u0026rsquo;s Background Execution Time WWDC2019: Advances in App Background Execution\nDo iOS apps run in the background?\nMisconceptions About iOS Multitasking\niOS Multitasking Misconception\n題圖來自：https://www.macworld.com/article/667789/iphone-xs-review.html\n","date":"2022-07-09T14:55:10Z","image":"/2022/07/do-i-need-to-force-kill-apps-on-iphone/20231011110457_hu_866faa8542cee1fa.webp","permalink":"/zh-hant-tw/2022/07/do-i-need-to-force-kill-apps-on-iphone/","title":"我需要清理iPhone的“後臺”嗎？在2022年看iPhone的後臺機制"},{"content":"最近拿到了 Azure 的學生服務器，Hexo 缺少好看而功能完備的主題，於是我開始籌建我的動態博客網站。我將分別使用我所提到的博客系統一段時間，看哪一個更適合。\n我不想把這篇文章寫成維基百科，所以我儘量的只講我的體驗和理解，你可以很容易的在網上查到這些博客框架的相關資料。\nHexo 優點 直接生成靜態網站，輕便，穩定，快速 原生支持Markdown 方便託管，可以託管在如Github Pages等平臺上節省服務器費用 缺點 靜態網站沒有後臺，不方便管理 很難實現跨設備編輯，除非部署Github自動化等 插入圖片比較困難，需要配合圖床和如Pic Go等軟件進行 對新手不友好，實際使用過程中改改主題的源碼實現某些功能是難免的事 樣例：L3ZC主站\nHexo是一個基於Node.js的靜態博客框架，這個就不消說了，光從它35k的stars就可以知道大家有多喜愛這個框架。\nHexo直接生成靜態網站，這意味著無比快速。原生支持Markdown，配合一個簡潔的Markdown編輯器如Typora，可以讓你集中精力到內容本身，這毫無疑問可以提高寫文章的效率。只有靜態網站可以被託管到Github Pages上，這也就是為什麼我當初選擇了Hexo作為自己博客的博客框架，而後為了迎合Hexo，我開始用Markdown寫作，做了自己的圖床，試著修改Hexo主題，即使我還沒開始學Java Script。自從用上了Hexo，我愛上了用Markdown寫作，以至於後面切回Wordpress的古騰堡編輯器的時候我都很不適應。\nHexo 自身的特性決定了它新手不友好，他沒有原生的評論系統，實現一個功能要對主題的源碼進行改動，這可不是人人都會並且願意的，新手很容易過分糾結網站的外觀和功能而忽略了內容本身。Markdown 難以插入圖片，需要額外建立圖床，這也是相對麻煩的事情。Hexo 沒有後臺，只能通過命令行生成網站，這就意味著你別想在移動設備上編輯文章，也不能在兩臺電腦之間交替編輯（當然如果配合堅果雲等那另說）。\n即使有這些缺點，Hexo 依然是一個優秀的博客框架，即使用上了動態博客框架， 我也依然不會放棄使用 Hexo 寫作。\nTypecho 優點 小巧快速 原生支持Markdown 提供了友好的圖片插入功能，當然你也可以用圖床 缺點 新手不友好，雖然比Hexo已經好很多 移動設備不好編輯文章 樣例：L3ZCの黑土地\n對於個人博客用途的網站，個人認為 Typecho 是一個相對理想的選擇，不像 Wordpress 那麼重，也不像 Hexo 那麼折騰，並且原生支持 Markdown 。\nTypecho 是動態博客框架，有原生的後臺和評論系統，不像 Hexo 這種靜態博客框架想要實現評論功能都要修改主題源碼，原生支持 Markdown 讓 Typecho 用起來非常舒服，如果計劃從 Hexo 遷移到 Typecho，絕對無需擔心出現不適應的情況，我完全可以像在 Hexo 寫博客一樣，在 Typora 裡寫好文章，然後直接複製粘貼到 Typecho 的文章編輯頁面，設置好文章標題和標籤等直接點擊發布，大功告成。如果是第一次使用 Typecho，也大可不必擔心圖床的問題，Typecho支持上傳附件，足以讓你在完全不用任何圖床的情況下寫出一篇圖文並茂的文章。嫌默認主題不好看？可以去網上找一找 Typecho 的主題，基本都可以找到自己想要的主題，爛大街的 Handsome 就是一個很好的例子。\n對於個人博客來說 Typecho 幾乎完美，但也不是沒有任何問題，例如，新手必須要學習怎麼寫 Markdown。移動設備不好編輯文章等等。總之Typecho 是一個比較適合我的博客框架。\nWordpress 優點 界面好懂，新手友好 後臺管理很容易，只要能上網，很容易就可以在任何時間地點用任何設備更新網站 用戶基數大，主題、插件豐富，實現某個功能很容易 缺點 不原生支持Markdown 出了名的重，速度相對比較慢，佔用服務器資源 樣例：L3ZCの試驗田\n全世界 30% 的網站都在使用 Wordpress，這可不是吹的。Wordpress 的功能有多豐富可想而知。\n這些 Wordpress 網站不光包括博客網站，還有論壇，甚至電子商務網站，你沒看錯，Wordpress 就是能實現很多功能。也更容易實現華麗的效果，如果你的網站有這種需求，那麼 Wordpress 是個不錯的選擇。Wordpress 對新手很友好，從部署網站開始，不僅可以直接使用 Wordpress 官方提供的託管服務，得益於 Wordpress 龐大的用戶基數，很多服務器提供商更是直接提供了一鍵部署 Wordpress 到服務器的功能。部署完成開始寫作，Wordpress 的編輯器直觀好懂，很容易就能上手寫出圖文並茂的文章。Wordpress 有功能豐富的後臺，很容易就能完成博客的管理，即使在手機上也是如此。用戶多就是任性，主題和插件多的挑不過來，直觀好用。\n當然，缺點也很明顯，Wordpress 非常臃腫，速度會相對較慢，在服務器性能低和網絡差的環境下則更明顯。其次是不原生支持Markdown這一點讓我非常惱火，在Typora裡寫好的文章複製粘貼到 Wordpress 的編輯器裡大概率需要重新排版，這也導致我很不願意在 Wordpress 上多發表文章，排版這種基礎的東西都需要花費精力，自然就沒法好好寫文章了。\nBlogger 先用一段時間再說。\n","date":"2022-07-04T17:28:43Z","permalink":"/zh-hant-tw/2022/07/comparison-of-different-blog-systems/","title":"Wordpress？Typecho？還是Hexo？哪個博客系統適合我？"},{"content":"我成功薅到羊毛，拿到了Azure的學生贈送額度，重新擁有了VPS，當前的博客是基於Hexo構建，靜態網站的侷限性讓我考慮了設立動態網站的可能。\n什麼？Azure有學生免費羊毛？ 這些天我一直在尋找一個適合我的虛擬服務器，我只是想搭建一個網站而已，我是學生，無法承受每月動輒一兩百配置卻低的可憐的正價服務器，看到Azure有羊毛可以薅那真是再好不過了。Azure有兩種試用方式，第一種贈送200美刀，但需要信用卡，我一學生怎麼可能有Visa卡？第二種方式贈送100美刀，只需要學生郵箱賬戶，既然只需要建站，100刀用一年其實不成問題，實際使用基本感覺不到很大的差異。\n先打開Azure學生免費申請入口，點擊免費開始使用，填入你的教育郵箱賬號（支持中國大陸的教育郵箱賬號，良心），收郵件驗證一下，你的免費額度就可以領到了。什麼？學校沒有給你教育郵箱？自己去要，什麼東西都要塞你手上嗎？據這個頁面上的介紹，每年100刀用完以後，如果你仍然是學生，可以再次申請到100刀的額度。如果這句話是真的，不出意外，那麼學生時代就不需要額外為雲服務器付費，想想就很香。\n這服務器怎麼樣呢？ 真要我說的話，一般。\n在中國大陸，開 Azure 服務器一般會選擇 South East Asia（新加坡）或者 East Asia（香港）兩個數據中心。這兩個數據中心卻沒有一個為大陸的網絡環境做過優化（雖然這也不能怪人家），簡單說，聯通連香港數據中心會繞路新加坡，電信連新加坡數據中心會繞路香港，移動則都會繞路東京，想要一個數據中心三大運營商的寬帶都不繞路約等於做夢。\n更坑爹的是，新加坡數據中心因為這個原因常年爆滿根本開不到服務器。大部分時候只能選擇香港數據中心，我也不例外。不過他們的服務器的網速倒是挺快，萬兆網用來從Github上Clone之類的挺舒服，聽我一句勸，不要跑測速，一跑就是一美刀（哭死）。\n順帶一提，上下行不對等那肯定是沒有獨立 IP 流媒體解鎖就別想了。因為在用別的上網方案，所以暫時沒有用這玩意來科學上網，過一陣子可能會裝上不同的協議測個速。另外服務器跑分什麼的有時間就弄。\n回到正題 終於要說我的兩個新動態網站了。本站新增了兩個動態網站，分別是基於 Wordpress 的L3ZCの試驗田和基於 Typecho 的L3ZCの黑土地，加上基於 Hexo 的L3ZC主站，三者並行。\n其中，試驗田是全新的網站，主要發佈技術類文章，日後可能會做出頻繁的改動；黑土地則追求穩定與快速，並且與主站保持一致的樣式，在時機成熟的時候可能會與主站的角色互換；主站是基於Hexo構建的靜態網站，託管在 Github 上，長期穩定存在。\ngraph TB A[發佈文章] --全部--\u003e B[主站] B -- 技術類 --\u003e C[試驗田] B -- 所有 --\u003e D[黑土地]To Do List 有一大堆要做的事，例如修好黑土地的評論系統，做好SEO等。總之，有得忙活了。\n","date":"2022-06-28T22:41:07Z","permalink":"/zh-hant-tw/2022/06/new-site-on-azure/","title":"在拿到了Azure的學生免費額度以後，我增設了兩個新站點"},{"content":"室友天天開黑，這就算了，還老是用外放，不得已，只能讓他們打不爽，從根本上阻止他們開黑，還我寢室一個安靜的環境，至少，讓他們按時睡覺。\n寢室的網絡環境 路由器 一臺撿垃圾的小米CR6608，刷入了 OpenWRT ，承擔我們寢室所有的網絡流量，由於是一所垃圾大學，校園網限制一套餐一終端，寢室裡又只有一個網絡口，大家都用我的套餐，整個寢室的網絡控制權當然在我的手上。\n室友上網的設備 其餘三個室友都打英雄聯盟，其中兩個使用筆記本，一個是臺式機，沒有無線網卡，而且臺式機恰巧是打的最兇的那位。\n決定採用的方案 首先，肯定不能徹底阻斷寢室網絡與英雄聯盟服務器的連接，這樣明顯感知太強，容易被發現，其次由於另外兩個室友都是筆記本電腦，發現丟包率太高肯定會開熱點換移動網絡，所以最終的方案確定為模仿GFW對網站隨機丟包的干擾模式。\n具體行動 首先先給每個室友分配靜態的IP地址，原因看到後面你就知道了。\n上網查找資料，可以知道英雄聯盟所使用的端口:\n項目 端口號 League of Legends Game Client 5000 - 5500 UDP Patcher and Maestro 8393 - 8400 TCP PVP.Net 2099 TCP PVP.Net 5223 TCP PVP.Net 5222 TCP HTTP Connections 80 TCP HTTPS Connections 443 TCP Spectator Mode 8088 UDP and TCP 向路由器的iptables裡添加以下隨機丟包的規則：\n# Block LOL iptables -I FORWARD -p udp --dport 5000:5500 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 8393:8400 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 2099 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 5223 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 5222 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 5233 -m statistic --mode random --probability 0.3 -j DROP iptables -I FORWARD -p tcp --dport 8088 -m statistic --mode random --probability 0.3 -j DROP關於如何在 OpenWRT 上自定義 iptables 規則，有兩種方法，第一種方法，打開 系統 -\u0026gt; TTYD終端 將上面的命令一行一行復制進去回車，用這種方法，規則會在路由器重啟或者 iptables 重啟後失效，第二種方法，打開 網絡 -\u0026gt; 防火牆 找到 自定義規則 選項卡，將上述內容粘貼到這個頁面已有內容的後面，注意不要覆蓋文本框裡原先的內容，完成後點擊頁面下方的 保存並應用，這樣即使是重啟路由器也不會重置 iptables 規則。\n這些 iptables 規則用到了 ipopt 模塊，而一些固件不會默認安裝 ipopt 模塊，如果發現 iptables 對這些規則報錯，請看後文的安裝 ipopt 部分。\n生效後，室友打英雄聯盟就會在校園網本就1%到5%丟包率的基礎上增加30%的丟包率。經過室友的盲測反饋（我怎麼可能會讓室友知情呢？！）放技能總是放不出去，打的非常不爽。\n但是這種方法似乎不適用於室友開加速器的情況，所以我們可以針對這種情況直接限制室友所有的流量，也就是說，不論室友的電腦發出什麼數據包，都能享受到30%的丟包率，除非室友開熱點，當然臺式機是不可能的，這種方法就可以讓所有的加速器都失效。前提是，室友的ip地址必須要提前確定，這也就是為什麼需要提前給室友的電腦分配靜態IP。\n向路由器的iptables裡添加以下規則\n# Block specific roommate iptables -I FORWARD -s 你室友的內網ip -m statistic --mode random --probability 0.3 -j DROP # 以此類推即可“照顧”室友所有的流量。\n很好，現在每天11點我都會準時更新防火牆規則，至少讓寢室安靜一點。\n授人以魚不如授人以漁 這些參數都是些什麼？\niptables iptables是運行在用戶空間的應用軟件，通過控制Linux內核netfilter模塊，來管理網絡數據包的處理和轉發。\n——維基百科\n簡單點說：iptables是Linux的防火牆軟件，可以通過設定的規則過濾掉特定的數據包達到防火牆的目的。OpenWRT基於Linux，自然也用iptables作為防火牆。\n-I FORWARD iptables有所謂的“五鏈”和“四表”。\n“五鏈”是指 netfilter 定義的 5 個規則鏈。每個規則表中包含多個數據鏈：INPUT（入站數據鏈）、OUTPUT（出站數據鏈）、FORWARD（轉發數據鏈）、PREROUTING（路由前數據鏈）和POSTROUTING（路由後數據鏈），防火牆規則存儲在這些數據鏈裡。\n“五鏈”的結構如下：\ngraph LR A[PREROUTING] --\u003e B[路由決策] B --\u003e C[FORWARD] B --\u003e D[INPUT] D --\u003e E[Local Process] E \u0026 C --\u003e F[POSTROUTING]四表分別是：\nfilter：過濾整個數據包，在 INPUT、FORWARD 和 OUTPUT 鏈可用 nat：控制數據包的地址轉換，在 PREROUTING 、INPUT、OUTPUT 和 POSTROUTING 鏈可用 mangle：修改過濾數據包中的原數據，在 PREROUTING、INPUT、OUTPUT、FORWARD 和 POSTROUTING 鏈可用 raw：控制 nat 表連接追蹤機制的啟用與否，在 PREROUTING、OUTPUT 鏈可用 路由器的功能是轉發數據，這些數據顯然經過 FORWARD 鏈，故規則都在 FORWARD 鏈上添加。在 iptables 上使用 -I 參數插入規則時，默認會插入 filter 表，也就是我們需要的表。\n-p xxx \u0026ndash;dport xxxx 使用 iptables 時，-p 參數用於指定規則適用的協議，\u0026ndash;dport，即destination port的縮寫，支持範圍匹配，可以匹配數據包所去往的端口，這裡參照英雄聯盟所使用的端口和與之對應的協議一一阻止。\n-m statistic \u0026ndash;mode random \u0026ndash;probability 0.3 這些都是自定義的 丟包參數，可以實現很多其他的功能，因為iptables功能太多，故這裡不做贅述，感興趣的話可以自行查閱iptables相關的教程。\n-j DROP iptables 可以對符合規則條件的數據包做多種處理：\nACCEPT：允許數據包通過 DROP：丟棄數據包 REJECT：拒絕數據包通過 LOG：記錄日誌 DNAT：目標地址NAT SNAT：源地址NAT MASQUERADE：地址欺騙 REDIRECT：重定向 需要隨機丟棄數據包，自然是選擇DROP。\n特定時間自動添加/刪除丟包規則 在路由器的 Crontab 裡添加如下規則\n#Automatic Block 0 0 23 * * ? iptables -I FORWARD -p udp --dport 5000:5500 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 8393:8400 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 2099 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 5223 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 5222 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 5233 -m statistic --mode random --probability 0.3 -j DROP 0 0 23 * * ? iptables -I FORWARD -p tcp --dport 8088 -m statistic --mode random --probability 0.3 -j DROP #Automatic unblock 0 0 7 * * ? iptables iptables -D FORWARD -p udp --dport 5000:5500 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 8393:8400 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 2099 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 5223 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 5222 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 5233 -m statistic --mode random --probability 0.3 -j DROP 0 0 7 * * ? iptables -D FORWARD -p tcp --dport 8088 -m statistic --mode random --probability 0.3 -j DROP即可實現每天晚上11點自動添加丟包規則，每天早晨7點自動刪除丟包規則。\n補充：安裝 ipopt 模塊 部分固件可能存在沒有ipopt模塊的問題，而這些規則大部分都使用到了這個模塊，這種情況下需要手動安裝。\nipopt 的安裝有兩個選擇，一般出於穩定性考慮會安裝用戶層的iptables-mod-ipopt，而內核級的kmod-ipt-ipopt則在設備 CPU 性能孱弱或存儲空間不夠用的情況下選擇。\n內核級的模塊一般需要預先編譯固件才能安裝，而用戶層只需執行以下opkg命令即可：\nopkg install iptables-mod-ipopt後期計劃 後續可能會寫一個每天指定時間自動添加，自動刪除iptables規則的腳本，實現應該相對容易。最近要期末考試，備考要緊。\n其次可能會補充iptables的常用功能解說。\n","date":"2022-06-26T23:34:25Z","permalink":"/zh-hant-tw/2022/06/use-iptables-to-ban-lol-in-dorm/","title":"在OpenWRT路由器上使用iptables對英雄聯盟隨機丟包"},{"content":"生活相對有規律，比較自律，早睡早起，鍛鍊身體，甚至每天絕大部分上網時間都沒有花在遊戲上，可能這就是你的樣子，人們根本就不會覺得這種人會和網癮扯上關係。很多情況下，事情並非如此。\n我到底是怎麼了？ “癮”這個詞，並不形容短期心理狀態，而形容長期大腦的變化。你絕對在某一時刻體驗過短時間內多巴胺爆棚的快感，並且從此喜歡上了這個狀態，這並不是上癮，僅僅是喜歡。更進一步，你可能並沒有察覺到你的大腦里正在發生的某些事情，成癮的過程無法被大腦察覺，你的大腦可能在嚐到這種快感以後發生了微妙的變化，產生了對這種狀態的依賴，這時才算是真的成癮。\n既然成癮無法被大腦察覺，如果不去刻意感知，絕不會知道自己正在上癮。自很早以前，在打開 YouTube、Twitter 等網站時即使知道自己正在虛度光陰，即使屏幕上的內容毫無樂趣也於我無用，我也還是會繼續看下去，並且不知不覺的看掉一個下午。在逛 AppStore 的時候，通常都是為了用一個 App 而用一個 App，即使不需要用到這個 App，我也會下載下來，摸索許久。在找資源、信息的時候，即使我用不到這個資源、信息，我也會不斷收集。即使還有更要緊的事要做，即使這對我無意義甚至有害，我卻無法停下。\n這算生病嗎？ 大腦傾向於尋找更多的多巴胺，自然也想要重複獲得多巴胺的體驗。物極必反，太多的多巴胺亦不是一件好事，人類進化出一套平衡機制：當你獲得太多的多巴胺時，大腦就會產生與多巴胺作用相反的物質來平衡。飛的越高，摔得越慘，放在這裡簡直再也合適不過，大腦體驗多巴胺爆棚的極樂之後，會立刻陷入生與多巴胺作用相反的物質所帶來的痛苦反噬的深淵。這種感覺實在是太過於痛苦，大腦傾向於找到更多的多巴胺來平衡痛苦反噬，卻又引發更多的痛苦反噬，從而陷入惡性循環。\ngraph LR A[想要獲得多巴胺] --\u003e B[獲得多巴胺] B --\u003e C[產生痛苦反噬] C --\u003e D[痛苦] D --\u003e A這就是上癮，一個無法掙脫的泥潭。其實任何東西成癮都可以算作是生病，就像吸毒一樣，即使你已深知吸毒的危害，即使毒品讓你的身體承受很大的痛苦反噬，你也還是想要吸毒，因為那裡有大腦迫切需要的多巴胺。得不到多巴胺的痛苦遠甚於做這件讓你獲得多巴胺的事所帶來的痛苦。\n人們從來沒有認真思考過這種現象是否是病，從某種意義上來說，這已經算是生病了。\n還是接著開頭說 我曾經把大把的時間花在上網上，看上去，我在學習。表面上，陷入這惡性循環的人看上去會很健康，包括生活方式。他們可能看起來在努力的工作，努力學習。他們自己也不知道自己已經患病。注意區分，兩種人很容易混淆，一種是大腦已經因為長期食用 Dopamine snacks 發生變化，一種則是純粹的追求舒適的感覺，大腦沒有變化。這裡所討論的人屬於第一種。\n從書籍到文章，從文章到博客，從博客到微博客，從微博客到視頻，再從視頻到短視頻，網絡連接的速度越來越快，人們接受信息的媒介卻變得越來越浮躁，每當學到一些新的東西，人類的大腦就會產生多巴胺獎勵自己，信息媒介的不斷進步把獲得多巴胺的門檻變得越來越低，簡單的來說，既然能以更小的代價獲得短期快樂，那麼大腦就不願意花更大的價錢去買長期來看更好但更貴的長期穩定的快樂了。\n不停的學新東西？聽上去很好啊？ We’re now in a day and age of Twitter and Facebook. We’re getting bite-sized, pithy wisdom, which is really hard to absorb.\n——Naval\n我們所看到的短信息，即使看上去是十分正確的大道理，十分有用的小知識，實際上全然無用，正所謂大道理只能自己悟出來，聽別人講大道理是沒用的。別人是在自己經歷和實踐上加以理解的基礎上總結，我們卻不能通過別人的總結反推出理解。\n大多數人被誤導：可以通過別人所發出的感悟學習到一些道理。事實上，從來都沒有這一回事。只有徹底明白某個道理的人才能發出感悟。想要從發出的感悟回溯被想明白的道理無異於從三條槓看出天地輪迴——都是自己的感悟，而非他的。當對問題的認識越透徹（這是一個籠統的感覺，只是借用了中文的這種表達方式），達到某個高度，才能從那個高度出發，發表一些本質上的感悟。這些感悟通常不具備實際的指導價值，可以透過現象看本質，即通過低層次的知識領悟高層次的知識，但若要通過高層次的知識倒退出作者是怎麼從低層次的知識獲得感悟，除瞎猜外，別無他法。\n自我感動改變不了看這些內容學不到東西的事實。\n這就像是吸毒 為了滿足大腦對多巴胺不斷增長的需求，我開始熬夜，我虛度光陰。得到了需要的多巴胺卻開始懊悔。\n一天不熬難受，熬了難受一天\n——我室友\n陷入前面提到的死循環的人症狀就像是吸毒，雖然知道毒品的危害，卻因為過度的痛苦不得不再次吸食毒品。一些藥品劑量大了就會變成毒品。一些本來對我們有益的舉動走火入魔就會變成追尋多巴胺的痛苦惡性循環。\n既然這就像是吸毒，也許我們可以以戒毒的方法消除這種看上去不像是成癮的成癮 根據 WHO 發佈的一段關於如何戒菸的視頻，為了戒菸，吸菸者需要克服尼古丁上癮，從大腦裡移除條件反射和打破潛意識的想法，以及移除社交上的關係紐帶。顯然，戒除這種看上去不像是成癮的成癮要比戒菸容易，因為我們不需要完成第一個挑戰以及最後一個挑戰，我們只需要移除條件反射和潛意識裡的想法，充其量算上克服我們的某個上癮，學習怎麼脫離某個事物生活。\n我會試著去做出一些改變：\n戒除早晨起來拿起手機玩的條件反射 戒除閒下來就想要碰電子產品的條件反射 戒除睡前“不能就這麼睡了”進而拿起手機的習慣 當然，僅僅做出這些改變還遠遠不夠。究其根源，癮的形成是因為更強烈的快感沖淡了其他一切能獲得的快樂。那麼更進一步，想要徹底戒除成癮，我們需要重拾那些能給我們帶來快樂的小事，體驗雖然小但是穩定的幸福感。不去追求一時的極致歡樂，自然也不會跌入痛苦的谷底而陷入惡性循環。\n","date":"2022-06-22T22:22:01Z","permalink":"/zh-hant-tw/2022/06/my-thoughts-on-addictions/","title":"看上去沒有病，就真的沒有病嗎？我對“癮”的思考"},{"content":"音樂是幾乎我生活中不可分割的一部分，我也不吝惜向音樂軟件裡付錢，用每月少量的錢換來舒適的音樂體驗，我認為很划算，這些年跌跌撞撞用過四款音樂軟件，想起來也算是回憶了。\nQQ音樂 小時候的我，住在一個悠閒而慵懶的小城。\n獨釣寒江雪。\n2015年，夢開始的地方，那時的我拿著一臺充話費送的手機，跑著安卓2.3，第一次體驗到聽音樂帶來的快樂，輕快的吉他聲在我耳邊響起，我在藍天白雲下自由的奔跑，跑累，癱在地上。\n越是長大，我越是感到憂鬱。\n氣壓越來越大，溫度越來越高，我的呼吸愈發困難，小城的慵懶與我無緣，整天與我陪伴的只有培訓課與作業，而音樂是我唯一的空間，只可惜，這點空間，我都無緣享受太久。\n網易雲音樂 2017年，初中開始，我漸漸的轉向了網易雲音樂，出於某些原因，我不得不搬走，要論宜居度，那麼我搬去的絕對不是一個宜居的地方。\n除了嶄新卻散發著令人作嘔的氣味的鋼筋水泥森林和寬闊卻死氣沉沉的道路，這裡什麼都沒有。\n是的，比溫馨的小城市更可怕的是光鮮亮麗而處於文化荒漠中的“大”城市。\n手機變成了一臺當年的價格屠夫，耳機變成了一副Ear Pods，論外文歌曲，網易雲音樂顯然比QQ音樂更加適合。當時的網易雲音樂，評論區裡還充滿著有趣的靈魂，或許，交流一下，就沒那麼不開心了。\n都說，“山雨欲來風滿樓”“黑雲壓城城欲摧”，烏雲已經壓了過來，空曠的廣場上沒有給我遮雨的地方。\n也許，在設計時就沒考慮有人會在廣場上走吧。\n雨沒有落下，但是陰天更可怕。涼風颳來，落葉飄零，街上本就不多的行人更加難覓蹤跡。想要Peace of mind？恐怕只有這種時候了。\nApple Music 一臺劃痕遍佈，看上去就很滄桑的 iPhone 6 到了我的手上。\n這段時光有些不堪回首。但總是忍不住回憶。說實在的，這一年，課業壓力並不繁重。但放假安排可並不這麼想，假期一再縮水，一週兩天變成半個月兩天，再到兩年後的一個月兩天。\n遲早是要來的。\nApple Music 簡潔，沒有冗餘的功能，更重要的是，沒有評論區。原先，網易雲的評論區裡有很多有趣的靈魂，那時甚至算得上沒有被發現的寶藏。只可惜，好地方總會被人發現，用的人多了，就容易變味。那種感覺，與看見一個又一個自然景觀被開發成不倫不類的旅遊景點無異。\n那些年，我見過多少原本險以遠的地方，被開發成不倫不類的旅遊景點。\n烈日可以烤焦一切，包括人。不幸的是，烈日天在此地並不少見。\n動輒39度的天氣顯然不是什麼好受的天氣，有空調的教室裡很舒適，我不否認這一點。烈日炎炎，愈是炎熱，空氣中的味道愈是複雜，石板鋪就的地面被烤出的“石頭味”，水塘裡散發的“水味”，植物蒸騰的“草地味”…… 樓下傳來割草機的聲音，原本生長旺盛的雜草就這麼倒下。太陽的炙烤放大了這種味道，一種比血腥還難聞味道。是的，植物也有血腥味，當走過那片剛被割過的草地，唯一的反應就是快些跑開。其實，這些雜草，很“美”，整齊劃一的馬尼拉草不過他們的陪襯罷了。\n奇怪的動植物要保護起來，奇怪的人卻受到排擠。\n總有一種力量想要掃清一切所謂的“雜草”，好不容易找到的一小片領地，總是這麼容易失去。\nSpotify 2021年，高三的我接觸到了 Spotify 。\n沒有人會愛我，包括我的家人，沒有人值得信任，包括自己的親人。接受現實，沒有人會喜歡你。即使沒有人會喜歡你，即使全世界都站在你的對立面，也得猶然笑之。\n而宋榮子猶然笑之，且夫舉世譽之而不加勸，舉世非之而不加沮。\n我如是告訴自己。要像宋榮子一樣，當所有人都不值得信任的時候只有自己最值得信任。家長真的值得信任嗎？他們所謂的為你好，不過一廂情願的自我感動，他們所謂的給了你最好的，為你犧牲，為你付出，不過連他們自己都不曾發覺的自我感動的遮羞布。自私是人的本性，事實無可避免，當你想要去信任某個人，最好先考慮清楚那個人是否值得信任。\n高三的我，不斷的質疑自己，懷疑我所經歷的、所看到的一切。\n第一次接觸到 Spotify ，用到 Spotify 的免費版。Spotify 免費版廣告重重，聽歌體驗很差，遷移過來，毫不誇張的說，我立刻回到了我原先使用的音樂軟件。當時我不想使用 Spotify ，真的不想，99刀一年的價格實在是超出了我的接受範圍。再者，我沒有 Spotify 接受的付款方式。\n高中階段在憂鬱的情緒裡結束的高考以一個不怎麼理想的成績結束了，我沒有如釋重負的感覺，也沒有興奮，再也找不到無憂無慮。直到這種時候，頂著與父母在填報志願時吵架的壓力，在與5人合租的賬號上開始聽起 Spotify。雖然 Spotify 鎖區，但曲庫足夠全，音質也是可以接受的水準。\n聽歌讓我心情變好，但總是驅散不去我心頭的陰霾。也許根本就不存在，也許沒必要，誰知道呢。（未完待續）\n","date":"2022-06-14T16:00:52Z","permalink":"/zh-hant-tw/2022/06/music-apps-i-use/","title":"那些年用過的音樂軟件"},{"content":"一直都在用VS Code，奈何以前太懶可惜高中的時候很忙，很長一段時間裡一直只把VS Code當作自己的文本編輯器，大學有了寫C/C++的需求，Xcode實在太大，於是轉戰在線編輯器repl.it，然而這類Cloud Based IDE鏈接不夠穩定，也沒有辦法離線作業，於是我開始尋找一個輕量化的C語言開發環境滿足我的實際需求。\n聲明 本文基於intel Mac，M1 Mac自行安裝/執行對應的版本/命令~~主要還是因為我太窮了(狗頭)~~其實現在這些工具大部分都適配了M1，應該不會有什麼問題\n默認你已經裝好了VS Code，沒有自行去VS Code官網下載安裝\n本文所提到的是Visual Studio Code，不是Visual Studio，如果分不清請自行搜索兩者的區別\n安裝C/C++編譯器 在Mac上，我用的C/C++編譯器是clang，相比於gcc，clang運行更快，能在程序出現語法錯誤編譯失敗時提供更加明確的錯誤信息和處理建議（這點我在Windows上用gcc時深有體會，gcc給的信息總是非常的confusing）。\n先檢查你的Mac是否自帶clang編譯器，執行clang -v或者clang --version，沒有出現clang的版本號則需要安裝clang，執行：\nxcode-select --install按照提示安裝完成。\n安裝VS Code相關擴展 在VS Code裡安裝以下拓展（括號裡的是作者）\nC/C++(Microsoft) Code Runner(Jun Han) 簡體中文拓展：Chinese(Simplified)（可選） 新建並配置工作區 新建一個文件夾作為工作區，注意文件夾名稱不能出現中文和空格！！，這裡根據我的需求，新建一個名為C_Homework的文件夾，隨後在VS Code的菜單欄裡選擇：文件-\u0026gt;打開文件夾，並信任此文件夾中文件的作者。\n測試C/C++環境是否正常 打開後在VS Code左側文件面板中剛剛創建好的文件夾裡新建一個C/C++文件，以.c/.cpp作為拓展文件名，例如hello.c/hello.cpp，然後寫一個基本的C/C++程序\n#include int main(){ printf(\"Hello VSCode!\"); return 0; }完成後按command + S保存文件，如果在之前的步驟里正確安裝了Code Runner，則可以方便的編譯運行代碼，點擊右上角的運行圖標或者在編輯區右鍵選擇Run Code，如果配置正確即可看到輸出。注意Code Runner只是幫你簡化了在控制檯輸命令的過程，所以需要自行保存文件後才能運作，當然也可以在設置成運行前自動保存。\n配置Debugger以調試程序 進入左側的Debug菜單，點擊上方運行與調試按鈕，選擇C++(GDB/LLDB)-\u0026gt;C/C++: clang 生成活動文件以生成tasks.json文件\n再次進入Debug菜單，點擊創建lauch.json文件，選擇C++(GDB/LLDB)以創建launch.json，將以下配置粘貼到launch.json裡，覆蓋掉原本的內容\n{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 \"version\": \"0.2.0\", \"configurations\": [ { \"name\": \"clang++ - Build and debug active file\", \"type\": \"cppdbg\", \"request\": \"launch\", \"program\": \"${fileDirname}/${fileBasenameNoExtension}\", \"args\": [], \"stopAtEntry\": true, \"cwd\": \"${workspaceFolder}\", \"environment\": [], \"externalConsole\": true, \"MIMode\": \"lldb\", \"preLaunchTask\": \"C/C++: clang 生成活動文件\" //沒有安裝簡體中文插件則自行在task.json裡複製粘貼換掉 } ] }這裡我將\u0026quot;externalConsole\u0026quot;項設置為true，避免在debug需要輸入的程序時找不到地方輸入的尷尬。\n替換後按command + S保存，以後碰到你需要debug的程序，打好斷點，在VS Code的上方菜單裡選擇運行-\u0026gt;啟動調試就可以痛苦的愉快的debug了。\n","date":"2022-06-10T19:42:57Z","image":"https://blog-img.l3zc.com/visual_studio_code.png","permalink":"/zh-hant-tw/2022/06/use-vscode-on-mac-to-build-c-programs/","title":"在Mac上使用VS Code搭建輕量化C/C++開發環境"},{"content":"網上大部分基於Hexo搭建個人博客的教程都是在Windows環境下實現的，Mac OS的教程很少，然而，Mac OS下完成這個任務遠比Windows要容易。\n準備工作 安裝 Homebrew Homebrew 是一個社區驅動的包管理器，它能方便我們安裝我們需要的環境。在中國大陸，推薦使用鏡像源安裝 Homebrew，下面以中科大鏡像源為例。\n設置環境變量：\nexport HOMEBREW_BREW_GIT_REMOTE=\"https://mirrors.ustc.edu.cn/brew.git\" export HOMEBREW_CORE_GIT_REMOTE=\"https://mirrors.ustc.edu.cn/homebrew-core.git\" export HOMEBREW_BOTTLE_DOMAIN=\"https://mirrors.ustc.edu.cn/homebrew-bottles\" export HOMEBREW_API_DOMAIN=\"https://mirrors.ustc.edu.cn/homebrew-bottles/api\"運行中科大 Homebrew 安裝腳本：\n/bin/bash -c \"$(curl -fsSL https://mirrors.ustc.edu.cn/misc/brew-install.sh)\"如果你的網絡環境良好（不在中國大陸），可以略過設置環境變量的步驟並直接使用正常的安裝腳本：\n/bin/bash -c \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\"安裝 Git 和 Node.js Homebrew安裝完成後，安裝 Git 和 Node.js：\nbrew install git brew install node測試所需組件是否安裝成功 依次輸入下面的命令\nnpm -v node -v git --version 出現npm、Node.js和git的版本號即代表安裝成功。\n安裝 Hexo 使用 npm 命令安裝 Hexo：\nnpm install -g hexo-cli等待安裝完成後初始化博客：\nhexo init blog這條指令的作用是在你目前所在的目錄下（默認是你的home目錄）新建一個名為blog的文件夾（你可以將這條命令中的blog替換成任何你想要的名字），並在內初始化你的博客。之後所有的操作都在這個文件夾下進行，請確保在執行後文的操作前已經切換到了這個文件夾（cd blog）。\n待初始化完成，切換到blog文件夾中，即可生成和預覽博客。\ncd blog hexo g hexo s執行hexo s命令後，通過瀏覽器訪問http://127.0.0.1:4000可以預覽你的博客，預覽功能會實時監測博客的文件變化，並實時反饋在瀏覽器上，在調試博客前端時非常好用。\n部署到GitHub 執行hexo g命令後博客靜態文件會生成在public文件夾下，只需要將這些文件上傳到你的靜態網站託管服務即可將站點發布到公網，本文用到的託管服務是Github Pages，下文提到的用戶名均指你的Github用戶名。\n添加SSH Key到github 若之前使用過相關功能且已經配置過請跳過此步。\n配置Git用戶名和賬號：\ngit config --global user.name \"username\" git config --global user.email \"example@example.com\"其中 username 是你的用戶名，example@example.com是你 Github 的登錄郵箱。\n然後通過終端命令生成 SSH Key：\nssh-keygen -t rsa -C \"example@example.com\"如果已經創建過會出現 Overwrite (y/n)? n提示可以輸入 n，沒有創建過的話三個回車就好，執行完成後會在~/.ssh/id_rsa.pub目錄下生成 需要使用的 key，也就是公鑰。\n到賬戶主文件夾下同時按Command+Shift+.顯示隱藏文件，找到.ssh文件夾，打開id_rsa.pub，將裡面的內容全部複製。\n打開GitHub_Settings_keys 頁面，新建New SSH Key，Title隨意填，Key就把剛才複製的內容全都粘貼上去。然後點Add SSH Key即可。\n完成這些工作以後可以通過以下命令測試是否配置成功：\nssh git@github.com 出現你的Github用戶名代表配置成功。\n上傳至 Github 在Github上新建一個倉庫，Repository Name 填你的用戶名.github.io，倉庫狀態設為 Public，點擊 Create Repository 創建新的網站倉庫。\n安裝 Hexo 的擴展 hexo-deployer-git，注意一定要在你的博客文件夾下執行：\nnpm install hexo-deployer-git --save編輯博客安裝文件夾下的_config.yml文件，翻到底部，修改deploy部分為：\ndeploy: type: git repo: git@github.com:你的用戶名/你的用戶名.github.io.git branch: master修改完成後按Command + S保存，此時就可以使用hexo d把存在本地的博客deploy到Github上了：\n#生成博客 hexo g #將博客推送到指定的地方，在這裡是我們的Github倉庫 hexo d 雖然我也不知道是為什麼，即使我們已經加好了 SSH 公鑰，並且填入hexo-deployer-git的倉庫信息也是 SSH 鏈接，第一次執行hexo d命令時還是可能要求你輸入你的Github賬號和密碼，這裡如果輸入你的賬號和密碼會出現如圖所示的報錯，這是因為 Github 在2021年 8 月 13 日停止了使用密碼認證的支持，在Gihub的Developer Settings頁面上新建一個 Personal Access Token 代替密碼就可以順利 deploy。\n新建一個 Token(classic)，並賦予這個 Token 操作 repo 的權限，有效期可以設置為 No expiration。\n其實出於安全考慮更推薦使用目前處於 Beta 階段的 Fine-grained tokens ，它提供了更精細的 Token 權限控制，例如可以只允許這個 Token 訪問特定的倉庫，而非傳統 Token 的全部倉庫。出於安全考慮，Fine-grained tokens 最高只能設置一年的有效期。\n打開倉庫的 Github Pages 功能 成功上傳後，博客倉庫裡應該會出現文件，這時只需在倉庫設置裡開啟 Github Pages 功能就可以了。\n打開倉庫的 Settings -\u0026gt; Pages，將 Build and deployment 項下的 Source 設置為「Deploy from a branch」，Branch 選擇「master」，單擊 Save 保存，Pages 功能就被打開了，每次hexo d，更新後的網頁都將被自動部署到 Github Pages。\n執行完畢後，打開你的用戶名.github.io就能看到你的博客了。\n綁定自定義域名（可選） 其實到這一步就可以開始寫博客了，默認的 github.io 的域名是可以更換的：\n首先自行申請一個域名，登陸到域名申請的後臺，添加一條CNAME解析記錄：你的用戶名.github.io。\n打開存放博客的Github倉庫，進入Settings頁面在pages選項裡的Custom domain裡填入你的域名，點擊Save，勾選Enforce HTTPS，即可通過自定義域名訪問你的博客。\n開始寫作 生成一篇新文章：\n$ hexo new \u003c/code\u003e\u003c/pre\u003e\u003cp\u003e執行後會在\u003ccode\u003eblog/source/_post\u003c/code\u003e文件夾裡生成一個名為\u003ccode\u003e\u0026lt;title\u0026gt;.md\u003c/code\u003e的文件，打開它即可使用 Markdown 開始寫作\n\u003cp\u003e\u003cimg alt=\".md 文件裡的 Front Matter\" class=\"gallery-image\" data-flex-basis=\"1057px\" data-flex-grow=\"440\" height=\"158\" loading=\"lazy\" sizes=\"(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) calc(100vw - 40px), (max-width: 1279px) calc(100vw - 280px), 960px\" src=\"/2022/05/mac%E7%8E%AF%E5%A2%83%E4%B8%8B%E4%BD%BF%E7%94%A8hexo%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E5%8D%9A%E5%AE%A2/20220502195744_hu_9a5670a73e1e1098.webp\" width=\"696\"\u003e \u003cp\u003e值得一提的是，Hexo生成時真正顯示的標題是\u003ccode\u003e\u0026lt;title\u0026gt;.md\u003c/code\u003e文件的 Front matter 裡 title 項的標題，文件名影響的是生成後文章的永久鏈接。\n\u003cp\u003e寫作完成後執行：\n\u003cpre\u003e\u003ccode class=\"language-bash\"\u003e#注意以下命令需要切換到blog文件夾(cd blog)執行 $ hexo g $ hexo d\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e即可將文章發佈，根據主題的不同，最好在執行\u003ccode\u003ehexo g\u003c/code\u003e前先執行：\n\u003cpre\u003e\u003ccode class=\"language-shell\"\u003e$ hexo clean\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e以避免潛在的問題。\n\u003ch2 id=\"hexo常用命令\"\u003eHexo常用命令 \u003c/h2\u003e\u003cpre\u003e\u003ccode class=\"language-bash\"\u003e#注意以下命令需要切換到blog文件夾(cd blog)執行 hexo n \"文章名稱\" =\u003e hexo new \"文章名稱\" #這兩個都是創建新文章，前者是簡寫模式，下同，new後面加一個draft可以生成草稿 hexo p =\u003e hexo publish #發佈草稿 hexo g =\u003e hexo generate #生成 hexo s =\u003e hexo server #啟動服務預覽 hexo d =\u003e hexo deploy #部署 hexo server #Hexo 會監視文件變動並自動更新，無須重啟服務器。 hexo server -s #靜態模式 hexo server -p 5000 #更改端口 hexo server -i 192.168.1.1 #自定義IP hexo clean #清除緩存，網頁正常情況下可以忽略此條命令\u003c/code\u003e\u003c/pre\u003e","date":"2022-05-30T16:27:30Z","image":"/2022/05/mac%E7%8E%AF%E5%A2%83%E4%B8%8B%E4%BD%BF%E7%94%A8hexo%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E5%8D%9A%E5%AE%A2/cover_hu_f8072877c13b7273.webp","permalink":"/zh-hant-tw/2022/05/mac%E7%8E%AF%E5%A2%83%E4%B8%8B%E4%BD%BF%E7%94%A8hexo%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E5%8D%9A%E5%AE%A2/","title":"Mac OS環境下使用Hexo搭建個人博客"},{"content":"某天在網上閒逛，發現一位名為linfangzhi老哥寫的Github項目——CSUST_network_autologin。於是白嫖下載了一份用來在圖書館上網，但是這個項目只發布了Windows版，沒發給手機和電腦用，所以，為了折騰滿足需求，自己動手，豐衣足食。\n管你怎麼樣先Fork一份再說 古語有云：“管你怎麼樣先fork一份再說“（大霧），這個項目的源碼公開，原理非常簡單，就是模擬幫你填個賬號登陸讓你上網，所以說，整個項目最有價值的東西其實就是登陸上長沙理工大學辦公區網絡的賬號和密碼。\n“既然這個項目源碼公開，那直接在源碼裡找到賬號密碼不就可以了嗎？”\n還真不行。\n賬號信息不會公佈（公佈是不可能公佈的，這輩子都不可能公佈）\n——linfangzhi\n事實上，他也確實做到了這一點，當你打開項目僅有的一個main.py文件就會看到如下的代碼片段\ninit(autoreset=True) account_info = [[]] # 隱私內容linfangzhi學長早就把核心的account_info信息刪去，留下一個擺著好看的坯子供你欣賞。他把這一個應用打包成了exe程序，只能用，不能看到隱私內容。\n可是我有iPad和Mac要登陸就只能洗洗睡了嗎？\n想辦法找到賬號信息 先試著直接拆開exe程序 有的exe程序可以直接用7-zip解壓，然而這個不行\n去網上找了一些方法，終於感覺此路不通，放棄\n抓取登陸的時候發送給認證服務器的數據包 長沙理工大學的認證服務器用的是萬年http，沒有s\n估計學校沒有想到覺得有人會在校園網裡抓別人的包，這意味著抓包會省不少事，只需要把程序發出的流量都引到抓包軟件上就可以直接獲取到裸奔的賬號信息。這個辦法的可行性明顯高得多，實際操作起來也更容易。\n那就抓包吧 這個項目發佈了exe文件，可我只有Mac，所以我在Crossover裡運行這個項目，不過需要一個簡單的python環境，crossover默認的wine容器環境完全沒有問題。於是我把用於Steam的容器用作這個exe的啟動器就可以。\n至於抓包，Mac上有很多優質的應用，這裡用到了Proxyman\n弄好Proxyman以後在容器的Internet設置裡設置一下本地的代理服務器讓所有的流量都走Proxyman，這樣就可以在Proxyman裡看到所有的包\n如前面所說，長沙理工大學的上網認證頁還在用著http，賬號密碼都在裸奔。其實用https也只是多一個安裝證書解密https的步驟。所以，到了這一步，直接在Crossover裡打開exe文件，在Proxyman裡觀察這個程序發出的網絡請求。\nPOST /eportal/?c=ACSetting\u0026a=Login\u0026protocol=http:\u0026hostname=192.168.7.221\u0026iTermType=1\u0026wlanuserip=10.171.184.114\u0026wlanacip=192.168.132.254\u0026wlanacname=JPL-ME60-1\u0026mac=6a-72-0c-e8-4e-15\u0026ip=10.171.184.114\u0026enAdvert=0\u0026queryACIP=0\u0026loginMethod=1 HTTP/1.1 Host: 192.168.7.221:801 User-Agent: python-requests/2.18.4 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Length: 74 Content-Type: application/x-www-form-urlencoded DDDDD=%2C0%2Cxxxxxx\u0026upass=xxxxxx\u0026R1=0\u0026R2=0\u0026R3=0\u0026R6=0\u0026para=00\u00260MKKey=123456很明顯，這個POST請求就是python的requests庫發出的登陸請求。因為linfangzhi學長不希望公佈賬號信息，我把賬號信息都換成了xxxxxx。\n將這段請求的原文還原一下（就是解碼）可以得到下面的內容：\n查看項目裡放出的源碼：\ndata = { 'DDDDD': ',0,{}'.format(account), 'upass': '{}'.format(pswd), 'R1': '0', 'R2': '0', 'R3': '0', 'R6': '0', 'para': '00', '0MKKey': '123456', } requests.post(url=post_url, data=data)可以輕易的知道賬號和密碼就在圖中兩個xxxxxx所在的位置。\n登陸和測速 在iPad上填入賬號信息嘗試登陸\n在長沙理工大學圖書館A館二樓測速\n速度還能接受。雖然用4G也可以實現相似的速度，但是免流量，加上找出來密碼的成就感，還是划算的，\n有一個小問題 每次連上半個小時就大概率會掉線，DHCP續租後又可以重新上線，可能是DHCP租約太短的原因，暫時還沒有找到解決辦法，可能以後會試著寫一個自動續租的腳本來勉強解決問題。\n（20220525更新：這個問題似乎被解決了）\n最後\u0026hellip; 如果想要賬號密碼可以在評論區留下郵箱2333\n","date":"2022-05-21T13:45:26Z","permalink":"/zh-hant-tw/2022/05/how-csust-bg-network-passwd-leaked/","title":"從某個項目裡找出csust辦公區網絡的密碼"},{"content":"昨晚，也就是2022-05-07晚上，正準備刷學校強制要求的智慧樹上的垃圾網課，卻發現智慧樹引入了一個刷課腳本的檢測機制。直接打斷了我的刷課進程。隨後試圖繞過這個機制，然而事情似乎並沒有那麼簡單。\n20220518更新：到現在，Greasy Fork上還在更新的腳本基本都實現了屏蔽檢測的功能，可以直接下載使用。\n摸爬滾打 經過一番摸爬滾打，大致掌握了一些信息：\n不論是通過Tamper Monkey還是通過開發者工具控制檯注入腳本都會被檢測到（廢話） 在檢查元素時，發現了一些奇怪的JS，毫無可讀性可言，但又正在運作，應該是經過混淆 在禁用了一些名稱可疑的奇怪JS後問題並沒有解決，難道檢測機制直接寫在index.html裡了？ 試圖替換頁面上的JS 沒辦法了，那就一個一個JS的看吧。\n這麼亂怎麼讀？那就先用工具規範一下格式\n先從第一個開始找吧，本來準備一個一個找，然而第一個腳本就出現了一些意想不到的東西。\n將所有一眼就知道是檢測的機制給替換成無意義的輸出\n然後替換網頁上原始的腳本\n似乎是成功了，不過腳本刷課自動切換的功能似乎失效。\n是在幫同學刷課，暫時手動切換，今天先鴿了，最近事情多是真的忙。\n","date":"2022-05-08T17:03:16Z","permalink":"/zh-hant-tw/2022/05/fuck-zhihuishu/","title":"嘗試繞過智慧樹對刷課腳本的檢測"},{"content":"Github的repo有個自定義域名的功能，其實就是在repo的根目錄下生成一個CNAME文件，裡面放著自定義的域名，然而Hexo每次deploy都會把這個CNAME文件覆蓋掉，結果就是自定義域名失效了。\n解決方案很簡單，把repo裡的CNAME文件下載下來，放到Hexo的/source目錄裡，個人猜測deploy是增量更新，只需經過第一次的deploy就不會出現丟CNAME的情況。\n","date":"2022-04-30T18:07:38Z","permalink":"/zh-hant-tw/2022/04/resolve-githubpages-cname-hexo/","title":"解決Hexo deploy到GithubPages時自定義域名失效的問題"},{"content":"世界，你好！\n『我只記得，我好像看過一幅漫畫，講述一枚雞蛋和一隻小雞的故事，在那副漫畫中，小雞說了一句‘Hello World’』\n","date":"2022-04-30T16:16:01Z","permalink":"/zh-hant-tw/2022/04/hello-world-0/","title":"Hello, World!"}]