返回列表

阿里雲企業帳號開通如何設定根網域名稱直接跳轉到 WWW

阿里雲國際 / 2026-07-06 16:48:32

第一章：先搞清楚你要解決的事

很多網站同時提供兩種進入方式：example.com（根網域）與 www.example.com（子網域）。用戶在瀏覽器輸入前者時，你希望網站不要停留在空白或錯誤頁，而是直接跳轉到後者。

這件事看起來像一句簡單的「導到 WWW」，但實際上涉及兩層：DNS 怎麼把流量送到你的伺服器、以及伺服器（或反向代理）如何判斷並回應轉址。

最常見、也最符合搜尋引擎習慣的做法是：把所有根網域流量（example.com）用 301 永久轉址導向 www.example.com。搜尋引擎會逐步把權重與索引合併到目標網址，長期更穩定。

第二章：決定轉址方向與策略

題目要求「根網域名稱直接跳轉到 WWW」。也就是：example.com → www.example.com。你要先確認你站點的「正規網址（canonical）」是否就是帶 WWW 的那個。

建議做法：

目標固定：只選一個版本做主站，例如 www 為主。
使用 301：永久轉址讓搜尋引擎理解長期意圖。
保留路徑與參數：/about 航向 /about，而不是只導首頁。

例如：

example.com/pricing → www.example.com/pricing
阿里雲企業帳號開通 example.com/blog/a?utm=1 → www.example.com/blog/a?utm=1（視你是否保留查詢字串）

如果你不保留路徑，容易造成大量 404 或錯誤內容被收錄。

第三章：確認現況，避免「改錯地方」

開始前先花十幾分鐘做現況盤點，後面就少走很多彎路。

1）檢查 DNS 現在怎麼解析

打開你的網域商或 DNS 服務商後，找出以下記錄：

A 記錄（根網域）：example.com → 目前指向哪個 IP？
AAAA 記錄（如有）：IPv6 是否也指向同一台或不同台？
阿里雲企業帳號開通 CNAME 記錄（www）：www.example.com → 目前指向什麼？

阿里雲企業帳號開通 特別留意：有些情況下，根網域目前會直接指向某個站點（甚至是不同主機）。你要做的是「導向」而不是「覆蓋內容」。如果根網域已經是某個服務，轉址應在那個服務完成。

2）確認 HTTPS 憑證與 Web 架構

你要轉址的網站是否同時提供 HTTPS？瀏覽器對於安全性要求高，如果憑證沒配好，跳轉會先遇到憑證錯誤，使用者根本看不到你想要的轉址頁。

常見情境：

你有同一套反向代理（如 Nginx、Apache、Cloud 代理）負責全站。
你用的是雲端平台（如負載均衡、WAF、CDN），轉址可能需要在平台規則中完成。
你把站點託管在 CMS 或專門服務（例如靜態站、主機面板），轉址在後台可直接設定。

在你還沒弄清楚「根與 www 導向哪裡」前，不要急著寫轉址規則。因為你可能把規則寫到錯誤的那台機器上。

第四章：DNS 設定的正確思路

即使你要做 HTTP 層面的轉址，DNS 仍然決定了「請求先落在哪裡」。因此 DNS 至少要保證：根網域的流量也能到達能處理轉址的那套服務。

情境 A：你使用同一台 Web 伺服器，讓兩者都指向它

最直觀的方式是：

example.com 用 A（和可能的 AAAA）指向你的伺服器 IP。
www.example.com 用 CNAME指向同一目的地（或同樣用 A 記錄指向伺服器）。

如果你的 www 目前已經是 CNAME 指到某個主機名，那根網域也可以用 A/AAAA 指到同一台；但在一些雲端平台中，A/AAAA 的指向通常應該完全符合你的部署方式。

情境 B：www 本來就有 CNAME，根網域目前是空的或指向不同服務

你要讓根網域流量「進入」同一個轉址處理位置。常見處理：

把 example.com 的 A/AAAA 指到與 www 相同的服務入口（同一 IP 或同一代理層）。
若你用的是 CDN/WAF/反向代理，讓根與 www 都指向代理層，而不是讓根直連內容源。

如果根網域仍然指向另一個主機，而轉址規則只寫在你想要的那台主機上，結果就是根網域「根本不會走到那條規則」，自然不會跳。

第五章：在 Web 端設定 301 永久轉址（核心步驟）

DNS 解決「流量到哪」，Web 端解決「收到後怎麼回」。你要做的就是：所有對根網域的請求都回應 301 到 www。

下面用幾種常見環境分別說明。你可以把對應段落套到你的實際系統上。

方法 1：Nginx 設定（推薦清晰）

假設你已經有 server 區塊處理 example.com（根網域），並且你要把它重導到 www。

你可以在 根網域的 server 配置中加入：

server {
    listen 80;
    server_name example.com;

    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    # 建議確保 SSL 憑證對 example.com 也有效
    # 這樣才不會在跳轉前就報錯

    return 301 https://www.example.com$request_uri;
}

要點：

同時處理 80 與 443：避免 HTTP 能跳但 HTTPS 不跳，或相反。
使用 $request_uri：保留路徑與查詢參數。
目標是 https：讓用戶永遠走安全連線。

方法 2：Apache 設定（.htaccess 或 vhost）

如果你在 Apache 上，且允許使用 .htaccess，你可以在根網域對應目錄加入：

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

阿里雲企業帳號開通 更精準的做法是針對根網域的 VirtualHost 來寫，避免條件判斷過多。你也可以在根網域的 vhost 中直接 return 301。

要點同樣是保留 REQUEST_URI，以及使用 R=301。

方法 3：Cloudflare（或類似 CDN/WAF 平台）轉址規則

如果你使用的是代理層（例如 Cloudflare），常見做法是用「頁面規則（Page Rules）」或「重定向規則（Redirect Rules）」。

目標規則大致是：

來源主機：example.com（根網域）
目標網址：https://www.example.com/$1（或保留 path 的方式）
狀態碼：301

注意保留 path 的寫法，否則所有路徑可能都被導到首頁。

如果你同時在伺服器端也寫了轉址，可能出現雙重跳轉或鏈式轉址。原則上：轉址只做一層，要嘛在平台，要嘛在主機。

方法 4：靜態站（例如只提供內容，沒法改伺服器設定）

若你把網站託管在靜態網站服務上，通常會有「重寫/重導」設定界面。例如：

指定根網域導向 www
指定 301 狀態碼
保留路徑

這種方式的優點是簡化；缺點是不同平台的語法與能力不同。你需要以你所用平台的規則格式為準，但原則不變：永遠 301、永遠保留路徑。

阿里雲企業帳號開通第六章：SSL 憑證與跳轉順序（最容易踩坑）

很多人卡住是因為「轉址前先發生憑證錯誤」。你設了 301，但瀏覽器一開始連的是 https://example.com，而 example.com 沒有憑證，這時候就會直接警告，根本看不到跳轉。

解法通常有兩種：

阿里雲企業帳號開通 讓 example.com 也有有效的憑證，讓它能回應 301。
確保先用 HTTP→HTTPS，再在 HTTP 端導向 www，但前提是你有能力在 80 端先攔下。

更可靠的做法是：為根網域與 www 都配置同等級的憑證。若你用的是自動憑證（如 Let’s Encrypt），通常會建議把兩者都納入憑證範圍。

第七章：路徑保留與參數處理（SEO 與體驗的細節）

轉址不只是導到哪個網域，還要導到正確的頁面。

1）保留路徑與查詢字串

你應該用類似 $request_uri（Nginx）或 %{REQUEST_URI}（Apache）來保留內容。

如果你使用了靜態規則，但寫成固定目標（例如只導 https://www.example.com/），那使用者輸入的頁面會全部失效。

2）UTM 與追蹤參數

阿里雲企業帳號開通 行銷人常會依賴 UTM 參數追蹤。你可以保留它們，讓分析不因跳轉而斷掉。

不過如果你有特定需求（例如你不想要保留某些參數），也要在規則設計時一併處理，避免導向後丟失關鍵資訊。

第八章：常見錯誤與快速排查清單

當你設定完後發現「沒跳」或「一直跳轉」，通常不是你不夠努力，而是落在下列原因之一。

錯誤 1：根網域 DNS 沒有指到處理轉址的那套服務

症狀：example.com 回應的不是你期望的狀態碼，可能是 200（內容）、404，或另一套服務回應。

排查：用瀏覽器或命令測試 header（看 Location）、並檢查 DNS 解析結果。

錯誤 2：只做了 HTTP（80）但 HTTPS（443）沒做

症狀：http://example.com 會跳，https://example.com 不跳或顯示錯誤。

排查：分別測試 http 與 https。

錯誤 3：寫了反向邏輯導致循環跳轉

症狀：瀏覽器報「重定向過多次」。

原因：www 端也被設定成導回根，或兩端都在導同一方向但規則條件未限制。

排查：確保只有根網域負責導到 www，www 端不需要導回。

錯誤 4：沒有正確保留 REQUEST_URI

症狀：永遠跳到首頁，或路徑丟失。

排查：檢查你的規則是否使用了 request_uri / REQUEST_URI。

錯誤 5：目標站點同時又強制改寫 canonical，導致多重信號衝突

SEO 層面不一定立刻出現錯誤，但會讓搜尋引擎在判斷正規網址時多一層成本。你應確保：

301 目標是你選的 canonical（例如 www）。
HTML 的 canonical tag 也一致（www）。

第九章：測試方式要「像工程師」而不是只靠感覺

你需要測的是「狀態碼」與「Location 標頭」。不要只看頁面是否跳，因為有時會發生中間跳或內容回退。

1）測試根網域的 HTTP 與 HTTPS

http://example.com
https://example.com

再測帶路徑與參數：

https://example.com/some/path
https://example.com/some/path?x=1

2）確認狀態碼是 301，而不是 302 或 200

301 用於永久。若你看到 302，搜尋引擎會理解成暫時，收斂速度通常更慢。

3）檢查重定向鏈

理想狀況：一次 301，從根直接到目標。

若你看到多段跳轉（例如根→某中間頁→www），要回到規則設計，砍掉多餘層。

第十章：SEO 與快取的現實：你要等，但不是盲等

301 不是立刻讓世界改變。搜尋引擎與瀏覽器都可能有快取。

阿里雲企業帳號開通 瀏覽器快取：第一次看起來像沒跳，刷新或換無痕模式再測。
搜尋引擎收錄：通常需要時間重新抓取與合併索引。
站內連結：最好把站內所有連結都更新成 www，避免不必要的轉址。

另外，建議你在站點內也維持一致性：

HTML 的 canonical 設定為 www 版本。
sitemap 與 robots 中的主要 URL 版本一致。

第十一章：把流程寫成一個可以照做的清單

如果你不想在設定中「試錯」，可以照這個順序：

Step 1：確認你選的目標是 www.example.com。
Step 2：檢查 example.com 的 DNS（A/AAAA）要能到達你的 Web/代理入口。
Step 3：確保 example.com 與 www 都有可用的 SSL 憑證（至少能讓端口回應 301）。
Step 4：在「根網域」的 Web/平台端建立 301 轉址規則到 www，保留路徑。
Step 5：測試 http 與 https，測路徑與參數，確認只發生一次 301。
Step 6：檢查 www 端不做反向導回，避免循環。
Step 7：更新站內連結與 canonical，使訊號一致。

第十二章：結語——把「跳轉」做成可靠的基礎建設

根網域導到 WWW 看似是小設定，實際上是你網站「一致性」與「可維護性」的起點。把 DNS 與轉址邏輯理順，你會得到更少的錯誤頁、更乾淨的搜尋引擎信號，以及更順的使用者體驗。

你不需要一次就把所有地方調到完美，但你要把核心原則抓穩：301、保留路徑、只在一處做轉址、確認 HTTPS 與不循環。做到這幾點，跳轉就會變成一條穩定的通道，而不是每天都要盯著的麻煩。