20261006 會議記錄
:::info
-
所有會議記錄 編輯當週文件 準備 總結 - 10/6 (二) 20:00
- NPO Hub 出席：bil, mrorz, nonumpa
- 線上出席：alfred, yutin
- https://meet.google.com/mrz-dgrd-pri :::
上週待辦
- cofacts.ai session 週報：GGM 手動貼到 #collab；MrOrz 準備 DC bot 之後自動化
url-resolver
nonumpa：繼續研究 FB / IG preview 仍是登入畫面的問題
- ready for review https://github.com/cofacts/url-resolver/pull/74
- 410 = Gone 確定壞掉，跳過瀏覽器；其他 status code 還是用瀏覽器開開看
- Facebook 重組完 URL 後可以不用瀏覽器也能拿到內容
- Threads 要先照著 URL fetch，判斷結果才能判斷狀況
- 如果 FB & Threads 換規則，就會因為沒 match 到特殊處理規則，而自動 fallback 成其他一般 URL 的路徑
- 特殊處理規則可以下個 log 判斷路是否有被走，如果發現都沒在走，可能未來就能簡化 [name=mrorz]
- Fetch 完有 log [name=nonumpa]
[!Note] TODO Code review https://github.com/cofacts/url-resolver/pull/74
Vector search
@yutin（10-05）：#388 更新完成，ListArticles(mediaUrl) 依登入/未登入決定是否建檔
- MrOrz code review
- 先推上 staging
- LINE / site 都還沒開 embedding search 時，應該會繼續使用 tf-idf 故不受影響
- 判斷新送進來的訊息 & reply 是否都有新寫 embedding
- 對 staging 做小規模 backfill 試試看 backfill 是否可以運作
[!Note] TODO MrOrz 執行以上內容
cofacts.ai
「內文好、出處糟」案例：a5e8351f、92371cf8
結論： 問題主張多數不是幻覺，而是出處搞丟。主張在 investigator 的回傳裡找得到，但 writer 掛上的網址並不支撐那句話。另外每個 session 各有 1–2 則是 writer 自己生的。問題主張一則都沒經過 verifier，卻全標 verifier_confirmed: true。
| 主張分類 | a5e8351f | 92371cf8 |
|---|---|---|
| A 有工具依據，出處正確 | 1 | 2 |
| B 有工具依據，出處掛錯 | 5 | 8 |
| C 只在原文或使用者訊息裡 | 1 | 1 |
| D 任何工具都沒回傳過 | 1 | 2 |
實例：
- a5e8351f：原文網址是 writer 自己編的。
thinkingtaiwan.com/content/3094從沒出現在任何工具輸出裡，正確的是.net/3055，使用者按了倒讚。- 唯一一次 verifier 呼叫中斷，沒有結果。
- gate 擋了兩次，writer 把網址補進
references就通過了。
- 92371cf8：網址真的出現在工具回傳裡，但掛錯句子。 例如「HIV 18%→0.27%」的 grounding 是 aidsmap，卻掛了疾管署 2008 年的報告，那份報告不可能有 2010 年的數據。
- D 類：「每 1 美元省 7 美元法律與醫療支出」是 writer 自己生的，還算在 UN/WHO 頭上。
- 上游就沒依據：「AAP 正式反對校園篩檢」這句 investigator 有寫，但它的 grounding 並不支撐。
根因：
- investigator 只回傳一段文字和一份
sources[]，沒說明哪句對應哪個網址（grounding_supports沒傳給 writer），writer 只能猜。 verifier_confirmed由 writer 自己填，gate 不比對 verifier 的實際結果。- 後續回合常常不叫 verifier 就直接改稿。
既有提案與 PR 的盲點
| 失敗類型 | 本次案例 | #144 網址須在 sources 裡 | #118 verifier 先抓頁面 |
|---|---|---|---|
| writer 編造網址 | thinkingtaiwan.com/3094 | ✅ | — |
| 真網址掛錯主張 | 13 則 B 類 | ❌ | ❌ |
| 主張沒經過 verifier | 兩個 session 的多數主張 | ❌ | ❌ |
| writer 或 investigator 自己生的主張 | D 類，加上 AAP、UN/WHO | ❌ | ❌ |
| verifier 讀不到頁面卻亂判 | 92371cf8 補救階段的 18:05、18:10 | — | ✅（PDF 除外） |
- #144 的效果： 在 a5e8351f 擋下 2/5，但聯集裡沒有正確網址，只能逼 writer 重查；在 92371cf8 擋下 0/5。實作時要做網址正規化，因為有 vertexaisearch 轉址。
- #118 的效果： 只在 verifier 有被叫、而且有跑完時才起作用；verifier 的 ✓ 也沒接到 gate。
建議討論
- investigator 回傳「主張→網址」對應。 把
grounding_supports轉成逐句出處。 verifier_confirmed改由系統依 verifier 實際的 ✓ 判定。 這就是 #144「後續」那一項，建議重新排優先序。- #118 要和第 2 點搭配。 它是讓 verifier 可靠的前提，單獨上線效果有限。
- #144 仍值得做。 成本低，能擋編造的網址。
- 以上動工都需要補 ADR。
Cofacts 收連結
@nonumpa（10-04）：GCP 機器的 chrome 開 FB url 會被導向 login，疑似 IP/ASN 問題；
photo.php?endpoint 的連結有三篇文章編輯回覆連結失效，embed endpoint 可轉成userid/posts/postid，Cloudflare 的情況晚點再試 @MrOrz（10-05）：FB 連 oembed 都藏在 API 裡、也不遵循 oembed discovery，無法用通用規則取內容。提議：(1) url-resolver 結果先過 Jev 等 decision API 判斷是否為 login wall，若是就記錄「被阻擋」而不是內文，避免污染檢索引擎，並掃過現有 hyperlinks 清除污染；(2) cofacts.ai/report偵測到 login page 後，改請使用者自行上傳截圖，用 CreateMediaArticle 送出，URL 只當查核協作者的複查參考 @nonumpa（10-05）：Threads 已盡量處理，但其他平台也有類似問題（例如 post unavailable 會回到首頁隨機貼文，不讀 error code 就會抓到錯資料）
- Cofacts 已經有很多 article 的 hyperlinks 都收到 FB login page 的內容，導致他們都被視為 related article
- 如果是 FB login or 404 page or …, 不要存內文會比硬存 404 好，因為這樣才不會弄髒搜尋結果
- Proposal 1: rumors-api 寫入 urls / hyperlinks 前，先判斷他是不是真正的內文，若是就記錄「被阻擋」
- 可用 Jev 等 decision API（但要測準度）
- url-resolver 可以試著偵測 410 等狀態，此時就讓他無法解析，不要去填 title & description [name=nonumpa]
- 每個網站遇到 error 處理方式也不太一樣，有的會 200 然後 error page [name=nonumpa]
- FB & Thread 因為都可以透過個別處理的 rule 判斷文章拿不拿得到，所以不急
- Proposal 2: cofacts.ai
/report- 只能收 URL，如果啥都拿不到就會很沒用
- 如果發現 url-resolver 拿不到內文，就改請使用者自行上傳截圖
- 用 CreateMediaArticle 送出，URL 只當查核協作者的複查參考
- 可以產生 transcript ＆ embedding 所以很好檢索
- URL 可能存 articles 的 references or hyperlinks 欄位之類
- 友限文會被這個公開嗎 [name=nonumpa]
- 詢問截圖的時候，先說「這篇貼文我們拿不到，請確認這是『公開貼文』，如果是公開貼文，請提供截圖」
- ios / android 螢幕截圖可以長長的，需要 tutorial 和使用者說我們要這種長長的 screenshot
- 影片可能就 1st frame 之類
[!Note] TODO Proposal 1：用 AI 判斷的部分先發成 issue，短期先繼續用 url-resolver 以及其 rule-based 的判斷 Proposal 2：發 issue
十月小聚檢討
小松果 https://g0v.hackmd.io/PFBi12djSsCddeKTT3QZCw
- 604 的地板插座可以開 [name=mrorz]
- 插座也比較多，後面與側邊都有 [name=bil]
- 604 不錯，之後可以借 [name=bil]
- 來的人都知道自己要做什麼，積極參與 [name=bil]
LINE Bot request_timeout：rumors-line-bot#417 部署後狀況
- fix: gracefully stop accepting connections on SIGINT before PM2 kills the worker #417：是否已 merge / 部署？
- 部署後
request_timeout（LINE Developers Console）與 Cloudflare 499 / 502 是否下降？零星單筆失敗是否歸零？- PM2 reload cron 目前每 3 小時，#417 驗證後是否維持？
- 9/22 凌晨 origin 卡住事件、group 訊息偶爾沒回覆的舊謎團：有新線索嗎？
https://claude.ai/artifact/RqWcP9jwDaxyvtTLsD9jZd?sk=ZWH42A_T3Gu75l1cPKAtsw
Artifact 內容摘要：LINE webhook 錯誤追蹤（2026-10-06，rumors-line-bot）</summary>
原始 HTML 存檔（artifact 設為「知道連結即可檢視」）：artifacts/20261006-RqWcP9jwDaxyvtTLsD9jZd.html
資料來源：Cloudflare /callback、cloudflared log、GCP Cloud Logging、LINE Developers Console（LINE console 顯示 JST，換成 UTC 後與 Cloudflare 非 200 紀錄逐筆對得上）。
結論：剩下的零星失敗有兩個來源：(1) PM2 reload 時約 1 秒沒有任何 worker 在 listen（設定問題，可修）；(2) Cloudflare tunnel 的 QUIC 連線偶爾斷線重連（非 app 問題）。LINE console 錯誤變少主要是因為 9/28 起 reload 從每小時改為每 3 小時；#417 沒有處理到主因，#416 看起來有效。
四個待確認事項
- #417（SIGINT graceful shutdown）：已上線，10/1 02:16 UTC merge（
release/20261001），prod container 10/1 04:26 UTC 重建後未再換。
- 錯誤是否下降：有，但主要是 reload 次數從每天 24 次降到 8 次；reload 每次約 2–4% 機率掉 1–2 個 webhook，#417 前後一樣。#417 上線後 5 天共 6 筆失敗：2 筆來自 reload、4 筆來自 tunnel 斷線。
- reload cron（目前每 3 小時，UTC :15）：先修 PM2 設定再決定頻率。
- 舊謎團：10/4、10/5 兩次無法用 reload 解釋的失敗，對得上 cloudflared tunnel 斷線重連。9/19–9/27 那波 499 仍無解（見下）。
每日失敗（/callback 非 200，UTC）：9/6–9/18 每天 0–3 筆；9/19 起 499 暴增（9/19 7、9/20 10、9/21 36、9/22 35、9/23 44、9/24 105、9/25 15、9/26 18、9/27 22），9/28 起降到 0–2。每天總請求約 1 萬。
事件：#416 於 9/26 08:21 UTC 上線、9/28 cron 改每 3 小時、#417 於 10/1 上線。403/405 為無關掃描流量，已排除。
cloudflared 失敗原因（9/6–10/5，以事件計；#416 前→後）
- reload 當下
connection refused（那一瞬間沒有 worker 在 listen）：10→3
- reload 當下
connection reset by peer（舊 worker 結束切斷 keep-alive）：4→1
- 平常時段 reset /
server closed idle connection / broken pipe（keep-alive 逾時 race，#416 處理的問題）：5→0，#416 有效
- tunnel
Retrying connection（QUIC 斷線）：#416 後 2 次
reload 為什麼掉請求（10/5 00:15 UTC 那次）：新 worker 00:15:02 啟動，PM2 標為 online；00:15:05 即停掉舊 worker 0、1（此時新 worker 尚未 listen）；00:15:08 停舊 worker 2，此時沒有任何 worker 在 listen，cloudflared 收到 connection refused ×2（即 LINE console JST 09:15:09 的 2 筆 502）；00:15:09 新 worker 才印出 Listening port 5001（啟動約 7 秒）。原因：ecosystem.config.js 沒設 wait_ready，PM2 只等預設 listen_timeout（3 秒）就認定就緒。修法是 rumors-line-bot#418：wait_ready: true，在 server.listen callback 內 process.send('ready')，listen_timeout 拉到約 15 秒。#417 改的是舊 worker 關閉流程，對此無幫助（舊 worker 收 SIGINT 後 60–200ms 就結束，handler 不等 server.close()，Node 16 不會主動關閉閒置 keep-alive 連線，所以 kill_timeout 也沒用到）。
tunnel 斷線：cloudflared 與 Cloudflare 之間維持 4 條 QUIC 連線，其中一條逾時（no recent network activity）會重連，期間走該連線的請求失敗，約每 2–3 天一次（例：10/4 23:36 UTC 重連→502 ×2；10/5 07:48 UTC 兩條同時重連→request_timeout ×2）。目前 cloudflared 為 2026.3.0，log 建議升 2026.9.0。
9/19–9/27 的 499 已知線索：只有 line-bot 受影響（其他 host 的 499 平常就多）；與 tunnel 斷線、reload 的 :15 都對不上，集中在台灣晚上 21:00–01:00；Cloudflare 記到數百筆但 cloudflared 只有約 15 筆 context canceled；/callback 驗簽後直接回 200、處理為非同步，不應慢到讓 LINE 放棄；app image 3 月起沒換、9/28 除 cron 外無其他變動；#416 上線後仍持續到 9/27。與 cron 調整時間吻合，但 9/6–9/17 cron 也是每小時卻沒出現，尚無結論。下一步可查那幾晚 app event loop 是否被卡住或 LINE 平台是否異常。
建議下一步：①line-bot 合 #418（wait_ready）；②devops 升級 cloudflared 到 2026.9.0；③團隊確認 LINE webhook redelivery 是否開啟；④之後再處理：SIGINT handler 等 server.close() 並關閉閒置連線（Node 18+ closeIdleConnections()）、清 Apollo API key 失效造成的 401/406 log。
相關 PR：#416（keepAliveTimeout）、#417（SIGINT graceful shutdown）、#418（PM2 wait_ready）。
</details>
另發 PR: https://github.com/cofacts/rumors-line-bot/pull/418
[!Note] TODO
推 rumors-line-bot#418 到 staging 確認 pm2 server 可以啟動
OK 的話推 production 進行後續觀察
Cofacts.tw AI search 更新
9/20 時允許 User 的 AI bot 爬取 ( https://github.com/cofacts/devops/pull/21 )
目前結果：https://claude.ai/artifact/AL2f6ZNFhX2KuK9VZGnYEq
Artifact 內容摘要：開放 AI 搜尋爬蟲兩週後的成效（2026-10-05，zone cofacts.tw）</summary>
原始 HTML 存檔（artifact 設為「知道連結即可檢視」）：artifacts/20261006-AL2f6ZNFhX2KuK9VZGnYEq.html
背景：9/20 調整 Cloudflare WAF（devops#21、devops#12），放行經驗證的 AI Search / AI Assistant 爬蟲，繼續封鎖訓練爬蟲。資料為 9/4–10/5 的 Cloudflare 流量（GraphQL Analytics、AI Crawl Control）與 GCP 帳單；「前期」9/6–9/19、「後期」9/21–10/4 各 14 天。
結論：Claude 爬完全站，但導流尚未出現。
- Claude-SearchBot 成功抓取 18.4 萬次：變更前 0，9/20 晚到 9/26 每天 2.8–4 萬次集中爬完一輪，9/27 起歸零。
- 多出的 GCE 網路費約 $1.5（Claude-SearchBot 用 15.4 GiB；GCE 送往 Cloudflare 流量 +10%）；一個月約多 $3–4，OAI-SearchBot 少抓 10.6 GiB 幾乎抵銷。
- 來自 claude.ai 的導流為 0（後期無 claude.ai referer 或 utm）。Claude-User（claude.ai 使用者對話即時讀取）由每天約 6 次變約 13 次，10/2 最高 43 次，量仍小。
各 bot 狀態（9/20 之後）
- 放行：Amzn-SearchBot（9/14 起每天穩定約 8,600，最穩定；AI Crawl Control 圖表未列出）、OAI-SearchBot（每天 5 千–1.4 萬，本來就放行）、Applebot／DuckAssistBot／ExaBot／ShapBot（ExaBot 9/26–29 爬一波）、ChatGPT-User（每天 200–800，9/10 起自約 1,500 下滑，早於變更）。
- 封鎖：ClaudeBot（訓練，9/22–26 單日最多 7.9 萬次全被擋）、GPTBot／PerplexityBot／Reflectionbot、meta-externalagent（10/1 起 5.5 千→1 萬→3.7 萬→9.6 萬/日，擋在 edge 不打 origin，需留意）、冒名 Claude-SearchBot（9/27 後仍用該 UA 但未通過驗證，掃
/.env、/.aws/config）。
- Claude Code 的 WebFetch 從使用者自己網路送出，無法驗證，仍會被擋。
成本：爬蟲抓文章頁時 SSR 會呼叫 GCE 上的 API，流量經 Cloudflare Tunnel 送出，帳單記為「Carrier Peering」。各 crawler 傳輸量（前期→後期 GiB）：Claude-SearchBot 0→15.4、Googlebot 68.0→77.9、BingBot 38.7→45.4、Applebot 34.3→30.7、OAI-SearchBot 22.0→11.4、ChatGPT-User 1.1→0.5；合計 164.2→181.4（+17.2）。GCP 帳單 9/20–10/5：GCE Carrier Peering 188.4 GiB $16.01（+10%）、Cloud Run Carrier Peering 76.1 GiB $3.19（+23%）、GCE Internet Egress 6.3 GiB $0.75（+9%）；網路費差額約 +$2.1。網路費不是預算壓力來源：這 15 天共 $135.64（月約 $270，超過 $250 預算），主因為 GCE RAM/Core（約 $41）、Gemini（約 $20）、Cloud Run CPU（約 $18）。
AI 導流（每日平均，前期→後期）：claude.ai 0.1→0；ChatGPT（utm_source=chatgpt.com）53→69（+30%，與本次調整無關）；chatgpt.com referer 8.1→4.4；gemini.google.com 2.1→0.6；copilot.microsoft.com 0.5→0.9；perplexity.ai 0→0；www.google.com 4,795→9,111（9/26 起大增，原因不明）。Claude 引用連結可能不帶 referer。
下一步：①10 月中再看 Claude-SearchBot 是否定期重爬、Referrals 有無 claude.ai；②直接在 claude.ai 問 Cofacts 查過的謠言，看是否引用 cofacts.tw；③留意 meta-externalagent；④看 AI 爬蟲全貌別只看 AI Crawl Control（只算放行請求、無 Amzn-SearchBot），要查 GraphQL Analytics。
</details>
site-tw 暫時擴容？
- site-tw CPU / Mem p99 連兩週貼近 1 vCPU / 1GB 上限，流量週增約 30%（9/23–24 尖峰，之後回落）
- 長期會由 cofacts.ai 取代，是否先暫時擴容因應流量增加？
[!Note]
bil 說可以
先拉到 2GB ram 試試看
詐騙檢舉與洗白紀錄
- 前因後果、檢舉 vs 洗白雙方時間軸： https://claude.ai/artifact/3sx9hfgcM2s8F2pqJbhd7w
Artifact 內容摘要：禾光啟源洗白案（2026-10-06 整理）</summary>
本 repo 為公開 repo，此摘要刻意省略 IP 位址、帳號 userId 等細節；takedowns 公告也只寫「WG 另掌握證據」。完整內容見 artifact 與 takedowns repo。
核心發現：10/06 凌晨（台灣時間）針對「禾光啟源」「映善 Lumen Mind」兩篇訊息出現 6 個新帳號（takedowns PR #359–#364），每個帳號送出內容的那幾秒，Cloudflare 都記錄到同一個 IP（US 資料中心 VPS）對 api.cofacts.tw/graphql 的 POST；該 IP 在動作前後持續瀏覽這兩篇文章（通過 Cloudflare challenge，像真實瀏覽器）。被洗白的目標與 10/02 來信要求下架的文章相同，極可能同一操作者，但無直接證據。6 個帳號在 02:13–02:37 間 24 分鐘內依序出手（4 個查核回應、2 個回報補充），皆已 merge 並封鎖（#361–#364 共用 -2.md 公告，分支歷史整理為單一 commit）。
時間線
- 2024/05/09–12：同一信箱兩度來信「檢舉二次詐騙」；5/14 mrorz 判定為詐騙集團 honeypot 探測（先前回信等於讓對方知道處理流程）。5/14、5/18 兩波 1,200–1,500 萬 req DDoS，打的正是信中檢舉的文章，判斷寄信者即攻擊者、目的為逼下架；處置為 Cloudflare WAF Managed Challenge。（出處：20240520 會議紀錄）
- 2024/12/22、2025/01/02：同一信箱再來信要求刪除二次詐騙回應／文章。
- 2026/05/05：LINE 使用者「激勵性的中山區泰勒」建立帳號，之後 5 個月送出 29 篇「某某是投資詐騙」。
- 2026/07/29–08/21：該使用者送出聚善共築、禾光啟源、愛聚時光、映善 × Lumentum、映善 Lumen Mind 等；洗白方隨後出現。「李總敏」樣板話術洗白已於 0818 公告封鎖（#334）；「深沉的大安班奈特」品牌洗白 SEO 於 0820 封鎖。
- 2026/10/02：同一信箱兩封信（簡繁各一）要求下架禾光啟源、刪除或更正映善兩篇，論點「證據不足、不應給確定性結論」。
- 2026/10/06 00:52–01:22：新帳號「細節的新豐格吉爾」送 4 篇洗白文，已封鎖的「深沉的大安班奈特」交錯送 5 篇（#358）；02:13–02:37 為上述 6 帳號。
檢舉方分析：29 篇皆「某某是投資詐騙」，14 篇附官方通報字樣（警政署 165、金管會、數發部），15 篇無官方來源（7/29 後針對「包裝成公益團體」的 8 篇幾乎全無來源）。WG 於 0821 公告判為「警示他人的一般回報者」。支持「集團互相攻訐」：近期無來源、句型制式、帶內部資訊口吻；支持「反詐檢舉者」：5 個月 29 個不同對象、早期附官方通報、無來源不等於不實、洗白方「查無商工登記就推定虛構」推論薄弱。尚未做：以經濟部登記／165／金管會逐一核對近期無來源指控。封鎖洗白帳號依據的是行為（同裝置操控、全部活動皆洗白），與誰說真話無關；日後處理檢舉者文章，標準應一致（可核實性、是否協同行為）。
確定 vs 推論
- 有資料支持：6 帳號唯一活動皆與同 IP 的 API POST 在 0–1 秒內重合；IP 動作前後瀏覽目標文章；標的與 10/02 來信相同；四個月來洗白敘事一致（要求證據、警告「假律師追款」）。
- 僅為推論：10/02 寄信者即操作者；與 2024/05 honeypot／DDoS 同一方；與李總敏、深沉的大安班奈特同一方；檢舉方與被指控集團是否為對手。
- 尚未查：來信者在 Cofacts 是否有帳號／reply；#358 帳號與 8 月帳號 IP（Cloudflare 資料只留約 4 週）；Cloudflare 看不到 request body，POST 與 mutation 的對應是時間推斷。
建議與討論
- 回信：2024/05 前例是被檢舉信誘出處理流程後遭 DDoS 施壓；回信前不透露流程與判斷標準，依 takedowns 流程處理，不因來信或攻擊而下架。
- 防護：是否對該 IP 加 WAF 規則（對方會換 IP）；是否預先對
3h9lawefylu95、2shkneniiib1y、1ktg8az7gcid1 三篇文章加 Managed Challenge 防 2024/05 式 DDoS。
- PR：是否補 IP 證據到 #359–#364 描述（公開公告不放 IP）。
相關 takedowns：1006-seo-reputation-management、-2。
</details>
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management.md
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management-2.md
- 選前 cofacts 不希望倒站，是可以考慮預先加 challenge [name=mrorz]
- 也可以設定只限台灣存取 [name=nonumpa]
- 其他網站也被洗留言，但通常會搭配二次詐騙，最近好像沒有 [name=nonumpa]
- 現在的行為真的很怪，沒有搭 LINE ID 就純洗形象 [name=mrorz]
易拉展
- X 展架的棒子只有兩截，收納袋 100cm 長，需要另外託運
- 健豪有四截式易拉展
Mozfest booth
上週重點整理（2026-09-29 ～ 2026-10-06）
GitHub 活動
cofacts/rumors-api
- #388 vector search（review 中，10/05 仍有更新；ListArticles(mediaUrl) 改依登入/未登入決定是否建檔）
- #405 transcript fallback 由 gemini-2.5-flash 換成 gemini-3.5-flash（closed 09-30，同時 closed #403）
- #400 transcript 直接把 media URI 交給 Vertex，不再複製到 GCS（closed 09-30）
- release/20260930
cofacts/rumors-site
cofacts/rumors-line-bot
cofacts/ai
- #147 [Demo preview] English UI + filing new messages（opened 09-29）
- #138 Report a suspicious message through a form at /report（10/04 有 review）
cofacts/devops
- #24 docs(cloudflare): add DDoS response SOP（opened 10-02 / closed 10-03）
- #25 Staging VPS OS 升級（Ubuntu 16.04 太舊）（opened 10-05）
- #23 Langfuse v3 → v4 升級追蹤（10/05 有新留言）
cofacts/kb
- #29 以 Jev 實作 Cofacts Topic Classifier 之可行性評估（10/05 有新留言）
cofacts/takedowns
Discord 重點討論
general
@chewei 想邀請 Cofacts 11/02 週一晚上，參加 AI Monday 線上分享
https://g0v.hackmd.io/@jothon/ai
- TA of AI monday?
- Coscup slides / 共筆 有些內容偏技術細節
[!Note] TODO
bil 會主講
投影片要放在 https://docs.google.com/spreadsheets/d/1y9RLwi-O040_NhvmGpuEhXXPSvsbgbHWgiAmIioI6i0/edit?pli=1&gid=0#gid=0&range=G35
alerts
10/05 Cofacts down（Health Check：cofacts.tw）
dev
@MrOrz（10-02）：query time 的 transcript 本來就存進正式位置；embedding 也是 query time 運算，沒必要另闢暫存機制，transcript 和 embedding 共用同一個 GCS file 比較簡潔。Media manager 有 media hash 機制，同檔案分配同一個 id
@MrOrz（10-02）：ListArticles with media 只有 LINE bot 用，且 always transcript.shouldCreate: true，breaking change 應無實際影響
@MrOrz（10-02）：yutin-local-dev service account 已有 rumors-db bucket 權限，可依 opendata CONTRIBUTING 把 production backup 還原到本機 ES 分析 hyperlinks（文件語法可能是 ES 6 舊版，歡迎發 PR 更新）
Cofacts production 環境週報（2026-09-29 ～ 2026-10-06）
總結： 本週系統整體穩定。Cloud Run 11 個服務都正常（✔）。GCE 主機的 Swap 從約 49% 降到約 31%，比上週好。需要注意的有兩件事：site-tw 的記憶體一直貼著上限，以及 10/03 出現一次記憶體尖峰。
GCE 主機（cofacts-prod）每日指標
格式：min | avg | p95 | max（%）
日期
CPU
Mem
Swap
09-29
8.8 | 16.2 | 21.7 | 46.7
63.5 | 66.1 | 68.5 | 70.6
46.9 | 48.7 | 51.6 | 52.1
09-30
10.4 | 15.6 | 20.5 | 32.8
62.0 | 65.1 | 67.3 | 69.0
21.7 | 32.6 | 48.7 | 49.8
10-01
10.5 | 16.8 | 21.9 | 25.9
61.4 | 64.8 | 66.5 | 69.2
27.7 | 29.9 | 32.2 | 33.8
10-02
10.5 | 17.4 | 23.9 | 39.5
62.0 | 64.9 | 66.8 | 68.1
29.6 | 30.8 | 32.9 | 34.8
10-03
12.0 | 17.8 | 23.1 | 34.8
62.7 | 65.5 | 67.3 | 85.1
28.6 | 30.2 | 33.2 | 34.1
10-04
10.2 | 16.9 | 22.7 | 45.1
62.0 | 65.4 | 67.5 | 69.9
29.1 | 31.0 | 33.0 | 34.4
10-05
11.2 | 18.4 | 24.1 | 46.3
63.1 | 65.7 | 68.1 | 69.9
29.8 | 31.4 | 33.6 | 34.4
10-06*
15.2 | 21.3 | 27.6 | 27.6
62.4 | 65.1 | 66.4 | 66.5
32.4 | 33.7 | 35.8 | 35.9
* 10-06 只有部分時段的資料。
目前狀態：已開機 152 天，load average 約 1.4，可用記憶體 10 GiB，Swap 用了 1.3 / 4 GiB，磁碟用了 61%（41 / 67 GB）。
GCE 主要行程
| 行程 | 平時用量（日均） | 穩定度（Stddev） | 觀察 |
|—|—|—|—|
| Elasticsearch | RSS 約 19.3 GB；CPU 比上週多約 6% | 低（RSS std 約 113 MB） | 很穩定。CPU 峰值從上週的 647k 降到 398k |
| node /srv/www/server.js（rumors-site） | RSS 約 358 MB（峰值 897） | 中等 | 和上週差不多（342 MB） |
| node /srv/www/build/index.js（API） | RSS 約 153 MB；CPU 比上週多約 3% | 低 | 10/06 CPU 略升 |
| python main.py（cofacts-ai） | RSS 約 86 MB；CPU 約 4k | 10/02 到 10/05 波動大 | 10/03 CPU 峰值約平常的 10 倍（37k，std 7.7k），可能是批次工作或突發的 AI 請求 |
| pm2-runtime | RSS 約 81 MB（上週 171） | 09/30 之後很低 | 09/30 RSS 從 393 降到約 70 MB，同一天 Swap 也降了，看起來是 pm2 重啟或重新部署後釋放出來的 |
| cloudflared | CPU 比上週多約 31% | 低 | 和流量一起上升，屬於正常範圍 |
| Chromium（puppeteer） | 上週有好幾個 renderer 佔了 500 MB 以上 | — | 本週峰值降到 378 MB 以下，比上週好 |
Cloud Run 服務
CPU 和 Mem 都是使用率比例（1.0 = 用到上限）。p50 取一週平均，p99 取一週最高。
服務
CPU p50 / p95 / p99
Mem p50 / p95 / p99
觀察
site-tw
0.09 / 0.78 / 1.01
0.79 / 0.98 / 1.01
記憶體 p95 長期貼近上限，上週也一樣。建議評估調高記憶體上限，或排查有沒有記憶體洩漏。每日外流流量約 4.8 GB（上週 5.7 GB，下降約 16%），符合 WAF 和快取的降費方向
cofacts-ai
0.016 / 0.17 / 0.34
0.06 / 0.07 / 0.07
10/04 有新部署。p95 CPU 從 0.12 升到 0.17，資源仍然很充裕
line-bot-en / ja / tw
約 0.01 / 0.12 / 0.3～0.43
約 0.40 / 0.43 / 0.63
10/01 有新部署，運作穩定
site-staging-tw / en / ja
約 0.006 / 0.1～0.2 / 0.3～0.44
約 0.75 / 0.9 / 0.98～1.01
staging-ja 從 10/03 開始才有流量，記憶體 p99 有碰到上限，但這是 staging 環境，影響很低
dev-line-bot
0.006 / 0.12 / 0.13
0.41 / 0.43 / 0.44
正常
建議
- site-tw 記憶體：p95 約 0.98、p99 超過 1.0，已經連續兩週。建議查 Cloud Run 有沒有 OOM 或 instance 重啟的紀錄，再決定要調高記憶體上限，還是追查洩漏。
- 10/03 GCE 記憶體尖峰（85%）：只出現過一次（當天 p95 只有 67%），時間上和
python main.py 的 CPU 尖峰吻合，推測是 cofacts-ai 的突發工作。如果之後還會發生，再深入追查。
- Egress：site-tw 的外流流量又降了約 16%，可以留到 10 月帳單一起驗收。
原始摘要檔都存在 workspace/metrics/*_2026-09-29_2026-10-06_1791259028_summary.json。
原始 HTML 存檔（artifact 設為「知道連結即可檢視」）：artifacts/20261006-RqWcP9jwDaxyvtTLsD9jZd.html
/callback、cloudflared log、GCP Cloud Logging、LINE Developers Console（LINE console 顯示 JST，換成 UTC 後與 Cloudflare 非 200 紀錄逐筆對得上）。release/20261001），prod container 10/1 04:26 UTC 重建後未再換。connection refused（那一瞬間沒有 worker 在 listen）：10→3connection reset by peer（舊 worker 結束切斷 keep-alive）：4→1server closed idle connection / broken pipe（keep-alive 逾時 race，#416 處理的問題）：5→0，#416 有效Retrying connection（QUIC 斷線）：#416 後 2 次connection refused ×2（即 LINE console JST 09:15:09 的 2 筆 502）；00:15:09 新 worker 才印出 Listening port 5001（啟動約 7 秒）。原因：ecosystem.config.js 沒設 wait_ready，PM2 只等預設 listen_timeout（3 秒）就認定就緒。修法是 rumors-line-bot#418：wait_ready: true，在 server.listen callback 內 process.send('ready')，listen_timeout 拉到約 15 秒。#417 改的是舊 worker 關閉流程，對此無幫助（舊 worker 收 SIGINT 後 60–200ms 就結束，handler 不等 server.close()，Node 16 不會主動關閉閒置 keep-alive 連線，所以 kill_timeout 也沒用到）。no recent network activity）會重連，期間走該連線的請求失敗，約每 2–3 天一次（例：10/4 23:36 UTC 重連→502 ×2；10/5 07:48 UTC 兩條同時重連→request_timeout ×2）。目前 cloudflared 為 2026.3.0，log 建議升 2026.9.0。context canceled；/callback 驗簽後直接回 200、處理為非同步，不應慢到讓 LINE 放棄；app image 3 月起沒換、9/28 除 cron 外無其他變動；#416 上線後仍持續到 9/27。與 cron 調整時間吻合，但 9/6–9/17 cron 也是每小時卻沒出現，尚無結論。下一步可查那幾晚 app event loop 是否被卡住或 LINE 平台是否異常。server.close() 並關閉閒置連線（Node 18+ closeIdleConnections()）、清 Apollo API key 失效造成的 401/406 log。[!Note] TODO 推 rumors-line-bot#418 到 staging 確認 pm2 server 可以啟動 OK 的話推 production 進行後續觀察
Artifact 內容摘要：開放 AI 搜尋爬蟲兩週後的成效（2026-10-05，zone cofacts.tw）</summary>
原始 HTML 存檔（artifact 設為「知道連結即可檢視」）：artifacts/20261006-AL2f6ZNFhX2KuK9VZGnYEq.html
背景：9/20 調整 Cloudflare WAF（devops#21、devops#12），放行經驗證的 AI Search / AI Assistant 爬蟲，繼續封鎖訓練爬蟲。資料為 9/4–10/5 的 Cloudflare 流量（GraphQL Analytics、AI Crawl Control）與 GCP 帳單；「前期」9/6–9/19、「後期」9/21–10/4 各 14 天。
結論：Claude 爬完全站，但導流尚未出現。
- Claude-SearchBot 成功抓取 18.4 萬次：變更前 0，9/20 晚到 9/26 每天 2.8–4 萬次集中爬完一輪，9/27 起歸零。
- 多出的 GCE 網路費約 $1.5（Claude-SearchBot 用 15.4 GiB；GCE 送往 Cloudflare 流量 +10%）；一個月約多 $3–4，OAI-SearchBot 少抓 10.6 GiB 幾乎抵銷。
- 來自 claude.ai 的導流為 0（後期無 claude.ai referer 或 utm）。Claude-User（claude.ai 使用者對話即時讀取）由每天約 6 次變約 13 次，10/2 最高 43 次，量仍小。
各 bot 狀態（9/20 之後）
- 放行：Amzn-SearchBot（9/14 起每天穩定約 8,600，最穩定；AI Crawl Control 圖表未列出）、OAI-SearchBot（每天 5 千–1.4 萬，本來就放行）、Applebot／DuckAssistBot／ExaBot／ShapBot（ExaBot 9/26–29 爬一波）、ChatGPT-User（每天 200–800，9/10 起自約 1,500 下滑，早於變更）。
- 封鎖：ClaudeBot（訓練，9/22–26 單日最多 7.9 萬次全被擋）、GPTBot／PerplexityBot／Reflectionbot、meta-externalagent（10/1 起 5.5 千→1 萬→3.7 萬→9.6 萬/日，擋在 edge 不打 origin，需留意）、冒名 Claude-SearchBot（9/27 後仍用該 UA 但未通過驗證，掃
/.env、/.aws/config）。
- Claude Code 的 WebFetch 從使用者自己網路送出，無法驗證，仍會被擋。
成本：爬蟲抓文章頁時 SSR 會呼叫 GCE 上的 API，流量經 Cloudflare Tunnel 送出，帳單記為「Carrier Peering」。各 crawler 傳輸量（前期→後期 GiB）：Claude-SearchBot 0→15.4、Googlebot 68.0→77.9、BingBot 38.7→45.4、Applebot 34.3→30.7、OAI-SearchBot 22.0→11.4、ChatGPT-User 1.1→0.5；合計 164.2→181.4（+17.2）。GCP 帳單 9/20–10/5：GCE Carrier Peering 188.4 GiB $16.01（+10%）、Cloud Run Carrier Peering 76.1 GiB $3.19（+23%）、GCE Internet Egress 6.3 GiB $0.75（+9%）；網路費差額約 +$2.1。網路費不是預算壓力來源：這 15 天共 $135.64（月約 $270，超過 $250 預算），主因為 GCE RAM/Core（約 $41）、Gemini（約 $20）、Cloud Run CPU（約 $18）。
AI 導流（每日平均，前期→後期）：claude.ai 0.1→0；ChatGPT（utm_source=chatgpt.com）53→69（+30%，與本次調整無關）；chatgpt.com referer 8.1→4.4；gemini.google.com 2.1→0.6；copilot.microsoft.com 0.5→0.9；perplexity.ai 0→0；www.google.com 4,795→9,111（9/26 起大增，原因不明）。Claude 引用連結可能不帶 referer。
下一步：①10 月中再看 Claude-SearchBot 是否定期重爬、Referrals 有無 claude.ai；②直接在 claude.ai 問 Cofacts 查過的謠言，看是否引用 cofacts.tw；③留意 meta-externalagent；④看 AI 爬蟲全貌別只看 AI Crawl Control（只算放行請求、無 Amzn-SearchBot），要查 GraphQL Analytics。
</details>
site-tw 暫時擴容？
- site-tw CPU / Mem p99 連兩週貼近 1 vCPU / 1GB 上限，流量週增約 30%（9/23–24 尖峰，之後回落）
- 長期會由 cofacts.ai 取代，是否先暫時擴容因應流量增加？
[!Note]
bil 說可以
先拉到 2GB ram 試試看
詐騙檢舉與洗白紀錄
- 前因後果、檢舉 vs 洗白雙方時間軸： https://claude.ai/artifact/3sx9hfgcM2s8F2pqJbhd7w
Artifact 內容摘要：禾光啟源洗白案（2026-10-06 整理）</summary>
本 repo 為公開 repo，此摘要刻意省略 IP 位址、帳號 userId 等細節；takedowns 公告也只寫「WG 另掌握證據」。完整內容見 artifact 與 takedowns repo。
核心發現：10/06 凌晨（台灣時間）針對「禾光啟源」「映善 Lumen Mind」兩篇訊息出現 6 個新帳號（takedowns PR #359–#364），每個帳號送出內容的那幾秒，Cloudflare 都記錄到同一個 IP（US 資料中心 VPS）對 api.cofacts.tw/graphql 的 POST；該 IP 在動作前後持續瀏覽這兩篇文章（通過 Cloudflare challenge，像真實瀏覽器）。被洗白的目標與 10/02 來信要求下架的文章相同，極可能同一操作者，但無直接證據。6 個帳號在 02:13–02:37 間 24 分鐘內依序出手（4 個查核回應、2 個回報補充），皆已 merge 並封鎖（#361–#364 共用 -2.md 公告，分支歷史整理為單一 commit）。
時間線
- 2024/05/09–12：同一信箱兩度來信「檢舉二次詐騙」；5/14 mrorz 判定為詐騙集團 honeypot 探測（先前回信等於讓對方知道處理流程）。5/14、5/18 兩波 1,200–1,500 萬 req DDoS，打的正是信中檢舉的文章，判斷寄信者即攻擊者、目的為逼下架；處置為 Cloudflare WAF Managed Challenge。（出處：20240520 會議紀錄）
- 2024/12/22、2025/01/02：同一信箱再來信要求刪除二次詐騙回應／文章。
- 2026/05/05：LINE 使用者「激勵性的中山區泰勒」建立帳號，之後 5 個月送出 29 篇「某某是投資詐騙」。
- 2026/07/29–08/21：該使用者送出聚善共築、禾光啟源、愛聚時光、映善 × Lumentum、映善 Lumen Mind 等；洗白方隨後出現。「李總敏」樣板話術洗白已於 0818 公告封鎖（#334）；「深沉的大安班奈特」品牌洗白 SEO 於 0820 封鎖。
- 2026/10/02：同一信箱兩封信（簡繁各一）要求下架禾光啟源、刪除或更正映善兩篇，論點「證據不足、不應給確定性結論」。
- 2026/10/06 00:52–01:22：新帳號「細節的新豐格吉爾」送 4 篇洗白文，已封鎖的「深沉的大安班奈特」交錯送 5 篇（#358）；02:13–02:37 為上述 6 帳號。
檢舉方分析：29 篇皆「某某是投資詐騙」，14 篇附官方通報字樣（警政署 165、金管會、數發部），15 篇無官方來源（7/29 後針對「包裝成公益團體」的 8 篇幾乎全無來源）。WG 於 0821 公告判為「警示他人的一般回報者」。支持「集團互相攻訐」：近期無來源、句型制式、帶內部資訊口吻；支持「反詐檢舉者」：5 個月 29 個不同對象、早期附官方通報、無來源不等於不實、洗白方「查無商工登記就推定虛構」推論薄弱。尚未做：以經濟部登記／165／金管會逐一核對近期無來源指控。封鎖洗白帳號依據的是行為（同裝置操控、全部活動皆洗白），與誰說真話無關；日後處理檢舉者文章，標準應一致（可核實性、是否協同行為）。
確定 vs 推論
- 有資料支持：6 帳號唯一活動皆與同 IP 的 API POST 在 0–1 秒內重合；IP 動作前後瀏覽目標文章；標的與 10/02 來信相同；四個月來洗白敘事一致（要求證據、警告「假律師追款」）。
- 僅為推論：10/02 寄信者即操作者；與 2024/05 honeypot／DDoS 同一方；與李總敏、深沉的大安班奈特同一方；檢舉方與被指控集團是否為對手。
- 尚未查：來信者在 Cofacts 是否有帳號／reply；#358 帳號與 8 月帳號 IP（Cloudflare 資料只留約 4 週）；Cloudflare 看不到 request body，POST 與 mutation 的對應是時間推斷。
建議與討論
- 回信：2024/05 前例是被檢舉信誘出處理流程後遭 DDoS 施壓；回信前不透露流程與判斷標準，依 takedowns 流程處理，不因來信或攻擊而下架。
- 防護：是否對該 IP 加 WAF 規則（對方會換 IP）；是否預先對
3h9lawefylu95、2shkneniiib1y、1ktg8az7gcid1 三篇文章加 Managed Challenge 防 2024/05 式 DDoS。
- PR：是否補 IP 證據到 #359–#364 描述（公開公告不放 IP）。
相關 takedowns：1006-seo-reputation-management、-2。
</details>
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management.md
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management-2.md
- 選前 cofacts 不希望倒站，是可以考慮預先加 challenge [name=mrorz]
- 也可以設定只限台灣存取 [name=nonumpa]
- 其他網站也被洗留言，但通常會搭配二次詐騙，最近好像沒有 [name=nonumpa]
- 現在的行為真的很怪，沒有搭 LINE ID 就純洗形象 [name=mrorz]
易拉展
- X 展架的棒子只有兩截，收納袋 100cm 長，需要另外託運
- 健豪有四截式易拉展
Mozfest booth
上週重點整理（2026-09-29 ～ 2026-10-06）
GitHub 活動
cofacts/rumors-api
- #388 vector search（review 中，10/05 仍有更新；ListArticles(mediaUrl) 改依登入/未登入決定是否建檔）
- #405 transcript fallback 由 gemini-2.5-flash 換成 gemini-3.5-flash（closed 09-30，同時 closed #403）
- #400 transcript 直接把 media URI 交給 Vertex，不再複製到 GCS（closed 09-30）
- release/20260930
cofacts/rumors-site
cofacts/rumors-line-bot
cofacts/ai
- #147 [Demo preview] English UI + filing new messages（opened 09-29）
- #138 Report a suspicious message through a form at /report（10/04 有 review）
cofacts/devops
- #24 docs(cloudflare): add DDoS response SOP（opened 10-02 / closed 10-03）
- #25 Staging VPS OS 升級（Ubuntu 16.04 太舊）（opened 10-05）
- #23 Langfuse v3 → v4 升級追蹤（10/05 有新留言）
cofacts/kb
- #29 以 Jev 實作 Cofacts Topic Classifier 之可行性評估（10/05 有新留言）
cofacts/takedowns
Discord 重點討論
general
@chewei 想邀請 Cofacts 11/02 週一晚上，參加 AI Monday 線上分享
https://g0v.hackmd.io/@jothon/ai
- TA of AI monday?
- Coscup slides / 共筆 有些內容偏技術細節
[!Note] TODO
bil 會主講
投影片要放在 https://docs.google.com/spreadsheets/d/1y9RLwi-O040_NhvmGpuEhXXPSvsbgbHWgiAmIioI6i0/edit?pli=1&gid=0#gid=0&range=G35
alerts
10/05 Cofacts down（Health Check：cofacts.tw）
dev
@MrOrz（10-02）：query time 的 transcript 本來就存進正式位置；embedding 也是 query time 運算，沒必要另闢暫存機制，transcript 和 embedding 共用同一個 GCS file 比較簡潔。Media manager 有 media hash 機制，同檔案分配同一個 id
@MrOrz（10-02）：ListArticles with media 只有 LINE bot 用，且 always transcript.shouldCreate: true，breaking change 應無實際影響
@MrOrz（10-02）：yutin-local-dev service account 已有 rumors-db bucket 權限，可依 opendata CONTRIBUTING 把 production backup 還原到本機 ES 分析 hyperlinks（文件語法可能是 ES 6 舊版，歡迎發 PR 更新）
Cofacts production 環境週報（2026-09-29 ～ 2026-10-06）
總結： 本週系統整體穩定。Cloud Run 11 個服務都正常（✔）。GCE 主機的 Swap 從約 49% 降到約 31%，比上週好。需要注意的有兩件事：site-tw 的記憶體一直貼著上限，以及 10/03 出現一次記憶體尖峰。
GCE 主機（cofacts-prod）每日指標
格式：min | avg | p95 | max（%）
日期
CPU
Mem
Swap
09-29
8.8 | 16.2 | 21.7 | 46.7
63.5 | 66.1 | 68.5 | 70.6
46.9 | 48.7 | 51.6 | 52.1
09-30
10.4 | 15.6 | 20.5 | 32.8
62.0 | 65.1 | 67.3 | 69.0
21.7 | 32.6 | 48.7 | 49.8
10-01
10.5 | 16.8 | 21.9 | 25.9
61.4 | 64.8 | 66.5 | 69.2
27.7 | 29.9 | 32.2 | 33.8
10-02
10.5 | 17.4 | 23.9 | 39.5
62.0 | 64.9 | 66.8 | 68.1
29.6 | 30.8 | 32.9 | 34.8
10-03
12.0 | 17.8 | 23.1 | 34.8
62.7 | 65.5 | 67.3 | 85.1
28.6 | 30.2 | 33.2 | 34.1
10-04
10.2 | 16.9 | 22.7 | 45.1
62.0 | 65.4 | 67.5 | 69.9
29.1 | 31.0 | 33.0 | 34.4
10-05
11.2 | 18.4 | 24.1 | 46.3
63.1 | 65.7 | 68.1 | 69.9
29.8 | 31.4 | 33.6 | 34.4
10-06*
15.2 | 21.3 | 27.6 | 27.6
62.4 | 65.1 | 66.4 | 66.5
32.4 | 33.7 | 35.8 | 35.9
* 10-06 只有部分時段的資料。
目前狀態：已開機 152 天，load average 約 1.4，可用記憶體 10 GiB，Swap 用了 1.3 / 4 GiB，磁碟用了 61%（41 / 67 GB）。
GCE 主要行程
| 行程 | 平時用量（日均） | 穩定度（Stddev） | 觀察 |
|—|—|—|—|
| Elasticsearch | RSS 約 19.3 GB；CPU 比上週多約 6% | 低（RSS std 約 113 MB） | 很穩定。CPU 峰值從上週的 647k 降到 398k |
| node /srv/www/server.js（rumors-site） | RSS 約 358 MB（峰值 897） | 中等 | 和上週差不多（342 MB） |
| node /srv/www/build/index.js（API） | RSS 約 153 MB；CPU 比上週多約 3% | 低 | 10/06 CPU 略升 |
| python main.py（cofacts-ai） | RSS 約 86 MB；CPU 約 4k | 10/02 到 10/05 波動大 | 10/03 CPU 峰值約平常的 10 倍（37k，std 7.7k），可能是批次工作或突發的 AI 請求 |
| pm2-runtime | RSS 約 81 MB（上週 171） | 09/30 之後很低 | 09/30 RSS 從 393 降到約 70 MB，同一天 Swap 也降了，看起來是 pm2 重啟或重新部署後釋放出來的 |
| cloudflared | CPU 比上週多約 31% | 低 | 和流量一起上升，屬於正常範圍 |
| Chromium（puppeteer） | 上週有好幾個 renderer 佔了 500 MB 以上 | — | 本週峰值降到 378 MB 以下，比上週好 |
Cloud Run 服務
CPU 和 Mem 都是使用率比例（1.0 = 用到上限）。p50 取一週平均，p99 取一週最高。
服務
CPU p50 / p95 / p99
Mem p50 / p95 / p99
觀察
site-tw
0.09 / 0.78 / 1.01
0.79 / 0.98 / 1.01
記憶體 p95 長期貼近上限，上週也一樣。建議評估調高記憶體上限，或排查有沒有記憶體洩漏。每日外流流量約 4.8 GB（上週 5.7 GB，下降約 16%），符合 WAF 和快取的降費方向
cofacts-ai
0.016 / 0.17 / 0.34
0.06 / 0.07 / 0.07
10/04 有新部署。p95 CPU 從 0.12 升到 0.17，資源仍然很充裕
line-bot-en / ja / tw
約 0.01 / 0.12 / 0.3～0.43
約 0.40 / 0.43 / 0.63
10/01 有新部署，運作穩定
site-staging-tw / en / ja
約 0.006 / 0.1～0.2 / 0.3～0.44
約 0.75 / 0.9 / 0.98～1.01
staging-ja 從 10/03 開始才有流量，記憶體 p99 有碰到上限，但這是 staging 環境，影響很低
dev-line-bot
0.006 / 0.12 / 0.13
0.41 / 0.43 / 0.44
正常
建議
- site-tw 記憶體：p95 約 0.98、p99 超過 1.0，已經連續兩週。建議查 Cloud Run 有沒有 OOM 或 instance 重啟的紀錄，再決定要調高記憶體上限，還是追查洩漏。
- 10/03 GCE 記憶體尖峰（85%）：只出現過一次（當天 p95 只有 67%），時間上和
python main.py 的 CPU 尖峰吻合，推測是 cofacts-ai 的突發工作。如果之後還會發生，再深入追查。
- Egress：site-tw 的外流流量又降了約 16%，可以留到 10 月帳單一起驗收。
原始摘要檔都存在 workspace/metrics/*_2026-09-29_2026-10-06_1791259028_summary.json。
原始 HTML 存檔（artifact 設為「知道連結即可檢視」）：artifacts/20261006-AL2f6ZNFhX2KuK9VZGnYEq.html
/.env、/.aws/config）。utm_source=chatgpt.com）53→69（+30%，與本次調整無關）；chatgpt.com referer 8.1→4.4；gemini.google.com 2.1→0.6；copilot.microsoft.com 0.5→0.9；perplexity.ai 0→0；www.google.com 4,795→9,111（9/26 起大增，原因不明）。Claude 引用連結可能不帶 referer。[!Note] bil 說可以 先拉到 2GB ram 試試看
Artifact 內容摘要：禾光啟源洗白案（2026-10-06 整理）</summary>
本 repo 為公開 repo，此摘要刻意省略 IP 位址、帳號 userId 等細節；takedowns 公告也只寫「WG 另掌握證據」。完整內容見 artifact 與 takedowns repo。
核心發現：10/06 凌晨（台灣時間）針對「禾光啟源」「映善 Lumen Mind」兩篇訊息出現 6 個新帳號（takedowns PR #359–#364），每個帳號送出內容的那幾秒，Cloudflare 都記錄到同一個 IP（US 資料中心 VPS）對 api.cofacts.tw/graphql 的 POST；該 IP 在動作前後持續瀏覽這兩篇文章（通過 Cloudflare challenge，像真實瀏覽器）。被洗白的目標與 10/02 來信要求下架的文章相同，極可能同一操作者，但無直接證據。6 個帳號在 02:13–02:37 間 24 分鐘內依序出手（4 個查核回應、2 個回報補充），皆已 merge 並封鎖（#361–#364 共用 -2.md 公告，分支歷史整理為單一 commit）。
時間線
- 2024/05/09–12：同一信箱兩度來信「檢舉二次詐騙」；5/14 mrorz 判定為詐騙集團 honeypot 探測（先前回信等於讓對方知道處理流程）。5/14、5/18 兩波 1,200–1,500 萬 req DDoS，打的正是信中檢舉的文章，判斷寄信者即攻擊者、目的為逼下架；處置為 Cloudflare WAF Managed Challenge。（出處：20240520 會議紀錄）
- 2024/12/22、2025/01/02：同一信箱再來信要求刪除二次詐騙回應／文章。
- 2026/05/05：LINE 使用者「激勵性的中山區泰勒」建立帳號，之後 5 個月送出 29 篇「某某是投資詐騙」。
- 2026/07/29–08/21：該使用者送出聚善共築、禾光啟源、愛聚時光、映善 × Lumentum、映善 Lumen Mind 等；洗白方隨後出現。「李總敏」樣板話術洗白已於 0818 公告封鎖（#334）；「深沉的大安班奈特」品牌洗白 SEO 於 0820 封鎖。
- 2026/10/02：同一信箱兩封信（簡繁各一）要求下架禾光啟源、刪除或更正映善兩篇，論點「證據不足、不應給確定性結論」。
- 2026/10/06 00:52–01:22：新帳號「細節的新豐格吉爾」送 4 篇洗白文，已封鎖的「深沉的大安班奈特」交錯送 5 篇（#358）；02:13–02:37 為上述 6 帳號。
檢舉方分析：29 篇皆「某某是投資詐騙」，14 篇附官方通報字樣（警政署 165、金管會、數發部），15 篇無官方來源（7/29 後針對「包裝成公益團體」的 8 篇幾乎全無來源）。WG 於 0821 公告判為「警示他人的一般回報者」。支持「集團互相攻訐」：近期無來源、句型制式、帶內部資訊口吻；支持「反詐檢舉者」：5 個月 29 個不同對象、早期附官方通報、無來源不等於不實、洗白方「查無商工登記就推定虛構」推論薄弱。尚未做：以經濟部登記／165／金管會逐一核對近期無來源指控。封鎖洗白帳號依據的是行為（同裝置操控、全部活動皆洗白），與誰說真話無關；日後處理檢舉者文章，標準應一致（可核實性、是否協同行為）。
確定 vs 推論
- 有資料支持：6 帳號唯一活動皆與同 IP 的 API POST 在 0–1 秒內重合；IP 動作前後瀏覽目標文章；標的與 10/02 來信相同；四個月來洗白敘事一致（要求證據、警告「假律師追款」）。
- 僅為推論：10/02 寄信者即操作者；與 2024/05 honeypot／DDoS 同一方；與李總敏、深沉的大安班奈特同一方；檢舉方與被指控集團是否為對手。
- 尚未查：來信者在 Cofacts 是否有帳號／reply；#358 帳號與 8 月帳號 IP（Cloudflare 資料只留約 4 週）；Cloudflare 看不到 request body，POST 與 mutation 的對應是時間推斷。
建議與討論
- 回信：2024/05 前例是被檢舉信誘出處理流程後遭 DDoS 施壓；回信前不透露流程與判斷標準，依 takedowns 流程處理，不因來信或攻擊而下架。
- 防護：是否對該 IP 加 WAF 規則（對方會換 IP）；是否預先對
3h9lawefylu95、2shkneniiib1y、1ktg8az7gcid1 三篇文章加 Managed Challenge 防 2024/05 式 DDoS。
- PR：是否補 IP 證據到 #359–#364 描述（公開公告不放 IP）。
相關 takedowns：1006-seo-reputation-management、-2。
</details>
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management.md
- https://github.com/cofacts/takedowns/blob/master/2026/1006-seo-reputation-management-2.md
- 選前 cofacts 不希望倒站，是可以考慮預先加 challenge [name=mrorz]
- 也可以設定只限台灣存取 [name=nonumpa]
- 其他網站也被洗留言，但通常會搭配二次詐騙，最近好像沒有 [name=nonumpa]
- 現在的行為真的很怪，沒有搭 LINE ID 就純洗形象 [name=mrorz]
易拉展
- X 展架的棒子只有兩截，收納袋 100cm 長，需要另外託運
- 健豪有四截式易拉展
Mozfest booth
上週重點整理（2026-09-29 ～ 2026-10-06）
GitHub 活動
cofacts/rumors-api
- #388 vector search（review 中，10/05 仍有更新；ListArticles(mediaUrl) 改依登入/未登入決定是否建檔）
- #405 transcript fallback 由 gemini-2.5-flash 換成 gemini-3.5-flash（closed 09-30，同時 closed #403）
- #400 transcript 直接把 media URI 交給 Vertex，不再複製到 GCS（closed 09-30）
- release/20260930
cofacts/rumors-site
cofacts/rumors-line-bot
cofacts/ai
- #147 [Demo preview] English UI + filing new messages（opened 09-29）
- #138 Report a suspicious message through a form at /report（10/04 有 review）
cofacts/devops
- #24 docs(cloudflare): add DDoS response SOP（opened 10-02 / closed 10-03）
- #25 Staging VPS OS 升級（Ubuntu 16.04 太舊）（opened 10-05）
- #23 Langfuse v3 → v4 升級追蹤（10/05 有新留言）
cofacts/kb
- #29 以 Jev 實作 Cofacts Topic Classifier 之可行性評估（10/05 有新留言）
cofacts/takedowns
Discord 重點討論
general
@chewei 想邀請 Cofacts 11/02 週一晚上，參加 AI Monday 線上分享
https://g0v.hackmd.io/@jothon/ai
- TA of AI monday?
- Coscup slides / 共筆 有些內容偏技術細節
[!Note] TODO
bil 會主講
投影片要放在 https://docs.google.com/spreadsheets/d/1y9RLwi-O040_NhvmGpuEhXXPSvsbgbHWgiAmIioI6i0/edit?pli=1&gid=0#gid=0&range=G35
alerts
10/05 Cofacts down（Health Check：cofacts.tw）
dev
@MrOrz（10-02）：query time 的 transcript 本來就存進正式位置；embedding 也是 query time 運算，沒必要另闢暫存機制，transcript 和 embedding 共用同一個 GCS file 比較簡潔。Media manager 有 media hash 機制，同檔案分配同一個 id
@MrOrz（10-02）：ListArticles with media 只有 LINE bot 用，且 always transcript.shouldCreate: true，breaking change 應無實際影響
@MrOrz（10-02）：yutin-local-dev service account 已有 rumors-db bucket 權限，可依 opendata CONTRIBUTING 把 production backup 還原到本機 ES 分析 hyperlinks（文件語法可能是 ES 6 舊版，歡迎發 PR 更新）
Cofacts production 環境週報（2026-09-29 ～ 2026-10-06）
總結： 本週系統整體穩定。Cloud Run 11 個服務都正常（✔）。GCE 主機的 Swap 從約 49% 降到約 31%，比上週好。需要注意的有兩件事：site-tw 的記憶體一直貼著上限，以及 10/03 出現一次記憶體尖峰。
GCE 主機（cofacts-prod）每日指標
格式：min | avg | p95 | max（%）
日期
CPU
Mem
Swap
09-29
8.8 | 16.2 | 21.7 | 46.7
63.5 | 66.1 | 68.5 | 70.6
46.9 | 48.7 | 51.6 | 52.1
09-30
10.4 | 15.6 | 20.5 | 32.8
62.0 | 65.1 | 67.3 | 69.0
21.7 | 32.6 | 48.7 | 49.8
10-01
10.5 | 16.8 | 21.9 | 25.9
61.4 | 64.8 | 66.5 | 69.2
27.7 | 29.9 | 32.2 | 33.8
10-02
10.5 | 17.4 | 23.9 | 39.5
62.0 | 64.9 | 66.8 | 68.1
29.6 | 30.8 | 32.9 | 34.8
10-03
12.0 | 17.8 | 23.1 | 34.8
62.7 | 65.5 | 67.3 | 85.1
28.6 | 30.2 | 33.2 | 34.1
10-04
10.2 | 16.9 | 22.7 | 45.1
62.0 | 65.4 | 67.5 | 69.9
29.1 | 31.0 | 33.0 | 34.4
10-05
11.2 | 18.4 | 24.1 | 46.3
63.1 | 65.7 | 68.1 | 69.9
29.8 | 31.4 | 33.6 | 34.4
10-06*
15.2 | 21.3 | 27.6 | 27.6
62.4 | 65.1 | 66.4 | 66.5
32.4 | 33.7 | 35.8 | 35.9
* 10-06 只有部分時段的資料。
目前狀態：已開機 152 天，load average 約 1.4，可用記憶體 10 GiB，Swap 用了 1.3 / 4 GiB，磁碟用了 61%（41 / 67 GB）。
GCE 主要行程
| 行程 | 平時用量（日均） | 穩定度（Stddev） | 觀察 |
|—|—|—|—|
| Elasticsearch | RSS 約 19.3 GB；CPU 比上週多約 6% | 低（RSS std 約 113 MB） | 很穩定。CPU 峰值從上週的 647k 降到 398k |
| node /srv/www/server.js（rumors-site） | RSS 約 358 MB（峰值 897） | 中等 | 和上週差不多（342 MB） |
| node /srv/www/build/index.js（API） | RSS 約 153 MB；CPU 比上週多約 3% | 低 | 10/06 CPU 略升 |
| python main.py（cofacts-ai） | RSS 約 86 MB；CPU 約 4k | 10/02 到 10/05 波動大 | 10/03 CPU 峰值約平常的 10 倍（37k，std 7.7k），可能是批次工作或突發的 AI 請求 |
| pm2-runtime | RSS 約 81 MB（上週 171） | 09/30 之後很低 | 09/30 RSS 從 393 降到約 70 MB，同一天 Swap 也降了，看起來是 pm2 重啟或重新部署後釋放出來的 |
| cloudflared | CPU 比上週多約 31% | 低 | 和流量一起上升，屬於正常範圍 |
| Chromium（puppeteer） | 上週有好幾個 renderer 佔了 500 MB 以上 | — | 本週峰值降到 378 MB 以下，比上週好 |
Cloud Run 服務
CPU 和 Mem 都是使用率比例（1.0 = 用到上限）。p50 取一週平均，p99 取一週最高。
服務
CPU p50 / p95 / p99
Mem p50 / p95 / p99
觀察
site-tw
0.09 / 0.78 / 1.01
0.79 / 0.98 / 1.01
記憶體 p95 長期貼近上限，上週也一樣。建議評估調高記憶體上限，或排查有沒有記憶體洩漏。每日外流流量約 4.8 GB（上週 5.7 GB，下降約 16%），符合 WAF 和快取的降費方向
cofacts-ai
0.016 / 0.17 / 0.34
0.06 / 0.07 / 0.07
10/04 有新部署。p95 CPU 從 0.12 升到 0.17，資源仍然很充裕
line-bot-en / ja / tw
約 0.01 / 0.12 / 0.3～0.43
約 0.40 / 0.43 / 0.63
10/01 有新部署，運作穩定
site-staging-tw / en / ja
約 0.006 / 0.1～0.2 / 0.3～0.44
約 0.75 / 0.9 / 0.98～1.01
staging-ja 從 10/03 開始才有流量，記憶體 p99 有碰到上限，但這是 staging 環境，影響很低
dev-line-bot
0.006 / 0.12 / 0.13
0.41 / 0.43 / 0.44
正常
建議
- site-tw 記憶體：p95 約 0.98、p99 超過 1.0，已經連續兩週。建議查 Cloud Run 有沒有 OOM 或 instance 重啟的紀錄，再決定要調高記憶體上限，還是追查洩漏。
- 10/03 GCE 記憶體尖峰（85%）：只出現過一次（當天 p95 只有 67%），時間上和
python main.py 的 CPU 尖峰吻合，推測是 cofacts-ai 的突發工作。如果之後還會發生，再深入追查。
- Egress：site-tw 的外流流量又降了約 16%，可以留到 10 月帳單一起驗收。
原始摘要檔都存在 workspace/metrics/*_2026-09-29_2026-10-06_1791259028_summary.json。
本 repo 為公開 repo，此摘要刻意省略 IP 位址、帳號 userId 等細節；takedowns 公告也只寫「WG 另掌握證據」。完整內容見 artifact 與 takedowns repo。
api.cofacts.tw/graphql 的 POST；該 IP 在動作前後持續瀏覽這兩篇文章（通過 Cloudflare challenge，像真實瀏覽器）。被洗白的目標與 10/02 來信要求下架的文章相同，極可能同一操作者，但無直接證據。6 個帳號在 02:13–02:37 間 24 分鐘內依序出手（4 個查核回應、2 個回報補充），皆已 merge 並封鎖（#361–#364 共用 -2.md 公告，分支歷史整理為單一 commit）。3h9lawefylu95、2shkneniiib1y、1ktg8az7gcid1 三篇文章加 Managed Challenge 防 2024/05 式 DDoS。- 現在的行為真的很怪，沒有搭 LINE ID 就純洗形象 [name=mrorz]
@chewei 想邀請 Cofacts 11/02 週一晚上，參加 AI Monday 線上分享 https://g0v.hackmd.io/@jothon/ai
- Coscup slides / 共筆 有些內容偏技術細節
[!Note] TODO bil 會主講 投影片要放在 https://docs.google.com/spreadsheets/d/1y9RLwi-O040_NhvmGpuEhXXPSvsbgbHWgiAmIioI6i0/edit?pli=1&gid=0#gid=0&range=G35
10/05 Cofacts down（Health Check：cofacts.tw）
@MrOrz（10-02）：query time 的 transcript 本來就存進正式位置；embedding 也是 query time 運算，沒必要另闢暫存機制，transcript 和 embedding 共用同一個 GCS file 比較簡潔。Media manager 有 media hash 機制，同檔案分配同一個 id
@MrOrz（10-02）：ListArticles with media 只有 LINE bot 用，且 always transcript.shouldCreate: true，breaking change 應無實際影響
@MrOrz（10-02）：yutin-local-dev service account 已有 rumors-db bucket 權限，可依 opendata CONTRIBUTING 把 production backup 還原到本機 ES 分析 hyperlinks（文件語法可能是 ES 6 舊版，歡迎發 PR 更新）
site-tw 的記憶體一直貼著上限，以及 10/03 出現一次記憶體尖峰。min | avg | p95 | max（%）node /srv/www/server.js（rumors-site） | RSS 約 358 MB（峰值 897） | 中等 | 和上週差不多（342 MB） |
| node /srv/www/build/index.js（API） | RSS 約 153 MB；CPU 比上週多約 3% | 低 | 10/06 CPU 略升 |
| python main.py（cofacts-ai） | RSS 約 86 MB；CPU 約 4k | 10/02 到 10/05 波動大 | 10/03 CPU 峰值約平常的 10 倍（37k，std 7.7k），可能是批次工作或突發的 AI 請求 |
| pm2-runtime | RSS 約 81 MB（上週 171） | 09/30 之後很低 | 09/30 RSS 從 393 降到約 70 MB，同一天 Swap 也降了，看起來是 pm2 重啟或重新部署後釋放出來的 |
| cloudflared | CPU 比上週多約 31% | 低 | 和流量一起上升，屬於正常範圍 |
| Chromium（puppeteer） | 上週有好幾個 renderer 佔了 500 MB 以上 | — | 本週峰值降到 378 MB 以下，比上週好 |python main.py 的 CPU 尖峰吻合，推測是 cofacts-ai 的突發工作。如果之後還會發生，再深入追查。workspace/metrics/*_2026-09-29_2026-10-06_1791259028_summary.json。