WordPress 隱藏登入網址：WPS Hide Login 教學

隱藏 WordPress 登入網址，不是把門鎖換得更強，而是把預設入口移開。對只會探測 /wp-login.php 與 /wp-admin 的自動化程式來說，少了現成入口，請求就比較難直接打到登入表單。

這項做法能減少預設路徑的掃描與記錄噪音，但不是存取控制，也不能取代強密碼、雙重驗證（2FA）、登入限流、WAF、更新與備份。把它當成低成本的輔助層，定位才不會跑掉。

為什麼公開登入網址會吸引自動化掃描

WordPress 的登入路徑固定，掃描程式不需要先研究網站內容，只要對網域送出 POST /wp-login.php 就能測試帳號密碼。暴力破解會對單一帳號嘗試大量密碼；credential stuffing（撞庫）則拿其他服務外洩的帳號密碼組合來測試。兩者都能自動化，失敗的請求仍會進入網站或前端防護層（見 OWASP 的撞庫防護指引）。

WordPress 使用比例高，預設登入路徑也容易被通用掃描工具辨識。W3Techs 的長期追蹤顯示，WordPress 占全球網站四成以上（2026 年 6 月資料）。不過，單一網站是否正在被掃描，仍要看自己的存取記錄，不能從市占率直接推定。

Statista 的行動裝置流量統計也不能拿來推論登入端點的風險。要判斷實際壓力，應查看 wp-login.php、xmlrpc.php 的請求方法、頻率、來源、回應碼，以及同時段的 PHP、資料庫與 WAF 記錄。

改登入網址後，只探測預設路徑的程式拿不到原本的登入表單；已經知道新網址的對象、會員登入頁或其他驗證端點則不受這層隱藏保護。大量登入請求可能消耗 PHP、資料庫與頻寬，實際影響仍取決於請求量、限流、快取及主機架構。網站變慢時，先用記錄確認瓶頸，不要把改網址當成效能修復保證。

判斷問題時，要把「有人敲門」和「有人成功登入」分開。Access log 能證明請求到過伺服器，卻不一定記錄 WordPress 驗證結果；WAF 記錄能顯示規則是否攔截，也不代表來源真的持有有效密碼。若安全外掛有登入事件記錄，可再核對帳號、成功或失敗、來源與時間。三種資料回答的問題不同，不能只看到一串 200 就宣稱帳號遭入侵。

可以先從主機面板下載 raw access log，搜尋 wp-login.php 與 xmlrpc.php。下面是刻意製作的格式示例，不是真實攻擊記錄：

192.0.2.10 - - [05/Aug/2026:03:14:22 +0800] "POST /wp-login.php HTTP/1.1" 200 1234

一筆記錄不足以判斷是否遭到攻擊。應比較同一路徑的請求量、時間分布、來源與 WAF 結果。200 只表示 HTTP 請求成功完成，不代表登入成功；3xx 表示重新導向；403 表示伺服器拒絕處理；404 表示找不到資源，或伺服器不願揭露資源是否存在；500 則是伺服器遇到無法完成請求的狀況（各狀態碼的定義見 RFC 9110）。

把變更前的基準數字記下來，改完登入網址後用相同時間範圍再比一次，才知道預設路徑的噪音是否下降。沒有所有網站都適用的固定攔截比例。

基準最好至少包含四個欄位：統計起訖時間、wp-login.php 請求數、xmlrpc.php 請求數、登入失敗事件數。比較前後資料時，使用相同時長與時區，並註記中間是否更換 WAF、CDN、主機或記錄保存設定。若前一週有七天資料、後一週只剩兩天，直接比較總數會得到錯誤結論；改看每日平均，也要保留尖峰時段，避免平均值掩蓋短時間的大量請求。

WPS Hide Login 到底做了什麼（還有，它沒做什麼）

WPS Hide Login 讓你指定新的登入路徑，並攔截對 wp-login.php 與未登入 wp-admin 的頁面請求。舊路徑會變得無法存取，實際顯示 404 頁面或前往哪個網址，取決於外掛設定與站點環境（見 WordPress.org 上的 WPS Hide Login 頁面）。

外掛官方說明很明確：它不會重新命名或修改 WordPress 核心檔案，也不會新增 rewrite rules，而是在 WordPress 載入後攔截頁面請求。停用外掛後，網站會回到啟用前的登入狀態。

這也說明了它的邊界。請求若先被 CDN、頁面快取、反向代理或主機安全層處理，看到的結果可能與 WordPress 應用層設定不同。問題不一定出在 Apache 或 Nginx 的網址重寫，也不能用「外掛註冊一組 rewrite rule」來解釋它的運作。

註冊、忘記密碼、登入小工具與工作階段過期等登入相關流程，官方表示仍可運作；但外掛或佈景主題若把 wp-login.php 寫死在程式碼裡，就可能不相容。多站台可使用子網域或子目錄，網路啟用時可設定全網預設值，各站仍可設定自己的登入網址（見 官方的相容性說明）。

「官方說可相容」不等於每個網站都不必測。會員站、課程站、電商站常有自訂登入、結帳或社群登入流程；有些郵件也會帶忘記密碼與啟用帳號連結。部署前先列出這些入口，部署後逐一點過。若網站讓使用者自行註冊，還要用一般會員權限測試，不能只用已登入的管理員畫面判斷。

它屬於 security through obscurity（靠隱密性降低曝光）的輔助手法，能降低預設入口的可見度，不能成為唯一防線。OWASP 的defense in depth（縱深防禦）強調多層、互補控制；登入安全仍應以唯一密碼、2FA、限流、最小權限、更新及可還原備份為主。

裝了之後會發生	裝了之後不會發生
預設登入路徑會被外掛攔截	弱密碼自動變安全
只探測預設路徑的請求可能減少	擋住知道新網址的攻擊者
未登入訪客無法從舊入口取得登入表單	取代 WAF、限流與雙重驗證
停用外掛後可恢復預設登入方式	讓核心、佈景主題與外掛不必更新

左欄處理的是預設路徑曝光，右欄是其他安全控制要負責的事。兩者混在一起，就容易高估外掛效果。

關於隱藏登入網址，兩個常見誤解

誤解一：換了網址，就不用管密碼強度。帳號密碼若因重複使用、惡意程式或其他事件外洩，攻擊者找到登入入口後仍可嘗試登入。隱藏網址、唯一密碼與 2FA 處理的是不同風險，不能互相取代。

誤解二：security through obscurity 完全沒用。它不適合當安全邊界，但存取記錄若顯示預設路徑承受大量掃描，改路徑仍可能降低這部分噪音。值不值得部署，要看會員登入相容性、維護成本與變更前後記錄，不套用來路不明的「可擋九成」數字。

簡單說，WPS Hide Login 是減少無差別探測的工具。新路徑一旦出現在公開頁面、郵件轉寄、分析工具或外洩記錄裡，隱藏效果就會下降。

這也是為什麼新網址不該拿來替代權限管理。知道網址的人不一定該有帳號，有帳號的人也不一定需要管理員權限。人員離開團隊時，應停用帳號、撤銷應用程式密碼與工作階段；只改一次登入網址，無法取代這些離職與交接流程。

五分鐘換掉登入網址：安裝與設定

動到登入流程前先備份，並確認你能使用主機檔案管理、SFTP 或 WP-CLI。萬一設定或外掛衝突讓管理者無法登入，這些站外管道就是救援入口。尚未建立備份流程，可先參考 UpdraftPlus 備份教學；不熟悉外掛安裝，可搭配安裝 WordPress 外掛。

1. 到「外掛 → 安裝外掛」，搜尋 WPS Hide Login。
2. 核對外掛名稱與 WordPress.org 官方頁面，點「立即安裝」及「啟用」。
3. 啟用後依畫面前往設定，之後可從「設定 → WPS Hide Login」回到同一頁。
4. 在 Login URL 欄位填入新的單一路徑並儲存。
5. 立刻記下完整網址，存進密碼管理器，再用無痕視窗測試新舊入口。

官方安裝說明列出的設定位置是「設定 → WPS Hide Login」，啟用後也會引導到設定頁。

新登入路徑	評價	問題所在
/admin	不建議	太常見，容易被猜到
/login	不建議	仍是常見登入詞
/wp-admin2	不建議	與預設路徑高度相似
/secret	普通	是可預測的常見單字
/my-brand-entry	尚可	好記，但品牌資訊可從網站得知
/entry-7k2qx	較好	含隨機片段，較難靠常見詞猜中
/door-3mn8w-fp	較好	有較長的隨機片段，仍須妥善保存

這不是密碼強度表，也沒有官方規定路徑必須是 6 至 12 碼。實務上可用小寫英文字母、數字與半形連字號組合，避開 admin、login、品牌名等容易猜到的內容。英文字母、數字、連字號、句點、底線與波浪號屬於 URI 的 unreserved characters，不需要拿問號、井號、等號等有語法用途的符號增加複雜度；可參考 IETF 的 RFC 3986（2026 年 8 月）。

命名時可把「方便辨識」與「不容易猜」拆開：用短前綴辨認用途，再接隨機片段，例如 /entry-7k2qx。前綴不是安全來源，隨機片段也不是正式憑證；整段網址只要公開，就應視為已被知道。需要輪替時，先通知確實要登入的人，更新密碼管理器，再更換設定並完成測試，避免舊書籤讓團隊誤以為網站故障。

想產生隨機片段，可用密碼管理器的產生器。電腦若已安裝 OpenSSL，也可執行 openssl rand -hex 4。參數 4 代表產生 4 位元組，再以十六進位顯示，因此結果會有 8 個十六進位字元。不要寫成所有 macOS 與 Linux 都一定內建，是否可用仍要看作業系統與安裝環境，指令細節見 OpenSSL 的 openssl-rand 文件（2026 年 8 月）。

WPS Hide Login 官方沒有公布「空格、中文或特殊符號會讓新舊路徑同時失效」的限制，也沒有 6 至 12 碼的安全門檻。這類絕對說法不宜當成外掛規格。選用容易跨瀏覽器、代理與伺服器處理的 URL-safe 字元，是相容性建議；真正的驗證方式仍是儲存後實測。

儲存後清除必要快取，再直接測試。外掛官方說明指出它不新增 rewrite rules，因此不應把「手動重新儲存固定網址」寫成每次都必做的原理性步驟。若站點另有路由問題，依主機或外掛支援文件處理即可。

怎麼確認它真的生效

設定值已儲存，不等於所有快取層與登入流程都正常。用下面四步檢查：

1. 用無痕視窗開舊網址。確認 /wp-login.php 與未登入的 /wp-admin 不再顯示登入表單。實際看到 404 或重新導向，依外掛的重新導向設定而定。
2. 用新網址登入一次。確認能看到登入表單、成功登入，也能正常使用忘記密碼與登出流程。
3. 查看主機存取記錄。確認舊路徑的回應符合設定。請求仍可能出現在 access log，因為伺服器已經收到它；判斷重點是登入表單是否仍被送出。
4. 在變更後複檢。外掛、快取、CDN、WAF 或主機設定調整後，再跑一次新舊路徑測試。

不要把「舊網址一定回 404」當成唯一合格條件。外掛可設定重新導向網址，站點的 WAF 或主機規則也可能回 403。先確認是哪一層回應，再判斷外掛是否失效。

驗收時至少保留兩個瀏覽器情境：完全登出的無痕視窗，以及已登入的管理員視窗。前者用來確認陌生訪客看不到舊登入表單；後者用來確認管理員仍可進後台、登出，並在工作階段到期後回到正確入口。網站若有會員，再加一個最低權限帳號測試。這能抓出「管理員正常、會員失敗」或「舊 Cookie 掩蓋錯誤」等情況。

把驗收結果寫進維護紀錄：日期、外掛版本、新路徑由誰保管、舊路徑的回應、新路徑登入結果、快取排除位置。記錄不必寫出完整祕密網址，可只留下密碼管理器項目名稱。下次更新出問題時，維運者會知道正常狀態原本長什麼樣子。

設定完反而登不進去？救援手冊

忘記新網址、路徑輸入錯誤或外掛衝突，都可能讓管理者無法登入。WPS Hide Login 不會刪除或重新命名 wp-login.php；官方 FAQ 建議從資料庫查看 whl_page，或移除外掛資料夾後改用預設登入頁（2026 年 8 月）。

1. 用 SFTP 或主機檔案管理停用外掛。把 /wp-content/plugins/wps-hide-login 改名為 wps-hide-login-disabled。WordPress 載入不到外掛後，便可再測試 /wp-login.php。不熟悉檔案操作，可先看WordPress FTP 完整教學。
2. 用 WP-CLI 停用。若主機提供 WP-CLI，可在正確的 WordPress 安裝目錄執行 wp plugin deactivate wps-hide-login。
3. 查主機工具或資料庫。前兩種方法都不可用時，依主機商文件停用外掛，或由熟悉 WordPress 資料庫的人查看 whl_page。不要直接剪貼修改序列化的 active_plugins。

救援完成後，不要只把資料夾名稱改回來就收工。先確認外掛狀態、重新設定登入路徑，測過新舊網址後再交付。完整登入網址與救援步驟應放進團隊使用的密碼管理器，不要只留在聊天記錄或某個人的記憶裡。

如果停用 WPS Hide Login 後仍打不開 /wp-login.php，問題可能不在這支外掛。接著檢查主機登入保護、WAF、自訂 .htaccess、Nginx 規則、頁面快取及其他安全外掛。一次只改一層並重測，才能知道哪個動作真的解決問題。不要同時清快取、停五支外掛又改伺服器設定，否則即使恢復，也無法確認根因。

登入頁不應被頁面快取。WPS Hide Login 官方（2026 年 8 月）要求，使用 WP Rocket 以外的頁面快取外掛時，要把新登入 slug 加入不快取清單。改完設定後清除既有快取，並確認新登入頁沒有被 CDN 或主機快取。快取觀念可參考網站快取指南。

隱藏網址只是輔助層：後台防護怎麼排

登入網址調整後，還要處理帳號外洩、自動化嘗試、漏洞利用與災後復原。WordPress 官方的 暴力破解防護建議（2026 年 8 月）包括唯一密碼、管理員 2FA、登入限流、WAF、更新、監控與可測試還原的備份。

防護層	處理的風險	做法
1. 唯一密碼＋最小權限	撞庫與帳號遭盜後的影響範圍	密碼管理器、嚴格的使用者角色權限
2. 雙重驗證（2FA）	密碼外洩後的帳號盜用	為管理員及高權限帳號啟用相容的 2FA
3. 限流與 WAF	暴力破解與大量惡意請求	在主機、CDN 或安全工具設定登入端點規則
4. 隱藏登入網址	只探測預設路徑的掃描噪音	WPS Hide Login，可選的輔助層
5. 定期備份	入侵、誤刪與更新失敗後的復原	異地保存，並實際測試還原
6. 核心與外掛更新	已知漏洞遭利用	使用受支援版本，重要站點先測再更新

一套安全工具可以涵蓋 2FA、限流或 WAF 的部分功能，但主機層、CDN 層與 WordPress 外掛層的能力不同。可參考WordPress 安全外掛清單，選擇能持續維護的組合，避免多套登入規則互相衝突。

備份不是阻擋攻擊，而是提供復原能力。能回到哪個時間點，取決於備份頻率、保存位置與最近一次成功還原測試。管理員帳號也應愈少愈好；撰稿者依工作需要使用編輯或作者角色，外部協作者任務結束後就收回權限。

各層的驗收標準也不同。2FA 要測遺失第二因素時的復原流程；限流要確認不會把公司共用 IP 或會員誤鎖；WAF 要看規則命中與例外；備份要做還原演練；更新要看前台、後台與排程工作是否正常。只確認外掛顯示「已啟用」，不足以證明控制有效。

若資源有限，先保護能修改網站、安裝外掛、匯出個資或處理訂單的高權限帳號。公開會員入口的流量通常更大，限流規則要兼顧真實使用者；管理後台帳號數量少，較適合要求 2FA 與嚴格的裝置管理。兩種入口不一定能共用同一套門檻。

同一支外掛，為什麼在不同主機結果不同

WPS Hide Login 在 WordPress 載入後攔截頁面請求，不新增伺服器 rewrite rules。不同環境出現不同結果，常見原因是頁面快取、CDN、反向代理、WAF、主機登入保護，或其他外掛硬寫 wp-login.php。官方也明載，硬編碼 wp-login.php 的外掛或佈景主題不在相容範圍內（見 外掛的相容性說明，2026 年 8 月）。

主機類型	常見影響	排查方向
一般虛擬主機	可能受主機安全規則、快取與外掛衝突影響	先查主機文件，再測新舊路徑
自管雲端主機	快取、反向代理與 WAF 都由維運者設定	逐層檢查回應標頭、Cookie 與記錄
託管式 WordPress 主機	平台可能有自家快取或登入保護	確認平台相容性與排除快取的方法

排查時，先清 WordPress 頁面快取，再依序檢查主機快取與 CDN。不要假設加上 ?test=1 就一定能繞過快取，是否略過查詢字串要看實際規則。用瀏覽器開發者工具或 curl -I 查看回應標頭，比只看畫面可靠。

看到快取命中時，先找是哪一層送出的回應。常見線索包括 Age、Cache-Control，以及供應商自訂的 cache status 標頭，但名稱與語意要查該服務文件。新登入路徑應列入不快取清單，舊路徑的既有快取也要清除。若 CDN 還留著舊登入表單，即使 WordPress 端已正確攔截，外部訪客仍可能看到過期內容。

選主機時要看安全控制、日誌、備份、支援與可管理程度。可從主機類型比較與WordPress 主機選擇指南開始，確認供應商如何處理登入保護與快取。

改完登入網址，還有哪些入口要檢查

/wp-admin 是第一個檢查點。未登入訪客原本會經由它前往登入流程；啟用 WPS Hide Login 後，外掛也會攔截這類請求。站內頁面、選單或佈景主題若硬寫 /wp-admin，仍要逐一測試。會員登入與登入後頁面的規劃，可搭配登入頁面設計。

第二個是 xmlrpc.php。WordPress 的 XML-RPC 實作支援遠端管理文章、頁面、留言及 Pingback；從 WordPress 3.5 起預設啟用。外掛隱藏登入頁，不會把這個端點一起關閉（見 wp_xmlrpc_server 的官方文件）。

若站點不使用 XML-RPC，可在測試後限制或封鎖。Apache 2.4 可在允許對應 override 的 .htaccess 中加入以下設定，回傳 403；有主設定檔權限時，Apache 官方建議優先改主設定。

<Files "xmlrpc.php">
    Require all denied
</Files>

Nginx 可在正確的 server 區塊加入以下設定，其中 = 是 URI 完全比對，deny all 會拒絕所有來源（見 Apache HTTP Server 的 Configuration Sections 與 Nginx 的 ngx_http_access_module 文件）。

location = /xmlrpc.php {
    deny all;
}

主機設定寫錯可能讓網站無法啟動，修改前要備份並用伺服器提供的設定測試工具驗證。託管主機若不開放設定檔，改用主機面板、WAF 或相容的安全外掛。仍在使用行動 App、遠端發文、Pingback 或第三方整合時，不要直接整個封鎖。

封鎖前可先盤點近一段時間的 xmlrpc.php 請求，分出 WAF 已判定的惡意流量與已知整合來源。封鎖後再測遠端發文、圖片上傳與排程串接，並觀察 403 是否突然增加。若正當工具仍需要 XML-RPC，可改用來源限制、登入限流或該工具支援的 REST API，不必在「全部開放」和「全部關閉」之間二選一。

第三個是 REST API 的使用者端點。WordPress 核心註冊 GET /wp/v2/users，完整網址通常是 /wp-json/wp/v2/users。未登入且沒有 list_users 權限的請求，核心會把結果限制為在可由 REST API 顯示的文章類型中已有已發佈內容的使用者；回應的公開欄位包含顯示名稱與 slug，不包含只有 edit context 才會出現的 username（行為細節見 WP_REST_Users_Controller::get_items() 的說明）。

這個 slug 來自 user_nicename。建立帳號時若沒有另填 nicename，WordPress 會從登入名稱產生 URL-safe 值（見 wp_insert_user() 的說明），所以兩者可能相同，也可能不同；不能直接寫成「slug 一定等於登入帳號」。公開回應也不提供角色，單靠這個端點不能確認誰是管理員。

可先在登出狀態開啟該端點，確認網站實際回傳什麼。若風險評估後要限制使用者清單，優先使用可維護的安全外掛或站點專用外掛，並只限制需要保護的 route。WordPress 官方不建議整個停用 REST API，因為後台功能會依賴它；官方提供的 rest_authentication_errors 範例是要求所有 REST 請求登入，套用前必須評估前端區塊與第三方整合（見 REST API Handbook 的 FAQ）。

判讀回應時，不要只看端點能否開啟。若回傳空陣列，可能是站上沒有符合公開條件的作者，不代表 route 已關閉；若回傳 401 或 403，才要再看錯誤內容與安全規則。限制完成後，重新測試文章作者頁、前端作者元件、區塊編輯器、行動 App 與內容串接，確認沒有把正常功能一起切斷。

不建議把這種站點級安全功能直接塞進父佈景主題的 functions.php。WordPress 官方在 Theme Handbook 說明，必須跨佈景主題持續生效的功能，較適合放在外掛；切換或更新佈景主題時也比較不會遺失。

WordPress 5.6 起提供應用程式密碼，讓外部工具使用可單獨撤銷的憑證存取 REST API 或啟用中的 XML-RPC。這些密碼以雜湊儲存，供程式化 API 驗證使用，不用於瀏覽器互動登入；其權限仍跟著所屬使用者帳號（見 官方的 Application Passwords 說明）。

WooCommerce 與其他會員外掛還可能提供自己的登入頁。依 W3Techs 的統計（2026 年 6 月），WooCommerce 是使用廣泛的電商系統，購物網站的「我的帳戶」也是登入入口，隱藏 /wp-login.php 不會讓它消失。會員入口仍要設定限流、唯一密碼與相容的 2FA。

三個會讓隱藏效果打折的習慣

1. 把新登入網址放在公開位置。不要貼在頁尾、公開文件或任何人都能讀到的說明頁。只分享給確實需要登入的人，並存進有權限控管的密碼管理器。
2. 長期不更新外掛與核心。隱藏路徑不會修補已知漏洞。更新前要有可還原備份，重要網站可先在 staging 測試，再維持於受支援版本。
3. 疊加多支功能重複的安全外掛。多套工具若同時改登入流程、快取或重新導向，結果可能互相衝突。每次調整後都要重跑新舊路徑、忘記密碼、登出與會員登入測試。

這些問題未必立刻報錯，卻可能讓防護在更新或設定變更後失去效果。例行複檢的目的，就是在真的需要它之前發現異常。

登入網址也要有交接規則。誰能取得、從哪裡取得、離職時怎麼撤權、網址外洩後由誰輪替，都應和帳號管理放在同一份程序裡。不要把完整網址寫進公開工單；內部工單需要引用時，可連到受權限保護的密碼管理器項目。

今天可完成的後台加固清單

1. 備份檔案與資料庫。確認備份能下載，也知道怎麼還原。
2. 安裝 WPS Hide Login。使用含隨機片段、避免常見詞的 URL-safe 路徑。
3. 保存新網址與救援方式。把完整網址、SFTP 或主機救援步驟放進密碼管理器。
4. 測試新舊入口。確認新網址可登入，舊網址不再提供登入表單；結果不必限定為 404。
5. 啟用 2FA 與限流。先保護管理員與其他高權限帳號，再處理會員登入入口。
6. 清點使用者權限。降級不需要管理權限的帳號，移除已不用的帳號與應用程式密碼。
7. 排定巡檢。依網站變更頻率檢查更新、登入異常與備份還原；維護成本可參考網站維護費用。

執行順序也有差。先確認備份與站外救援管道，再改登入網址；新入口驗收完成後，才清理快取並觀察記錄。接著啟用 2FA、限流與 WAF，每加一層就測一次登入、忘記密碼、登出及會員流程。這樣出現異常時，能把問題縮小到最近一次變更，不必一次停掉整套安全設定。

巡檢時保留可比較的資料，不只看外掛是否還在。記下舊路徑的請求趨勢、管理員登入失敗、WAF 命中、未預期的 5xx，以及最近一次還原演練日期。若新登入網址已公開、團隊成員誤傳，或記錄顯示它開始承受大量未知來源請求，可以輪替路徑；若只是預設路徑仍有掃描記錄，但登入表單沒有送出，則不代表外掛失效。

這套做法不能保證網站不受攻擊，但能降低預設入口的噪音，減少帳號遭盜的機會，也保留出事後可驗證的復原路徑。WPS Hide Login 做的是其中一小層；密碼、2FA、限流、權限、更新與備份，才是長期要維持的基本盤。