DNS 設定

網站架設會用到的記錄類型

DNS 記錄的類型不少，但一般企業網站架設實際會碰到的大約六種。以下依使用頻率排列。

A 記錄：讓網站能被打開

最基本的一筆設定，把網域指向主機的 IP。一般會設定兩筆：

• 主機名稱留空或填 @，代表 example.com 本身
• 主機名稱填 www，代表 www.example.com

兩者都必須能開啟，但只能有一個是主要版本，另一個要 301 轉向過去。若兩個網址都直接開著相同內容，搜尋引擎會視為重複內容，網站評價被拆成兩份。這個轉向是在網頁伺服器設定，不是在 DNS 做。

CNAME：把一個名字指向另一個名字

與 A 記錄的差別在於，CNAME 指向的是名稱而非 IP。好處是當目標的 IP 變動時，您這邊不用跟著改。

常見用途：

• 把 www 指向主網域
• 把子網域指向外部服務，例如 shop 指向電商平台提供的位址
• 各種服務商要求的驗證用子網域

兩個重要限制

1. 同一個名稱上有 CNAME 就不能再有其他記錄。例如 www 設了 CNAME，就不能同時在 www 上設 A 記錄或 TXT 記錄。
2. 網域根部（example.com 本身）原則上不能設 CNAME。因為根部必然有 NS 與 SOA 記錄，會與上一條衝突。若服務商要求把根網域指向一個名稱，需改用該平台提供的 ALIAS、ANAME 或 CNAME 展平等替代功能。

這兩點是實務上最常踩的坑，設定存不進去多半就是撞到其中之一。

MX 記錄：決定信件送到哪裡

MX 記錄比其他類型多一個「優先權」數值。數字越小優先權越高，寄件方會先嘗試數字最小的那台，失敗才往下試。

例如使用外部郵件服務時，服務商可能提供一組或多組 MX 值，直接照抄即可，不要自行更動優先權數字。

三個常見錯誤

• 舊的 MX 沒刪乾淨——換郵件服務時只新增沒刪除，導致部分信件仍被送往舊主機，收信變得時有時無，這種問題極難察覺
• MX 指向 CNAME——依規範 MX 應指向具有 A 記錄的名稱，指向 CNAME 可能造成部分郵件伺服器拒收
• 只改 MX 沒改 SPF——收信正常但寄信被擋，詳見下一段

TXT 記錄：郵件防偽與各種驗證

TXT 本身只是純文字，實際用途由內容決定。網站架設最常用到三種郵件防偽設定：

SPF

聲明哪些伺服器有權以您的網域名義寄信。一個網域只能有一筆 SPF 記錄——如果同時使用郵件服務與電子報平台，必須把兩者合併寫在同一筆裡，不能各設一筆。另外 SPF 的查詢次數有上限，串接太多服務會超限而失效。

DKIM

為寄出的信件加上數位簽章，收件方可據以確認信件未被竄改。通常設在服務商指定的子名稱下，值是一長串金鑰，由服務商提供，直接複製貼上即可。

DMARC

告訴收件方：遇到 SPF 或 DKIM 驗證失敗的信要怎麼處理。政策由寬到嚴分別是「僅觀察」、「隔離」、「拒收」。

建議先從最寬鬆的觀察模式開始，收集一段時間的報告，確認所有合法的寄信來源都通過驗證後，再逐步收緊。一上來就設成拒收，很可能把自己公司的行銷信、系統通知信全部擋掉。

為什麼這三項現在是必要的

主要郵件服務商近年大幅提高對寄件方的驗證要求，未通過驗證的信件很容易被直接判為垃圾郵件。結果是您寄出的報價單客戶收不到，而您完全不會知道。這已經不是可有可無的進階設定。

設定時的通用注意事項

• 主機名稱欄位的寫法各家不同——有些要填完整網域，有些只填子名稱，有些用 @ 代表根網域。填錯會變成 www.www.example.com 這種結果
• 值的結尾點號——部分系統要求 CNAME 或 MX 的值結尾加一個點，代表完整網域，照該系統的既有範例格式填寫
• 修改前先截圖備份——尤其是要改動既有的郵件相關設定時
• 一次只改一項——同時改多項，出問題時無法判斷是哪一項造成的

簡短的答案

一般數分鐘到數小時，多數情況一小時內完成，最長可能需要 24 到 48 小時。實際時間取決於三件事：您設定的 TTL 值、各地解析器的快取狀態，以及您自己電腦與瀏覽器的快取。

「改了設定但網站還是舊的」幾乎都不是設定失敗，而是快取還沒過期。以下說明機制與加速方法。

TTL 是什麼

TTL（Time To Live）是每一筆 DNS 記錄附帶的數值，單位是秒，意思是「這個答案可以被快取多久」。

當某個解析器來查詢，取得答案後就會照 TTL 記住這段時間。在快取到期前，它不會再來問，所以您改了也沒用。

取捨

• TTL 短——變更生效快，但查詢次數多，理論上多耗費一點解析時間
• TTL 長——效率好，但要變更時得等很久

日常維持 3600 是合理的，這一點的實際效能差異對一般企業網站可以忽略。

正確的變更節奏

這是專業做法與臨時抱佛腳的分界：

1. 預計變更的一到兩天前，先把該筆記錄的 TTL 調低到 300
2. 等待原本的 TTL 時間過去，確保各地快取都已換成新的短 TTL
3. 正式變更記錄內容——此時擴散只需要幾分鐘
4. 確認一切正常後，把 TTL 調回 3600

換句話說，擴散時間長短是可以事先控制的。臨時要切換卻發現 TTL 是 86400，那就只能等一天，這是規劃問題不是技術問題。

為什麼有人看得到、有人看不到

因為每個解析器的快取到期時間各自獨立。中華電信的解析器可能十分鐘前才查過，遠傳的可能一小時前查過，兩邊到期時間不同，就會出現同一時間不同人看到不同版本。

這在切換期間是正常且無法避免的現象。若切換的是網站主機，切換期間新舊主機都還開著，使用者不論被導到哪一邊都能看到網站，這也是為什麼換主機時新舊主機要並存一段時間。

怎麼確認實際生效狀況

先排除自己電腦的快取

最常見的情況是：全世界都好了，只有您自己還看到舊的。依序處理：

• 清除瀏覽器快取，或用無痕視窗測試
• 清除作業系統的 DNS 快取——Windows 在命令提示字元執行 ipconfig /flushdns；macOS 需執行對應的清除指令
• 檢查 hosts 檔——如果之前為了測試而在 hosts 檔指定過這個網域，它的優先權高於一切，會蓋掉正常的 DNS 查詢結果。這是測試期間最容易忘記還原的設定
• 換一個網路測試——用手機行動網路開一次，最快排除本機問題

用工具查詢實際回傳值

Windows 可用 nslookup 網域名稱，Linux 與 macOS 可用 dig 網域名稱。若要指定用某個解析器查詢，可在指令後方加上該解析器位址，藉此比對不同解析器目前拿到的答案是否一致。

另外也有線上的多地點 DNS 查詢服務，可以一次看到世界各地的解析結果，適合用來確認擴散進度。

常見誤解

「重新整理頁面就會更新」

不會。瀏覽器重新整理的是網頁內容，不是 DNS 查詢結果。要清的是 DNS 快取。

「重開機就好了」

重開機會清掉本機快取，對自己有效，但對其他人沒有幫助。

「一定要等 48 小時」

48 小時是最保守的上限值，源自早年 TTL 普遍設得很長的時代。現在多數情況遠快於此，如果事前降過 TTL，通常十分鐘內就完成。

「改了但完全沒動靜，一定是還在擴散」

如果超過原 TTL 兩倍的時間仍毫無變化，比較可能是改錯地方了——例如 NS 早已指向主機商，您卻在註冊商後台修改。請先確認網域的 NS 指向哪裡，那裡才是實際生效的管理位置。

換主機最怕的兩件事

網站搬家時客戶最常問的是：「切換的時候網站會不會關掉？」「客戶寄的信會不會不見？」

答案是：規劃得當可以做到完全不中斷；規劃不當，可能斷線數小時並遺失郵件。 差別在流程，不在技術難度。

以下是我們實際執行網站搬遷時採用的順序。

核心原則：新舊並存，先測後切

整個流程的關鍵在於——在切換 DNS 之前，新主機就必須已經完全可以運作。切換只是最後把指標移過去的動作，不是「開始搬家」的動作。

很多人的做法是先把 DNS 改掉再開始上傳檔案，這中間網站當然是壞的。

階段一：切換前一到兩週

1. 盤點目前的所有 DNS 記錄

不是只有網站那一筆。請完整列出並截圖備份：

• A 與 AAAA 記錄（網站、以及可能存在的各種子網域）
• CNAME 記錄
• MX 記錄（郵件）
• TXT 記錄（SPF、DKIM、DMARC、各服務的所有權驗證）
• 其他特殊記錄

最常被漏掉的是 TXT 記錄裡的各種驗證值。搬完之後才發現 Search Console 掉了驗證、電子報平台無法寄信，都是這個原因。

2. 確認郵件的搬遷方式

這是最需要提前決定的一項。三種情況：

強烈建議：如果信箱也在舊主機，不要和網站同時搬。 先搬網站，穩定後再處理郵件，或反過來。同時進行時一旦出問題，很難判斷是哪一邊造成的。

階段二：切換前一到兩天

3. 在新主機完成部署並測試

• 上傳程式與檔案、匯入資料庫
• 設定好網頁伺服器與 PHP 版本
• 申請並安裝 SSL 憑證

4. 用 hosts 檔測試新主機

這是整個流程中最重要的技巧。修改自己電腦的 hosts 檔，把網域指向新主機的 IP，就能在不影響任何人的情況下，用正式網址完整測試新環境。

測試項目：首頁、內頁、後台登入、表單送出、圖片顯示、SSL 是否正常。確認全部無誤，才進行下一步。具體操作方式可參考我們既有的 hosts 檔修改教學。

5. 把 TTL 調低到 300

針對即將變更的記錄（通常是 A 記錄）調低 TTL，並等待原 TTL 時間過去。這一步決定了切換當下的擴散速度，詳見改了 DNS 要多久才生效。

階段三：切換當天

6. 選對時間

建議選在流量最低的時段，一般是平日深夜或週間上午。避免週五下午——出問題時整個週末沒有人力處理。

7. 最後一次同步資料

如果網站有後台可新增內容、或有訂單與表單資料，切換前要再同步一次資料庫，避免這段期間新增的資料遺失。

8. 修改 A 記錄，指向新主機 IP

只改必要的記錄。MX 與 TXT 若不需變動就完全不要碰。

9. 舊主機保持開啟

這是關鍵。擴散期間部分使用者仍會連到舊主機，若此時把舊主機關掉，這些人就會看到錯誤頁面。舊主機至少保留三到七天。

階段四：切換後

10. 驗證清單

• 有 www 與沒有 www 的網址都能開啟
• http 自動轉為 https，憑證有效
• 後台可正常登入、可新增內容
• 表單送出後有收到通知信
• 從外部信箱寄信到公司信箱，確認收得到
• 用公司信箱寄信到 Gmail，確認沒進垃圾郵件匣
• Search Console 沒有出現大量抓取錯誤

11. 觀察期

切換後三到七天內每天檢查一次。確認舊主機的存取紀錄已無流量，才可以關閉舊主機。

12. 把 TTL 調回 3600

雙主機期間的資料一致性問題

這是最容易被忽略的風險：擴散期間，一部分訪客連到新主機、一部分連到舊主機。如果網站有寫入功能——訂單、會員註冊、留言、後台發文——就會出現資料分散在兩個資料庫的情況。

處理方式：

• 最單純：在切換前把舊網站的寫入功能暫停，或掛上維護公告，直到擴散完成
• 次之：讓舊主機的程式連線到新主機的資料庫，兩邊共用同一份資料
• 不建議：兩邊各自運作，事後手動比對合併

對純展示型的形象網站，這個問題不存在；對購物網站或有會員的網站，則必須事先規劃。

三個角色，常被當成同一件事

「我的網站是在某某公司做的」——這句話在出問題時完全幫不上忙，因為一個網站能正常運作，背後至少牽涉三個獨立的服務，而它們很可能分屬三家不同的廠商。

三者可以全部在同一家，也可以分屬三家。沒有標準答案，但您必須知道自己是哪一種。

為什麼一定要分清楚

出問題時才知道該找誰

網站打不開的原因可能是：網域忘記續約（找註冊商）、DNS 記錄設錯（找 DNS 管理方）、主機當機或空間滿了（找主機商）。搞不清楚架構，只能一家一家問，每家都說不是自己的問題。

換廠商時才知道要帶走什麼

更換網頁設計公司時，要移轉的可能是網域、可能是主機、也可能只是網站檔案。三者的移轉方式完全不同。

避免被單一廠商綁住

如果網域、DNS、主機、網站全都在同一家且都登記在對方名下，實質上就是被完全掌控。網域的所有權至少要在自己手上，這是最低限度的自保。

怎麼查出自己目前的架構

查網域註冊商

用 WHOIS 查詢，結果會顯示 Registrar（註冊商）欄位。若已開啟隱私保護，註冊商名稱通常仍會顯示。

查 DNS 管理位置

查詢該網域的 NS 記錄。NS 指向誰，實際生效的設定就在誰那裡。

• 指向註冊商的名稱伺服器 → 在註冊商後台管理
• 指向主機商的名稱伺服器 → 在主機控制台管理
• 指向第三方服務 → 在該服務控制台管理

這是最常搞錯的一項。很多人一直在註冊商後台修改記錄卻毫無效果，原因就是 NS 早已指向別處。

查主機位置

查詢 A 記錄取得 IP，再查該 IP 屬於哪家業者。或直接看主機控制台的登入網址。

三種常見的組合

組合一：全部集中在同一家

優點：管理單純，只有一個後台、一組帳號、一張帳單，出問題只需找一家。
缺點：更換廠商時牽動全部，且議價空間較小。
適合：不想花心力管理的中小企業，但前提是網域註冊人必須登記為貴公司。

組合二：網域自己管，DNS 與主機交給廠商

優點：最重要的資產在自己手上，日常維運仍由專業處理。
缺點：需要自己保管註冊商帳號。
適合：我們最常建議的做法，兼顧安全與便利。

組合三：三者完全分開

優點：彈性最大，各項服務可獨立更換。
缺點：管理複雜，需自行釐清權責。
適合：有資訊人員的公司，或有特殊需求（例如需要第三方 CDN）。

網站架設時應該取得並保存的資訊

不論選哪種組合，以下清單請整理成文件保存在公司內部，不要只存在承辦人的個人電腦或瀏覽器裡：

• 網域：註冊商名稱、後台網址、帳號密碼、註冊人資料、到期日
• DNS：目前的管理位置、完整記錄清單截圖
• 主機：主機商名稱、控制台網址、帳號密碼、方案內容、到期日
• 網站：後台網址、管理員帳號、使用的系統與版本
• SSL 憑證：由誰申請、到期日、是否自動更新
• 其他：郵件服務、Search Console、GA 的帳號歸屬

這份清單在人員異動時的價值會顯現出來。實務上我們接手的案子，超過一半的第一個工作項目就是幫客戶把這些資訊找回來。

一個判斷廠商的小方法

在洽談網站架設時，可以直接問對方：「網域會登記在誰名下？DNS 由誰管理？我可以拿到哪些帳號？」

願意清楚說明並提供帳號的，通常在後續合作上也比較坦白；含糊帶過或強調「這些您不用管」的，就值得多留意。這不是技術問題，是合作關係的問題。

先分清楚是哪一種問題

「信箱有問題」實際上是三種完全不同的故障，排查方向也不同：

最麻煩的是第二種——沒有任何錯誤訊息，您以為信寄出去了，客戶卻在垃圾郵件匣裡，或根本沒收到。報價單、訂單確認、客服回覆就這樣消失。

症狀一：收不到信

1. 檢查 MX 記錄是否正確且唯一

最常見的原因是舊的 MX 記錄沒刪乾淨。換過郵件服務的公司特別容易發生：新的加上去了，舊的忘記刪，於是部分寄件方把信送往已經沒人管理的舊主機。

症狀是「有時收得到、有時收不到」，而且看起來毫無規律。查詢自己網域的 MX 記錄，確認只有現行服務商提供的那幾筆。

2. 確認 MX 沒有指向 CNAME

依規範 MX 應指向具有 A 記錄的名稱。指向 CNAME 可能造成部分郵件伺服器拒收，同樣呈現時好時壞的症狀。

3. 檢查信箱容量與過濾規則

DNS 都正確的話，往下查主機端：信箱空間是否已滿、是否有自動轉寄或封鎖規則、防垃圾郵件機制是否過於嚴格。

4. 請對方提供退信內容

如果寄件方有收到退信，那封退信裡通常寫明了原因，比任何猜測都準確。請對方完整轉寄過來，不要只截圖第一行。

症狀二：寄出去被當垃圾信

這是目前最常見的問題。原因是主要郵件服務商近年大幅提高對寄件方的驗證要求，沒有完成身分驗證的信件很容易被直接分類為垃圾郵件。

必須完成的三項設定

1. SPF——聲明哪些伺服器可以用您的網域寄信
2. DKIM——為信件加上數位簽章
3. DMARC——告訴收件方驗證失敗時該怎麼處理

三項的設定方式詳見DNS 記錄類型完全解說。以下是實務上最常出錯的地方。

SPF 的三個常見錯誤

• 設了兩筆以上——一個網域只能有一筆 SPF。同時使用郵件服務、電子報平台、CRM 系統時，必須把所有來源合併在同一筆裡，不能各設一筆。設兩筆的結果是全部失效，比沒設還糟
• 查詢次數超限——SPF 在驗證時允許的查詢次數有上限，串接太多服務會超過，整筆判定失敗
• 漏掉實際的寄信來源——網站的表單通知信是從網站主機寄出的，這個來源常被遺漏。結果是人工信件正常，系統信件全進垃圾桶

DMARC 不要一開始就設最嚴格

DMARC 政策由寬到嚴分為「僅觀察」、「隔離」、「拒收」。請先從僅觀察模式開始，並設定接收報告，跑一到兩個月，確認所有合法寄信來源都通過驗證後，再逐步收緊。

直接設成拒收的後果是：任何一個您忘記納入 SPF 的來源，寄出的信會被對方直接丟棄，而且您不會收到通知。

症狀三：退信與黑名單

如果退信內容提到黑名單，代表您的寄件 IP 或網域被列入了垃圾郵件名單。常見原因：

• 與其他人共用主機 IP，同 IP 上有人濫發信件
• 公司內部電腦中毒，被利用來發送垃圾信
• 信箱帳號密碼外洩，被他人盜用寄信
• 短期內大量寄送行銷信件
• 使用了曾被濫用的二手網域——這一點在購買二手網域時務必先查

處理方式是先找出並解決根本原因（改密碼、清毒、停止大量寄信），再向該黑名單機構提出除名申請。若是共用主機的 IP 問題，請聯繫主機商協助，或考慮改用專用 IP 或外部郵件服務。

系統性的排查順序

1. 確認範圍——是所有人都收不到，還是只有特定對象？只有 Gmail 有問題通常是驗證設定問題；全部都有問題比較可能是 MX 或主機問題
2. 查 DNS——MX 記錄是否唯一且正確、SPF 是否只有一筆、DKIM 與 DMARC 是否存在
3. 做一次往返測試——用外部信箱寄進來、用公司信箱寄出去，兩個方向都測
4. 檢查郵件標頭——收到的信件可以查看原始標頭，裡面會顯示 SPF 與 DKIM 的驗證結果是通過還是失敗，這是最直接的證據
5. 查黑名單——用線上工具查詢自己的網域與寄件 IP

預防勝於排查

• 網站架設完成時就把 SPF、DKIM、DMARC 一次設好，不要等出事
• 新增任何會寄信的服務時，同步更新 SPF
• 設定 DMARC 報告接收信箱，定期查看
• 換主機或換郵件服務後，務必做雙向收發測試，詳見網站搬家的 DNS 切換流程

為什麼要用外部郵件服務

不少中小企業的公司信箱是附在虛擬主機方案裡的，等於「買網站空間送信箱」。這在早期沒什麼問題，但現在有幾個現實的限制：

• 空間小，信件累積幾年就滿
• 手機同步、多裝置使用體驗較差
• 共用主機 IP，容易受同一台主機上其他人的寄信行為影響而進黑名單
• 缺乏完整的防垃圾郵件與防釣魚機制
• 主機一旦出問題，網站與信箱同時停擺

把郵件搬到專門的服務（Google Workspace 或 Microsoft 365 是最常見的兩個選擇），可以讓網站與信箱互不影響——這一點在網站搬家或主機故障時特別有價值。

兩者怎麼選

對網站架設而言兩者沒有差別，DNS 設定的邏輯完全相同，只是填入的值不同。實際選擇請以團隊慣用的辦公軟體為主。

設定流程（兩者通用）

第一步：驗證網域所有權

服務商會要求您證明這個網域是您的，通常是在 DNS 加一筆指定的 TXT 記錄，或上傳一個檔案到網站根目錄。

TXT 驗證是比較單純的做法。驗證通過後這筆記錄請不要刪除，部分服務會定期重新檢查。

第二步：建立使用者帳號

在服務商後台建好所有要使用的信箱帳號。這一步要在改 MX 之前完成——否則 MX 改過去了，帳號還沒建，信件會直接被退。

第三步：搬移舊信件（如果需要）

兩家服務都提供從舊伺服器匯入信件的工具。建議在切換 MX 之前先做一次匯入，切換後再補做一次增量，可以把落差降到最低。

第四步：修改 MX 記錄

• 刪除所有舊的 MX 記錄
• 新增服務商提供的 MX 值，優先權數字照抄不要自行調整
• 切換前一兩天先把 MX 的 TTL 調低，加快生效速度

具體的 MX 值請以服務商後台的設定精靈當下顯示的為準。 這些值兩家都調整過，網路上找到的舊教學可能已經過期，照抄會設錯。

第五步：設定 SPF、DKIM、DMARC

• SPF——加入服務商指定的內容。若同時還有其他寄信來源（例如網站的表單通知信），必須合併在同一筆記錄裡
• DKIM——需在服務商後台先產生金鑰，再把提供的值加到 DNS，最後回後台按下啟用
• DMARC——先設為僅觀察模式

第六步：其他記錄

部分服務會要求額外的 CNAME 記錄以支援自動設定或行事曆等功能，依後台指示新增即可。

最容易出錯的五個地方

1. 舊 MX 沒刪乾淨——信件時而收得到時而收不到，最難查的問題
2. SPF 設了兩筆——原本主機的 SPF 留著，又加了一筆服務商的。結果是兩筆都失效
3. DKIM 只加了 DNS 沒回後台啟用——兩邊都要做，缺一不可
4. 帳號還沒建就改 MX——切換空窗期的信件全部退回
5. 忘記網站的表單通知信——網站是從主機寄信的，這個來源要一併納入 SPF

切換後的驗證

• 從外部信箱寄一封到公司信箱，確認收得到
• 用公司信箱寄一封到 Gmail，檢查是否進垃圾郵件匣
• 檢視收到信件的原始標頭，確認 SPF 與 DKIM 都顯示通過
• 從網站的聯絡表單送出一次，確認通知信正常且未進垃圾桶
• 手機與電腦的收信設定都測試一次

若出現異常，排查方式參考公司信箱收不到信或被當垃圾信怎麼查。

一個實務建議

不要把郵件搬遷和網站搬家排在同一天。 兩件事都牽涉 DNS，同時進行時一旦出問題，很難判斷是哪一邊造成的。建議至少間隔一週，先完成一項並確認穩定，再處理另一項。

子網域是什麼

在主網域前面加一段名稱，就形成子網域，例如 shop.example.com、blog.example.com、test.example.com。

技術上，開一個子網域不需要另外付費、不需要另外註冊，只要在 DNS 加一筆記錄即可，數量通常也沒有實質限制。這是它最大的優勢——成本幾乎為零。

怎麼開一個子網域

情況一：指向自己的主機

新增一筆 A 記錄，主機名稱填子網域名稱（例如 shop），值填主機 IP。接著在主機端建立對應的網站目錄與設定。

情況二：指向外部服務

新增一筆 CNAME 記錄，值填服務商提供的位址。常見於使用外部電商平台、客服系統、活動報名平台的情況。

注意 CNAME 的限制：同一個名稱上有 CNAME 就不能再有其他記錄。如果服務商同時要求 CNAME 和 TXT 驗證放在同一個子網域名稱下，就會衝突，此時需請服務商提供替代方案。

情況三：萬用字元

用 * 作為主機名稱，可以讓所有未特別指定的子網域都指向同一處。適合會動態產生大量子網域的系統（例如每個客戶一個網址的平台）。

但一般企業網站不建議使用——它會讓任意輸入的子網域都能開啟，容易被利用於釣魚或產生無意義的頁面被搜尋引擎收錄。

SSL 憑證怎麼處理

這是最常被忽略的一步。主網域的 SSL 憑證不會自動涵蓋子網域，子網域用 https 開啟會出現憑證錯誤警告。

三種處理方式：

• 為每個子網域各自申請憑證——子網域不多時最單純，多數主機面板都支援自動申請與續期
• 申請萬用字元憑證——一張涵蓋所有子網域，適合子網域較多的情況，但申請時通常需要以 DNS 方式驗證
• 由外部服務提供——若子網域是 CNAME 指向外部平台，憑證通常由該平台負責

另外請確認憑證的自動續期有正常運作。子網域的憑證過期是很常見的疏忽，因為平常沒人會去開那個網址。

三種常見用途與規劃建議

測試站

網站改版期間，新版通常先放在 test.example.com 或 dev.example.com 供客戶驗收。兩件事一定要做：

• 加上密碼保護——用主機的目錄密碼或程式端的登入限制，不要讓測試站公開可存取
• 阻擋搜尋引擎收錄——測試站被收錄後，會與正式站產生重複內容互相競爭，而且客戶搜尋公司名稱時可能搜到未完成的版本

阻擋方式建議兩層都做：robots.txt 設定不允許檢索，同時在頁面加上 noindex 標記。單靠 robots.txt 不保證不被收錄。

最重要的提醒：正式上線時務必解除這些設定。 測試期間的封鎖設定被帶到正式站，導致整個網站不被搜尋引擎收錄，是網站改版最常見也最嚴重的失誤，詳見網站改版或更換網域，SEO 排名怎麼保住。

購物站

如果購物功能是用外部平台，通常只能用子網域（CNAME 指向平台）。如果是自建，建議優先考慮放在子目錄而非子網域，權重集中效果較好。兩者的取捨詳見子網域、子目錄還是另外註冊網域。

活動網站

短期行銷活動常用 event.example.com 或 2026.example.com。規劃時請一併決定活動結束後怎麼處理：

• 直接刪除 → 產生 404，累積的連結與流量全部消失
• 301 轉向到主站相關頁面 → 建議做法
• 保留為封存頁面並加上活動已結束的說明 → 若內容仍有參考價值

命名建議

• 短、好念、語意明確——shop、blog、news、event 這類通用字最好
• 避免使用員工姓名或專案代號——人員異動後沒人知道那是什麼
• 測試站的名稱要一望即知——test、dev、staging，避免用 new、v2 這種日後會混淆的名字
• 不要用 www 以外的變體當主站——例如 web.example.com 當主網址，使用者不會這樣輸入

維護提醒

子網域開起來很容易，但每一個都是需要維護的資產。建議建立一份清單，記錄每個子網域的用途、指向何處、由誰負責、SSL 到期日。

已經廢棄的子網域請把 DNS 記錄刪除。 留著指向已經不存在的服務，可能被他人接管該服務位址後冒用您的子網域，這是實際存在的資安風險。

第三方 DNS 服務在做什麼

把網域的名稱伺服器指向第三方服務（Cloudflare 是最常見的一家），DNS 查詢就改由對方處理。多數這類服務同時提供 CDN、防護與加速功能，等於在使用者與您的主機之間加了一層。

運作方式的差別在於：

• 只做 DNS——單純提供解析服務，使用者仍直接連到您的主機
• 加上代理（CDN）——使用者連到的是服務商的節點，由節點回主機取資料。此時您的主機 IP 對外是隱藏的

這兩種模式在同一個服務裡通常是逐筆記錄可切換的，不是全有全無。

可能的好處

速度

靜態檔案（圖片、CSS、JS）由鄰近使用者的節點提供，減少往返時間。對台灣客群、主機也在台灣的網站，改善幅度有限；但如果主機在國外、或有海外客群，差異會很明顯。

穩定性

主機短暫故障時，部分服務可以繼續提供快取版本的頁面，不至於完全開不了。

安全

• 隱藏主機真實 IP，降低被直接攻擊的機會
• 提供分散式阻斷服務攻擊的緩解
• 可加上網站應用程式防火牆規則

管理便利

DNS 管理介面通常比註冊商或主機商的好用，變更生效也快。

要付出的代價

多一層可能出錯的環節

網站打不開時，除了主機和 DNS，還要多查一層代理設定。對排查問題的人來說，架構複雜度是有成本的。

快取造成的困惑

更新了網站內容或圖片，但使用者看到的還是舊版——因為節點快取還沒更新。需要在服務商後台手動清除快取。這件事如果沒人知道，會被誤判為網站故障。

SSL 設定容易搞錯

啟用代理後，加密其實分成兩段：使用者到節點、節點到主機。如果第二段設定不當，可能出現看似有鎖頭、實際上後半段未加密的情況，或產生無限重新導向的錯誤。設定時務必選擇兩段都加密的模式。

需要交出 DNS 控制權

名稱伺服器必須改指向該服務商。這代表該帳號的安全性等同於整個網域的安全性——帳號被盜，等於網站與信箱都被接管。務必啟用兩步驟驗證。

郵件容易出事

最常見的意外：把郵件相關的記錄也開啟代理。MX 記錄不能被代理，指向郵件伺服器的 A 記錄也應維持直連，否則信件會無法送達。設定時要逐筆確認代理的開關狀態。

什麼情況建議用

• 主機在國外，或有海外客群
• 網站曾經遭遇攻擊，或屬於容易被攻擊的類型
• 流量較大、圖片較多的網站
• 需要在多個主機之間做流量調度
• 有人懂得管理，出問題時知道怎麼查

什麼情況不必用

• 單純的企業形象網站、客群集中在台灣、主機也在台灣——多這一層的效益很有限，反而增加複雜度
• 公司內部沒有人熟悉這類設定，且配合的廠商也不熟
• 網站有大量動態內容，快取效益不高

我們的實際建議是：不要為了「聽說很好」而導入。 網站慢的原因多半是圖片沒壓縮、程式沒最佳化、主機規格不足，這些問題不會因為加一層 CDN 就消失。先把根本問題處理好，才是有效的做法。

如果決定導入，請注意

1. 先完整備份現有的所有 DNS 記錄。匯入時系統會自動掃描，但不保證抓得完整，尤其是 TXT 記錄容易遺漏
2. 逐筆核對匯入後的記錄與原本是否一致，特別是 MX 與 SPF、DKIM、DMARC
3. 先只做 DNS，不開代理，觀察數天確認一切正常
4. 再逐步為網站相關的記錄開啟代理，郵件相關記錄維持直連
5. 啟用後完整測試網站與收發信
6. 為帳號啟用兩步驟驗證

切換名稱伺服器同樣有擴散時間，作法與注意事項參考改了 DNS 要多久才生效。

為什麼要自己查

網站或信箱出問題時，最耗時的往往不是修復，而是判斷問題出在哪一層。會用查詢工具，可以在幾分鐘內確認 DNS 是否正常，把範圍縮小。

這篇整理最基本、也最實用的幾個指令。不需要背，用到時查一下即可。

工具的取得

• Windows——內建 nslookup，在命令提示字元或 PowerShell 直接使用
• macOS 與 Linux——內建 dig，功能較完整，輸出也較清楚
• 沒有指令環境——用線上的 DNS 查詢服務也可以，部分還能同時查詢多個地區的解析結果

基本查詢

查 IP（A 記錄）

nslookup example.com

dig example.com A +short

+short 只顯示結果，不顯示完整的查詢資訊，日常使用比較方便。

查郵件伺服器（MX 記錄）

nslookup -type=mx example.com

dig example.com MX +short

信箱有問題時第一個要查的。重點是確認只有現行服務商的記錄，沒有殘留的舊記錄。

查名稱伺服器（NS 記錄）

nslookup -type=ns example.com

dig example.com NS +short

這是最該優先學會的一個。 它告訴您這個網域實際由誰管理，也就是您該去哪裡改設定。改了半天沒效果，多半就是改錯地方。

查 TXT 記錄（SPF、DKIM、DMARC）

nslookup -type=txt example.com

dig example.com TXT +short

查 SPF 就看回傳結果中以 v=spf1 開頭的那一筆，如果出現兩筆，那就是問題所在。

DMARC 記錄放在特定的子名稱下：

dig _dmarc.example.com TXT +short

指定用哪個解析器查詢

這是排查擴散問題的關鍵技巧。在指令中指定解析器，就能看到不同解析器目前拿到的答案：

dig @8.8.8.8 example.com +short

nslookup example.com 8.8.8.8

用途：

• 比對不同解析器的結果是否一致，判斷擴散進度
• 若各家解析器答案已一致、只有自己看到舊的，那就是本機快取或 hosts 檔的問題

直接問權威伺服器

如果想跳過所有快取，直接問存放資料的源頭，可以先查出 NS，再指定該 NS 查詢：

dig @ns1.example.com example.com +short

這裡回傳的是最新、未經快取的真實設定值。若這裡是對的、外面是錯的，那就純粹是等擴散；若這裡也是錯的，那就是設定沒存進去。

看完整的查詢路徑

dig example.com +trace

會顯示從根伺服器一路往下查到權威伺服器的完整過程。用於診斷 NS 設定錯誤、或委派層級出問題的情況。日常用不到，但架構有異常時很有用。

清除本機快取

確認外面都正常、只有自己不對時：

• Windows：ipconfig /flushdns
• macOS：需執行對應的清除快取指令（版本間略有差異）
• 瀏覽器：用無痕視窗測試，或清除瀏覽紀錄
• 檢查 hosts 檔：測試期間手動加的指定會蓋掉一切，這是最容易忘記還原的設定

常見情境的排查順序

網站打不開

1. dig example.com NS +short — 確認由誰管理
2. dig example.com A +short — 確認有回傳 IP，且是預期的 IP
3. 若 IP 正確，問題不在 DNS，往主機端查
4. 若沒有回傳或 IP 不對，直接問權威伺服器，判斷是設定錯誤還是擴散中

信箱收不到信

1. dig example.com MX +short — 確認記錄正確且沒有殘留
2. 確認 MX 指向的名稱有 A 記錄
3. 往主機或郵件服務端查容量與過濾規則

寄信被當垃圾信

1. dig example.com TXT +short — 確認 SPF 只有一筆且涵蓋所有寄信來源
2. dig _dmarc.example.com TXT +short — 確認 DMARC 存在
3. 檢視實際收到信件的原始標頭，看驗證結果

詳細的處理方式見公司信箱收不到信或被當垃圾信怎麼查。

一個實用習慣

在做任何 DNS 變更之前，先把現有記錄查一次並存下來：

dig example.com ANY

部分伺服器已不完整回應 ANY 查詢，較保險的做法是逐一查詢 A、CNAME、MX、TXT、NS 並各自留存。這份紀錄在出問題要還原時，價值極高。