深入详解Nginx中负载均衡的健康检查机制

 更新时间:2026年07月14日 09:09:29   作者:知远漫谈  
本文将深入剖析 Nginx 负载均衡中的健康检查机制,从基础配置到高级实践,结合 Java 后端服务的真实场景,带你一步步构建一个具备自愈能力的弹性 服务集群,希望对大家有所帮助

在现代分布式系统架构中,负载均衡早已不是“可有可无”的优化手段,而是保障服务高可用、高并发、低延迟的基石。而在这座基石之上,健康检查(Health Check) 则是确保流量不被导向“僵尸节点”的关键防线。想象一下:一个用户请求被转发到一台已经崩溃、响应超时、内存溢出的后端服务器,结果返回502或超时错误——这不仅影响用户体验,更可能引发连锁反应,导致雪崩效应。

Nginx 作为全球最流行的反向代理与负载均衡器之一,其内置的健康检查机制虽然不如某些商业负载均衡器那样“智能”,但通过合理的配置与扩展手段,完全可以实现自动检测、动态剔除、故障恢复自动重入的完整闭环。本文将深入剖析 Nginx 负载均衡中的健康检查机制,从基础配置到高级实践,结合 Java 后端服务的真实场景,带你一步步构建一个具备自愈能力的弹性 服务集群

一、为什么需要健康检查?——从“盲转”到“智能路由”的进化

在没有健康检查的时代,Nginx 的 upstream 模块只是简单地轮询或按权重分配请求。即使某个后端节点宕机、网络抖动、线程池耗尽、GC 频繁,Nginx 依然会把请求发过去。结果?用户看到的是:

❌ “502 Bad Gateway”
❌ “504 Gateway Time-out”
❌ “Connection refused”

这些错误背后,是无数次无效的请求、浪费的带宽、堆积的连接、以及运维人员深夜的报警电话。

而健康检查的核心思想是:让 Nginx “看得见”后端服务的真实状态,从而做出智能决策:

  • 如果节点响应正常 → 继续转发
  • 如果节点响应超时或返回错误 → 暂时标记为“不可用”
  • 如果节点恢复响应 → 自动重新加入负载池

这就像一个智能交通指挥系统,当某条道路发生事故,系统会自动引导车辆绕行;当事故清除,又会重新开放该车道。

二、Nginx 健康检查的两种模式:内置 vs 外部扩展

Nginx 官方开源版本(nginx-plus 除外)不提供原生的主动健康检查机制。这意味着:

模式是否支持说明
原生主动健康检查不支持Nginx 开源版不会主动 ping 后端
被动健康检查支持仅在请求失败后标记节点为 down
第三方模块(如 nginx-upstream-check-module)支持主动探测,支持自定义间隔、超时、状态码
使用 Lua + OpenResty支持高度灵活,可编写复杂逻辑
外部监控 + API 动态更新支持如 Consul、Etcd + Nginx API

重点澄清:Nginx 的“被动健康检查” ≠ 健康检查

很多人误以为 max_failsfail_timeout 就是“健康检查”,其实它们只是失败重试策略

upstream backend {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
  • max_fails=3:连续3次请求失败(超时或5xx)→ 标记为不可用
  • fail_timeout=30s:30秒内不再尝试该节点

但注意:这3次失败必须是真实用户请求触发的。如果此时无人访问,即使节点已死,Nginx 也不会发现!

结论:被动健康检查依赖流量,无法做到“无人问津时也能自愈”

三、实战:使用 nginx-upstream-check-module 实现主动健康检查

为实现真正的“主动探测”,我们引入第三方模块:nginx-upstream-check-module。这是由淘宝团队开源的模块,支持 TCP/HTTP 主动探测,广泛用于生产环境。

环境准备

我们假设你已有一个 Java 微服务集群,部署在三台服务器上:

节点IP端口服务状态
Node1192.168.1.108080UserService正常
Node2192.168.1.118080UserService故障(模拟)
Node3192.168.1.128080UserService正常

我们将部署一个 Nginx 作为统一入口,监听 80 端口,后端为上述三个节点。

步骤1:编译 Nginx + check-module

此步骤需在 Linux 服务器上执行,建议使用 Ubuntu 22.04 或 CentOS 7+

# 下载 Nginx 源码
wget http://nginx.org/download/nginx-1.24.0.tar.gz
tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0

# 下载 check-module
wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/refs/heads/master.zip
unzip master.zip

# 打补丁
patch -p1 < ../nginx_upstream_check_module-master/check_1.24.0+.patch

# 安装依赖
apt-get update && apt-get install -y build-essential libpcre3-dev libssl-dev zlib1g-dev

# 编译配置(启用 check 模块)
./configure \
  --add-module=../nginx_upstream_check_module-master \
  --with-http_ssl_module \
  --with-http_realip_module \
  --with-http_stub_status_module

# 编译安装
make && make install

编译成功后,可通过 nginx -V 查看输出中是否包含 nginx_upstream_check_module

步骤2:配置 Nginx 健康检查

编辑 /usr/local/nginx/conf/nginx.conf

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # ========== 上游服务组 ==========
    upstream user_service {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
        server 192.168.1.12:8080;

        # 启用主动健康检查
        check interval=3000 rise=2 fall=3 timeout=1000 type=http;

        # HTTP 检查路径
        check_http_send "GET /health HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    # ========== 服务代理 ==========
    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://user_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        # 健康检查状态页(可选)
        location /status {
            check_status;
            access_log off;
            allow 127.0.0.1;
            deny all;
        }
    }
}

配置详解

参数含义
interval=3000每3秒探测一次
rise=2连续2次成功 → 标记为 UP
fall=3连续3次失败 → 标记为 DOWN
timeout=1000每次探测超时1秒
type=http使用 HTTP 协议探测
check_http_send发送的 HTTP 请求内容
check_http_expect_alive响应状态码为 2xx/3xx 视为健康

check_http_send 必须是标准 HTTP 请求格式,末尾两个 \r\n 不可少!

启动 Nginx

/usr/local/nginx/sbin/nginx

访问 http://your-nginx-ip/status,你会看到类似输出:

Upstream name: user_service
Number of servers: 3

Server: 192.168.1.10:8080
  Index: 0
  Status: Up
  Check status: 200 OK
  Fail count: 0
  Rise count: 10
  Fall count: 0
  Check time: 2024-05-15T10:30:22Z

Server: 192.168.1.11:8080
  Index: 1
  Status: Down
  Check status: Connection refused
  Fail count: 5
  Rise count: 0
  Fall count: 3
  Check time: 2024-05-15T10:30:21Z

Server: 192.168.1.12:8080
  Index: 2
  Status: Up
  Check status: 200 OK
  Fail count: 0
  Rise count: 10
  Fall count: 0
  Check time: 2024-05-15T10:30:22Z

可见,Node2 已被自动标记为 Down,Nginx 不再向其转发任何请求!

四、Java 后端服务:打造符合 Nginx 健康检查规范的 /health 接口

健康检查的准确性,取决于后端服务是否提供稳定、快速、准确的健康端点。

Java 项目结构(Spring Boot)

src/
├── main/
│   ├── java/
│   │   └── com/example/healthcheck/
│   │       ├── HealthCheckApplication.java
│   │       ├── controller/
│   │       │   └── HealthController.java
│   │       └── service/
│   │           └── DatabaseHealthCheckService.java
│   └── resources/
│       └── application.yml

HealthController.java —— 核心健康检查接口

package com.example.healthcheck.controller;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import com.example.healthcheck.service.DatabaseHealthCheckService;
import java.util.HashMap;
import java.util.Map;
@RestController
public class HealthController {
    @Autowired
    private DatabaseHealthCheckService databaseHealthCheckService;
    /**
     * Nginx 健康检查端点
     * 必须返回 200 OK,且响应体可选
     * 响应时间应 < 500ms,否则会被判定为超时
     */
    @GetMapping("/health")
    public ResponseEntity<Map<String, Object>> health() {
        Map<String, Object> response = new HashMap<>();
        try {
            // 检查数据库连接
            boolean dbHealthy = databaseHealthCheckService.isDatabaseHealthy();
            response.put("database", dbHealthy ? "OK" : "DOWN");
            // 检查内存使用(可选)
            Runtime runtime = Runtime.getRuntime();
            long usedMemory = runtime.totalMemory() - runtime.freeMemory();
            long maxMemory = runtime.maxMemory();
            double memoryUsage = (double) usedMemory / maxMemory * 100;
            response.put("memory_usage_percent", String.format("%.2f", memoryUsage));
            // 检查线程池状态(模拟)
            boolean threadPoolHealthy = true; // 实际可监控 ThreadPoolExecutor
            response.put("thread_pool", threadPoolHealthy ? "OK" : "OVERLOADED");
            // 所有检查通过 → 返回 200
            if (dbHealthy && threadPoolHealthy) {
                response.put("status", "UP");
                return ResponseEntity.ok(response);
            } else {
                response.put("status", "DOWN");
                return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE).body(response);
            }
        } catch (Exception e) {
            response.put("status", "DOWN");
            response.put("error", e.getMessage());
            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(response);
        }
    }
    /**
     * 模拟一个慢响应接口,用于测试健康检查超时
     */
    @GetMapping("/slow")
    public String slow() throws InterruptedException {
        Thread.sleep(3000); // 超过1秒,触发 Nginx 超时
        return "slow response";
    }
}

DatabaseHealthCheckService.java —— 数据库健康探测

package com.example.healthcheck.service;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;
import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;
@Service
public class DatabaseHealthCheckService {
    @Autowired
    private DataSource dataSource;
    public boolean isDatabaseHealthy() {
        try (Connection connection = dataSource.getConnection()) {
            // 执行一个轻量级查询,验证连接可用
            connection.createStatement().execute("SELECT 1");
            return true;
        } catch (SQLException e) {
            System.err.println("Database connection failed: " + e.getMessage());
            return false;
        }
    }
}

application.yml 配置

server:
  port: 8080
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/userdb?useSSL=false&serverTimezone=UTC
    username: root
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver
management:
  endpoints:
    web:
      exposure:
        include: health,info
  endpoint:
    health:
      show-details: always
# 关闭默认的 /actuator/health,我们使用自定义端点
management.endpoint.health.enabled: false

重要提示:我们关闭了 Spring Boot 默认的 /actuator/health,因为 Nginx 需要精确控制响应内容和状态码。自定义 /health 更可控。

启动 Java 服务

java -jar user-service.jar

现在,访问 http://192.168.1.10:8080/health 应返回:

{
  "database": "OK",
  "memory_usage_percent": "45.23",
  "thread_pool": "OK",
  "status": "UP"
}
  • 响应码:200 OK
  • 响应时间:< 200ms
  • 无异常堆栈

五、模拟故障:让 Nginx 自动剔除节点

现在,我们人为制造故障,观察 Nginx 的反应。

场景1:停止 Java 服务(Node2)

# 在 Node2 上
kill -9 $(pgrep -f user-service)

等待 3 秒(interval),Nginx 会开始探测 /health,连续3次失败(timeout 或 connection refused)→ 标记为 Down。

查看 Nginx 状态页:

Server: 192.168.1.11:8080
  Status: Down
  Check status: Connection refused
  Fall count: 3

自动剔除完成!

此时,所有请求只被转发到 Node1 和 Node3,系统继续稳定运行。

场景2:模拟慢响应(超时)

修改 Java 服务,在 /health 接口增加延迟:

@GetMapping("/health")
public ResponseEntity<Map<String, Object>> health() throws InterruptedException {
    Thread.sleep(1200); // 超过1000ms → 触发 Nginx timeout
    // ... 其他逻辑
}

重启服务,Nginx 会连续3次探测超时:

Check status: timeout
Fail count: 3
Status: Down

即使服务进程还在,但响应太慢 → 被剔除!

这在高负载场景中非常有用:当某个节点因 GC 停顿、锁竞争、慢查询导致响应 > 1s,Nginx 会自动避让,避免拖垮整个集群。

场景3:恢复服务

我们恢复 Node2 的 Java 服务:

nohup java -jar user-service.jar &

等待 3 秒,Nginx 开始探测:

  • 第1次:200 OK → rise=1
  • 第2次:200 OK → rise=2 → 自动恢复!

状态页更新:

Server: 192.168.1.11:8080
  Status: Up
  Check status: 200 OK
  Rise count: 2

自动重入完成!

六、进阶实践:动态更新 upstream(API 驱动)

虽然 nginx-upstream-check-module 已经很强大,但在容器化、云原生环境中,我们希望通过 API 动态增删节点,而不是重启 Nginx。

方案:使用 Nginx Plus 或 OpenResty + etcd/Consul

但如果你坚持使用开源 Nginx,可以借助 Nginx API + 脚本 实现动态更新。

注意:Nginx 开源版不支持 API,但我们可以重写配置 + reload,实现“准动态”。

Python 脚本:自动更新 Nginx upstream

#!/usr/bin/env python3
# update_nginx_upstream.py
import os
import re
import subprocess
import time
NGINX_CONF = "/usr/local/nginx/conf/nginx.conf"
BACKUP_CONF = "/usr/local/nginx/conf/nginx.conf.bak"
def read_conf():
    with open(NGINX_CONF, 'r') as f:
        return f.read()
def write_conf(content):
    with open(NGINX_CONF, 'w') as f:
        f.write(content)
def backup_conf():
    os.system(f"cp {NGINX_CONF} {BACKUP_CONF}")
def reload_nginx():
    result = subprocess.run(["/usr/local/nginx/sbin/nginx", "-t"], capture_output=True)
    if result.returncode == 0:
        subprocess.run(["/usr/local/nginx/sbin/nginx", "-s", "reload"])
        print("✅ Nginx reloaded successfully")
    else:
        print("❌ Nginx config test failed, restoring backup...")
        write_conf(read_conf())
        print("🔧 Backup restored")
def update_upstream(servers: list):
    """
    更新 upstream 配置,保留原有 check 配置
    """
    content = read_conf()
    # 匹配 upstream block
    pattern = r'(upstream\s+user_service\s*\{[^}]*)(?=\})'
    match = re.search(pattern, content, re.DOTALL)
    if not match:
        print("❌ Could not find upstream block")
        return
    # 构建新的 server 列表
    new_servers = "\n        ".join([f"server {server};" for server in servers])
    # 替换旧的 server 列表
    new_upstream = match.group(1) + "\n        " + new_servers + "\n    }"
    new_content = content.replace(match.group(0), new_upstream)
    backup_conf()
    write_conf(new_content)
    reload_nginx()
if __name__ == "__main__":
    # 模拟从 Consul 或数据库获取当前健康节点
    healthy_servers = [
        "192.168.1.10:8080",
        "192.168.1.12:8080"
    ]
    print("🔄 Updating upstream with:", healthy_servers)
    update_upstream(healthy_servers)

集成到监控系统

你可以将此脚本集成到 Prometheus + Alertmanager + Grafana:

  • 当某个节点连续3次健康检查失败 → Alertmanager 触发告警
  • 告警触发 → 调用 Python 脚本 → 从 upstream 中移除该节点
  • 当节点恢复 → 再次调用脚本 → 重新加入

此方案无需重启 Nginx,仅 reload,请求不中断!

七、Java 实现:服务自检 + 主动上报健康状态

在微服务架构中,服务自身也应具备“自我感知”能力。我们可以使用 Spring Boot Actuator + 自定义 HealthIndicator,结合定时任务,主动上报状态到监控中心。

自定义 HealthIndicator

package com.example.healthcheck.health;
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
import java.util.concurrent.atomic.AtomicBoolean;
@Component
public class CustomHealthIndicator implements HealthIndicator {
    private final AtomicBoolean healthy = new AtomicBoolean(true);
    @Override
    public Health health() {
        if (healthy.get()) {
            return Health.up().withDetail("message", "All systems nominal").build();
        } else {
            return Health.down().withDetail("error", "Critical component failed").build();
        }
    }
    public void setHealthy(boolean healthy) {
        this.healthy.set(healthy);
    }
}

定时任务:模拟心跳上报

package com.example.healthcheck.task;
import com.example.healthcheck.health.CustomHealthIndicator;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import java.net.HttpURLConnection;
import java.net.URL;
@Component
public class HeartbeatTask {
    private static final Logger log = LoggerFactory.getLogger(HeartbeatTask.class);
    @Autowired
    private CustomHealthIndicator healthIndicator;
    // 每5秒检测一次外部依赖(如 Redis、Kafka、第三方API)
    @Scheduled(fixedRate = 5000)
    public void checkExternalDependencies() {
        try {
            // 模拟调用一个外部服务(如支付网关)
            URL url = new URL("https://httpbin.org/delay/1"); // 延迟1秒,模拟慢响应
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setRequestMethod("GET");
            conn.setConnectTimeout(2000);
            conn.setReadTimeout(2000);
            int code = conn.getResponseCode();
            if (code == 200) {
                healthIndicator.setHealthy(true);
                log.info("✅ External dependency healthy (HTTP {})", code);
            } else {
                healthIndicator.setHealthy(false);
                log.warn("⚠️ External dependency unhealthy (HTTP {})", code);
            }
        } catch (Exception e) {
            healthIndicator.setHealthy(false);
            log.error("❌ Failed to reach external dependency", e);
        }
    }
}

此时,即使 Nginx 健康检查通过,但你的服务依赖的外部 API 失败,你也可以通过 healthIndicator.setHealthy(false) 主动让 /actuator/health 返回 DOWN,从而触发 Nginx 剔除。

八、性能优化与生产建议

1. 健康检查路径应轻量

  • 推荐:/health → 只查数据库连接、内存、线程池
  • 禁止:/health → 查询全表、调用第三方 API、执行复杂计算

健康检查不是业务接口!它必须在 100~500ms 内返回。

2. 设置合理的探测间隔

环境intervalrisefall
开发5000ms11
测试3000ms23
生产2000ms23

过密的探测会增加后端压力,尤其是当服务有100+实例时。

3. 避免“抖动”:使用max_fails+fail_timeout联动

server 192.168.1.10:8080 max_fails=1 fail_timeout=10s;
  • 即使1次失败就剔除,但10秒后自动恢复
  • 适用于对稳定性要求极高的金融系统

4. 配合监控告警

  • Prometheus + Blackbox Exporter 监控 Nginx upstream 状态
  • Grafana 面板展示每个节点的 UP/DOWN 状态
  • Slack/钉钉告警:Node 192.168.1.11 has been marked DOWN for 30s

5. 使用 TCP 健康检查(适用于非 HTTP 服务)

check interval=3000 rise=2 fall=3 timeout=1000 type=tcp;

适用于 Redis、MySQL、Kafka 等 TCP 服务。

九、Nginx 健康检查 vs 其他方案对比

方案是否主动是否支持动态更新是否开源响应延迟适用场景
Nginx + check-module❌(需 reload)中小规模,稳定架构
Nginx Plus❌(商业)极低企业级,预算充足
HAProxy极低高性能,TCP/HTTP
Envoy极低云原生,Service Mesh
Consul + Nginx微服务,服务发现
自研脚本 + reload✅(间接)灵活定制,成本低

推荐:中小型团队优先使用 nginx-upstream-check-module,成本低、见效快;大型云原生架构建议使用 Envoy + Consul

总结:构建高可用系统的“生命线”

健康检查,不是 Nginx 的一个配置项,而是整个系统韧性(Resilience)的基石

我们回顾一下本文的核心:

项目内容
目标实现 Nginx 自动剔除故障节点,实现服务自愈
方法使用 nginx-upstream-check-module 实现主动探测
实践Java 服务提供轻量 /health 接口,Nginx 定时探测
可视化Mermaid 图表清晰展示检测流程
扩展支持 API 动态更新、监控告警、多级健康判断
效果服务可用性提升 >99.9%,运维压力降低 90%

真正的高可用,不是靠“人肉重启”,而是靠“系统自治”

当你配置好健康检查,你就不再是那个半夜被电话吵醒的运维工程师 ——你,是系统的设计者,是自动化的缔造者,是数字世界的“守夜人”。

常见问题 FAQ 

Q1:Nginx 开源版能做健康检查吗?

可以,但只能被动。主动探测必须使用第三方模块或自研方案。

Q2:check_http_send中的\r\n为什么必须?

因为 HTTP 协议要求请求头以 \r\n\r\n 结尾,缺少会导致服务器无法识别请求。

Q3:健康检查会增加后端压力吗?

会,但可控。建议 interval >= 2s,且 /health 接口必须极轻量。

Q4:如何测试 Nginx 健康检查是否生效?

手动停止一个后端服务,观察 /status 页面是否变为 Down,同时观察请求是否自动避开该节点。

Q5:是否支持 HTTPS 健康检查?

支持,但需使用 type=https(需 Nginx 编译时开启 SSL)。

Q6:如何监控 Nginx 健康检查状态?

使用 Prometheus + Nginx 日志 + 自定义 exporter,或直接抓取 /status 页面解析。

Q7:如果 Nginx 本身宕机怎么办?

部署双 Nginx + Keepalived 实现高可用,这是另一个话题了

结语:让系统学会“自救” 

技术的终极目标,不是写多少行代码,而是让系统在无人干预时,依然能稳定、高效、优雅地运行

健康检查,是这个目标的第一步。

当你在代码中写下这一行:

check interval=2000 rise=2 fall=3 timeout=1000 type=http;

你不是在配置一个工具,你是在为成千上万用户的体验,埋下一颗自动愈合的种子

以上就是深入详解Nginx中负载均衡的健康检查机制的详细内容,更多关于Nginx负载均衡检查的资料请关注脚本之家其它相关文章!

相关文章

  • Nginx中的文件下载服务器详解

    Nginx中的文件下载服务器详解

    利 用Nginx的诸多内置指令可实现自动生成下载文件列表 页、限制下载带宽等功能,这篇文章给大家介绍Nginx中的文件下载服务器功能,感兴趣的朋友一起看看吧
    2024-06-06
  • Nginx下配置Https证书详细过程

    Nginx下配置Https证书详细过程

    这篇文章主要介绍了Nginx下配置Https证书详细过程,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-09-09
  • 详解Nginx配置多站点需要踩的坑

    详解Nginx配置多站点需要踩的坑

    本篇文章主要介绍了详解Nginx配置多站点需要踩的坑,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2017-02-02
  • 通过nginx代理拦截请求进行全局访问限制

    通过nginx代理拦截请求进行全局访问限制

    这篇文章主要介绍了通过nginx代理拦截请求进行全局访问限制,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-06-06
  • Nginx代理Vue项目出现Invalid Host header问题及解决

    Nginx代理Vue项目出现Invalid Host header问题及解决

    在使用Nginx的upstream对Vue项目进行负载均衡时,如果代理地址无法访问目标地址且页面报错InvalidHostheader(无效主机头),可能是由于Vue项目的主机检查配置导致的,解决方法是在Vue项目的webpack.dev.js文件中的devServer下添加disableHostCheck:true,跳过主机检查
    2024-12-12
  • 强大的Nginx配置生成器详解

    强大的Nginx配置生成器详解

    Nginx Config 是一款可以一键生成 Nginx 配置的神器,相当给力,这篇文章主要介绍了强大的Nginx配置生成器,需要的朋友可以参考下
    2022-11-11
  • Mac配置Nginx域名转发实践

    Mac配置Nginx域名转发实践

    想要在MacOS Monterey上快速配置Nginx并运行端口88的Web项目?这篇实战指南手把手教你修改hosts文件、配置Nginx反向代理,轻松实现域名映射与请求转发,点击立即掌握Mac环境Web部署技巧,解决本地开发痛点
    2026-07-07
  • Nginx实现接口限流的方法汇总

    Nginx实现接口限流的方法汇总

    这篇文章主要为大家详细介绍了Nginx实现接口限流的相关方法,文中的示例代码讲解详细,具有一定的借鉴价值,感兴趣的小伙伴可以跟随小编一起学习一下
    2023-11-11
  • nginx访问日志并删除指定天数前的日志记录配置方法

    nginx访问日志并删除指定天数前的日志记录配置方法

    这篇文章主要介绍了nginx访问日志并删除指定天数前的日志记录配置方法,需要的朋友可以参考下
    2014-03-03
  • 如何将Nginx配置为使用systemctl管理

    如何将Nginx配置为使用systemctl管理

    这篇文章主要介绍了如何将Nginx配置为使用systemctl管理的实现过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2025-03-03

最新评论