一、反向代理基礎
實驗目的：通過 Nginx 反向代理，將客戶端請求按類型（靜態頁面 / 動態 PHP 頁面）轉發到不同的后端服務器（RS1 處理靜態資源，RS2 處理動態請求），實現 “客戶端只與代理服務器交互，無需知道后端實際服務器” 的架構，提升服務安全性、可擴展性和資源處理效率。
反向代理的核心價值
反向代理是指 代理服務器接收客戶端所有請求，再根據規則轉發到后端不同服務器，客戶端僅感知代理服務器的存在，對后端服務器的 IP、架構等信息完全透明。其核心作用：
-
隱藏后端架構：保護后端服務器不直接暴露在公網，降低被攻擊風險；
-
請求分流：將靜態資源（HTML、圖片等）和動態請求（PHP、JSP 等）分配到不同服務器處理，發揮各自優勢（如靜態服務器可優化緩存，動態服務器專注計算）；
-
擴展性強：后續可輕松添加更多后端服務器（如增加 RS3 處理圖片），只需修改代理配置，無需改動客戶端。
實驗架構與準備
-
代理服務器：Nginx 所在主機（192.168.67.100），接收客戶端請求并轉發；
-
RS1（后端靜態服務器）：192.168.67.10，處理靜態頁面（HTML 等）；
-
RS2（后端動態服務器）：192.168.67.20，處理動態請求（PHP 等）；
-
本地解析：客戶端（如 Windows）需在
hosts文件中添加www.haha.org到代理服務器 IP（192.168.67.100）的映射，確保通過域名訪問時指向代理服務器。
RS1 配置靜態頁面
echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html
systemctl restart nginxRS2 配置 php 動態頁面
yum install php -y
mkdir /usr/share/nginx/html/php/
vim /usr/share/nginx/html/php/index.php
###########
<?phpphpinfo();
?>
########### ?
systemctl restart nginxnginx 代理服務器配置代理
vim /usr/local/nginx/conf.d/haha.conf
##########
server {listen ?80;server_name www.haha.org;
?location / { # 規則 1：普通路徑請求（如 /）轉發到 RS1（靜態服務器）proxy_pass http://192.168.67.10; # 轉發請求到 RS1 的 IP}
?location ~ \.(php|jsp|js)$ { # 規則 2：.php/.jsp/.js 后綴的動態請求轉發到 RS2（動態服務器）proxy_pass http://192.168.67.20; # 轉發請求到 RS2 的 IP}
}
##########
systemctl restart nginx測試：
測試靜態請求轉發：
客戶端訪問 www.haha.org，代理服務器匹配 location /，轉發到 RS1，頁面顯示 “rs1 - 192.168.67.10”，驗證靜態請求正確轉發。
測試動態請求轉發：
客戶端訪問 www.haha.org/php/index.php，代理服務器匹配 ~ .(php)$，轉發到 RS2，頁面顯示 PHP 環境信息（phpinfo() 輸出），驗證動態請求正確轉發。
為什么這樣配置？核心邏輯
-
資源分流，提升效率：靜態資源（HTML）無需計算，由 RS1 專注處理；動態資源（PHP）需要解析執行，由 RS2 處理，避免單服務器同時處理兩類請求導致的性能瓶頸。
-
隱藏后端，增強安全：客戶端僅知道代理服務器（192.168.67.100），無法直接訪問 RS1/RS2，減少后端服務器被直接攻擊的風險。
-
靈活擴展，便于維護：若后續靜態資源增多，可添加 RS3 作為新靜態服務器，只需修改 location / 的 proxy_pass 為負載均衡組（如 http://static_servers）；動態服務同理，擴展性極強。
適用場景
反向代理廣泛用于：
-
大型網站的請求分流（靜態資源 CDN 轉發、動態請求到應用服務器）；
-
負載均衡（多臺后端服務器分擔請求壓力）；
-
安全隔離（代理服務器作為入口，過濾惡意請求后再轉發到后端）。
二、反向代理 - 負載均衡
實驗目的：通過 Nginx 負載均衡功能，將客戶端請求按規則分配到多個后端服務器（RS），實現 “請求分流” 以分擔單服務器壓力；同時配置健康檢查和備用服務器（sorry server），確保后端服務器故障時自動切換，提升服務可用性（避免單點故障導致服務中斷）。
負載均衡的核心價值
在高并發場景下，單臺后端服務器（RS）可能因請求量過大導致響應緩慢或宕機。負載均衡通過 “多服務器協同工作” 解決這一問題：
-
請求分流：將客戶端請求均勻分配到多臺后端服務器，避免單服務器過載；
-
高可用：通過健康檢查自動剔除故障服務器，請求僅轉發到正常服務器；
-
容災備份：當所有主服務器故障時，自動切換到備用服務器（sorry server），避免返回錯誤頁面，提升用戶體驗。
實驗架構與準備
-
代理服務器：Nginx 所在主機（假設 IP 為代理服務器 IP），負責負載均衡調度；
-
后端主服務器（RS）：
-
RS1：192.168.67.10，提供靜態頁面服務；
-
RS2：192.168.67.20，提供靜態頁面服務；
-
-
備用服務器（sorry server）：代理服務器本地的 Apache 服務（端口 8888），當所有主服務器故障時提供兜底響應。
RS 主機配置默認訪問頁面。
echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html
systemctl restart nginx修改 nginx 子配置文件
vim /usr/local/nginx/conf.d/haha.conf
##########
upstream webserver {server 192.168.67.10:80 weight=1 fail_timeout=15s max_fails=3; # RS1：權重 1，失敗 3 次后標記為不可用，15 秒后重試檢測server 192.168.67.20:80 weight=1 fail_timeout=15s max_fails=3;server 192.168.67.100:8888 backup; # 備用服務器：僅當所有主服務器故障時啟用，端口 8888
}
server {listen ?80;server_name www.haha.org;
?location / {proxy_pass http://webserver; # 所有請求轉發到定義的 webserver 服務器組}
}
##########
?
systemctl restart nginx配置 nginx 代理服務器的 sorry server 功能。運用 apache 服務器，修改端口作為 sorry server。
yum install httpd
vim /etc/httpd/conf/httpd.conf
########
Listen 8888 # 修改端口
########
?
echo sorry > /var/www/html/index.html
?
systemctl start httpd
systemctl enable --now httpd
netstat -antlupe | grep http
測試負載均衡效果
-
正常輪詢：客戶端多次訪問 www.haha.org，頁面會交替顯示 “rs1 - 192.168.67.10” 和 “rs2 - 192.168.67.20”，驗證請求被均勻分配到兩臺主服務器。
-
故障自動剔除：手動停止 RS1 的 Nginx 服務（systemctl stop nginx），再次訪問時，請求僅轉發到 RS2（頁面穩定顯示 RS2 內容），驗證故障服務器被自動剔除。
-
備用服務器激活：同時停止 RS1 和 RS2 的服務，訪問時頁面顯示 “sorry”，驗證備用服務器生效，提供兜底響應。
為什么這樣配置？核心設計邏輯
-
請求分流，降負載：通過 weight 配置實現請求均勻分配（或按權重分配），避免單服務器因高并發過載，提升整體響應速度。
-
健康檢查，保可用：max_fails 和 fail_timeout 確保故障服務器被及時剔除，請求不浪費在無效節點上，減少用戶等待。
-
多級備份，防極端：backup 備用服務器解決 “全故障” 場景，將 “服務中斷” 轉化為 “降級可用”，最大限度減少用戶流失。
-
靈活擴展，易維護：新增后端服務器時，只需在 upstream 中添加 server 配置，無需修改客戶端或代理入口，擴展性極強。
適用場景
負載均衡廣泛用于：
-
高并發網站（如電商平臺、資訊門戶），通過多服務器分擔流量；
-
核心業務系統，通過冗余服務器避免單點故障；
-
混合架構服務（如部分服務器處理靜態資源，部分處理動態請求）。
三、四層代理 - 負載均衡
實驗目的：通過 Nginx 的 stream 模塊實現四層（傳輸層）負載均衡，針對非 HTTP 協議的服務（如 DNS、MySQL）進行請求分流，將客戶端連接按規則分配到多臺后端服務器，同時通過健康檢查確保服務可用性，適用于數據庫、DNS 等底層服務的負載均衡場景。
核心原理：四層代理與 stream 模塊
四層代理工作在 TCP/UDP 傳輸層，僅根據 “源端口、目標端口、IP 地址” 轉發數據，不解析應用層協議（如 HTTP 頭部、DNS 報文內容），因此適用于所有基于 TCP/UDP 的服務（如 DNS、MySQL、SSH 等）。
Nginx 通過 stream 模塊實現四層代理，功能類似硬件負載均衡器的 “四層轉發”，核心優勢：
-
通用性：支持所有 TCP/UDP 服務，不受應用層協議限制；
-
高性能：轉發邏輯簡單（僅處理傳輸層數據），性能接近硬件級；
-
高可用：結合健康檢查（max_fails、fail_timeout）自動剔除故障節點。
3.1.DNS 負載
實驗背景
DNS 服務是網絡基礎服務，負責將域名解析為 IP 地址，通常使用 UDP 53 端口（普通查詢）和 TCP 53 端口（區域傳輸等）。通過四層代理實現 DNS 負載均衡，可分擔單臺 DNS 服務器的查詢壓力，同時避免單點故障。
RS 安裝 bind 軟件，配置 DNS 服務。
yum install bind -y # 安裝 BIND（DNS 服務軟件）
?
vim /etc/named.conf
############
options {
...listen-on port 53 { any; }; # 確保 DNS 服務可被遠程客戶端訪問（不僅限于本地）allow-query ? ? { any; }; # 允許所有 IP 地址查詢該 DNS 服務器，適合作為公共解析服務dnssec-validation no; # 關閉 DNS 記錄的數字簽名驗證（測試場景簡化，生產環境需開啟）
...
}
############禁用 DNSSEC 驗證后，系統在處理 DNS 解析結果時，不會對記錄的數字簽名進行驗證，直接接受并使用解析結果（無論其是否被篡改、是否來自真實域名所有者）。
dnssec-validation no; 是為了 “可用性” 犧牲 “安全性” 的配置，讓系統 “不較真” DNS 記錄的真實性，直接使用解析結果。
vim /etc/named.rfc1912.zones
###########
zone "haha.org" IN { # 添加以下內容type master; # 作為主 DNS 服務器 ?file "haha.org.zone"; # 解析記錄文件路徑 allow-update { none; }; # 禁止動態更新（安全加固）
};
###########
?
cd /var/named/
cp -p named.localhost haha.org.zone
?
vim haha.org.zone
###########
$TTL 1D
@ ? ? ? IN SOA dns.haha.org. root.haha.org. (0 ? ? ? ; serial1D ? ? ; refresh1H ? ? ; retry1W ? ? ; expire3H ) ? ; minimumNS ? ? dns.haha.org.
dns ? ? A ? ? ? 192.168.67.10 # 為了查看效果 20 主機寫本機 IP
###########
?
systemctl start named
systemctl enable --now namednginx 代理服務器配置。
# 主配置文件添加
vim /usr/local/nginx/conf/nginx.conf
##########
...
include "/usr/local/nginx/tcp.d/*.conf"; # 引入四層代理配置文件（不可放在 http 或 server 塊內）
...
##########mkdir /usr/local/nginx/tcp.d/
vim /usr/local/nginx/tcp.d/xixi.conf
#########
stream {upstream dns {server 192.168.67.10:53 max_fails=3 fail_timeout=5; # RS1 的 DNS 服務（53 端口），3 次失敗后標記不可用，5 秒后重試server 192.168.67.20:53 max_fails=3 fail_timeout=5;}
?server {listen 53 udp; # 監聽代理服務器的 UDP 53 端口proxy_pass dns; # 轉發到 dns 服務器組 }server {listen 53; # 默認 TCP 協議，監聽 53 端口proxy_pass dns;}
}
#########
?
systemctl restart nginx
netstat -antlupe | grep nginx
預期結果：多次查詢會交替返回 RS1（192.168.67.10）和 RS2（192.168.67.20）的 IP，驗證請求被輪詢分配到兩臺后端 DNS 服務器。
dig @192.168.67.100 dns.haha.org
3.2.Mysql 負載
實驗背景
MySQL（或 MariaDB）是常用的關系型數據庫，使用 TCP 3306 端口通信。通過四層代理實現 MySQL 負載均衡，可將客戶端連接分配到多臺數據庫服務器，分擔讀寫壓力（需配合數據庫主從復制等策略確保數據一致性）。
后端 RS 下載 mariadb，配置 server_id，授權用戶。
# 安裝 mariadb
yum install mariadb-server ?-y
?
vim /etc/my.cnf.d/mariadb-server.cnf
[mysqld]
...
server-id=10 # RS1 設為 10，RS2 設為 20（唯一標識，便于區分實例）
...
?
systemctl enable --now mariadb
?
mysql -e "grant all on *.* to zyz@'%' identified by 'zyz'" # 進入MySQL# 添加可遠程登錄的用戶
?
# 測試：遠程登錄 mysql
mysql -uzyz -pzyz -h192.168.13.10
mysql -uzyz -pzyz -h192.168.13.20nginx 主機配置
vim /usr/local/nginx/tcp.d/xixi.conf
########
stream {upstream mariadb {server 192.168.67.10:3306 max_fails=3 fail_timeout=4; # RS1 的 MySQL 服務（3306 端口），3 次失敗后標記不可用，4 秒后重試server 192.168.67.20:3306 max_fails=3 fail_timeout=4;}server {listen 3306; # 監聽代理服務器的 3306 端口 ?proxy_pass mariadb; # 轉發到 mariadb 服務器組}
}
########
netstat -antlupe | grep nginx
測試：
預期結果：多次連接會交替返回 server_id=10（RS1）和 server_id=20（RS2），驗證請求被輪詢分配到兩臺后端數據庫服務器。
四層代理的核心價值與配置解析
-
關鍵參數作用
-
stream 塊：Nginx 處理四層代理的核心模塊，與 http 塊平級，專門用于配置 TCP/UDP 服務的轉發規則。
-
upstream 服務器組：定義后端服務節點，支持 max_fails（最大失敗次數）和 fail_timeout（失敗檢測周期）實現健康檢查 —— 超過失敗次數后自動剔除故障節點，超時后重新檢測。
-
listen 指令：指定代理服務器監聽的端口和協議（udp 需顯式聲明，默認 TCP），如 listen 53 udp 對應 DNS 的 UDP 服務，listen 3306 對應 MySQL 的 TCP 服務。
-
proxy_pass：將監聽端口的請求轉發到定義的 upstream 服務器組，實現負載均衡。
-
-
適用場景與優勢
-
通用性：支持所有 TCP/UDP 服務（DNS、MySQL、SSH、Redis 等），解決七層代理（僅 HTTP）的局限性；
-
高性能：轉發邏輯簡單（不解析應用層數據），資源消耗低，可支撐高并發場景；
-
高可用：通過健康檢查自動剔除故障節點，結合備用服務器可實現服務無感知切換；
-
易擴展：新增后端服務器只需在 upstream 中添加節點，無需修改客戶端配置。
-
通過四層代理配置，Nginx 突破了僅處理 HTTP 服務的限制，成為通用的傳輸層負載均衡器，為底層服務（如數據庫、DNS）提供分流與高可用保障，是構建企業級分布式架構的重要組件。
![【[特殊字符][特殊字符] 協變與逆變：用“動物收容所”講清楚 PHP 類型的“靈活繼承”】](http://pic.xiahunao.cn/【[特殊字符][特殊字符] 協變與逆變：用“動物收容所”講清楚 PHP 類型的“靈活繼承”】)
)
)
