当前位置:

首页 > 编程开发 > FastAPI配置SSL:Nginx反向代理教程

FastAPI配置SSL:Nginx反向代理教程

本教程详细阐述了如何在Docker容器化环境中,为FastAPI后端和React前端应用配置SSL证书。通过引入Nginx作为反向代理,实现SSL终止,从而简化应用层面的证书管理,解决直接在Uvicorn中配置SSL可能导致的CORS问题,并提供完整的Nginx配置、DockerCompose集成及Certbot证书管理指南。

为FastAPI应用配置SSL证书:Nginx反向代理实践

本教程详细阐述了如何在Docker容器化环境中,为FastAPI后端和React前端应用配置SSL证书。通过引入Nginx作为反向代理,实现SSL终止,从而简化应用层面的证书管理,解决直接在Uvicorn中配置SSL可能导致的CORS问题,并提供完整的Nginx配置、Docker Compose集成及Certbot证书管理指南。

1. 背景与问题概述

在现代Web应用开发中,数据传输的安全性至关重要,HTTPS已成为标配。对于使用FastAPI构建后端API和React构建前端界面的应用,通常会将其容器化部署。直接在FastAPI(通过Uvicorn)中配置SSL证书虽然可行,但可能引入额外的复杂性,例如CORS(跨域资源共享)配置的挑战,以及在多服务架构中管理证书的繁琐。更常见的做法是利用Nginx作为反向代理,统一处理SSL加密和解密,并将未加密的HTTP请求转发给后端应用。

2. 解决方案:Nginx反向代理实现SSL终止

Nginx作为一款高性能的HTTP和反向代理服务器,是处理SSL终止的理想选择。其核心思想是:Nginx监听外部的HTTPS请求(端口443),使用配置好的SSL证书进行加密/解密,然后将解密后的HTTP请求转发给内部的FastAPI或React应用。这样,FastAPI和React应用本身无需关心SSL,只需监听HTTP端口。

优点:

  • 简化应用配置: FastAPI应用只需运行在HTTP模式下,无需处理证书和HTTPS逻辑。
  • 集中式SSL管理: 所有证书管理(获取、更新、部署)都在Nginx层面进行,便于统一维护。
  • 性能优化: Nginx在处理静态文件和高并发连接方面表现优异,能有效卸载后端应用的压力。
  • 灵活的路由: 可以根据域名、路径等灵活配置请求转发规则。

3. 前提条件

在开始配置之前,请确保您已具备以下条件:

  • 一个或多个已注册的域名或子域名(例如 mysite.ru 和 back.mysite.ru)。
  • 已安装Docker和Docker Compose。
  • 已通过Certbot或其他方式获取了SSL证书文件(fullchain.pem、privkey.pem、chain.pem),并知道它们的存储路径(通常在 /etc/letsencrypt/live/your_domain/)。

4. 核心配置步骤

本教程将以一个包含FastAPI后端、React前端和PostgreSQL数据库的Docker Compose项目为例进行说明。

4.1 初始Docker Compose文件结构

假设您的项目结构如下,并且 docker-compose.yml 中已定义了后端、前端和数据库服务:

# docker-compose.yml (初始部分)
version: '3.7'
services:
  frontend:
    container_name: "frontend"
    build:
      context: ./frontend
    stop_signal: SIGTERM
    ports:
      - "80:80" # 前端应用内部监听80端口,外部也暴露80端口(将被Nginx代理)
    volumes:
      - ./uploads:/app/uploads
    networks:
      - good_network
    depends_on:
      - backend

  backend:
    container_name: "backend"
    build:
      context: ./backend
    stop_signal: SIGTERM
    ports:
      - "8000:8000" # 后端应用内部监听8000端口,外部也暴露8000端口(将被Nginx代理)
    networks:
      - good_network
    volumes:
      - ./uploads:/app/uploads
    depends_on:
      - postgres

  postgres:
    container_name: "postgres"
    image: postgres:16.0
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -d sugar -U postgres" ]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 5s
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    networks:
      - good_network

networks:
  good_network:

volumes:
  postgres_data:

注意: 这里的 ports 配置是服务内部监听的端口,Nginx将通过内部网络访问这些端口。对于前端,我们让它监听80端口;对于后端,监听8000端口。

4.2 Nginx配置文件 (nginx.conf)

创建 nginx/nginx.conf 文件,用于配置Nginx的反向代理和SSL。我们将为前端和后端分别配置HTTP(端口80)和HTTPS(端口443)访问。

# nginx/nginx.conf
events {
  worker_connections 1024; # 定义Nginx worker进程可以同时处理的最大连接数
}

http {
    # 后端服务定义
    upstream back {
        # 'backend' 是docker-compose中后端服务的名称,Nginx将通过这个名称在内部网络中解析到后端容器
        # '8000' 是后端FastAPI应用监听的端口
        server backend:8000;
    }

    # 前端服务定义
    upstream front {
        # 'frontend' 是docker-compose中前端服务的名称
        # '80' 是前端React应用(例如由serve或类似的HTTP服务器提供)监听的端口
        server frontend:80;
    }

    # =======================================================
    # 后端API服务的Nginx配置 (back.mysite.ru)
    # =======================================================

    # HTTP (端口80) 配置 - 将所有HTTP请求重定向到HTTPS (可选,但推荐)
    server {
        listen 80;
        server_name back.mysite.ru; # 替换为你的后端子域名

        location / {
            # 将HTTP请求代理到后端服务
            proxy_pass http://back;
            # 设置必要的HTTP头,以便后端应用获取真实的客户端IP等信息
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto http; # 原始协议是HTTP
            # 如果需要强制HTTPS重定向,可以添加:
            # return 301 https://$host$request_uri;
        }
    }

    # HTTPS (端口443) 配置 - 处理加密请求并转发到后端
    server {
        listen 443 ssl;
        server_name back.mysite.ru; # 替换为你的后端子域名

        # SSL证书路径,这些路径将通过Docker卷挂载到Nginx容器中
        ssl_certificate /etc/letsencrypt/live/back.mysite.ru/fullchain.pem; # 完整的证书链
        ssl_certificate_key /etc/letsencrypt/live/back.mysite.ru/privkey.pem; # 私钥
        ssl_trusted_certificate /etc/letsencrypt/live/back.mysite.ru/chain.pem; # 信任链(可选,但推荐)

        # 推荐的SSL配置,增强安全性
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # HSTS

        location / {
            # 将HTTPS请求代理到后端服务
            proxy_pass http://back; # 注意这里依然是http://back,因为Nginx已经处理了SSL
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https; # 告诉后端原始协议是HTTPS
        }
    }

    # =======================================================
    # 前端Web服务的Nginx配置 (mysite.ru)
    # =======================================================

    # HTTP (端口80) 配置 - 将所有HTTP请求重定向到HTTPS
    server {
        listen 80;
        server_name mysite.ru; # 替换为你的主域名

        location / {
            # 强制重定向到HTTPS
            return 301 https://$host$request_uri;
            # 如果不重定向,直接代理:
            # proxy_pass http://front;
            # proxy_set_header Host $host;
            # proxy_set_header X-Real-IP $remote_addr;
            # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            # proxy_set_header X-Forwarded-Proto http;
        }
    }

    # HTTPS (端口443) 配置 - 处理加密请求并转发到前端
    server {
        listen 443 ssl;
        server_name mysite.ru; # 替换为你的主域名

        # SSL证书路径
        ssl_certificate /etc/letsencrypt/live/mysite.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/mysite.ru/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/mysite.ru/chain.pem;

        # 推荐的SSL配置
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

        location / {
            # 将HTTPS请求代理到前端服务
            proxy_pass http://front; # 注意这里依然是http://front
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https; # 告诉前端原始协议是HTTPS
        }
    }
}

4.3 Nginx Dockerfile (nginx/Dockerfile)

创建一个简单的 nginx/Dockerfile 来构建Nginx镜像,并将自定义的 nginx.conf 复制进去。

# nginx/Dockerfile
FROM nginx:latest # 基于官方Nginx镜像

# 将自定义的nginx.conf复制到容器的Nginx配置目录
COPY nginx.conf /etc/nginx/nginx.conf

4.4 更新Docker Compose文件

最后,将Nginx服务添加到您的 docker-compose.yml 文件中。

# docker-compose.yml (完整版)
version: '3.7'
services:
  frontend:
    container_name: "frontend"
    build:
      context: ./frontend
    stop_signal: SIGTERM
    # 注意:这里不再直接暴露80端口到宿主机,而是通过Nginx代理
    # ports:
    #   - "80:80"
    volumes:
      - ./uploads:/app/uploads
    networks:
      - good_network
    depends_on:
      - backend

  backend:
    container_name: "backend"
    build:
      context: ./backend
    stop_signal: SIGTERM
    # 注意:这里不再直接暴露8000端口到宿主机,而是通过Nginx代理
    # ports:
    #   - "8000:8000"
    networks:
      - good_network
    volumes:
      - ./uploads:/app/uploads
    depends_on:
      - postgres

  postgres:
    container_name: "postgres"
    image: postgres:16.0
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -d sugar -U postgres" ]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 5s
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    networks:
      - good_network

  nginx: # 新增Nginx服务
    build: ./nginx # 指定Nginx Dockerfile的构建上下文
    ports:
      - "80:80"   # Nginx监听宿主机的80端口
      - "443:443" # Nginx监听宿主机的443端口,用于HTTPS
    volumes:
      # 挂载宿主机的Certbot证书目录到Nginx容器内部,以便Nginx能访问证书文件
      - /etc/letsencrypt:/etc/letsencrypt:ro # 只读挂载
    networks:
      - good_network
    depends_on: # 确保Nginx在前端和后端服务启动后再启动
      - frontend
      - backend

networks:
  good_network:

volumes:
  postgres_data:

重要说明:

  • 在Nginx服务中,ports: - "443:443" 将宿主机的443端口映射到Nginx容器的443端口,使得外部请求可以通过HTTPS访问。
  • volumes: - /etc/letsencrypt:/etc/letsencrypt:ro 是关键一步,它将您的Certbot证书目录(通常位于 /etc/letsencrypt)以只读方式挂载到Nginx容器内部的相同路径,确保Nginx可以找到并使用证书。请确保您的宿主机上已通过Certbot获取了相应的证书。
  • depends_on: - frontend - backend 确保Nginx服务在前端和后端服务启动并可用之后才启动,避免Nginx尝试代理一个尚未运行的服务。

5. 启动与测试

完成上述配置后,在项目根目录运行:

docker-compose up --build -d

这将构建并启动所有服务。之后,您应该能够通过 https://mysite.ru 访问您的前端应用,并通过 https://back.mysite.ru 访问您的FastAPI后端API。

6. 注意事项与最佳实践

  • DNS解析: 确保您的域名 mysite.ru 和子域名 back.mysite.ru 都已正确配置DNS A记录,指向您的服务器IP地址。

  • 防火墙: 确保服务器的防火墙(如ufw或firewalld)允许80和443端口的入站连接。

  • CORS配置: 由于Nginx处理了SSL,FastAPI应用接收到的请求是HTTP。如果您的FastAPI应用需要处理CORS,请确保在FastAPI应用中配置CORS中间件,允许来自您前端域名的请求。例如:

    # main.py (FastAPI CORS配置示例)
    from fastapi import FastAPI
    from fastapi.middleware.cors import CORSMiddleware
    
    app = FastAPI()
    
    origins = [
        "http://localhost", # 开发环境
        "http://localhost:3000", # 开发环境
        "https://mysite.ru", # 您的前端域名
        # 如果需要,可以添加更多允许的源
    ]
    
    app.add_middleware(
        CORSMiddleware,
        allow_origins=origins,
        allow_credentials=True,
        allow_methods=["*"],
        allow_headers=["*"],
    )
    
    @app.get("/")
    async def read_root():
        return {"message": "Hello from FastAPI backend!"}
  • 证书自动续期: Certbot通常会设置cron作业或systemd timer来自动续期证书。确保此机制在您的宿主机上正常工作,以避免证书过期导致服务中断。

  • 日志: 监控Nginx和应用容器的日志,以便及时发现和解决问题。

  • 安全性: Nginx配置中的 ssl_protocols 和 ssl_ciphers 示例提供了较强的安全配置,您可以根据最新的安全建议进行调整。Strict-Transport-Security (HSTS) 头强制浏览器只通过HTTPS访问您的站点,进一步增强安全性。

7. 总结

通过将Nginx作为反向代理,我们成功地为FastAPI后端和React前端应用实现了SSL加密。这种架构不仅简化了应用层面的SSL管理,还提供了更高的性能、更好的可扩展性和更灵活的配置。遵循本教程的步骤,您可以在Docker容器化环境中安全、高效地部署您的Web应用。

本文内容来源于互联网,如有侵权请联系删除。
作者最新文章
编程开发
相关文章 更多
using namespace 使用中遇到的问题怎么解决
using namespace 使用中遇到的问题怎么解决

命名空间的基本概念与常见引入问题在C++等编程语言中,命名空间(namespace)是一种将代码标识符(如变量、函数、类名)封装在特定名称下的机制,其主要目的是避免命名冲突,尤其是在大型项目或使用多个第三方库时。使用“using namespace”指令可以将指定命名空间中的所有名称引入当前作用域,

c语言函数递归 实操经验总结:这些技巧很实用
c语言函数递归 实操经验总结:这些技巧很实用

理解递归的基本原理在C语言中,递归是一种函数调用自身的编程技术。要掌握它,首先需要理解其核心思想:将一个复杂的大问题,分解为一个或几个与原问题相似但规模更小的子问题,直到子问题足够简单,可以直接求解。这个过程通常包含两个关键部分:递归出口和递归体。递归出口定义了问题何时不再继续分解,即最简单、可直接

c语言函数递归 怎么选?常见方案对比分析
c语言函数递归 怎么选?常见方案对比分析

递归函数的基本概念与适用场景在C语言编程中,递归是一种函数调用自身的编程技巧。它并非适用于所有问题,但在处理某些具有自相似结构的问题时,能提供极其清晰和优雅的解决方案。递归的核心思想是将一个大规模问题分解为一个或多个同类型但规模更小的子问题,直到子问题简单到可以直接求解。典型的适用场景包括树形结构的

Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解
Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解

理解内存管理的基石在Objective-C的编程世界中,内存管理是开发者必须掌握的核心技能之一。它直接关系到应用的性能、稳定性与资源利用效率。与一些采用自动垃圾回收机制的语言不同,Objective-C在很长一段时间里,依赖一套基于引用计数的、需要开发者部分介入的管理规则。这套规则的核心思想是明确的

如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏
如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏

理解 dealloc 的角色与时机在 iOS 应用开发中,内存管理是保障应用性能与稳定性的基石。dealloc 方法是 Objective-C 中对象生命周期结束时的关键回调,它标志着对象即将被系统回收内存。正确理解其触发时机至关重要:当一个对象的引用计数降为零时,运行时系统会自动调用该对象的 de

深入理解 Objective-C 中的 dealloc 方法:内存管理核心机制
深入理解 Objective-C 中的 dealloc 方法:内存管理核心机制

内存管理的基石在Objective-C的世界里,内存管理是开发者必须掌握的核心技能之一。作为一门在手动引用计数(MRC)时代诞生的语言,Objective-C要求程序员对对象的生命周期有清晰的认识。dealloc方法正是这一生命周期中至关重要的终点站。它是一个实例方法,当对象的引用计数降为零时,系统

理解 native2ascii:Java 国际化开发中的字符编码工具
理解 native2ascii:Java 国际化开发中的字符编码工具

native2ascii 工具的基本定位在Ja va应用程序的国际化与本地化开发过程中,处理非拉丁字符集是一个常见且关键的环节。Ja va内部使用Unicode字符集来统一表示全球各种语言的文字,但其属性文件(.properties)在历史上要求使用ASCII编码,或者更准确地说,要求非ASCII字

如何使用 native2ascii 转换中文字符为 Unicode 转义序列
如何使用 native2ascii 转换中文字符为 Unicode 转义序列

理解 native2ascii 工具的基本用途在软件开发,特别是涉及国际化处理的场景中,开发者常常需要处理不同编码的文本资源。native2ascii 是 Ja va 开发工具包(JDK)中提供的一个命令行实用程序,其主要功能是将包含本地字符编码(非ASCII字符)的文件,转换为包含 Unicode

Java native2ascii 命令详解:解决属性文件乱码问题
Java native2ascii 命令详解:解决属性文件乱码问题

native2ascii 命令的由来与作用在Ja va开发中,处理国际化资源文件是一个常见需求。资源文件通常以.properties格式存储,用于支持多语言界面。然而,Ja va属性文件默认采用ISO-8859-1字符集编码,这导致了一个直接的问题:当文件中包含非拉丁字符(如中文、日文、韩文等)时,

一个 memwatch 实战案例:定位野指针问题
一个 memwatch 实战案例:定位野指针问题

内存监控工具的价值与挑战在软件开发,尤其是使用C/C++这类手动管理内存的语言时,内存错误是程序员最常遭遇的难题之一。其中,野指针问题因其隐蔽性和破坏性,往往成为最难定位的“幽灵”缺陷。它可能潜伏在代码中,在特定条件下才被触发,导致程序崩溃、数据损坏或难以预测的行为。传统的调试手段,如打印日志或使用

查看更多
精品专题 更多
装机必备
装机必备

正软商城装机必备专区,精选办公、浏览器、安全防护、影音播放、压缩解压、设计创作和系统工具等电脑常用正版软件,帮助用户快速完成新电脑软件配置。

Windows
Windows

正软商城Windows软件专区,汇集适用于Windows电脑的办公、设计、安全防护、影音播放、开发工具和系统优化软件,提供软件介绍、系统要求、正版授权及购买下载服务。

macOS软件
macOS软件

正软商城macOS软件专区,精选适用于Mac电脑的办公、设计、影音、效率、开发和系统工具,提供软件功能介绍、macOS兼容版本、正版授权及购买下载服务。

Mac软件 更多
灵活计算器
灵活计算器
macOS/iOS/Android

灵活计算器是一款笔记式算数应用,支持实时计算、动态关联和云端同步功能。记录、整理和输出之间的过渡会更自然,适合长期写作、做笔记或持续沉淀个人内容。

赤友清理大师
赤友清理大师
macOS

赤友清理大师是一款为 Mac 设计的智能清理优化工具,可精准扫描垃圾、大文件、重复文件等,释放磁盘空间。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

极度公式
极度公式
Windows/macOS/Linux

极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

WINDOWS 更多
Windows 10
Windows 10
Windows

Windows 10 是一款微软推出的经典操作系统,拥有硬件兼容性与多任务处理能力。它更偏向把系统状态查看和常用调节动作放在一起,适合需要持续观察和微调设备状态的场景。

极度公式
极度公式
Windows/macOS/Linux

极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

密码键盘
密码键盘
Windows/macOS/iOS/Android

密码键盘是一款兼具安全性与便捷性的高效密码管理器。日常使用里的持续防护和信息管理会更突出,适合把安全控制放进长期使用流程中的场景。