nginx反向代理配置教程：从零开始搭建高性能代理服务器
部署nginx作为代理服务器的答案很直接：用一条apt install nginx命令安装，改一个/etc/nginx/sites-available/default配置文件，然后systemctl reload nginx就能跑起来，整过程约10分钟，关键是理解proxy_pass参数的方向，它决定了流量转发到内网哪个端口。
nginx是目前市场占有率领先的Web服务器软件,据统计全球有相当比例的网站运行在nginx之上，它之所以如此受欢迎，除了静态文件处理能力强劲外，反向代理和负载均衡功能功不可没，今天我们从服务器安装配置角度，把这台”流量二传手”彻底讲透。
理解反向代理的应用场景
反向代理本质上是客户端与服务端之间的中间层,客户端只与nginx通信，nginx再把请求转发给内网的真实服务，这样做有三个直接好处：
- 安全隔离：内网服务IP彻底隐藏，外界只能看到nginx的IP，端口扫描和定向攻击难度大增
- 负载均衡：一台nginx可以管理多台业务服务器，通过权重或ip_hash策略分发请求，单点故障时自动摘除宕机节点
- 统一入口：SSL证书、访问控制、请求日志都可以在nginx层集中处理，后端语言（PHP、Python、Java）能专注业务逻辑，不必重复造轮子
哪些场景必须用它？比如你有两台应用服务器分别跑Java和Python，但只对外暴露一个域名和443端口，此时nginx就是那个”调度中枢”，根据请求路径把流量分别转发到8080和5000端口。
nginx反向代理核心配置的五个关键步骤
第一步：确认基础环境并安装nginx
在Ubuntu 22.04或Debian 12这类主流Linux发行版上，安装命令几乎一致：
sudo apt update sudo apt install nginx -y
安装完成后,先检查运行状态：
sudo systemctl status nginx
页面出现active (running)字样说明服务已正常拉起，此时访问服务器公网IP，应该能看到nginx默认欢迎页，如果看不到，多半是云服务商的安全组规则挡了80端口，去控制台放行即可。
第二步：编写站点配置文件
nginx的配置路径体系很清晰,主配置文件是/etc/nginx/nginx.conf，它通过include指令加载/etc/nginx/sites-enabled/目录下的所有站点配置，我们在sites-available里新建一个业务配置文件：
sudo vim /etc/nginx/sites-available/example.com
写入以下反向代理配置：
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
这段配置含义：接收来自
example.com的HTTP请求，全部转发给本机8080端口的上游服务。proxy_set_header三行是保持客户端真实IP的关键，否则后端程序看到的所有请求都来自127.0.0.1，日志分析和防盗链策略会全部失效。
第三步：启用站点并测试配置
创建软链接把配置从sites-available映射到sites-enabled：
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
接下来做语法检查,这是避免服务中断的保命动作：
sudo nginx -t
返回test is successful后优雅重载配置：
sudo systemctl reload nginx
此刻访问http://example.com，nginx已经把请求转发到8080端口的服务上了。
第四步：排查跳转失败和循环重定向
配置完成后最常见的问题是502 Bad Gateway，出现这个错误页面，先查nginx错误日志：
sudo tail -50 /var/log/nginx/error.log
如果日志报connect() failed (111: Connection refused)，说明上游服务没监听在预期端口，用以下命令确认监听状态：
ss -tlnp | grep 8080
另一类高频问题表现是页面无限重定向,浏览器提示”将您重定向的次数过多”，这种情况多出现在混合配置了HTTPS但证书链不完整时，可以用curl命令直接观察响应头：
curl -I http://example.com
返回301或302带Location: https://example.com属正常跳转，但跳转后再次跳回HTTP就是典型的循环，检查配置文件里是否写了矛盾的rewrite规则。
第五步：处理长连接和WebSocket协议
后端跑得是Node.js或Django Channels等WebSocket服务时，默认的HTTP代理配置无法胜任，需要在location块内补充协议升级头：
location /ws/ {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}
proxy_read_timeout设置为3600秒是为了避免长时间连接被nginx掐断，线上实际环境因心跳机制不同，这个值需要做适当调节，数值参考业务自身的保活间隔。
网站服务器响应慢如何排查nginx瓶颈
当用户反馈网站加载缓慢,nginx层面存在两个常见拖后腿项：缓存未开启和进程数过低。
启用proxy_cache数据缓存
静态资源（图片、CSS、JS）完全不必每次都穿透到后端，给nginx配置缓存池能显著降低响应耗时，配置片段如下：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
server {
location ~ .(jpg|jpeg|png|gif|css|js)$ {
proxy_cache my_cache;
proxy_cache_valid 200 60m;
proxy_pass http://127.0.0.1:8080;
}
}
这里的inactive=60m表示60分钟内未被访问的缓存条目会被清理。max_size=1g定义了缓存上限，超过后nginx按LRU算法自动淘汰。
调整worker进程模型
nginx默认配置通常是worker_processes auto，这没问题，但worker_connections值得关注，它决定单进程能同时维护的连接数，在高并发长连接场景下，把这个数值从默认的768提升到4096是常见优化手段，配置位置在/etc/nginx/nginx.conf的events块。
nginx配置后网站不生效？从三个层面自检
如果你跟教程操作后,访问域名却打不开或者跳转到默认页，检查顺序如下。
DNS解析是否指向正确
在本地终端执行：
dig +short example.com
返回的IP必须与你的服务器公网IP一致,如果解析到旧服务器IP或CDN节点，请求根本不会到达nginx，域名商控制台的解析记录TTL值调低，等待生效时间降低。
监听端口与实际访问协议是否匹配
配置文件监听80端口,而用户访问的是https://example.com，自然连接失败，多数情况下，先在监听80的server块内配置return 301 https://$host$request_uri;做跳转，再新建一个监听443的server块处理实际业务。
安全组和防火墙双重排查
云服务器有安全组和iptables两层屏障,逐条检查：
sudo iptables -L -n --line-numbers
允许80和443端口的入站流量后保存iptables规则,控制台安全组一样要放行这部分入站端口，现实情况中因安全组漏配导致nginx配置不生效的案例相当多。
额外加固：为nginx配置防火墙保护
安装完nginx直接对公网开放80端口,等于把入口完全暴露在扫描工具之下，用ufw工具做最小化放行：
sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable
这套规则限制了SSH、HTTP、HTTPS三个必需端口，其余一律拒绝，服务器被漏洞扫描工具探测的次数会明显减少。
为Nginx加上基础防攻击规则很有必要,在配置文件里临时限制单个IP的并发连接数：
limit_conn_zone $binary_remote_addr zone=addr:10m;
server {
location / {
limit_conn addr 5;
}
}
单IP同时保持5个连接,超出部分nginx直接返回503，DDoS攻击和CC攻击的破坏力在连接数层面被有效压制。
独立服务器性能优化与进程防护
当代理流量到了一定量级,调整Linux内核参数对nginx性能提升立竿见影，编辑/etc/sysctl.conf：
net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1
执行sudo sysctl -p让参数立刻生效。somaxconn和tcp_max_syn_backlog扩大后，突发流量导致内核丢弃连接请求的问题基本消失。
进程防护同样不可忽视,nginx的主进程由root运行，但worker进程必须降权运行，默认配置已通过user www-data;指令实现降权，需要确认你千万不要改动这个选项，若把worker进程也跑在root权限下，一旦被攻击者利用漏洞提权，整台服务器瞬间沦陷。
常用运维命令参考
| 命令 | 作用 |
|---|---|
sudo nginx -t |
检查配置语法正确性 |
sudo systemctl reload nginx |
平滑重载配置不掉线 |
sudo systemctl restart nginx |
硬重启（会短暂断连） |
sudo tail -100 /var/log/nginx/error.log |
查看最新错误日志 |
sudo ss -tlnp | grep nginx |
确认监听状态 |
从上面步骤看到,nginx反向代理的路程不算复杂，要按照业务诉求搭配处理，按这份指南走，不用验证复杂参数就能跑通基本转发链路，后续再接上SSL证书自动续期、Gzip压缩、访问日志切割，才是一台生产级代理服务器该有的样子。
关于nginx配置常见问题解答
问：nginx代理配置做了修改，但业务服务收不到请求，可能是什么原因？
首选确认请求是否真正进入nginx并到达location匹配块,在location内部临时添加access_log /var/log/nginx/custom_access.log;观察是否有请求日志，日志为空说明客户端请求没有到达该location，检查路径匹配规则和执行顺序，能用curl http://127.0.0.1/test直接测试后端的连通性，排除网络问题后集中在nginx的proxy_pass参数是否写对。
问：多个业务域名共用一台服务器时，nginx的server_name如何配置？
在/etc/nginx/sites-available/下为每个域名创建独立配置文件，每个文件里写独立的server_name和proxy_pass，最后都启用软链接到sites-enabled，nginx根据HTTP请求头中的Host字段自动匹配对应server块，与最前面的listen端口无关，注意不要有两个server块配置完全相同的server_name，否则先加载的那个会全部命中，后续规则覆盖不到。
问：nginx负载均衡的upstream参数怎么配置？
upstream配置放在http层而非location层,定义一个在后端服务器集群逻辑组。
upstream backend_servers {
ip_hash;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
}
server {
location / {
proxy_pass http://backend_servers;
}
}
ip_hash保证同一用户IP始终分配到同一后端节点，解决Session一致性问题。weight参数表示负载比例，weight为3的服务器接收的请求约是weight为1服务器的三倍，后端节点宕机时nginx连接失败会自动将其标记为不可用，并把流量切到健康节点，不影响整体服务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e5%a6%82%e4%bd%95%e4%b8%ba%e4%bb%a3%e7%90%86%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%ae%89%e8%a3%85%e9%85%8d%e7%bd%aenginx%ef%bc%8c%e9%9c%80%e8%a6%81%e6%b3%a8%e6%84%8f%e4%bb%80%e4%b9%88%ef%bc%9f/
