H5部署两台服务器时，访问方案的核心答案是：通过Nginx反向代理或负载均衡器，为两台服务器配置统一的对外入口（域名或VIP），将用户请求按规则分发到任意一台服务器。这种部署方式可以提升稳定性和并发处理能力，本文会从配置方法、技术选型到问题排查,一步步讲清楚。
h5部署两台服务器怎么访问：先理解流量走向
单台服务器部署H5，访问路径是用户→服务器IP/域名→站点文件，两台服务器的情况，路径会多出一个”调度者”角色。
假设你有两台服务器，IP分别是0.0.2和0.0.3，H5项目已经通过Git或CI/CD工具同步到两台机器的相同目录（比如/var/www/h5），此时需要考虑的不仅是”怎么访问”，更是”用户访问哪个IP才不会感觉卡顿或报错”。
直接暴露两台服务器的访问方式
较简单的做法是让用户直接访问两个IP，但这要求用户手动切换，体验较差，实际部署中,有几种常见方案：
- 在域名解析商处添加两条A记录，指向两台服务器IP，利用DNS轮询实现简单的负载均衡
- 通过前端路由或JS检测服务器可用性，自动切换请求地址
- 使用云服务商的负载均衡产品（如简米云SLB、酷番云CLB），在控制台配置后端服务器池
行业共识认为，中小项目初期用DNS轮询就能解决访问问题，但DNS解析存在缓存机制，一台服务器宕机后，部分用户仍会被分配到故障IP,导致网站打不开。
两台服务器负载均衡配置方法：Nginx实操
多数团队选择Nginx做反向代理，它比硬件负载均衡器便宜，配置也灵活,以下是具体操作。
第一步：准备一台调度服务器
调度服务器不一定要多高的配置，1核3GB内存就足够支撑日活十万以内的流量，Nginx官方文档指出,单Worker进程可以处理大量并发连接。
在这台机器上安装Nginx：
apt update && apt install nginx -y # Debian/Ubuntu # 或 yum install nginx -y # CentOS/RHEL
第二步：编辑Nginx配置实现反向代理
修改/etc/nginx/conf.d/h5.conf,写入以下内容：
upstream h5_cluster {
server 10.0.0.2:8080 weight=1 max_fails=2 fail_timeout=30s;
server 10.0.0.3:8080 wei
ght=1 max_fails=2 fail_timeout=30s;
}
server {
listen 80;
server_name yourdomain.com;
location / {
proxy_pass http://h5_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
几个配置项说明：
weight=1：两台服务器权重相同，表示平均分配流量max_fails=2和fail_timeout=30s：30秒内失败两次就暂时摘除该服务器proxy_set_header用于传递用户真实IP，H5里的日志统计和风控逻辑会用到
检查配置并重载：
nginx -t && nginx -s reload
第三步：后端子路径的匹配策略
H5项目往往不只一个页面，可能包含接口和静态资源,精细一点的配置会按路径分流：
location /api/ {
proxy_pass http://h5_cluster/; # 去掉前缀，直接转发到后端
}
location /static/ {
alias /var/www/h5/static/; # 静态资源直接从调度机读
}
location / {
proxy_pass http://h5_cluster;
}
这样做的目的是减少后端服务器的压力，静态图片、CSS、JS文件不走反向代理转发，而是由调度服务器直接返回，需要留意的是，如果H5包含上传功能，涉及大文件传输，Nginx的client_max_body_size参数默认只有1MB,要按需调大。
单机部署和多机部署的区别：到底加一台服务器值不值
做了双机部署后，网站性能表现确实会有变化,下面用表格做一个直观对比：
| 对比维度 | 单台服务器 | 两台服务器（Nginx负载均衡） |
|---|---|---|
| 流量承载能力 | 受单机带宽和CPU限制，高峰期容易卡顿 | 两台分担流量，单台压力降到较低水平 |
| 故障应对 | 服务器宕机，H5直接无法访问 | 一台故障，Nginx把流量切到另一台，用户几乎无感知 |
| 发布更新 | 更新时需要停服或会造成短暂白屏 | 可以逐台发布，先拉出一台，更新完成后再切换 |
| 运维复杂度 | 低，只需关注一个节点 | 需要管理配置同步、会话状态、日志聚合 |
| 成本 | 单台机器费用 | 双倍机器费用加上少量带宽成本 |
为什么双机部署后反而感觉变慢了
有不少团队反馈，两台服务器配好之后，首屏加载时间不降反升，排查后发现,多数情况是后端服务出现会话不一致问题。
举个典型场景：用户登录后，首次请求发到服务器A，A生成了Session并保存在本地内存，下一次请求被分发到服务器B，B没有这份Session，就会要求用户重新登录，H5频繁跳转登录页,体感上确实非常慢。
解决办法有两种：
- 在Nginx中配置
ip_hash，让同一个用户IP的请求始终落在同一台服务器 - 把Session从本地内存迁移到Redis或Memcached，两台服务器共享同一份会话数据
行业共识认为，ip_hash配置简单，但无法在服务器不均衡时动态调整，如果用户量级较大,更推荐使用Redis集中存储会话。
需要留意的是，Nginx默认的轮询算法会把请求平均分发，但服务器之间存在性能差异时，较慢的机器会拖累整体响应时间，可以手动设置weight参数，比如服务器A是8核，服务器B是4核，权重比设置为2:1,有效利用两台机器的算力。
域名解析和HTTPS证书的部署细节
配置好Nginx只是第一步，外部访问还依赖域名解析和HTTPS证书,这个环节有几个容易踩坑的地方。
DNS解析的TTL设置
如果你用的是DNS轮询（不加负载均衡器），在域名解析平台添加两条A记录后，务必将TTL值调低到300秒左右，这样在服务器故障需要摘除IP时，生效时间会比较短，据工信部数据，国内主流DNS服务商已全面支持秒级TTL刷新,不必担心设置不生效。
证书放在哪里
Nginx配置HTTPS时，SSL证书直接放在调度服务器上就好，让Nginx完成TLS终止，后端两台服务器内部走HTTP明文通信，这样证书不需要同步到两台机器,省去部分维护工作量。
证书续期时要记得检查调度服务器上的/etc/letsencrypt/live/目录是否还有剩余空间，证书文件小,但续期脚本要求目录可写。
静态资源跨域请求问题
H5的前后端完全分离时，通常前端页面的域名是www.abc.com，接口域名是api.abc.com，如果负载均衡层没有处理跨域头,浏览器控制台会报CORS错误。
在Nginx配置中增加：
add_header Access-Control-Allow-Origin ""; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "Authorization, Content-Type";
两台服务器不在同一机房能配置吗
异地双活的部署方式多用于容灾场景，比如一台服务器在杭州，另一台在青岛,DNS解析或全局负载均衡把用户就近接入。
这种场景下，配置思路仍然是Nginx反代，但需要注意数据同步时延,MySQL或Redis在跨地域场景下的主从延迟会显著升高。
- 读多写少的H5：可以在两台机器各自部署一套只读从库，主库单独在机房A
- 实时性要求较低的页面：采用文件同步工具（如rsync）定时把静态资源推到两台服务器
- 高实时性的数据：不建议直接实现异地双写，成本过高，可以考虑分区域部署
比较稳妥的做法是，调度服务器用云厂商的负载均衡产品（如简米云SLB），它支持按地域转发，配置了健康检查后，自动屏蔽故障节点，具体操作路径：简米云控制台→负载均衡→创建实例→添加监听→配置后端服务器组。
常见问题解答
h5部署两台服务器后，页面打开提示502 Bad Gateway怎么排查
502表示Nginx收到请求但无法从后端服务器取得响应,逐项排查：
- 在调度服务器上执行
curl -I http://10.0.0.2:8080，确认后端进程是否正常 - 检查两台服务器防火墙是否放行8080端口（
firewalld或ufw配置） - 查看Nginx错误日志
/var/log/nginx/error.log，若出现connect() failed (111: Connection refused)，说明后端服务没启动或监听端口不匹配
发布新版本时怎么做到不中断访问
思路是逐个下线更新：
- 在Nginx配置中把服务器A的
down参数临时加上（server 10.0.0.2:8080 down;），流量全部进入B - 更新服务器A的代码，执行编译或打包
- 完成后，恢复A的
down参数，再把B摘掉 - 更新B，最后恢复全部节点，重新reload Nginx
H5多数情况下是打包静态文件，操作窗口很小，如果两台机器上的代码是通过Git仓库拉取的,流程可以压缩到分钟级。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/590270.html
