SLB配置并不复杂，核心在于搞清楚监听、后端服务器和健康检查这三者的关系，按顺序操作即可在十几分钟内完成上线。
很多朋友第一次接触负载均衡,看到控制台里密密麻麻的选项容易犯怵，其实把SLB配置拆解开，它做的事情就三件：听流量、转流量、查健康，下面我们直接进入实操层面，把每一步讲透。
SLB配置前的准备工作
配置SLB之前,你得先想清楚几个问题，否则后面容易返工。
确认业务场景和网络架构
你要先明确这几点：
- 地域选择：SLB和ECS必须处于同一地域，否则没法绑定，如果你的用户都在华东，就选华东地域，别贪图便宜选到华北。
- 网络类型：是经典网络还是VPC私有网络？现在主流基本都是VPC，新购的SLB也默认支持VPC，如果你还有经典网络的ECS，需要确认是否支持混挂。
- 业务协议：是HTTP、HTTPS还是TCP/UDP？这决定了你创建监听时的配置项，尤其是HTTPS需要提前准备好证书。
准备后端服务器资源
建议将后端ECS的操作系统、Web服务环境（如Nginx、Apache、Tomcat）提前配置一致，避免出现部分服务器因环境差异导致的服务异常。确认安全组规则已放行SLB的健康检查IP段和业务端口，这是新手最容易踩的坑SLB配置看着全对，但健康检查就是不通过，多半是安全组把流量挡了。
Slb配置核心步骤详解
整个配置过程说穿了就三步,下面的操作以简米云控制台为例，其他云厂商流程大同小异。
创建SLB实例并设置规格
进入负载均衡控制台,点击“创建负载均衡”，你需要选择：
- 计费方式：按量付费或包年包月，如果只是测试，选按量付费更灵活，测试完删掉不心疼。
- 实例规格：共享型实例性能有上限约束，适合中小流量场景；性能保障型实例有更高的SLA保障，适合核心生产业务，大多数中小型网站选共享型足够了。
- 主可用区：选择一个可用区，如果需要同城容灾，开启“主备可用区”功能，这样当主可用区故障时，流量会自动切换到备可用区。
配置监听和后端服务器组
实例创建完成后,点击“配置监听”，这是整个SLB配置过程中的核心环节。
- 添加TCP/HTTP/HTTPS监听：填写监听端口（如80或443），如果是HTTPS，需要上传SSL证书，并选择“单向认证”或“双向认证”，行业共识认为，对外提供Web服务使用HTTP/HTTPS七层负载均衡即可，TCP四层转发更适合数据库、游戏等长连接场景。
- 配置后端服务器：选择“默认服务器组”，把准备好的ECS实例添加进来，并设置权重，权重默认为100，意味着流量平均分配，如果某台服务器性能更强，可以把权重调高，让负载分配更符合实际处理能力，如果实际业务是读写分离的，建议后端服务器组按角色分开配置，便于后续单独调整权重。
- 开启会话保持：对于需要保持登录状态的Web应用，打开“会话保持”开关，超时时间建议设置为15-30分钟，这样同一用户的请求会被转发到同一台后端服务器，避免出现“登录后刷新又掉线”的问题。
设置健康检查
健康检查配置不当,会导致SLB把请求转发给“带病运行”的服务器，用户访问时出现间歇性报错，具体设置建议：
- 检查协议：HTTP监听建议使用HTTP健康检查，端口指向后端服务的真实端口，检查路径填写一个稳定的探针页面，比如
/health.html，TCP监听则使用TCP健康检查。 - 响应超时时间：建议设置为5秒，连续几次失败认为实例不可用。
- 健康检查间隔：默认5秒一次，如果后端实例压力较大，可以适当调大到10秒。
- 不健康阈值：默认3次。
响应超时时间要结合后端应用的响应速度来设，如果后端接口本身响应就要3秒，你把超时设成2秒，后端服务器永远会被判定为不健康。
SLB配置中的常见问题及排查思路
即便照着文档操作,仍然有相当一部分用户会遇到问题，这里列举几个高频故障场景。
健康检查显示“异常”
先别急着改SLB配置,按以下顺序排查：
- 直接用浏览器或curl访问后端ECS的IP加健康检查路径,看是否能正常返回200状态码。
- 检查后端ECS的安全组入方向是否放行了64.0.0/10这个网段的访问（或者简米云文档中提到的健康检查源IP段）。
- 确认后端服务器的防火墙（iptables/firewalld）没有拦截。
配置完成后，公网IP访问不通
- 检查SLB实例的“访问控制”是否开启了黑名单/白名单策略。
- 确认SLB的“公网带宽”不是0Mbps，否则默认不提供公网访问能力。
- 检查监听端口是否被安全组策略拦截。
负载不均衡，某台ECS流量特别高
- 检查会话保持是否开启,这会导致长连接用户的请求始终落在同一台机器上。
- 检查权重配置是否一致。
- 查看后端服务的KeepAlive配置,如果客户端和SLB都开启了长连接，连接数分布可能会集中。
Slb服务器搭建的进阶技巧
基础的SLB配置学会后,想让它跑得更稳定、更省心，下面这几个技巧能派上用场。
合理使用域名和转发策略
不要只配置一个监听端口转发到所有后端。利用域名和URL路径做转发是SLB的核心进阶玩法。
- 在HTTP监听里,可以添加“域名+URL”的转发策略，将
api.example.com的请求转发到API服务器组，将web.example.com的请求转发到Web服务器组。 - 这样既解决了不同业务混用SLB实例的问题,也方便后续做灰度发布，配置路径为：监听详情 -> 转发策略 -> 添加转发策略。
跨地域容灾怎么处理
如果公司业务覆盖全国甚至海外,单地域的SLB无法解决跨地域容灾问题，行业共识是采用多地域SLB + DNS轮询/全局流量管理的架构，在华北、华东、华南各部署一套SLB，再通过云解析DNS将域名解析到多个SLB的公网IP，配合健康检查实现故障自动切换。
获取客户端真实IP
后端服务器默认看到的是SLB的私网IP,拿不到用户真实IP，解决方法是：
- 四层TCP监听：开启Proxy Protocol协议功能，后端Nginx需要配合修改配置接收真实IP。
- 七层HTTP监听：默认支持通过
X-Forwarded-For请求头获取真实客户端IP，只需要在后端Nginx日志格式中增加$http_x_forwarded_for字段即可。
Nginx和Slb哪个好用
很多技术人员比较关心SLB和自建Nginx之间的选择,这个问题没有绝对的答案，主要看使用场景。
| 对比维度 | SLB（云负载均衡） | 自建Nginx |
|---|---|---|
| 运维成本 | 几乎为零，无需维护软件本身 | 需要自己打补丁、维护配置文件、监控进程状态 |
| 高可用性 | 云厂商承诺SLA，默认多副本 | 需要自己处理Keepalived或LVS方案 |
| 功能扩展 | 支持HTTPS证书统一管理、WAF集成 | 可通过Lua脚本、Nginx模块实现复杂功能 |
| 7层转发性能 | 高，硬件加速 | 依赖服务器CPU性能，较高 |
| 价格 | 按实例规格付费，价格有优势 | 需要额外投入服务器资源 |
简单总结一下：如果你的需求是
快速部署、稳定可靠，直接使用SLB配置是性价比最高的方案，如果你需要复杂的流量控制逻辑，比如根据Header动态路由、限流、重试，自建Nginx更有掌控力。
Nginx和Slb哪个好用取决于你的场景
在实际项目中,很多团队采取的是SLB（四层） -> Nginx（七层） -> 后端服务的架构模式，SLB负责网络层的稳定接入和基础容灾，Nginx负责负载均衡策略和缓存控制，这种方案兼顾了稳定性和灵活性，在大型项目中使用比例相当高。
Slb配置价格影响因素
关于cost,SLB的计费主要是两部分：
- 实例费：按小时或按月收取，不同地域价格略有差异。
- 公网流量费：按使用的公网流量计费，这部分才是大头。
在SLB配置时选择“按量付费”+“按使用流量”计费，可以在业务低谷期节省成本，对于业务量稳定的大企业，包年包月+固定带宽的方式更容易做预算控制，小流量的个人站点，每月的费用支出通常可以控制在较低水平，相比单独购买多台高性能ECS来搭建负载均衡，成本优势明显，具体的slb配置价格，你可以直接查看云厂商官网的计费页，或者使用价格计算器估算。
SLB配置Q&A
问：SLB配置中，会话保持的超时时间设置多少合适？
答：常规Web应用建议设置为15-30分钟，如果后端是WebSocket应用，建议开启TCP协议的四层监听，并将会话保持时间拉长或使用应用层的心跳机制来维持长连接，超时时间越长，对后端单台服务器的压力越集中，需要结合后端会话的存储方式综合判断。
问：SLB后端ECS的权重设置有什么实操技巧？
答：同一组内多台ECS权重保持一致，实现均匀负载，如果新旧服务器配置有差异，新购的服务器权重可以临时调低，观察一段时间稳定后再逐步调高权重，实现平滑扩容，这种灰度切换方式能最大程度降低服务波动风险。
问：slb和nginx哪个好用，能直接用Nginx替代SLB吗？
答：如果业务部署在单台云服务器上，用Nginx做负载均衡可以满足基本要求，但当业务需要横向扩容、跨可用区容灾或自动故障转移时，SLB配置的托管属性决定了其比自建方案拥有更高的可用性保障，它不需要你维护虚拟IP、不需要安装Keepalived软件，内网场景下，也建议优先使用云厂商提供的SLB，因为其默认集成了内网DNS解析的联动能力，这在自建方案中实现起来比较复杂。