Web 應用程式已經上線，接下來想把平台提供的網址，換成自己的 app.example.com。
這項工作不只有購買網域。還要在應用程式的託管平台註冊主機名稱、透過 DNS 指定連線目標，並準備能讓這個名稱使用 HTTPS 的憑證。
來回切換設定畫面時，這三件事很容易混在一起。本文先分清楚各自的角色，再以 KamuiDash 為例，說明要輸入什麼，以及上線後要確認哪些項目。前提是應用程式已經能透過預設網址正常運作，而且你能編輯所持有網域的 DNS 設定。
螢幕截圖是日文介面的操作示範。網域和驗證值都是範例，不代表實際註冊網域、核發憑證或連線成功。畫面文字依據 2026 年 11 月 5 日確認的 UI。
本文內容
分清楚主機名稱、DNS 與 HTTPS
在 https://app.example.com/notes 中，app.example.com 是主機名稱，/notes 是應用程式內的路徑。取得網域後，就能管理其下的名稱；要連到哪個應用程式，還需要另外設定。
| 設定項目 | 決定的事情 | 主要設定位置 |
|---|---|---|
| 應用程式的自訂網域 | 哪個應用程式接收此主機名稱的請求 | 應用程式的託管平台 |
| DNS 記錄 | 如何查詢此主機名稱的連線目標 | 管理網域 DNS 的服務 |
| TLS 憑證，畫面也可能標示為 SSL | 能否以此主機名稱接受 HTTPS 連線 | 託管平台的憑證或自訂網域設定 |
當同一個平台服務多個應用程式時，光有連線目標還無法決定要交給哪個應用程式。註冊自訂網域，就是把主機名稱與應用程式連結起來。Render 的官方步驟也分為新增網域、設定 DNS、驗證網域。Render 官方：Custom Domains
購買網域的公司與管理 DNS 的服務不一定相同。如果 DNS 已經移交給另一家服務，應在移交後的服務編輯記錄。除了在哪裡購買，也要確認現在由哪裡管理 DNS。
先連接 app.example.com
本文使用已取得的 example.com 網域底下的 app.example.com。
example.com 本身也稱為根網域或 apex。連接根網域時，設定方式會因託管平台與 DNS 服務的組合而異。例如 Cloudflare 提供 CNAME flattening，讓根網域可以使用 CNAME 設定。先用子網域理解流程，再依雙方的說明處理根網域，會比較容易進行。Cloudflare 官方：CNAME flattening
連接前，先確認這個名稱是否已經用於網站或其他服務。新增 app 的設定，不需要更動無關的名稱或電子郵件記錄。若要搬移使用中的主機名稱，切換前先記下原設定與還原方式。
網域的註冊、續約費用，與託管平台自訂網域功能的費用是分開的。KamuiDash 的自訂網域也屬於額外計費項目，設定前請確認官方文件及價格頁面。
1. 在託管平台註冊主機名稱
在 KamuiDash 的應用程式詳細頁面開啟自訂網域設定；日文介面的按鈕是「カスタムドメインを設定」。輸入想使用的主機名稱：
app.example.com
不包含 https:// 或 /notes 等路徑。這裡要註冊的是連接應用程式的名稱，而非完整網址。
註冊後確認 DNS 設定說明。已設定的網域，可以從「カスタムドメインを管理」（管理自訂網域）查看。KamuiDash 每個應用程式可設定一個自訂網域，因此更換前要先確認既有設定。KamuiDash 官方：自訂網域
2. 設定 CNAME 與畫面顯示的驗證記錄
DNS 端先設定主機名稱的連線目標。CNAME 是參照另一個主機名稱的記錄；A 記錄指定 IPv4 位址，AAAA 記錄指定 IPv6 位址。應使用託管平台指定的記錄類型與值。Cloudflare 官方：DNS record types
KamuiDash 使用自訂網域畫面顯示的 CNAME 目標。請複製畫面上的值，不要自行推測應用程式的預設網址就是目標。
若將這個畫面的內容填入 example.com 的 DNS，對應方式如下。表內都是說明用的範例，請勿直接照值註冊。
| 類型 | 名稱／主機欄位 | 值／目標欄位 |
|---|---|---|
| CNAME | app 或 app.example.com |
畫面顯示的目標；此例為 demo-target.example.net |
| TXT，畫面顯示時 | 畫面顯示的 Key；此例為 _acme-challenge.app |
畫面顯示的 Value；此例為 demo-validation-value |
有些 DNS 服務的名稱欄只需輸入 app，有些則接受 app.example.com。請確認儲存後的完整記錄名稱是 app.example.com。 如果畫面會自動補上網域，卻又輸入完整名稱，尾端的網域可能重複。
app 分開理解。CNAME 的值不包含 https:// 或路徑。CNAME 是 DNS 上的別名，設定後不會因此自動把瀏覽器重新導向另一個網址。Cloudflare 官方：CNAME 記錄
確認每筆 TXT 的用途與值
核發憑證前，需要驗證你能控制該網域。其中一種方式是在 DNS 放入指定的 TXT 記錄。也有不使用 DNS 的驗證方式，所以並非所有託管服務都一定需要 TXT。Let's Encrypt 官方：Challenge Types
KamuiDash 目前的 UI 可能在 SSL 準備中顯示憑證驗證用的 TXT，SSL 生效後也可能不再顯示這項說明。若另外顯示「TXTレコード（所有権確認）」，那是所有權驗證，也需要處理。不要預設一定是「一筆 CNAME 加一筆 TXT」，而要確認當前畫面要求的記錄。
若同一個 TXT 名稱要求多個值，請將每個值分別註冊，不要串接成一個字串。Cloudflare 的TXT 憑證驗證說明也記載需要多筆驗證記錄的情況。
如果使用 Cloudflare 管理 DNS，也要遵守託管平台對代理狀態等條件的指示。僅 DNS 與透過 Cloudflare 代理流量的設定，行為並不相同。Cloudflare 官方：Proxy status
3. 確認 DNS 與 SSL，再開啟應用程式
儲存 DNS 記錄後，不代表所有查詢端立即傳回相同答案。DNS 回應可以快取，而 TTL 會影響保留時間。不要假定「儲存後固定幾分鐘就能使用」，而應確認設定與實際回應。Cloudflare 官方：TTL
回到 KamuiDash 重新確認狀態，查看是否顯示「SSL有効」（SSL 已生效）。
不要只看 SSL 狀態就結束。請用瀏覽器開啟 https://app.example.com，確認顯示的是預期應用程式。除了首頁，也要測試實際使用的頁面與 API。
應用程式若有登入或外部 API 整合，也要確認網址改變的影響。例如認證服務註冊的回呼網址、跨來源的 API 請求，以及 Cookie 的 Domain 設定。即使 DNS 與 HTTPS 正確，原本依賴舊網址的功能仍可能需要調整。
也要確認 HTTP 請求的處理方式。以下指令會顯示回應標頭，請將 app.example.com 換成自己的主機名稱。
curl -sS -D - -o /dev/null http://app.example.com/
若預期重新導向 HTTPS，請查看回應狀態與 Location 標頭。HTTPS 可用，與 HTTP 自動重新導向 HTTPS，是不同的行為，應依平台與應用程式設定確認。
無法開啟時，依 DNS、憑證、應用程式的順序檢查
找不到名稱，或連到不同的地方
先確認編輯記錄的服務是否正在管理該網域的 DNS，再檢查名稱和值。注意網域尾碼是否重複、目標是否複製錯誤，以及同一名稱下是否留有衝突記錄。
終端機若有 dig，可以用下列方式查詢 DNS 回應。
dig app.example.com CNAME +short
dig app.example.com A +short
dig _acme-challenge.app.example.com TXT +short
TXT 查詢名稱要換成設定畫面指定的名稱。有些設定會傳回 CNAME 目標，有些則因代理或 CNAME flattening 而以 A 記錄回應。不能只因 CNAME 查詢沒有結果，就判定設定失敗。 要依託管平台與 DNS 服務採用的方式解讀。Cloudflare 官方：CNAME flattening
即使沒有 dig，也能先在 DNS 管理畫面檢查儲存的名稱和值。安裝額外工具之前，先確認輸入位置與內容。
出現憑證警告，或一直顯示 SSL 準備中
確認註冊的主機名稱、DNS 目標，以及要求的驗證記錄。若仍在準備 SSL，查看畫面要求的驗證是否完成。將瀏覽器錯誤與平台狀態對照，不要忽略憑證警告就視為上線完成。
KamuiDash 顯示「要対応」（需要處理）或「確認できません」（無法確認）時，也應先查看當前記錄與錯誤，再考慮是否需要重新註冊。要分清楚需要等待的狀態，以及需要修正輸入的狀態。
HTTPS 能開啟，但出現 404 或 502
確認自訂網域連結到哪個應用程式，以及應用程式的目前狀態。預設網址也有同樣錯誤時，可據此調查啟動狀態或程式內的路由。只有自訂網域出錯時，則確認主機名稱的註冊及應用程式允許的主機設定等。
404 或 502 可能來自平台，也可能來自應用程式。不能只因收到 HTTP 錯誤回應，就判定 DNS 之後全部正確。請依回應內容或記錄，確認由哪一層傳回。
用自己的網址完成平常的操作，才算完成
連接自訂網域，就是在託管平台註冊主機名稱、設定 DNS 目標與所需驗證記錄，再確認 HTTPS 與應用程式回應。
最後確認自己的主機名稱能透過 https:// 開啟預期的應用程式、必要頁面與登入功能正常，而且 HTTP 的行為符合預期。分開檢查後，即使開啟失敗，也能選擇下一個確認位置，而不會只停在「應該還在等待生效」。
應用程式尚未上線的話，可以先看推送到 GitHub 後自動部署的步驟。若仍在選擇託管平台，可參考個人開發 Web 應用程式的部署選項。
KamuiDash 是能從 GitHub 部署 Web 應用程式的 PaaS。