Cloudflare Access 私有 HTTP 網站登入改用瀏覽器後，先查這三件事
如果內網工具跑在明碼 HTTP 的 port 80，過去透過 Cloudflare Access 進入時，使用者可能先看到 Cloudflare One Client 的驗證通知，再由通知開啟瀏覽器。Cloudflare 7 月 20 日改為讓這類 private application 直接在瀏覽器走標準 Access login，成功後取得 application token。看見登入頁不代表 Cloudflare One Client 可以移除；它仍負責將流量路由到私有網路。
這是登入路徑的改變，不是把 HTTP 變成 HTTPS，也不是跳過 Access policy。
先確認你碰到的是 HTTP private application
這次改動的範圍是：經 Cloudflare Access 保護、使用 plaintext HTTP、port 80 的 private application。SSH、RDP、任意 TCP／UDP 等非 HTTP 協定仍維持 Cloudflare One Client 的通知登入流程。若你是在 SSH 登入失敗時套用這篇流程，方向就錯了。
| 現象 | 先確認的邊界 |
|---|---|
| 瀏覽器直接出現 Access login | 目標是否為 port 80 的 HTTP private app |
| 瀏覽器可登入但連不到 origin | Cloudflare One Client 是否仍在執行並有私有網路路由 |
| SSH／RDP 仍跳通知 | 預期行為；不在本次變更範圍 |
| 收到憑證或 mixed-content 警告 | 這不是 Access 登入流程可解決的 TLS 問題 |
排錯順序：路由、Access、再來才是應用程式
當登入成功但工具仍開不起來時，我會依序縮小範圍：
- 確認 Cloudflare One Client：官方說明它仍是把流量導向私有網路的必要元件；先確認使用者裝置已連線且能取得正確路由。
- 確認 Access application 與 policy：檢查目標 hostname／path 是否對上正確應用程式，以及身分提供者、群組或 service token 條件是否允許此次登入。
- 確認 origin 的 HTTP 回應：在已授權的網路環境，以瀏覽器或
curl -I檢查 origin 是否真的在 port 80 回應。不要從公開網路直接暴露 origin 來「驗證」。
# 在已授權、可抵達私有網路的環境執行curl -I http://internal.example.test/這個檢查只用來分辨 Access 後的應用程式回應，並不會取代 Access policy 或 Cloudflare One Client。
不要把 convenience 改成安全結論
直接開啟瀏覽器登入頁會少一個通知步驟，但它沒有替明碼 HTTP 加密內容。只要服務能改成 HTTPS，仍應依既有部署與憑證流程處理；而 Access policy、origin 防火牆與最小權限群組規則也仍要維持。這篇變更更適合拿來更新 helpdesk runbook：讓支援人員知道 HTTP private app 的第一個畫面現在是瀏覽器登入，而不是 Client 通知。
如果你同時管理不同帳號的 Workers 部署，可搭配 Wrangler authentication profiles 把登入帳號與部署帳號分開記錄；兩者解決的不是同一個問題。
參考資料：
Cloudflare Changelog：Browser-based login for plaintext HTTP private applications
回報錯字、失效連結，或告訴我你想看的延伸主題。