文章詳情

阿里雲帳號購買開通阿里雲香港反向代理國內伺服器教程

阿里雲國際2026-08-25 15:02:51阿里雲

第一章：先把問題想清楚

很多人一開始做「香港反向代理」時，只盯著兩個名詞：阿里雲和反向代理。結果會遇到同一類挫折——連上了但很慢、證書不工作、回源失敗、或被防火牆擋住。要避免這些反覆試錯，最好的方式是先把目標拆解成可驗證的子任務。

你想要的通常是這樣一條鏈：外部使用者訪問你的域名（例如 www.example.com）→ 請求先到阿里雲香港節點 → 由香港端的 Nginx 將請求轉發到國內後端伺服器（例如 10.x.x.x 或 119.x.x.x）→ 國內服務回應，香港節點再把回應返回給使用者。

這個架構最關鍵的其實不是「用不用反向代理」，而是四件事：

阿里雲帳號購買開通 域名解析要落到香港節點，且解析生效可預期。
香港節點能穩定連到國內後端（網路、端口、安全組合都要通）。
HTTPS 的證書與域名要能被客戶端驗證，且 Nginx 的配置不出錯。
反向代理要處理好常見細節：Host、X-Forwarded-For、WebSocket、重定向、超時。

當你把這四件事都確定了，教程就能變得非常落地，而不是憑運氣。

第二章：環境與前置條件

2.1 角色分工：香港端與國內端

建議你把系統分成兩層：

香港端（反向代理層）：負責對外入口（域名、HTTPS、路由、轉發、日誌、限流或 WAF 規則若有）。
國內端（業務層）：提供實際服務（Web、API、管理後台等），不需要直接暴露給外網（或至少不要讓外網直接打到它）。

這能讓國內服務保持相對安全，同时把對外變更控制集中在香港端。

阿里雲帳號購買開通 2.2 網路可達性：安全組與防火牆

你必須先確認阿里雲香港實例與國內後端之間，是否存在「能不能連」的問題。常見卡點包括：

香港實例的安全組未放行出站到國內後端的端口。
國內後端的防火牆未允許來自香港節點的源 IP。
國內後端在 NAT 後導致回包路由異常。
後端服務綁定在錯誤的網卡（例如只綁定 127.0.0.1）。

實作前做一個簡單測試是最省時間的：從香港實例執行連線測試，確認後端端口可通。例如確認後端是 80 或 443，就測這些端口。

2.3 域名與 DNS：不要跳過驗證

你需要一個已掌握控制權的域名。DNS 應該把 A/AAAA 記錄指向香港實例的公網 IP（IPv4 常用 A 記錄）。如果你打算使用多區域或多實例，則需要更精細的策略；但在入門階段，先保證單點可用即可。

阿里雲帳號購買開通 同時確保域名解析生效：可以用本機 DNS 查詢或線上診斷確認。

第三章：香港端部署反向代理（Nginx 方案）

3.1 基礎目標：用 Nginx 做轉發

以 Nginx 為例，你的配置核心就是 server 內的 location，把請求轉發到國內後端。

下面以你的後端服務在國內內網或公網地址為例：

香港 Nginx 對外：https://www.example.com
國內後端：http://1.2.3.4:8080（示例，可替換）

注意：如果國內後端是 HTTPS，則 proxy_pass 也要用 https，並考慮證書校驗策略（必要時可配置 proxy_ssl_verify，但更好的方式是讓內部也具備可驗證的證書鏈）。

3.2 安裝與啟動 Nginx

阿里雲帳號購買開通 如果你使用的是 Linux 實例，一般可用系統包管理器安裝 Nginx。安裝完成後，確認服務狀態為 active，再配置網站。

你會需要一個可被 Nginx 讀取的站點配置檔。常見位置依發行版而不同。總之，原則是：配置文件放到 Nginx 讀取的站點目錄或主配置 include 目錄。

3.3 HTTP 先跑通：把 HTTPS 放在後面

很多人一上來就配 HTTPS，結果中間任意一步錯了（證書路徑、憑證鏈、重定向），排查成本暴增。建議流程是：

先讓 HTTP 正常轉發（80 端口）
確認應用層功能（API、靜態資源、重定向）都正常
再上 HTTPS

HTTP 測試期間，你可以用最小配置，先把 proxy_pass 跑通。

3.4 範例：HTTP 反向代理配置

以下是一個典型配置示例（請按你的域名與後端地址調整）：

server {
    listen 80;
    server_name www.example.com;

    client_max_body_size 50m;

    location / {
        proxy_pass http://1.2.3.4:8080;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

這份配置解決了幾個常見需求：

Host 傳遞：讓後端能知道使用者請求的域名。
真實 IP：讓應用層可以記錄正確來源地址（尤其是做日誌、風控、限流時）。
超時參數：避免轉發後端慢時出現不必要的斷線。

3.5 WebSocket 與長連線（若你的服務需要）

如果你有 WebSocket、SSE 或需要長連線的功能，你必須在 Nginx 補上相關頭。以 WebSocket 為例，你可以在 location 中加：

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

並將讀超時調大一些。否則在連線建立後可能很快就掉。

第四章：上 HTTPS：證書與重定向策略

4.1 為什麼要認真做 HTTPS

如果你的服務對外提供 API 或前端頁面，HTTPS 不只是安全問題，更會影響瀏覽器行為與部分 API 的調用規則。即便你只想讓外部連到服務，證書錯誤也會直接導致訪問失敗。

4.2 證書取得方式

阿里雲通常會提供證書申請或集成能力，你也可以採用第三方 CA。無論你用哪種方式，Nginx 最終都需要：

域名對應的證書（fullchain）
私鑰檔（key）

確保證書檔案的權限正確，Nginx 有能力讀取。

4.3 HTTPS 站點配置範例（含重定向）

上 HTTPS 後，你通常希望：

所有 http（80）請求自動跳轉到 https（443）
https 才真正轉發到後端

示例：

server {
    listen 80;
    server_name www.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    client_max_body_size 50m;

    location / {
        proxy_pass http://1.2.3.4:8080;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

如果你的服務不使用 WebSocket，也可以移除 Upgrade/Connection，以減少不必要的干擾。

4.4 常見 HTTPS 錯誤排查

證書鏈不完整：瀏覽器顯示不受信任，通常是 missing fullchain。
域名不匹配：證書發給了別的域名，或你用了泛域名但配置錯。
端口未放行：安全組未放行 443。
重定向死循環：後端也做了類似重定向，且 Nginx 又把 scheme 設錯，導致反覆跳。

遇到錯誤不要先改一堆配置。先用瀏覽器查看錯誤類型，再定位到證書或重定向邏輯。

第五章：把國內後端接到香港端（回源細節）

5.1 後端地址選擇：內網還是公網

理想情況下，你會用內網地址或私網連線，降低曝露面。但這通常依賴你是否能做到跨地域的內網互通（例如專線、VPN、專用通道）。如果你目前沒有內網互通，只能使用國內伺服器的公網 IP，那也可行。

不管你用哪種方式，重點是：

香港端能連到後端
後端能回應（回包路由正常）
防火牆/安全組允許來源

5.2 應用層要知道「真實協議」與「真實 IP」

反向代理最常見的坑，是後端程式誤判使用者來源與協議，導致生成錯誤的跳轉連結或錯誤的安全判斷。

因此你在 Nginx 設置了：

X-Forwarded-Proto：讓後端知道原始是 http 還是 https
：讓後端知道使用者真實 IP

後端程式也要配合使用這些 header。你不需要在所有框架上手動硬編程，但至少在框架層要讓它信任反向代理（例如在安全設定或 middleware 中加入 trusted proxy）。

阿里雲帳號購買開通 5.3 反向代理的路徑問題：location 與應用根目錄

如果你的應用不是部署在根目錄（例如它只在 /api 下工作），你需要調整 location 以及是否要做重寫。常見做法是：

如果後端也以相同路徑提供服務：直接按同樣路徑轉發。
如果後端在根目錄，但你希望外部用 /api：就要做 prefix 去除或重寫。

阿里雲帳號購買開通 簡單原則是：讓外部和後端的路由約定一致，能少很多麻煩。

第六章：把可用性做起來：健康檢查、限流與日誌

6.1 日誌：你要看得到什麼才算真的運行

反向代理出問題時，你通常需要同時看兩層日誌：

香港 Nginx 日誌：看到請求是否到達、是否轉發、狀態碼、上游連線錯誤。
國內後端日誌：看到是否真的處理了請求、路由是否錯、應用是否報錯。

建議至少把 error_log 打到能追蹤問題的級別，並保留合理的日誌輪轉策略，避免磁碟被打滿。

6.2 上游多實例：最先做負載不是硬上複雜集群

如果你有多台國內後端，可以用 Nginx 的 upstream 做簡單負載。這比你手動切換要可靠。

示例（概念）：

upstream backend_pool {
    server 1.2.3.4:8080;
    server 1.2.3.5:8080;
    # 可視需求加權重、容錯策略
}

server {
    # ...
    location / {
        proxy_pass http://backend_pool;
        # header 與超時等同前
    }
}

健康檢查與更進階容錯（如 keepalive、fail_timeout）可以逐步加。先把單點穩定跑通，再談高可用。

6.3 限流與安全基本功

把入口放在香港，等於把攻擊集中在香港端。這是優點，但你也要在香港端做基本保護：

限制最大上傳大小（client_max_body_size）。
對高頻路徑做簡單限流（可選）。
保留敏感端點的訪問限制（例如只允許內網或指定來源）。

阿里雲帳號購買開通 如果你使用 WAF 或安全產品，確保它不會誤殺你的業務流量。尤其是 API 的 header、token 格式，容易被過度規則影響。

阿里雲帳號購買開通第七章：跨地域連線品質：為什麼你會覺得「慢」

7.1 延遲與帶寬的現實

香港到國內的連線，延遲與抖動通常比同地域低效能方案更可控，但仍然存在。你需要理解：反向代理讓「每次請求」多了一跳。若後端響應本身就慢，多出這跳只會放大問題。

你可以從三個角度改善：

提升後端本身效能：慢查詢、緩存、壓縮。
調整 Nginx 超時與緩衝：避免小問題造成大幅超時。
使用 keepalive：讓連線複用，減少握手成本。

7.2 在 Nginx 開啟 keepalive 的思路

當你代理到後端時，連線複用可以減少 TCP/TLS 開銷。具體配置因 Nginx 版本與需求不同，但你可以先在 upstream 或 proxy 層加入 keepalive 相關配置。

不要一上來就把參數調到極端。建議以日誌和監控數據為依據逐步調整。

第八章：實戰排錯清單（照著查會快很多）

阿里雲帳號購買開通 8.1 連不上：先查安全組，再查後端綁定

香港能否對國內後端 ping（若被阻擋不代表不可用）。
香港到後端端口是否通（用連線測試）。
國內後端是否只綁定了 127.0.0.1。
安全組/防火牆是否允許來源 IP 與目標端口。

8.2 能訪問但 502/504：上游連線或超時

502 常見是上游連線失敗或返回不符合預期。
504 通常是讀超時或連線超時。
檢查 Nginx error_log，通常會直接告訴你是 connect timeout 還是 upstream timed out。

不要只看瀏覽器狀態碼。瀏覽器只會告訴你結果，error_log 才會告訴你過程。

8.3 重定向錯亂：X-Forwarded-Proto 的信任鏈

如果你的後端框架（例如某些 Web 框架）會根據請求協議判斷跳轉，反向代理必須正確傳 X-Forwarded-Proto，並且後端要信任這個 header。

否則可能出現：

https 跳到 http，再跳回 https（死循環）
生成錯誤的絕對連結
cookie secure 標記不生效

排錯時，從後端日誌或框架的 request 解析結果確認它看到的 scheme 是什麼。

8.4 靜態資源 404：靜態路徑沒有一致

前端引用的資源路徑是否匹配反向代理的 URL。
後端的靜態目錄是否正確。
location 是否過於寬泛，導致某些請求被錯誤轉發。

如果你有子路徑部署（例如 /app），特別要檢查 base path 設定。

第九章：最佳實務：讓系統更穩、更好維護

9.1 配置分離：把可變與不可變拆開

你可以把常用代理通用段落（header、超時）抽成 include 檔，然後不同站點只改域名和 upstream。這樣維護時不會每次都抄一遍，出錯機率明顯下降。

9.2 版本策略：先小改、再觀察

每次改 Nginx 配置後，都建議先執行配置檢查（例如 nginx -t 類似的語法檢查），再 reload。更重要的是：改完後要觀察 10 到 30 分鐘的日誌，確認狀態碼、上游錯誤是否增加。

9.3 監控：不只是「能不能打開」

單純「能不能打開」是不夠的。你至少要觀察：

上游錯誤率：502/504 是否上升。
平均與分位數延遲：特別是 95th、99th。
帶寬與連線數：避免突然爆流量把代理拖垮。

阿里雲帳號購買開通 把這些指標跟後端一起對照，你會更快找到瓶頸在網路、代理還是業務。

第十章：整體流程回顧（你可以直接照順序做）

確定目標：外網入口是香港實例，國內後端提供服務。
先通網路：確認香港到國內後端端口可達，安全組與防火牆放行。
部署 Nginx（HTTP）：先用 proxy_pass 讓請求跑通。
檢查細節：Host、X-Real-IP、X-Forwarded-For、X-Forwarded-Proto。
需要 WebSocket 就補上 Upgrade/Connection。
上 HTTPS：配置證書，並把 80 重定向到 443。
觀察日誌：確認 Nginx 與後端都沒有持續錯誤。
逐步完善：keepalive、超時調整、必要的限流與健康檢查。
上監控：用錯誤率與延遲指標驗證穩定性。

只要你按這個順序做，成功率會比「一邊配置一邊祈禱」高很多。

尾聲：把反向代理當作一扇門，而不是一次性的搬運

香港反向代理的價值不在於「把服務搬到哪裡」，而在於你能用一個受控的入口，集中完成安全、協議、路由與可觀測性。當入口穩定、後端可持續迭代，你才真正擁有可維護的架構。

如果你願意，我也可以根據你的實際情況把配置落到更精準的版本：例如你的後端是 HTTP 還是 HTTPS、服務是放在根目錄還是子路徑、是否需要 WebSocket、你希望是否做負載與健康檢查。你把域名、後端地址與目標服務端口告訴我就行。

上一篇Azure帳號快速購買 Azure代充值安全嗎下一篇騰訊雲帳號充值騰訊雲 CDN 快取規則配置錯誤導致後台登入失敗解決

阿里雲帳號購買開通 阿里雲香港反向代理國內伺服器教程