Auto-login-netlib：用 GitHub Actions 自動登入 netlib.re，保活免費網域的設定與限制

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Auto-login-netlib 是一個掛在 GitHub Actions 上的開源小腳本，作用是定期幫你登入 netlib.re，因為這個服務會收回長期沒有活動的免費第二層網域，定期登入就是常見的保活手段。整套邏輯只有一支約 4.3 KB 的 JavaScript 檔案加一個工作流設定，fork 之後填好帳號就能跑，門檻相當低。不過它的 README 寫「每 60 天執行一次」，實際工作流卻是每個月 1 號固定跑、有 31 號的月份再加碼一次，一年大約跑 19 次，遠比 README 說的密集，這篇會把兩邊都對照著講清楚。

同樣把排程掛在 GitHub Actions 上的例子還有 News Agent 新聞聚合管線，它的示範部署也遇過網域失效與排程停擺，文件與 cron 的落差同樣值得先核對再依賴。

下面關於運作機制的描述，都來自實際讀過 repo 裡的 login.js 原始碼、工作流檔案與 netlib.re 官網，沒有 fork 下來連跑一整個月，所以長期穩定度不在這篇能背書的範圍，涉及作者身分與使用感受的環節會標明是誰說的。

netlib.re 的免費網域，為什麼需要保活

netlib.re 是一個老牌的免費網域專案，官網首頁掛的標語是「Free domain names for the common folks」，翻成白話就是「把網域還給一般人」。它讓你註冊一個像是 yourname.netlib.re 這樣的第二層網域，提供專屬所有權（exclusive ownership）、DNS 區域委派、NS 記錄等功能，可以接自家主機、做內網穿透，或託管到 Cloudflare 的 DNS 上管理。對想低成本架個個人服務或測試環境的人，這類免費網域是常見的起手式，TechMoon 先前整理的 網域價格比較也把免費選項列進來討論過。

免費的代價是服務會清理不活躍的帳號。從 netlib.re 官網的 News 頁面可以找到一封給使用者的公開說明，裡面明白寫著「any account has been deleted if」開頭的清理條件，並提到有人曾經濫用區域委派（zone delegation）功能的事件，營運者在清除涉濫用的帳號之後，讓剩下約 7,000 多個帳號繼續運作。換句話說，服務收回網域的風險真實存在，而且服務一旦判定某個帳號涉及濫用，不管有沒有定期登入都會直接刪除，遵守服務條款是保活之前的前提。netlib.re 官方並沒有在可見的地方寫出「多久沒登入會觸發回收」的精確天數，所以保活腳本能做到的是定期登入、維持你在服務上的活躍紀錄，至於這個頻率是否正好踩在官方的回收門檻上，無法從公開資訊確認。

netlib.re 對網域採取的是一種「專屬所有權」制度。從官網的介面字串能看到，使用者可以對某個網域提出 exclusive ownership 申請，也能把網域委派（delegate）出去或轉交給新的擁有者；一旦服務清除某個帳號，名下的網域就會變成所謂的孤兒網域（orphan domain），開放讓其他人重新認領。這套機制解釋了保活腳本為什麼要特別去檢查頁面上有沒有出現 exclusive owner 字樣：登入成功、而且你仍是網域的專屬擁有者，才算保活真正到位。反過來說，如果你長期不登入、帳號進入清除程序，服務就會釋出你名下的那個網域，讓下一個有意願經營的人接手，這就是免費網域服務常見的回收循環。

腳本實際做什麼：用無頭瀏覽器跑一次真實登入

翻開 login.js，會看到這支腳本實際上是啟動一個 Playwright 無頭 Chromium 瀏覽器，把登入流程從頭到尾操作一遍，全程不經過任何 API 呼叫。它的步驟是：開啟 netlib.re 首頁、點一下 Login、把帳號填進使用者名稱欄、密碼填進密碼欄、點 Validate 送出，然後等頁面載入完成後檢查內容裡有沒有出現 exclusive owner 或使用者名稱字樣，有就判定登入成功。這是很標準的瀏覽器自動化寫法，好處是不需要對方提供官方 API 也能運作，代價是 netlib.re 一旦改版面、改按鈕文字，腳本就會在你看不到的地方失敗。

Pin

多帳號是透過一個名叫 ACCOUNTS 的環境變數處理。原始碼裡解析帳號用的正規式是 split(/[,;]/)，意思是逗號或分號都能當分隔符號，每組帳號密碼之間用冒號隔開，格式像 user1:pass1,user2:pass2。腳本會逐一登入每個帳號、中間間隔 3 秒，最後把全部結果彙整成一條「幾號成功幾號失敗」的摘要。如果你額外設了 BOT_TOKEN 和 CHAT_ID 兩個 Telegram 變數，這條摘要會透過 Telegram Bot API 推到你的聊天室；沒設的話功能照樣跑，只是不會收到通知。這套「定時跑、跑完推一條結果」的設計，和 TechMoon 介紹過的 wxpush 用 Cloudflare Workers 推通知是同一類輕量自動化的思路。

腳本對失敗的處理也值得看一眼。login.js 把每個帳號的登入包在獨立的 try 區塊裡，單一帳號超時或例外不會中斷整批工作，瀏覽器執行個體會在 finally 裡關閉，避免程序卡住。每個動作設了 30 秒的預設超時，送出表單後還會等待網路 idle 再多睡 5 秒，讓頁面有時間渲染出登入結果，這對一個用 UI 操作取勝的腳本是必要的緩衝。不過這也意味著一次執行要連續開關瀏覽器，帳號一多，整個工作流的執行時間會線性拉長，帳號數量在個位數到十來個之內都還在 GitHub Actions 免費額度的舒適區。

這個專案以 GPL-3.0 授權釋出，依賴只有 axios 與 playwright 兩個套件，工作流跑在 ubuntu-latest 加 Node 20 的環境上。作者 eooce 顯示名稱是老王，GitHub 帳號下有 78 個公開 repo，以各種 keep-alive 類型的腳本為主，這個 Auto-login-netlib 則建立於 2025 年 11 月。截至本文查看時，repo 累計約 1,224 顆星、1,921 個 fork，fork 數明顯高於星數，反映多數人是直接 fork 去跑而不是只收藏，這是實用型自動化腳本相當常見的樣態。

README 寫 60 天、工作流寫 30 天，真相在 cron

這個專案有個值得記下來的內部不一致。README 的功能清單裡寫著「每60天自動執行一次」，其他介紹文章也跟著沿用 60 天的說法；但 .github/workflows/login.yml 的排程設定是 cron: '0 0 */30 * *'，檔案註解用中文寫著「每30天運行一次」。這個 */30 放在「日」欄很容易踩坑：它並不是字面上的 30 號，而是從 1 號起每隔 30 取一次，在 1 到 31 的範圍裡只會落在 1 號和 31 號，時間都是世界協調時間 0 點（台灣時間早上 8 點）。實際運行起來是每個月 1 號固定執行，有 31 號的那七個月份（1、3、5、7、8、10、12 月）再多跑一次，一年累計約 19 次；而 31 號到隔月 1 號只差一天，所以間隔並不固定。它既不是 README 寫的 60 天一次，也不是檔案註解暗示的 30 天一次，實際頻率比這兩種說法都更密集。

Pin

這個落差本身是個品質訊號，代表作者的文件沒有跟上自己的工作流設定。對使用者的實際影響有兩個：一是你腦中對「這支腳本多久會碰一次我的帳號」的預期，要從 60 天修正成一年將近 19 次、平均大約每 19 天一次；二是 GitHub Actions 的免費額度是按分鐘計算的，這種每月一兩次、幾分鐘就結束的無頭瀏覽器任務，對絕大多數個人帳號都在免費範圍內，不太需要為了額度操心。要改頻率的話，直接編輯自己 fork 裡的 login.yml 即可，例如想兩週跑一次可以換成 0 0 1,15 * *。

還有兩個 GitHub Actions 排程的常識，會影響你怎麼看待這支腳本的準時度。其一，GitHub Actions 的 cron 一律以世界協調時間（UTC）計算，login.yml 設的 0 點就是 UTC 0 點、對應台灣時間早上 8 點，不會跟著你的時區走。其二，GitHub 官方也說明過，排程工作流在高負載時段可能延後、甚至略過，不一定分秒不差地觸發，尤其在整點這類熱門時段延遲更明顯。好在 login.yml 同時開了 workflow_dispatch，讓你隨時可以進 Actions 頁面手動觸發，等於在自動排程之外保留一條隨時補單的後路，這對保活這種「有跑就好、不必精準」的任務來說是恰當的設計。

怎麼設定：Fork、Secrets、手動跑一次

實際把它接起來的流程很短。先到 eooce/Auto-login-netlib 的 GitHub 頁面點右上角的 Fork，把倉庫複製一份到自己的帳號下。fork 完之後進到自己那份倉庫的 Actions 頁面，會看到一條提示要你按下「I understand my workflows, go ahead and enable them」，按下去之後工作流才會處於啟用狀態，排程才走得動。

接著到倉庫的 Settings、Secrets and variables、Actions 頁面新增環境變數。必填的只有一個 ACCOUNTS，把你的 netlib.re 帳號密碼照 user:pass 的格式填進去，多帳號就用逗號或分號串接。如果想收 Telegram 通知，再額外加 BOT_TOKEN 和 CHAT_ID 兩個變數，前者是到 t.me/BotFather 建機器人取得的 Token，後者是聊天室 ID。這兩個變數完全可選，不設的話保活功能照常運作，只是不會收到訊息。全部設好之後，回 Actions 頁面手動觸發一次工作流，確認帳號填對、登入流程沒出錯，之後每個月就會自動跑一次。

判斷這次手動觸發有沒有成功，看的是 Actions 那次執行的 log。腳本在每個帳號登入後會印出對應的結果，成功會看到一行「登入成功」，失敗則是「登入失敗」或「登入異常」帶著錯誤訊息，最後還有一條「所有帳號處理完成」做收尾。常見的失敗原因多半出在設定環節：ACCOUNTS 誤用了全形冒號或頓號、帳號密碼本身打錯、或是首次執行時工作流還沒完成授權。只要手動跑這一次的 log 出現成功訊息，後續的自動排程基本就會照樣運作，你可以把它當成整條設定鏈的驗收點。

README 沒寫、但你該先知道的現實限制

GitHub 會靜默暫停沒活動的排程。GitHub 對公開倉庫有一條規則：排程工作流在倉庫連續 60 天沒有任何活動之後會自動停用，fork 出來的倉庫還需要你先手動啟用 Actions。這代表「設定一次、終身免管」的期待跟平台規則有一段落差，你還是得偶爾回 fork 的倉庫提交個活動、或重新啟用工作流，保活腳本本身才會繼續跑。

對方改版面就會悄悄失敗。腳本認按鈕用的是 text=Login、button:has-text(“Validate”) 這類 UI 選擇器，netlib.re 一旦改登入頁的文字或欄位名稱，登入就會在無頭瀏覽器裡失敗，而且失敗不會發信告訴你，唯一的訊號是你有設 Telegram 通知才會收到的「登入失敗」摘要。換句話說，關掉 Telegram 通知等於放棄唯一一條失敗警報線，建議至少留著這個開關。

帳號密碼要交給 GitHub Secrets。ACCOUNTS 變數裡裝的是明文的帳號密碼，雖然 GitHub Secrets 有加密、也不會在 log 裡顯示，但本質上你是在把 netlib.re 的登入憑證放進 GitHub。這是一個信任決定：對只拿來綁個人側邊專案的免費網域，多數人會覺得可接受；如果你那組帳密還綁了其他重要服務、或重複使用同一組密碼，就值得先換一組專用密碼再交出去。

把這三點疊起來看，Auto-login-netlib 比較接近「把每月一次的登入雜事自動化、但你還是要偶爾回頭看一眼」的工具，設定完仍然不能徹底忘掉。它把你本來得手動做的重複動作接掉了，卻沒有、也很難把背後的平台規則與第三方改版風險一起接掉。適合的人是已經在用 netlib.re 免費網域、願意偶爾確認工作流還活著的使用者；如果你連一個月回頭檢查一次都不願意，或對把憑證放進 GitHub 有顧慮，那麼每個月自己手動登入一次，反而是在這類免費服務上相對穩妥、不依賴任何腳本的保活方式。