瀏覽器輸入網址後發生什麼事？完整請求流程圖解

你有沒有想過，每天打開 Chrome、輸入網址、按下 Enter，網頁就這樣「蹦」出來了——這中間到底發生了什麼？

說真的，這整個過程其實超級複雜。

你的請求要穿越好幾層網路設備、經過各種伺服器的處理，最後才能把網頁送到你眼前。但神奇的是，這一切通常只需要幾百毫秒就完成了。

這個問題也是工程師面試超常見的考古題，面試官很愛問：「請說明從輸入網址到網頁出現的過程。」

為什麼愛考這題？因為這題可以測出你對網路架構的理解有多深，從前端到後端、從硬體到軟體，全部都會牽涉到。

別擔心，這篇文章會用最白話的方式，帶你走一遍這整個旅程。不管你是剛開始學程式的新手，還是想準備面試的工程師，看完這篇應該都會有收穫。

第一站：你的瀏覽器

瀏覽器是什麼？

簡單說，瀏覽器就是讓你「看網頁」的軟體。你常用的 Chrome、Safari、Firefox、Edge 都是瀏覽器。

但瀏覽器做的事情可不只是「顯示網頁」這麼簡單。它其實是一個超級複雜的軟體，負責：

1. 解析 HTML：把網頁的骨架結構讀懂
2. 套用 CSS：幫網頁穿上衣服、化好妝（顏色、字體、排版）
3. 執行 JavaScript：讓網頁動起來（按鈕可以點、表單可以送）
4. 發送網路請求：幫你去跟伺服器要資料
5. 管理快取：把常用的東西存起來，下次開更快

所以當你打開一個網頁，瀏覽器其實在背後忙得要命。

延伸閱讀：什麼是網頁瀏覽器？從零開始認識網頁世界的入口

小提醒：手機版和電腦版不一樣

同一個網站，有時候電腦上跑得好好的，手機卻壞掉。這很正常，原因有幾個：

1. 螢幕大小不同：手機螢幕小，排版要重新設計
2. 瀏覽器版本不同：手機版 Chrome 和電腦版 Chrome 不完全一樣
3. 效能限制：手機的運算能力比電腦弱，太複雜的網頁可能跑不動
4. 觸控 vs 滑鼠：操作方式不同，有些功能要另外處理

所以現在的網頁開發者都要做「響應式設計（Responsive Design）」，讓網頁能自動適應不同的螢幕大小。

第二站：訊號怎麼出去的？

你在瀏覽器打完網址按 Enter 後，這個訊號要送出去，總得有條路吧？

這條路就是我們說的「網路」。不管你是插網路線還是連 Wi-Fi，訊號大概會這樣跑：

flowchart TD
    A[🖥️ 你的電腦] --> B[🔌 網卡]
    B --> C[📶 Wi-Fi 分享器 / 網路線]
    C --> D[🌐 路由器]
    D --> E[🏢 ISP]
    E --> F[🌍 外面的網路世界]

讓我們簡單認識一下這幾個東西。

網卡、Wi-Fi 分享器、路由器

簡單介紹一下這幾個東西：

• 網卡：電腦用來上網的元件，有線（插網路線）和無線（連 Wi-Fi）兩種。有線通常比較快又穩，無線比較方便。
• Wi-Fi 分享器：讓你連無線網路的小盒子，負責把無線訊號轉成有線訊號往後送。
• 路由器（Router）：網路的「大總管」，負責分配 IP 給每台設備，並把你家的網路跟外面的網際網路接起來。

用宿舍來比喻

如果你住過宿舍，應該有印象：房間裡可能有個小小的 Wi-Fi 分享器，讓室友們可以一起上網。

但這個分享器不是直接連到網際網路的。它的後面還連著整棟宿舍的「大路由器」，所有學生的網路請求都會先經過這個大路由器，再一起送出去。

這就是為什麼：

• 同一棟宿舍的人，IP 位址前面幾碼會長得一樣
• 宿舍網路常常很慢，因為太多人在搶頻寬

延伸閱讀：Hub 集線器、Switch 交換器、Router 路由器 完全解析：一次搞懂三大網路設備

ISP：網路服務供應商

ISP（Internet Service Provider）就是提供你網路服務的公司，像是中華電信、台灣大哥大、凱擘等等。

你每個月繳的網路費，就是付給 ISP 的。他們負責把你家的網路連到整個網際網路上。

你的請求離開路由器後，會先到達 ISP 的機房，然後再從那裡送到你要去的地方。

第三站：DNS — 網址翻譯機

好，你的請求已經成功離開你家了。但現在有個問題：你輸入的是 www.google.com，可是網路世界根本不認識這串字。

電腦其實看不懂網址

這就像你跟計程車司機說「我要去台北 101」，司機可能聽得懂。但如果你跟 GPS 說「台北 101」，GPS 需要的其實是經緯度座標。

在網路世界也是一樣：

• 網址（URL）：www.google.com → 人看得懂
• IP 位址：142.250.185.78 → 電腦看得懂

URL 是給人類用的，因為我們比較容易記住有意義的文字。但電腦和網路設備只認得數字組成的 IP 位址。

IP 位址是什麼？

IP 位址就是每台連上網路的設備的「門牌號碼」。就像你家有個地址，網路上的每台電腦、每台伺服器也都有自己的 IP 位址。

目前常見的 IP 位址有兩種格式：

1. IPv4：像 192.168.1.1 這樣，四組數字，每組 0-255
2. IPv6：像 2001:0db8:85a3:0000:0000:8a2e:0370:7334 這樣，更長、更複雜

IPv4 的數量有限（大約 43 億個），已經快不夠用了，所以慢慢在轉向 IPv6。

延伸閱讀：IP 是什麼？public IP 與 private IP：深入了解與應用場景解析

DNS 就是翻譯官

DNS（Domain Name System，網域名稱系統） 伺服器的工作就是幫你做翻譯：

「你要找 www.google.com？讓我查一下⋯⋯喔，它的 IP 是 142.250.185.78，給你。」

這個過程叫做「DNS 解析」或「域名解析」。

延伸閱讀：DNS 是什麼？讓網站被找到的關鍵角色

為什麼 DNS 很重要？

DNS 掛掉的話，你就算知道網站存在，也連不上去。

這就像電話簿不見了，你知道朋友叫什麼名字，但不知道他的電話號碼。

歷史上發生過幾次大規模的 DNS 故障，導致大半個網際網路都不能用。所以 DNS 的穩定性非常重要。

第四站：進入伺服器的世界

好，DNS 已經告訴你 IP 位址了。現在你的請求終於可以飛向目標伺服器了。

但「伺服器」到底是什麼？讓我們來好好聊聊。

伺服器就是⋯⋯一台電腦

沒錯，伺服器本質上就是一台電腦。只是它：

• 通常 24 小時不關機
• 硬體規格比較好（更多 CPU、更大記憶體、更快的硬碟）
• 放在專門的機房裡（有空調、有備用電源）
• 跑的是伺服器專用的作業系統（通常是 Linux）

你可以在家用自己的電腦架一個伺服器，但如果要給很多人用，還是得用專業的機器和機房。

先搞懂一件事：Server 這個詞很曖昧

「Server」這個詞在業界用得很氾濫，有時候會讓人搞混。它可能指：

1. 硬體伺服器：那台實體的機器
2. Web Server 軟體：跑在機器上、處理網頁請求的程式（後面會詳細介紹）
3. 泛指後端：「我要把這個丟給 server 處理」

講話的時候最好講清楚你指的是哪一種，不然很容易雞同鴨講。

在這篇文章裡，如果我說「伺服器機器」就是指硬體，說「Web Server」就是指軟體。

延伸閱讀：伺服器是什麼？新手入門指南

前端 vs 後端，界線在哪？

如果你是剛入行的新手，可能常常聽到「前端」、「後端」這兩個詞。它們到底怎麼分？

其實很簡單，就看程式碼跑在哪裡。用一張圖來看最清楚：

flowchart LR
    subgraph 前端
        A[🖥️ 瀏覽器<br/>輸入 URL]
    end

    A --> B[📶 Wi-Fi]
    B --> C[🌐 Router]
    C --> D[📖 DNS<br/>URL → IP]
    D --> E

    subgraph 後端
        E[🖧 Server]
    end

簡單來說：

• 前端：在你的瀏覽器上跑的東西，負責畫面和互動，使用者按 F12 就能看到程式碼
• 後端：在伺服器上跑的東西，負責資料處理和商業邏輯，使用者看不到

你的請求經過 Router、被 DNS 翻譯成 IP 之後，就會進入後端 Server 的地盤了。

延伸閱讀：Web 開發進化論：為什麼前後端分離成為主流？

第五站：負載平衡器 — 流量分配員

好，現在你的請求已經通過 DNS 翻譯成 IP，準備要進入 Server 了。

但在真正進去之前，可能會先遇到一個守門員：負載平衡器。

如果你是一個小網站，可能一台伺服器就夠了，請求直接進去就好。但如果你是 Facebook、Google 這種等級的網站呢？

為什麼需要這東西？

想像一下，Facebook 每秒有幾百萬人在用。如果所有請求都打到同一台機器，會發生什麼事？

1. 那台機器的 CPU 會飆到 100%
2. 記憶體會被吃光
3. 網路頻寬會塞爆
4. 然後⋯⋯機器就掛了

網站一掛，使用者看到的就是「無法連線」或「伺服器錯誤」。對於大公司來說，每分鐘的當機都是在燒錢。

負載平衡器怎麼運作？

負載平衡器（Load Balancer） 就像銀行的叫號機：

「1 號請到 A 櫃檯，2 號請到 B 櫃檯，3 號請到 C 櫃檯⋯⋯」

它會把大量的請求分散到好幾台伺服器，讓每台都不會太累：

flowchart LR
    A[用戶請求] --> B[負載平衡器]
    B --> C[伺服器 A<br/>處理 33% 請求]
    B --> D[伺服器 B<br/>處理 33% 請求]
    B --> E[伺服器 C<br/>處理 33% 請求]

延伸閱讀：負載平衡（Load Balancing）是什麼？

如果你很窮呢？

沒錢買很多台伺服器？那就只有一台硬扛。

這就是所謂的「窮人版架構」：

用戶請求 → 直接打到那唯一的一台伺服器

用戶請求 → 直接打到那唯一的一台伺服器

流量小的時候還好，流量大的時候⋯⋯就祈禱吧。

不過現在雲端服務很方便，AWS、GCP、Azure 都有提供負載平衡的服務，不用自己買硬體也能用。小公司通常會選擇這種方式。

第六站：Web Server — 真正幹活的傢伙

經過負載平衡器的分配（如果有的話），請求終於來到某一台伺服器了。

但請求進來之後，是誰在處理？就是我們說的 Web Server。

Web Server 是什麼？

Web Server 是跑在伺服器機器裡面的程式，專門負責處理 HTTP 請求。

你可以這樣理解層次關係：

Web Server 的工作內容

Web Server 負責的事情：

1. 監聽請求：隨時等著，看有沒有人來敲門
2. 解析請求：「這個人要什麼？他要首頁？還是要登入？」
3. 處理請求：執行對應的程式邏輯
4. 回傳回應：把結果打包好送回去

請求（Request）與回應（Response）

Web Server 的工作就是「收請求、給回應」：

• 請求（Request）：瀏覽器送出的資訊，包含你要什麼（GET 讀取、POST 新增）、要訪問哪個頁面、你的登入狀態等等
• 回應（Response）：Web Server 處理完後回傳的結果，可能是網頁、JSON 資料、圖片等等

回應裡會有一個「狀態碼」告訴你結果如何，常見的有：

• 200：成功
• 404：找不到（這個頁面不存在）
• 500：伺服器錯誤（後端程式爆炸了）

常見的 Web Server 框架

根據不同的程式語言，有不同的 Web Server 框架可以用：

選哪個框架通常取決於團隊熟悉什麼語言，以及專案的需求。

第七站：一台機器怎麼跑多個網站？

到這裡，你可能會有個疑問：如果我只有一台伺服器，但想同時架好幾個網站，該怎麼辦？

先來看問題

假設你是一個接案的工程師，手上有幾個案子：

• 客戶 A 的官網：www.company-a.com
• 客戶 B 的課程網站：course.company-b.com
• 你自己的部落格：blog.myname.com

但你很窮，只租得起一台伺服器。這三個網址經過 DNS 翻譯後，都會指向同一個 IP（因為你只有一台機器）。

那問題來了：請求來了，機器怎麼知道要交給誰處理？

Port（埠號）：不同的碼頭

把 IP 位址想成一個「港口」，Port 就是港口裡的「不同碼頭」：

• 1.2.3.4:8080 → 第 8080 號碼頭（客戶 A 的官網）
• 1.2.3.4:8081 → 第 8081 號碼頭（客戶 B 的課程網站）
• 1.2.3.4:8082 → 第 8082 號碼頭（你的部落格）

每個 Port 可以跑不同的服務，這樣就算只有一個 IP，也能同時跑很多網站。

延伸閱讀：什麼是 Port？為什麼它在網路世界中這麼重要？

但 DNS 不管 Port 啊

這裡有個問題：DNS 只負責把網址翻成 IP，它根本不會幫你加 Port。

所以當使用者輸入 www.company-a.com：

1. DNS 說：「IP 是 1.2.3.4」
2. 瀏覽器預設會連到 Port 80（HTTP）或 443（HTTPS）
3. 請求來到你的伺服器⋯⋯然後呢？

你的伺服器收到請求後，要怎麼知道應該轉給 8080（客戶 A）還是 8081（客戶 B）？

反向代理：交通指揮中心

這就是 反向代理（Reverse Proxy） 登場的時候了！

反向代理就像機場的入境大廳，有人會看你的機票，然後告訴你：

「你是飛國內線的？往左邊走。你是國際線的？往右邊走。」

在我們的例子裡：

用戶請求 www.company-a.com
        ↓
  DNS 解析：1.2.3.4
        ↓
  請求來到 Port 80（反向代理在這裡守著）
        ↓
  反向代理看一下：「喔，你要找 company-a.com」
        ↓
  轉發到 Port 8080（客戶 A 的 Web Server）

用戶請求 www.company-a.com
        ↓
  DNS 解析：1.2.3.4
        ↓
  請求來到 Port 80（反向代理在這裡守著）
        ↓
  反向代理看一下：「喔，你要找 company-a.com」
        ↓
  轉發到 Port 8080（客戶 A 的 Web Server）

對於其他網站也是一樣：

• company-a.com → 轉到 Port 8080
• company-b.com → 轉到 Port 8081
• myname.com → 轉到 Port 8082

常見的反向代理軟體

最常用的反向代理軟體是：

1. Nginx：效能好、設定彈性、最流行
2. Apache：老牌、功能完整
3. Caddy：新興、自動 HTTPS、設定簡單

如果你是新手，建議從 Nginx 或 Caddy 開始學。

反向代理還能幹嘛？

反向代理不只是做轉發，它還能：

快取加速

把常用的東西存起來，使用者再來問的時候，直接從反向代理這裡回覆，不用去煩 Web Server：

第一次請求：使用者 → 反向代理 → Web Server → 反向代理（存起來） → 使用者
第二次請求：使用者 → 反向代理（直接回覆） → 使用者

第一次請求：使用者 → 反向代理 → Web Server → 反向代理（存起來） → 使用者
第二次請求：使用者 → 反向代理（直接回覆） → 使用者

這對於靜態內容（圖片、CSS、JS）特別有效。

處理 HTTPS 加密

HTTPS 需要做加解密，這很吃 CPU。可以讓反向代理統一處理，後面的 Web Server 就只要用 HTTP 就好：

使用者 ←→ HTTPS ←→ 反向代理 ←→ HTTP ←→ Web Server

使用者 ←→ HTTPS ←→ 反向代理 ←→ HTTP ←→ Web Server

這叫做「SSL 終止」或「SSL Termination」。

直接回傳靜態檔案

圖片、CSS、JS、影片這些「靜態檔案」不需要經過 Web Server 處理，反向代理可以直接從硬碟讀出來給使用者：

動態請求（API、網頁）→ 轉給 Web Server
靜態檔案（圖片、CSS）→ 反向代理直接處理

動態請求（API、網頁）→ 轉給 Web Server
靜態檔案（圖片、CSS）→ 反向代理直接處理

這樣可以減輕 Web Server 的負擔。

安全防護

反向代理可以幫忙擋掉一些惡意請求，像是：

• 過濾可疑的 IP
• 限制請求頻率（防止 DDoS）
• 隱藏後端伺服器的真實資訊

延伸閱讀：反向代理（Reverse Proxy）是什麼？初學者必看詳解

第八站：正向代理 — 你這邊的代理人

講完反向代理，順便來講講它的兄弟：正向代理（Proxy）。

代理 vs 反向代理

這兩個名字很像，但角色完全相反：

用生活例子來比喻

• 正向代理：你請代購幫你買國外的東西，賣家只看到代購，不知道真正的買家是你
• 反向代理：公司有個總機，所有電話打進來都先經過總機，再轉接到各部門

正向代理在哪？

你可能不知道，但你的網路請求可能每天都在經過正向代理：

學校/公司的網路

學校和公司通常會架設代理伺服器，用來：

• 監控網路使用狀況
• 擋掉特定網站（像是遊戲網站、社群媒體）
• 快取常用資料，節省頻寬

宿舍網路

宿舍的網路也常常有代理，主要是為了省頻寬。如果 100 個學生都要看同一部 YouTube 影片，代理伺服器可以只下載一次，然後分給大家。

翻牆工具

你聽過的 VPN、Shadowsocks 這些「翻牆工具」，本質上就是一種代理。你的請求先送到代理伺服器（在國外），再由代理伺服器幫你去訪問被封鎖的網站。

爬蟲常用

寫爬蟲的人常常會用代理伺服器，讓每個請求看起來來自不同的 IP，避免被網站封鎖。

為什麼網頁沒更新？

有時候你會發現：「奇怪，網站明明更新了，我看到的還是舊的？」

可能的原因之一就是：中間的代理伺服器還存著舊資料。

這種狀況特別常發生在學校或公司的網路。解決方法是：

• 按 Ctrl+F5 強制重新載入
• 清除瀏覽器快取
• 等一陣子讓代理的快取過期

第九站：資料庫 — 資料住的地方

前面講了這麼多，但好像漏了一個重要的東西：資料存在哪裡？

當你登入一個網站，它怎麼知道你是誰？當你在購物網站下訂單，訂單資料存在哪裡？

答案是：資料庫（Database）。

資料庫是什麼？

資料庫就是專門用來「存資料」和「查資料」的軟體。你可以把它想像成一個超級大的 Excel 表格，可以存幾百萬、幾千萬筆資料，而且查詢速度超快。

Web Server 和資料庫的關係

使用者請求：「我要看訂單編號 12345」
        ↓
    Web Server 收到
        ↓
    去資料庫查：「SELECT * FROM orders WHERE id = 12345」
        ↓
    資料庫回傳：「訂單資料在這裡」
        ↓
    Web Server 把資料包裝成網頁
        ↓
    回傳給使用者

使用者請求：「我要看訂單編號 12345」
        ↓
    Web Server 收到
        ↓
    去資料庫查：「SELECT * FROM orders WHERE id = 12345」
        ↓
    資料庫回傳：「訂單資料在這裡」
        ↓
    Web Server 把資料包裝成網頁
        ↓
    回傳給使用者

常見的資料庫

不同的場景會選擇不同的資料庫，有時候一個系統會同時用好幾種。

延伸閱讀：從資料庫到 API：後端怎麼讓前端拿到想要的資料？

第十站：回程 — 資料怎麼回到你眼前

好，伺服器已經處理完你的請求，準備好回應了。接下來這些資料要原路返回。

回程的路線

flowchart LR
    subgraph 後端
        A[Web Server<br/>產生回應] --> B[反向代理<br/>加 Header、壓縮]
        B --> C[負載平衡器]
    end

    subgraph 網路
        C --> D[網際網路]
        D --> E[ISP]
        E --> F[路由器]
    end

    subgraph 前端
        F --> G[正向代理<br/>可能快取]
        G --> H[網卡]
        H --> I[瀏覽器<br/>渲染網頁]
    end

瀏覽器拿到資料後做什麼？

瀏覽器收到 HTML 後，會解析內容、下載需要的資源（CSS、JavaScript、圖片）、然後把畫面「畫」出來。這整個過程叫做渲染（Rendering）。

為什麼有些網頁很慢？

現在你應該可以理解了。一個網頁慢，可能是因為：

• DNS 解析很慢
• 伺服器在很遠的地方
• 伺服器太忙，處理很慢
• 回傳的資料太大
• 網頁太複雜，瀏覽器渲染很久
• 你的網路很慢

工程師會用各種技術來加速，像是 CDN、快取、壓縮、延遲載入⋯⋯這些都是之後可以深入學習的主題。

完整流程：一張圖看懂

讓我們把整個旅程串起來：

sequenceDiagram
    participant 瀏覽器
    participant 路由器
    participant DNS
    participant 負載平衡器
    participant WebServer
    participant 資料庫

    Note over 瀏覽器: 輸入網址，按 Enter

    瀏覽器->>路由器: 發送請求
    路由器->>DNS: URL 是什麼 IP？
    DNS-->>路由器: IP 是 1.2.3.4
    路由器->>負載平衡器: 請求送達
    負載平衡器->>WebServer: 分配到某台伺服器
    WebServer->>資料庫: 查詢資料
    資料庫-->>WebServer: 回傳資料
    WebServer-->>負載平衡器: 產生回應
    負載平衡器-->>路由器: 回應返回
    路由器-->>瀏覽器: 收到回應

    Note over 瀏覽器: 渲染網頁，顯示畫面！

整個過程通常只需要幾百毫秒！

重點整理

結語

從你按下 Enter 的那一刻開始，你的請求就踏上了一段奇妙的旅程。它穿越了你的電腦、路由器、ISP、DNS、負載平衡器、反向代理、Web Server、資料庫⋯⋯然後再原路返回。

這一切在幾百毫秒內完成，快到你幾乎感覺不到。但背後其實是無數工程師幾十年來的努力，建立起這套複雜但高效的系統。

希望這篇文章有幫助你理解這個過程。下次面試被問到這題的時候，你就可以侃侃而談啦！