目录
[1.1 Nginx概述](#1.1 Nginx概述)
[1.1.1 企业青睐 Nginx 的核心原因](#1.1.1 企业青睐 Nginx 的核心原因)
[1.1.2 Nginx的作用](#1.1.2 Nginx的作用)
[1.3 反向代理和负载均衡](#1.3 反向代理和负载均衡)
[1.4 注](#1.4 注)
[1.4.1 代理百度并使用 18090 端口](#1.4.1 代理百度并使用 18090 端口)
1.1 Nginx概述
1.1.1 企业青睐 Nginx 的核心原因
Nginx 由俄罗斯开发者打造，具有超高稳定性（资源占用极低，几乎不会宕机）、性能优异（并发处理能力强）的特点，是企业级场景中流量入口和服务治理的核心工具。
1.1.2 Nginx的作用
- 反向代理：隐藏后台真实 IP，保障服务安全
-
原理：用户只感知 Nginx 的 IP（如 192.168.0.1），后台真实服务器的 IP（如 192.168.0.2）对用户完全隐藏。
-
配置示例：
location /hello {
proxy_pass http://192.168.0.2/aaa;
}
用户访问 192.168.0.1/hello 时，Nginx 会自动转发到后台 192.168.0.2/aaa 接口，用户永远不知道真实接口和服务器 IP，实现 "请求代理与隐藏"。
- 负载均衡：分摊流量，提升系统稳定性
Nginx 提供多种负载均衡策略，适配不同业务场景：
-
轮询（默认策略）：请求依次分发到不同服务器。例如 3 台服务器，第 1 个请求给 Server1，第 2 个给 Server2，第 3 个给 Server3，循环往复。
-
按权重：根据服务器性能分配流量比例，支持服务器资源不均和灰度发布场景。
-
配置示例：
假设我们有三个订单服务的实例部署在不同的服务器上： -
- 订单服务 A 运行在服务器 192.168.1.101 的 8080 端口。
- 订单服务 B 运行在服务器 192.168.1.102 的 8080 端口。
-
订单服务 C 运行在服务器 192.168.1.103 的 8080 端口。
它们提供的接口路径都是 /order/create。1. 定义一个 upstream 块，起一个名字，比如叫 order_service_cluster
这个块就代表了我们的"服务集群"
upstream order_service_cluster {
# 服务器 A，权重是 1
server 192.168.1.101:8080 weight=1;
# 服务器 B，权重是 2
server 192.168.1.102:8080 weight=2;
# 服务器 C，权重是 1
server 192.168.1.103:8080 weight=1;
}2. 在 server 块中，使用 location 匹配外部请求
server {
listen 80;
server_name www.my-shop.com;# 当用户访问 /api/order/create 时 location /api/order/create { # 3. 使用 proxy_pass 指向我们上面定义的集群名字 # Nginx 会自动根据 upstream 中定义的策略（轮询、权重等）选择一个服务器 proxy_pass http://order_service_cluster/order/create; }}
这个配置是如何工作的？
*
- upstream order_service_cluster：这是核心。我们在这里告诉 Nginx，"订单服务集群" 由三个节点组成，并且它们的权重分别是 1, 2, 1。
- proxy_pass http://order_service_cluster/order/create;：当一个用户请求 www.my-shop.com/api/order/create 时，Nginx 会接收到这个请求。proxy_pass 指令会告诉它："把这个请求转发给 order_service_cluster 这个集群，并将请求路径改为 /order/create"。
- 负载均衡发生：Nginx 内部会根据 upstream 块里的配置（权重）来决定具体转发到哪台服务器。
-
-
- 权重为 2 的服务器 B 会被分配到大约一半的请求。
-
- 权重为 1 的服务器 A 和 C 会各自被分配到大约四分之一的请求。
- 自动剔除不可用应用与请求过滤
- 自动剔除不可用应用：Nginx 可监控后台服务状态，若服务不可用则自动将其从负载均衡池中剔除，保障流量只分发到健康服务。
- 请求过滤（结合 OpenResty/nginx+Lua 脚本）：可通过自定义脚本拦截非法请求，例如 "某个接口若不传指定字段，直接拒绝连接"。
1.3 反向代理和负载均衡
-
编写nginx.conf文件
nginx.conf 是 Nginx 的核心配置文件，作用是告诉 Nginx 怎么工作------ 比如哪些域名要代理到哪个后台服务、如何分摊流量（负载均衡）、哪些请求要拦截等，是实现反向代理、负载均衡等功能的 "指挥手册"。
nginx.conf
设置运行nginx的用户和用户组
user nginx;
worker_processes auto;定义运行的进程数，可以是自动检测的，也可以手动设定
#worker_processes 1;
定义nginx运行的pid文件存放路径
pid /var/run/nginx.pid;
包含Nginx服务器默认设置
events {
worker_connections 1024;
}HTTP服务器配置
http {
# 基本设置
include /etc/nginx/mime.types;
default_type application/octet-stream;# 日志配置 access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; upstream order { server 47.94.43.58:8080 weight=90; server 43.143.218.119:8080 weight=10; } # 设置HTTP服务器 server { # 监听80端口 listen 80; # 服务器名称，可以是域名或IP地址 server_name localhost; location /learn/ { proxy_pass http://order/login; } # 错误页面处理 error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }}
解释：
- 全局配置段（1-11行）
-
user nginx;：指定 Nginx 以 nginx 用户和用户组运行，保障权限安全。
-
worker_processes auto;：自动检测服务器 CPU 核数，启动对应数量的工作进程，提升并发处理能力。
-
pid /var/run/nginx.pid;：定义 Nginx 进程 ID 文件的位置，用于管理进程（如重启、停止）。
2.events 段（事件模块配置）（14-16行） -
配置 Nginx 处理网络连接的能力，worker_connections 1024; 表示每个工作进程最多同时处理 1024 个连接。
3.http 段（HTTP 服务全局配置）（18行到最后） -
include /etc/nginx/mime.types;：引入文件类型映射规则，让 Nginx 能正确识别 .html、.css 等文件的类型。
-
access_log 和 error_log：分别定义用户访问日志和错误日志的存储路径，用于排查问题。
-
upstream order { ... }：这是负载均衡的核心！定义了一个叫 order 的服务集群，包含两台后台服务器，并通过 weight 配置了流量分配比例（9:1）。
-
server { ... }：定义一个具体的 HTTP 服务实例：
-
listen 80;：监听 80 端口，用户访问 http://localhost （虚拟机或者是云服务器ip，具体看在那个地方访问的）时会命中这个服务。
-
location /learn/ { ... }：这是反向代理的核心！当用户访问 http://localhost/learn/ 时，Nginx 会把请求转发到 upstream 集群 order 的 /login 路径，用户完全感知不到后台真实的服务器 IP 和路径。
-
error_page：配置报错时的兜底页面，提升用户体验。
效果： -
用户访问 http://localhost/learn/ → Nginx 接收请求。
-
Nginx 通过 location /learn/ 匹配到规则，触发反向代理。
-
反向代理将请求转发到 upstream 定义的 order 集群，Nginx 会按 weight 配置的 9:1 比例，将请求分发到两台后台服务器上，实现负载均衡。
nginx模板：1. 全局配置（必写，整个Nginx的基础设置）
user nginx;
worker_processes auto;
pid /var/run/nginx.pid;2. events段（必写，网络连接相关配置）
events {
worker_connections 1024; # 必写，默认1024即可
}3. http段（必写，所有HTTP服务的顶层配置）
http {
# http段必写基础配置（固定模板，直接抄）
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;# 【可选-负载均衡】按需添加（要做负载均衡才写） upstream 集群名 { # 集群名自定义（如order、user） server 服务器IP:端口 weight=权重; # 后台服务地址，可多个 server 服务器IP:端口 weight=权重; } # 4. server段（必写，单个HTTP服务实例，可多个） server { listen 80; # 必写，监听端口（默认80，可改如8080） server_name localhost; # 必写，服务器名（本地用localhost，线上填域名） # 【核心-反向代理】按需添加（要做反向代理才写，可多个location） location /访问路径/ { # 访问路径自定义（如/learn/、/api/） proxy_pass http://目标地址; # 目标地址：要么是upstream集群名，要么是单个服务IP } # 错误页面（必写，兜底配置，直接抄） error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }}
自定义部分的内容：
- 负载均衡相关（要做负载才写）
- upstream 集群名 { }：集群名自己起（如 order、goods），随便命名但要统一
- server 服务器IP:端口 weight=权重;：替换IP:端口为实际后台服务地址，weight值自定义（如 90、10，数字越大流量越多）
- 反向代理相关（核心自定义，必改）
- location /访问路径/：/访问路径/是用户访问的路径（如 /learn/、/api/、/login/）
- proxy_pass http://目标地址;：目标地址二选一：
- 做负载均衡：填upstream定义的集群名（如 http://order/login）
- 不做负载：填单个后台服务地址（如http://47.94.43.58:8080/login）
注：
对于nginx.conf: - 数量与组织
- 单文件：所有配置写在一个主文件里（小型项目用）。
- 多文件（推荐）：按项目拆分（如project1.conf），主文件用include引入子配置，隔离性好、易维护。
- 位置要求
- 默认：/etc/nginx/nginx.conf（Linux）。
- 自定义：可通过nginx -c 路径指定，但建议用默认目录（如主配置在/etc/nginx/，子配置在conf.d/）。
-
修改docker-compose.yml文件
原来的docker-compose.yml没有挂载nginx.conf，现在需要加上。
volumes: - ./nginx.conf:/etc/nginx/nginx.conf
添加数据卷挂载是为了让 Nginx 能够读取到我们自定义的反向代理配置文件，同时保证配置的持久化和可维护性 ------ 这是 Docker 容器化部署 Nginx 时实现反向代理的必要步骤。
具体解释：
从 Nginx 的配置逻辑和 Docker 容器的特性来分析：
- Nginx 的配置依赖外部文件
Nginx 的核心功能（反向代理、负载均衡等）都需要通过配置文件 nginx.conf 来定义。默认情况下，这个配置文件存放在 Nginx 容器内部的 /etc/nginx/nginx.conf 路径。 - Docker 容器的 "隔离性" 限制
Docker 容器是沙箱化的，容器内部的文件（包括 nginx.conf）默认是 "临时" 的 ------ 如果直接在容器内部修改配置，一旦容器重启或重建，修改会丢失。
同时，我们需要把自定义的反向代理规则写入 nginx.conf，但直接进入容器内部编辑文件非常不便。 - 数据卷挂载的作用
通过 volumes 配置（图二中的 - ./nginx.conf:/etc/nginx/nginx.conf），我们可以将宿主机上的 nginx.conf 文件"挂载" 到容器内部的对应路径：
- 宿主机的 ./nginx.conf：是我们在本地编写的、包含反向代理规则的配置文件。
- 容器内的 /etc/nginx/nginx.conf：是 Nginx 实际读取配置的路径。
这样做的好处是： - 配置持久化：宿主机的 nginx.conf 不会因为容器重启而丢失，修改后只需重启容器即可生效。
- 编辑方便：直接在宿主机上修改 nginx.conf（比如添加反向代理规则），无需进入容器内部操作。
- 启动docker-compose
此时浏览器访问 http://192.168.117.133/learn/ 就发发现页面会以设置的权重比，跳到不同的页面，但是9:1不是绝对的9:1，是在访问次数无线大时，比例是9:1。
1.4 注
1.4.1 代理百度并使用 18090 端口
现在想要实现代理百度并使用 18090 端口。
需结合Docker Compose 的端口映射和Nginx 配置的 server 监听来理解。
- 核心逻辑：端口的 "两层映射"
- Docker Compose 的ports：是 "宿主机端口 → 容器内端口" 的映射。比如"18090:80"表示：外部访问宿主机的 18090 端口时，流量会被转发到容器内的 80 端口。
- Nginx 的listen：是容器内 Nginx 监听的端口。只有当 Nginx 监听的端口与 "容器内被映射的端口" 一致时，流量才能被 Nginx 捕获并处理。
- 可行的配置方法分析
一共有三种方法，实际场景中，方法 2（新增 server + 新增端口映射） 更推荐，因为它能同时保留原有服务和新增代理百度的功能；方法 3 适合完全替换原有服务的场景。以下逐一说明：
-
方法 1："把原来的 80 端口全部修改成 18090，然后地址改成百度"
修改 Nginx 的listen 18090，并同时修改 Docker Compose 的ports为"18090:18090"和路径，但这种方式会破坏原有 80 端口的服务，通常不建议 "全部替换"，而是新增服务逻辑。 -
方法 2："在 nginx.conf 重新建一个 server，然后使用 18090，在 docker-compose 里暴露 18090"
Nginx 侧：新增一个server块，监听 18090 端口，并配置代理百度的逻辑：server {
listen 18090; # 容器内Nginx监听18090
server_name localhost;location /web/ { proxy_pass https://www.baidu.com/; # 代理到百度首页 proxy_ssl_server_name on; # 解决HTTPS代理的SSL握手问题 proxy_set_header Host www.baidu.com; # 传递百度的Host头（优化兼容性） }}
Docker Compose 侧：在ports中新增 18090 的映射（确保 "宿主机 18090 → 容器内 18090"）：
ports:
- "80:80" # 原有80端口的映射保留
- "18090:18090" # 新增18090端口的映射效果：原有 80 端口的服务不受影响，同时外部访问宿主机 18090 端口时，会被代理到百度。
-
方法 3："把主机的 18090 映射到容器的 80 端口，然后修改地址"
合理性：可行，适合只想修改端口映射、不新增 Nginx server的场景。
Docker Compose 侧：修改ports为"18090:80"（宿主机 18090 → 容器内 80）。
Nginx 侧：保持原有listen 80不变，但修改proxy_pass为百度的地址：location /learn/ {
proxy_pass https://www.baidu.com/login; # 注意百度的路径是否匹配，若只需代理百度首页，可简化location
}
效果：原有 80 端口的服务被替换，外部访问宿主机 18090 端口时，流量通过容器内 80 端口被 Nginx 捕获，进而代理到百度。