TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
WebCamera 開源監控工具：官網改賣 VPN，自架 2 秒連線
WebCamera 是把舊手機變成網路攝影機的開源 WebRTC 工具，實測發現官方網站已兩度易主、現在轉址到 VPN 促銷頁，但 GitHub 上的 MIT 原始碼自架後仍可完整運作：本篇記錄安裝撞牆與連線成功的全程，並拆解它點對點宣稱背後的訊號伺服器、Math.random 連線 ID 與沒有 TURN 中繼的三個邊界。
用 AI 摘要這篇文章：
今天從搜尋結果點進 WebCamera 官網的人，看到的不會是攝影機監控工具，而是一頁名為 GreatFireVPN 的 VPN 促銷內容。原本的每一條功能網址，包含攝影機頁與監看頁，全都轉址到這頁廣告。
不過這個工具的原始碼還在 GitHub 上，MIT 授權、462 顆星。我把它抓下來在自己的機器上自架，攝影機頁與監看頁在 2.1 秒內完成連線，影像正常流動。先從這個工具原本的樣子說起。
兩頁共用一組 ID，就是它的全部設計
WebCamera 是一個用 Nuxt.js 寫的網頁工具，用途是把一支閒置的手機或電腦變成網路攝影機，讓另一台裝置遠端看畫面。它沒有帳號系統，也沒有 App，介面只有中英兩種語言可切換。
整個使用流程只有兩個頁面。攝影機裝置打開「攝影機」頁，系統自動產生一組 16 字元的連線 ID，輸入框預設用圓點遮住，旁邊有眼睛圖示可以揭開；監看端打開「監看」頁，填入同一組 ID 按連線，畫面就過來了。攝影機頁能選視訊設備與解析度（選單預設 4K 優先），可以打開聲音，也有斷線後自動重連的開關。監看頁內建錄影，錄製時會顯示經過時間與檔案大小，存檔格式由頁面依瀏覽器支援自動挑選。
配對完成後，影像走瀏覽器內建的 WebRTC 通道點對點傳輸。專案在 2024 年 5 月底上架，約兩週內累積 29 次提交，之後程式碼停在 6 月 13 日，再也沒有動過。
官網兩度易主：從攝影機工具到新聞鏡像，再到 VPN 廣告
網域過期被別人接手，是小型開源專案最常見的死法，WebCamera 是一份完整樣本。
網頁存檔紀錄顯示：原始網站一路活到 2024 年 11 月 11 日，中間都有正常快照；2024 年 12 月起，存檔服務多半已抓不到內容。網域的註冊紀錄則顯示現任持有者是 2025 年 11 月重新註冊的，註冊人身分躲在隱私保護後面；到了 2026 年 4 月，同一個網域上掛的是一個俄羅斯新聞鏡像站，頁面圖片代理自俄羅斯媒體與 Telegram 的檔案位址。而今天，所有路徑一律以 302 轉址，目的地是 /vpn/ 目錄下的促銷頁，標語主打在中國、俄羅斯、伊朗、印度繞過網路審查；伺服器送來的標頭還帶著一個名為 smm_redirected_to 的 cookie，是轉址行銷系統的典型手痕。
倉庫端的訊號也很一致。掛著的兩個提問 issue，一個是 2024 年 7 月反映的連線超時，一個是 2024 年 10 月問的 USB 攝影機相容問題，作者其實都親自答覆過，前者告訴提問者可以自己部署、後者建議檢查瀏覽器的攝影機授權；但那之後程式碼就沒有再動過，作者在 repo 的寫碼足跡停在 2024 年 6 月。
要說清楚的是，這不代表作者有什麼問題，沒有人有義務永遠維護免費工具。只是結果很實際：搜尋引擎裡累積的推薦文還在，點進去卻是廣告頁，而工具本身的重生路徑只剩自架一條。順帶一個安全提醒：這類被轉賣的舊網域，價值就在殘留的點擊流量，接手的人想把流量變現，你不會知道頁面上的下載鈕連去哪裡；從舊推薦文點進任何已經改頭換面的網站，安裝或輸入資料前都值得多看一眼。WebCamera 本體是網頁服務，從來沒有安裝檔，真正的原始出處只有 GitHub 倉庫一個。
自架實測：正式建置會撞牆，開發模式完好
照 README 的順序走：抓原始碼、裝依賴、建置、啟動。我實際跑了兩種裝法，一種讓 npm 自行解析依賴，裝了 1432 個套件；另一種用倉庫附的 yarn.lock 凍結依賴樹，鎖在作者當年的 vue 3.4.27 與 nuxt 3.11.2。Node 22 與 Node 26 兩種執行環境都試過。
三種組合的結果一致：伺服器行程啟動正常，負責配對的 API 也活著，攝影機頁的註冊端點正確吐出事件流；但三個頁面在正式建置下全部變成 500 錯誤頁，畫面渲染層直接崩潰。換成開發模式啟動，三個頁面立刻全部正常。
這說明這份 28 個月前凍結的 Nuxt 3.11 專案，在今天的正式建置管線上有相容性斷層，但程式碼本身沒有壞。README 附的 Dockerfile 用浮動的 node:lts-alpine 基底映像，今天重新建置一樣會吃到新版 Node，能不能過全看運氣。想自架的人有兩條比較穩的路：先用開發模式驗證功能，正式部署時把基底釘在 Node 20 一代的映像檔重試；或者乾脆接手把依賴升到現在的 Nuxt 版本，程式量不大，這也是一個練手的方向。
實際把功能跑通的順序是這樣：抓下原始碼後用 yarn 裝依賴（沿用倉庫的鎖定檔），接著以開發模式啟動，服務會開在本機的 3000 埠；同一個網段的手機直接用瀏覽器打開電腦的位址，就能當攝影機端授權媒體。注意 localhost 以外的環境要拿攝影機權限，一定得走 HTTPS，所以對外開放時你要在前面掛反向代理與憑證；家裡沒有對外 IP 的人，再疊一層內網穿透，例如 frp 這類工具，我們先前介紹過有圖形介面的 frpc-desktop。習慣用 Docker 收拾自架服務的人，也可以參考現成的 docker compose 模板庫把整套服務納入管理。
硬體門檻低到可以忽略：建置出來的伺服器輸出只有 3.75MB，跑起來就是一支 Node 程式，配對流量是幾十 KB 以內的文字訊息，影像又不經過它。一台舊筆電或樹莓派等級的小機器，扛這個服務全家使用綽綽有餘，真正的成本在你願不願意花一個下午處理網域、憑證與建置斷層。
連線實錄：2.1 秒拿到畫面
我用兩個隔離的無頭瀏覽器環境，分別打開攝影機頁與監看頁做端到端測試。攝影機頁自動生成了一組 16 字元英數 ID，授權媒體後按下連線，設備欄位正確列出了視訊來源，解析度顯示 4K 優先。
監看頁貼入同一組 ID 再按連線，2.1 秒後監看端的畫面元件進入可播放狀態，收到 960×540 的影像串流。攝影機端的本地預覽是 3840×2160，兩邊的統計面板同步跳動：攝影機端送出約 53KB、收到約 2.6KB 的流量，狀態欄顯示已連線，本地與遠端候選位址都以 UDP 直連模式列出。整個配對過程，從交換連線資訊到協商媒體通道，都照設計走完。
兩邊的日誌欄把這 2.1 秒攤得很開：監看端先登記，接著收到攝影機端送來的媒體邀約，半秒內送出答覆；雙方各自丟出網路候選位址，互收對方的，前後不到一秒全部交換完畢，然後狀態跳成已連線。日誌欄同時也是除錯時最好的朋友，連不上卡在哪一步，看最後一條紀錄就知道。
拆開看這 2.1 秒裡發生的事，會更清楚伺服器站在哪個位置。攝影機頁按下連線時，先用自己的 ID 向伺服器登記一條持續連線；監看頁按下連線時，也是先向伺服器登記，然後把自己的識別碼託伺服器轉交給攝影機端；攝影機端收到後送出媒體邀約，對方答覆，兩端再交換一串網路候選位址，最後挑出一條能直通的路線，影像才開始流。登記表有上限：最多 2048 組 ID，閒置 10 分鐘自動釋出，自己一家人用餘裕非常大。
同一支手機放客廳、你人在公司用另一支手機看，走的就是這條管線。差別只在：這次測試的兩端在同一台機器上，跨網路的穿透情境沒有涵蓋，這點放到限制段談。
點對點的三個但書
README 說這是點對點加密連線。就媒體軌而言是真的：WebRTC 的影像與聲音走 DTLS 加密的直接通道，金鑰協商在兩端瀏覽器之間完成。但自架或使用前，有三個邊界值得知道。
配對這一步經過伺服器。剛才拆解的流程裡，邀約、答覆與候選位址全都經伺服器轉交，而候選位址包含兩端裝置的內網與公開 IP，實測紀錄裡就看得到帶公開 IP 的位址。影像本身不過伺服器，但誰跟誰連、兩端的位址，伺服器端看得到。用別人架的站，等於把你家的位址交給那個站；這也是自架的意義不只是續命的地方，它同時讓這個中繼角色收歸自己掌控。
連線 ID 是唯一憑證，而它不是密碼學等級的亂數。原始碼裡產生 ID 的函式用的是 Math.random()，湊 16 位英數字。拿到 ID 的人就能連上你的攝影機，所以 ID 等同密碼，分享時要走你信任的通道，用看待密碼的標準看待它，是比較安全的姿勢。有個小細節值得一提：攝影機頁會把 ID 存進瀏覽器的本機儲存，重開頁面不用重打，這很貼心，但也等於把這組密碼留在那台設備上，共用設備的人記得手動換一組。作者其實有想到日誌這一側，倉庫後期的提交特地改過伺服器輸出，讓它只印出 ID 的前六個字元。
穿牆能力有上限。專案的 ICE 清單放了兩百七十幾個公開 STUN 伺服器，裡面甚至有一個台灣的（stun.mitake.com.tw），但沒有任何 TURN 中繼。多數家用網路靠 STUN 就能穿透；換到公司或校園這類對稱 NAT 環境，可能直接配對失敗，而且沒有中繼備案。這不是實測結論，是從清單結構推得的行為邊界。
集中限制
正式建置在今日環境是 500 錯誤頁，自架得走開發模式，或自行處理建置與依賴升級。HTTPS 與網域是硬前置，瀏覽器不會在純 HTTP 的遠端頁面交出攝影機。沒有 TURN 中繼，對稱 NAT 環境可能連不上，屬推論未實測。單人維護、28 個月沒有任何程式碼更新，遇到問題沒有上游可以求助。本次連線測試在同一台機器的兩個頁面間完成，跨網路穿透、長時間運作、手機瀏覽器背景行為都沒有驗證。若打算開放給不特定的人連線，Math.random() 產生的 ID 強度需要自己再加固。
判斷：誰該撿，誰該繞
想練自架的人，這是一個乾淨的小題目：程式碼小、結構單純，MIT 授權也沒有商用疑慮，跑通之後你會完整摸過一遍 WebRTC 配對、訊號伺服器與憑證部署。先前介紹過的 cobalt 開源下載器也是同一種官方受限、自架復活的路線，喜歡這類練習的人可以對照著看。服務跑起來之後，UptimeFlare 這類存活監測可以順便掛上，斷線時你會第一個知道。
但如果你要的是放在客廳 24 小時穩定監看寵物或長輩的解方，我不建議把需求寄託在一個 28 個月沒人寫碼維護、正式建置還會撞牆的專案上。同一個需求，活躍維護中的 go2rtc 是更穩的選擇：約一萬四千顆星、MIT 授權、2026 年 9 月仍有程式碼活動，支援的協議與設備範圍也廣得多。
WebCamera 值得留下的，是它把「網頁就能做監控」推到極簡的那個設計：兩個頁面、一組 ID，沒有帳號也沒有 App。這個介面概念依然漂亮；只是它的地基，官網與維護者，都已經不在了。自架的人等於繼承了這份漂亮，也一併繼承它的所有帳單。
