民宿、學生宿舍想讓每位住戶用帳號登入、甚至分開計費，該怎麼做？本文從 captive portal 強制門戶的封包層運作、RADIUS 認證與計費，一路談到它與 WPA3 加密的分工，說明高雄租屋物件的住戶帳號管理與常見誤區。
captive portal 到底攔截了什麼？從封包層看它怎麼運作
你一定連過這種網路：手機一接上飯店、機場或咖啡廳的 WiFi，還沒開瀏覽器，畫面就自己跳出一個登入或同意條款的小視窗，按完才能上網。那個東西就是 captive portal。多數人以為它只是「一個網頁」，其實背後動作不少，值得拆開來看。
關鍵在於：在你通過認證之前，這個網路會把你圈養在一個叫 walled garden（圍籬花園）的白名單裡，只放行你連到登入頁和認證伺服器，其他一律先擋下或重導。它靠幾招把你的連線攔住：
- DNS 攔截：你的裝置想解析網址（例如查某個網站的 IP），閘道器不回真答案，直接丟回一個「登入頁伺服器的 IP」，於是瀏覽器連過去，看到的就是登入頁。
- HTTP 302 重導：你送出的一般 HTTP 請求會被閘道器攔下，回一個「302 暫時轉址」，瀏覽器就乖乖跟著跳到登入頁網址。
- 連線偵測探針：這是為什麼手機會「自己」跳出登入視窗。蘋果裝置在背景會偷偷連一個內含「Success」字樣的偵測小網頁，Android 則去連一個正常會回「HTTP 204 無內容」的網址。連得到就代表真的能上網；連不到、被登入頁攔住，作業系統就判定「這裡有強制門戶」，主動彈出那個內建的登入小瀏覽器。
等你在登入頁輸入帳密，後端通常交給一個叫 RADIUS 的認證伺服器去核對。核對過了，RADIUS 就通知現場的網路設備放行這台裝置，通常會綁著它的 MAC 位址記一段有效期，這樣你不必每開一個網頁就重登一次。整個流程講白了就是：攔下你、把你導到登入頁、驗明正身、再放你出去。搞懂這個順序，後面很多「為什麼登入頁不跳」「為什麼蘋果手機卡住」的毛病才有辦法對症下藥。
一人一帳號，值錢的不是「登入」而是「可追溯」
很多房東問：不就是多一道登入手續，有必要嗎？共用密碼難道不能用？能用，但共用密碼有三個先天缺陷，而 captive portal 剛好一次補齊。
- 可追溯：每個帳號對應到一個房號或一位住戶，誰在什麼時間用了多少流量、連了哪些設備，都留得下紀錄。真出事（例如有人拿你的網路做壞事、警察上門調閱），你拿得出對照表，不會全棟一起揹鍋。
- 可單獨處置：某個房客退租、或某支帳號被濫用，你只要停掉那一組，其他人完全不受影響。共用密碼一旦要換，是全棟一起重連，管理成本天差地遠。
- 可分級：登入頁天生就是個「入口」，你可以在這裡顯示使用條款、公告、報修連結，也能把它當成分級與升速的收費關卡。基本速度免費、加價升速，全靠這一頁做區隔。
最容易搞錯的一件事——登入頁不等於加密
這段我必須講重一點，因為它是實務上最常被裝機廠商含糊帶過、事後最容易出包的地方：captive portal 是「存取控制」，它本身不負責把你的無線傳輸加密。
用網路分層來看會更清楚。captive portal 是跑在比較上層（第三層與第七層）的網頁登入機制；真正把空中訊號加密的，是跑在第二層的 WPA2／WPA3（WPA3 用的是 SAE 這套更強的握手協定）。這兩件事各管各的，缺一不可。把它們搞混，是很多「明明有登入頁卻還是被竊聽」案例的根源。
問題就出在：如果你圖方便，把網路做成「開放網路＋登入頁」的形式（很多公共 WiFi 就是這樣），那麼登入頁自己就算掛了 HTTPS，登入之後你一般上網的流量在空中仍然是明文。同一個 SSID 底下，隔壁房間只要用點手法被動側錄，你逛了什麼、送了什麼，理論上都攔得到。對旅館、宿舍這種「一群陌生人共處一張網」的環境，這個風險不能不理。
正確做法是兩層一起上：底層用 WPA2／WPA3 把每台裝置的傳輸加密，上層再用 captive portal 做帳號登入與分級。如果你希望「客人不用打密碼、掃了就連」又不想犧牲加密，還有一招叫 OWE（機會式無線加密，也就是 WPA3 的 Enhanced Open），它能在不設密碼的開放網路上，替每一台裝置各自建立一條加密通道，讓「免密碼」和「有加密」同時成立，再接上登入頁做身分辨識，體驗最順。這是這兩年比較新、也比較優雅的解法。
順帶提醒，captive portal 本身也不是銅牆鐵壁。它常靠 MAC 位址記住「這台已登入」，而 MAC 是可以偽冒的；業界也出現過「架一個長得一模一樣的假登入頁」去釣住戶密碼的社交工程手法。所以登入管理一定要搭配加密、設定合理的連線有效期，別把一張登入頁當成整套資安來看。
「分開計費」技術上怎麼算？RADIUS accounting 與逐帳號限速
回到老闆娘最想要的分開計費。技術上這件事是成立的，關鍵字叫 RADIUS accounting（計費紀錄）。當設備開了 accounting，它會針對每個帳號回報累計的上傳與下載位元組（就是常聽到的 Acct-Input-Octets／Acct-Output-Octets 這類欄位），你就有了「這個房號這個月用了多少量」的原始數據，要按量、要設上限都有依據。
限速與升速也是同一套機制在管。透過 RADIUS 下發的頻寬屬性（例如業界常用的 WISPr-Bandwidth-Max-Up／Down 這種上下行上限），可以逐帳號指定「基本方案每秒幾 Mbps、升級方案每秒幾 Mbps」；房客一加價，你就把他的帳號套上另一組 policy，速度立刻不一樣，不必到現場動任何線。搭配前面文章談過的每戶限速與網段隔離，要做到分級、分流、記量，工程上都不算難。
難的不是技術，是技術以外的事。把網路做成「計費商品」對外收費，可能牽涉電信相關法規，也牽涉你跟房客的租賃契約——台灣的住宅租賃定型化契約，對「網路費由誰負擔」是建議白紙黑字寫清楚的。所以實務上，多數租屋物件會用 captive portal 來做帳號管理與分級體驗，把「升速」當成一種加值服務，而不是真的按流量逐戶開帳單。這一塊我一律建議保守處理：先把合約跟法規確認清楚，再決定要收到什麼程度，別為了省事惹上後面的麻煩。
什麼場景該上？幾個工程上的判準與常見坑
不是每個物件都需要 captive portal，也不是裝了就萬事太平。幾個實務上的判斷與地雷，先講在前面，能幫你少走冤枉路：
- 戶數少、關係單純的別硬上：四、五戶的透天分租，其實用「一戶一組 WPA2 密碼＋一戶一個 VLAN 網段隔離」就乾淨俐落，硬套 captive portal 反而多養一台伺服器、多一個故障點。青旅、學生宿舍、日租套房這種「人多、流動快、又要辨識」的場景，才是它真正發揮價值的地方。
- walled garden 白名單一定要開對：前面提到手機靠探針偵測強制門戶，如果你沒把那些偵測用網址，還有登入頁與認證伺服器一起放進白名單，就會出現「登入頁不自己跳出來」「蘋果裝置卡在轉圈圈連不上」的經典災情，這是新手最常踩的坑。
- 登入伺服器是單點，備援要先想好：captive portal 的認證入口一旦掛掉，全棟可能一起上不了網。這台服務放在哪、會不會自動重啟、斷了有沒有告警，導入前就要規劃清楚，不能等出事才在那邊手忙腳亂。
- 連線有效期要拿捏：設太短，客人三不五時被踢出來重登，體驗很差；設太長，帳號被借用、被冒用的風險就升高。這個值要按物件性質分別調——旅館短住可以短一點，宿舍長住就放寬些。
說到底，captive portal 解決的從來不只是「多一道登入」，而是讓一張大家共用的網路，變得可辨識、可管理、可分級。無論是青旅、學生宿舍還是長租套房，一人一帳號能讓你的網路看起來專業、用起來好管，出事時也查得到人。廷皓科技在高雄替民宿、宿舍、分租物件導入 captive portal 登入頁與帳號管理，底層搭配 WPA2／WPA3 加密、必要時上 OWE，並提供月約代管，連 walled garden 白名單、連線有效期、備援這些細節都幫你顧到。想讓住戶上網做到「一人一帳號、好管理」，歡迎跟我們聊聊。
