Nginx七层（应用层）反向代理：HTTP反向代理proxy_pass篇（三）-阿里云开发者社区

Nginx七层（应用层）反向代理：HTTP反向代理proxy_pass篇（二）：

在现代的Web应用架构中，多应用服务器代理是一种常见且强大的部署模式。这种模式允许我们将多个不同的应用或服务部署在同一个域名下，由Nginx作为前端代理服务器来管理和分发请求。这不仅简化了客户端的访问方式，还提供了更灵活的后端架构设计空间。

首先，让我们考虑一个典型的场景：假设我们有一个主Web应用、一个API服务和一个静态文件服务，我们希望将它们统一在同一个域名下。我们可以使用Nginx的location指令来实现这种路由：

http {
    upstream main_app {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
    }

    upstream api_service {
        server 192.168.1.20:3000;
        server 192.168.1.21:3000;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://main_app;
        }

        location /api/ {
            proxy_pass http://api_service;
        }

        location /static/ {
            root /var/www/static;
        }
    }
}

在这个配置中，我们定义了两个上游服务器组：main_app和api_service，每个组都包含两个服务器实例，实现了简单的负载均衡。然后，我们使用location指令将不同的路径映射到不同的后端服务：

根路径"/"被代理到主应用服务器组。

"/api/"路径被代理到API服务器组。

"/static/"路径直接由Nginx服务静态文件。

这种配置方式使得我们可以独立地扩展和维护每个服务，同时对外提供一个统一的访问接口。

在实际应用中，我们可能需要对不同的服务应用不同的配置。例如，API服务可能需要更长的超时时间，而静态文件服务可能需要更激进的缓存策略。我们可以在各自的location块中添加这些特定的配置：

location /api/ {
    proxy_pass http://api_service;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

location /static/ {
    root /var/www/static;
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
}

在这个增强的配置中，我们为API服务设置了更长的读取和发送超时时间，为静态文件设置了30天的过期时间和相应的缓存控制头。

另一个常见的需求是在代理过程中修改请求或响应。例如，我们可能需要为API请求添加一个自定义头部，或者在代理静态文件时去掉某些响应头：

location /api/ {
    proxy_pass http://api_service;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-API-Key "secret_key";
}

location /static/ {
    root /var/www/static;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
}

在这个配置中，我们为API请求添加了客户端IP信息和一个自定义的API密钥，同时在静态文件响应中隐藏了一些可能暴露服务器信息的头部。

在多应用服务器代理的场景中，安全性也是一个重要的考虑因素。我们可能需要对不同的路径应用不

同的安全策略。例如，我们可能希望限制API的访问频率，或者只允许特定的IP地址访问某些路径：

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

    server {
        location /api/ {
            proxy_pass http://api_service;
            limit_req zone=api_limit burst=10 nodelay;
        }

        location /admin/ {
            proxy_pass http://admin_service;
            allow 192.168.1.0/24;
            deny all;
        }
    }
}

在这个配置中，我们对API请求应用了速率限制，每秒最多允许5个请求，突发情况下最多允许10个请求排队。同时，我们限制只有来自特定IP范围的请求才能访问管理接口。

最后，在多应用服务器代理的场景中，日志管理也是一个重要的话题。我们可能希望为不同的服务配置不同的日志文件，或者在日志中包含更多的信息：

http {
    log_format detailed '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" '
                        '$request_time $upstream_response_time';

    server {
        location / {
            proxy_pass http://main_app;
            access_log /var/log/nginx/main_app.log detailed;
        }

        location /api/ {
            proxy_pass http://api_service;
            access_log /var/log/nginx/api.log detailed;
        }
    }
}

在这个配置中，我们定义了一个详细的日志格式，包含了请求处理时间和上游响应时间等信息。然后，我们为主应用和API服务配置了独立的日志文件，使用这个详细的日志格式。

通过这种方式配置多应用服务器代理，我们可以在保持对外接口简单统一的同时，实现后端服务的灵活部署和精细化管理。这种架构模式使得我们可以根据不同服务的特点和需求，应用不同的代理策略、安全措施和性能优化，从而构建一个更加健壮和高效的系统。

7.2 API网关

在现代微服务架构中，API网关扮演着至关重要的角色。它作为客户端和后端服务之间的中间层，负责请求路由、组合、协议转换等功能。Nginx凭借其高性能和灵活的配置，成为实现API网关的理想选择。本节将详细探讨如何使用Nginx配置API网关。

首先，我们需要定义上游服务器组，这些服务器将处理实际的API请求：

http {
    upstream auth_service {
        server auth1.example.com:8080;
        server auth2.example.com:8080;
    }

    upstream user_service {
        server user1.example.com:8081;
        server user2.example.com:8081;
    }

    upstream product_service {
        server product1.example.com:8082;
        server product2.example.com:8082;
    }
}

在这个配置中，我们定义了三个上游服务器组，分别对应认证服务、用户服务和产品服务。每个服务都有两个实例，实现了简单的负载均衡。

接下来，我们配置Nginx服务器块，定义API路由规则：

server {
    listen 80;
    server_name api.example.com;

    location /auth/ {
        proxy_pass http://auth_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

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

    location /products/ {
        proxy_pass http://product_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这个配置将不同的API路径路由到相应的后端服务。例如，所有以/auth/开头的请求都会被转发到认证服务。

作为API网关，我们通常需要实现一些通用的功能，如请求限率、认证等。我们可以使用Nginx的模块来实现这些功能：

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

    server {
        listen 80;
        server_name api.example.com;

        location /auth/ {
            limit_req zone=api_limit burst=10 nodelay;
            proxy_pass http://auth_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location /users/ {
            auth_request /auth/validate;
            limit_req zone=api_limit burst=10 nodelay;
            proxy_pass http://user_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location /products/ {
            auth_request /auth/validate;
            limit_req zone=api_limit burst=10 nodelay;
            proxy_pass http://product_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location = /auth/validate {
            internal;
            proxy_pass http://auth_service/validate;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            proxy_set_header X-Original-URI $request_uri;
        }
    }
}

在这个增强的配置中，我们添加了请求限率功能，每个IP每秒最多可以发送5个请求，突发情况下最多允许10个请求排队。我们还添加了一个认证检查，所有访问/users/和/products/的请求都需要先通过/auth/validate的认证。

API网关还常常需要修改请求或响应。例如，我们可能需要添加一些自定义头部，或者在响应中隐藏某些敏感信息：

location /users/ {
    auth_request /auth/validate;
    limit_req zone=api_limit burst=10 nodelay;
    proxy_pass http://user_service;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-API-Version "1.0";

    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;

    sub_filter_once off;
    sub_filter "internal_id" "id";
    sub_filter_types application/json;
}

在这个配置中，我们为所有用户服务的请求添加了一个自定义的API版本头部。同时，我们隐藏了一些可能暴露服务器信息的响应头，并使用sub_filter指令将响应中的"internal_id"替换为"id"。

最后，作为API网关，记录详细的访问日志对于监控和故障排查至关重要。我们可以配置一个自定义的日志格式：

http {
    log_format api_gateway '$remote_addr - $remote_user [$time_local] "$request" '
                           '$status $body_bytes_sent "$http_referer" '
                           '"$http_user_agent" $request_time $upstream_response_time '
                           '$upstream_addr';

    server {
        listen 80;
        server_name api.example.com;

        access_log /var/log/nginx/api_access.log api_gateway;

        # 其他配置...
    }
}

这个日志格式包含了请求处理时间、上游响应时间和上游服务器地址等有用信息，可以帮助我们更好地分析API性能和问题。

通过以上配置，我们实现了一个基本的API网关，它能够路由请求、进行认证、限制请求率、修改请求和响应，以及记录详细的访问日志。这个API网关为我们的微服务架构提供了一个统一的入口点，简化了客户端的调用方式，同时也为我们提供了集中管理API的能力。然而，需要注意的是，API网关的具体实现应该根据实际的业务需求和系统架构来调整。在实际应用中，我们可能还需要考虑更多的因素，如API版本管理、服务发现、熔断器等高级功能。

7.3 静态资源服务器

在现代Web应用中，静态资源服务器扮演着重要角色。它负责高效地提供静态文件，如HTML、CSS、JavaScript、图片等，从而减轻应用服务器的负担。Nginx作为一个高性能的Web服务器，非常适合用作静态资源服务器。本节将详细探讨如何使用Nginx配置静态资源服务器。

首先，我们需要在Nginx配置文件中定义一个服务器块，用于处理静态资源请求：

server {
    listen 80;
    server_name static.example.com;
    root /var/www/static;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

在这个基本配置中，我们指定服务器监听80端口，并设置了服务器名称。root指令定义了静态文件的根目录。try_files指令告诉Nginx首先尝试提供请求的文件，如果文件不存在，则返回404错误。

为了提高性能，我们可以添加一些缓存相关的配置：

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

这个配置为常见的静态文件类型设置了30天的过期时间，并添加了相应的缓存控制头。这可以显著减少服务器负载并提高访问速度，因为浏览器可以缓存这些文件。

对于大文件，我们可以启用Nginx的sendfile功能来提高传输效率：

sendfile on;
tcp_nopush on;
tcp_nodelay on;

sendfile指令启用了零拷贝文件传输，可以显著提高大文件的传输速度。tcp_nopush和tcp_nodelay指令可以进一步优化TCP传输。

为了防止恶意请求，我们可以限制单个请求的大小：

client_max_body_size 10m;

这个配置将客户端请求体的最大允许大小设置为10MB。

在某些情况下，我们可能需要保护某些静态文件不被直接访问。我们可以使用Nginx的访问控制功能来实现这一点：

location /protected/ {
    internal;
}

这个配置将/protected/目录标记为内部位置，只能通过内部重定向访问，而不能直接从外部访问。

对于图片文件，我们可以配置Nginx进行动态调整大小：

location ~ ^/images/(.+)$ {
    image_filter resize 300 200;
    image_filter_jpeg_quality 75;
}

这个配置使用Nginx的image_filter模块将所有图片调整为300x200的大小，并将JPEG图片的质量设置为75%。这可以帮助减少带宽使用并提高页面加载速度。

为了进一步优化性能，我们可以启用Gzip压缩：

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

这个配置指定了访问日志和错误日志的位置。我们可以通过分析这些日志来了解服务器的使用情况和潜在问题。

通过以上配置，我们实现了一个高性能的静态资源服务器。它不仅可以高效地提供静态文件，还实现了缓存控制、访问控制、性能优化等功能。这种配置可以显著提高Web应用的性能，减轻应用服务器的负担。然而，需要注意的是，静态资源服务器的具体配置应该根据实际的业务需求和系统架构来调整。在实际应用中，我们可能还需要考虑更多的因素，如CDN集成、安全性增强、日志分析等高级功能。

8. 总结

本文全面介绍了Nginx反向代理的工作原理、配置方法和应用场景。我们深入探讨了反向代理的概念、Nginx的事件驱动架构、基本配置指令如proxy_pass和location的使用，以及负载均衡、SSL/TLS配置等高级特性。此外，我们还详细讲解了如何使用Nginx搭建高性能的静态资源服务器，包括缓存控制、性能优化和访问控制等关键配置。

最后，希望本文对你有所帮助。