运维123 - 负载均衡
type: channel
link: https://www.sddts.cn/index.php/category/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/
items: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
items: Frontail Web日志实时流式工具技术分析
items: Octopus LLM API 聚合服务技术分析
items: gpt-load 企业级多渠道大模型 API 管理平台技术分析
items: Nginx + LVS + Keepalived 百万并发架构实战技术分析
items: Patroni + HAProxy + Keepalived + watchdog + ETCD PostgreSQL 高可用集群架构分析
items: 自建CA 手动生成rsa1024的证书并配置nginx实现嵌入式设备ssl加密
items: 配置nginx for一些验证的场景
items: nginx配置wss
items: nginx server 一般配置

Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析
type: item
date: 2026-01-18T00:11:25+00:00
description: Bonding 双活模式：Balance-tlb 与 Balance-alb 技术分析一、概述1. 背景在上一篇文章中讨论了 active-backup 模式，能够在一张网卡出现故障时快速切换，配置简单。但这种方式存在明显缺点——虽然有两张网卡，但同一时间只能使用一张，只有当主网卡挂了才会使用备网卡。2. 核心问题在高可用设计中，双活优于主备，主备意味着浪费。用户希望实现两张网卡都在工作，当其中一张网卡挂了时，退回到单网卡模式。3. 解决方案Linux Bonding 驱动提供了两种双活模式：Balance-tlb（Adaptive transmit load balancing，模式 5）：发送负载均衡Balance-alb（Adaptive load balancing，模式 6）：收发双向负载均衡二、Balance-tlb 模式1. 工作原理A. 发送方向假设两张网卡都要发送数据，需要解决 MAC flapping 问题——如果同一个 MAC 地址一会从端口 1 发出，一会从端口 2 发出，交换机通过收到的包学习 MAC 地址会感到困惑。因此，两个 interface 必须使用不同的 MAC 地址。对于发送流量，可以使用两个 interface 来发送，交换机看起来就像是两个不同的主机。B. 接收方向对于接收流量，只能用一个 interface 来接收。实现方式是：在回应 ARP 请求时，总是使用其中一个 interface 的 MAC 地址来回复。graph LR subgraph 服务器 B0[bond0 IP: 192.168.1.10 主MAC: 1a:50:9c:11:58:a3] E0[eth0 MAC: 1a:50:9c:11:58:a3 主接口: 收+发] E1[eth1 MAC: 9e:fa:f1:b5:0c:28 备接口: 仅发] B0 --> E0 B0 --> E1 end C1[客户端1] -->|目标MAC: 1a:50| SW[交换机] C2[客户端2] -->|目标MAC: 1a:50| SW SW --> E0 SW --> E1 E0 -->|源MAC: 1a:50| SW E1 -->|源MAC: 9e:fa| SW SW --> C1 SW --> C22. 流量特征对于发送流量：使用两个 interface 发送数据通过 hash 机制保证同一个 TCP 流总是走同一个 interface，避免 reorder 问题实际上会根据两张卡的负载动态调整使用哪张卡对于接收流量：由于其他客户端只知道 IP 对应一个网卡的 MAC 地址，入流量总是走到其中一个 interface 上从交换机视角看，有一个主机的 MAC 地址只会发出去包，但从来没有其他人发给这个 MAC3. 适用场景虽然只是发送流量可以使用两张卡，但对于面向客户的服务器来说：进入服务器的流量较少（请求一般比较小）从服务器出去的流量较多（响应一般很大）对于短视频服务器、流媒体、HTTP 服务器等，这种方案可以有效解决性能问题。三、Balance-tlb 故障切换流程1. 角色定义主接口：接收流量的 interface备接口：不接受流量、只发送的 interface2. 故障场景A. 备接口故障接收端不受影响发送端切换到只用主接口发送B. 主接口故障发送端切换到只使用备接口发送接收端流量也要切换到备接口3. 快速切换机制接收端流量的切换需要让发送流量的地方来切换。直观思路是切换 ARP，但 ARP 太慢，在 ARP 更新到发送者之前，流量会因发送到挂掉的 MAC 地址而被丢弃。更好的解决办法是让交换机来切换：发送者的流量发送给交换机，交换机再发送给服务器客户端的目标 MAC 地址不能变，但交换机转发的端口改变这与 active-backup 中讨论的 Gratuitous ARP 类似4. MAC 地址交换机制Balance-tlb 模式需要硬件支持改写 MAC 地址。切换过程需要保持主 MAC 地址总是可用，以不影响 ARP 缓存，实现快速切换：sequenceDiagram participant C as 客户端 participant SW as 交换机 participant E0 as eth0 (主: 1a:50) participant E1 as eth1 (备: 9e:fa) Note over C,E1: 正常状态 C->>SW: 发送至 MAC: 1a:50 SW->>E0: 从端口1转发 E0->>SW: 发送 (源MAC: 1a:50) E1->>SW: 发送 (源MAC: 9e:fa) Note over C,E1: 主接口故障 E0--xE0: 故障 E1->>E1: MAC交换 eth1: 1…

Frontail Web日志实时流式工具技术分析
type: item
date: 2026-01-17T15:57:01+00:00
description: Frontail Web日志实时流式工具技术分析一、概述1. 简介A. 是什么Frontail 是一个基于 Node.js 开发的日志实时流式传输工具，将传统的 tail -F 命令功能带入了 Web 浏览器。它通过 WebSocket 技术实现日志文件的实时推送，让开发者可以在浏览器界面中实时查看服务器日志，无需通过终端访问。B. 为什么学解决远程日志查看问题，无需 SSH 登录即可监控日志提供友好的 Web UI 界面，支持搜索和高亮显示支持多文件同时监控，适合微服务架构可以集成到现有 Web 基础设施中，与 Nginx 等反向代理配合使用C. 学完能做什么快速搭建日志监控 Web 服务配置基于 Basic Auth 的日志访问控制集成 HTTPS 加密传输自定义日志高亮规则通过 Nginx 反向代理嵌入现有系统2. 前置知识A. 必备技能基本的 Linux 命令行操作了解 tail -F 命令的基本用法Node.js 环境配置B. 推荐知识WebSocket 通信原理Nginx 反向代理配置HTTP 基本认证机制二、环境准备1. 系统要求Node.js 12.x 或更高版本npm 或 yarn 包管理器Linux/Unix/macOS/Windows 操作系统2. 安装步骤全局安装：npm install frontail -g本地安装：npm install frontail --save-dev3. 验证安装frontail --version三、核心概念1. 基本术语WebSocket：全双工通信协议，用于服务器主动推送日志tail -F：持续跟踪文件增长，即使文件被轮转也能继续监控Basic Auth：HTTP 基本认证，用于保护日志访问Daemon：后台进程模式，将 frontail 作为守护进程运行2. 工作原理graph LR A[日志文件] -->|tail -F| B[Frontail 服务] B -->|WebSocket| C[浏览器] C -->|搜索/过滤| B D[配置文件] -->|高亮规则| B E[Nginx] -->|反向代理| B三、核心架构1. 系统组成graph TB subgraph 前端层 A[Web UI] B[WebSocket 客户端] C[搜索过滤] end subgraph 服务层 D[Node.js 服务] E[文件监控模块] F[WebSocket 服务] G[认证模块] end subgraph 数据层 H[日志文件] I[配置文件] end A --> B B --> F F --> E E --> H G --> I四、快速上手1. Hello World 示例# 监控单个日志文件 frontail /var/log/nginx/access.log # 访问 http://localhost:90012. 核心功能演示# 监控多个文件 frontail /var/log/app/*.log # 指定端口和主机 frontail -h 0.0.0.0 -p 8080 /var/log/syslog # 启用高亮 frontail --ui-highlight /var/log/app.log3. 代码讲解Frontail 内部使用 Node.js 的 fs.watch() API 监控文件变化，通过 WebSocket 将新增的日志行实时推送到浏览器。前端使用纯 JavaScript 渲染日志流，支持自动滚动和搜索功能。五、功能详解1. 命令行参数A. 基础参数参数说明默认值-h, --host监听地址0.0.0.0-p, --port监听端口9001-n, --number启动时显示的行数10-l, --lines浏览器中存储的行数2000B. 安全参数参数说明-U, --userBasic Auth 用户名-P, --passwordBasic Auth 密码-k, --keyHTTPS 私钥文件-c, --certificateHTTPS 证书文件C. UI 参数参数说明-t, --theme主题（default、dark）--ui-hide-topbar隐藏顶部栏--ui-no-indent取消缩进--ui-highlight启用高亮--ui-highlight-preset自定义高亮规则文件D. 运行模式参数说明-d, --daemonize后台运行--pid-pathPID 文件路径--log-path日志文件路径--url-pathURL 路径前缀2. 高亮配置默认高亮规则（preset/default.json）：{ "words": { "err": "color: red;", "warn": "color: orange;" }, "…

Octopus LLM API 聚合服务技术分析
type: item
date: 2026-01-16T06:59:47+00:00
description: Octopus LLM API 聚合服务技术分析一、新闻概述1. 标题Octopus：为个人打造的 LLM API 聚合与负载均衡服务2. 发布时间2025 年 1 月 16 日3. 来源GitHub 开源项目二、核心内容1. 事件摘要A. 主要内容Octopus 是一个面向个人用户的 LLM API 聚合服务项目，旨在通过统一入口管理多个 LLM 提供商的 API，实现智能负载均衡和成本优化。B. 核心亮点多渠道聚合：统一管理多个 LLM 提供商通道智能负载均衡：支持轮询、随机、故障转移、加权等多种模式协议转换：无缝转换 OpenAI Chat、OpenAI Responses、Anthropic API 格式自动同步：模型列表和价格信息自动更新优雅 UI：简洁美观的 Web 管理面板2. 关键信息A. 技术栈后端：Go 1.24.4前端：Next.js + pnpm数据库：SQLite、MySQL、PostgreSQLB. 部署方式Docker 容器化部署二进制文件直接运行源码编译C. 默认配置服务端口：8080默认账号：admin/admin数据存储：/app/data3. 背景介绍A. 项目起源随着 LLM 服务提供商日益增多，个人用户面临管理多个 API Key、分散调用、成本统计困难等问题。Octopus 应运而生，提供统一的 API 聚合解决方案。B. 相关上下文项目借鉴了 axonhub 的 LLM API 适配模块设计，并整合了 models.dev 的 AI 模型数据库用于价格信息同步。三、详细报道1. 主要内容A. 功能特性渠道管理：支持单通道多 API Key 配置每个通道支持多个端点，智能选择延迟最短的端点自动根据通道类型追加 API 路径分组管理：将多个通道聚合为统一的对外模型名称调用时设置 model 参数为分组名称即可访问所有通道支持多种负载均衡模式负载均衡模式：轮询模式：按顺序依次分配请求到各通道随机模式：随机选择可用通道故障转移：优先使用高优先级通道，失败时切换到低优先级通道加权模式：根据配置的通道权重分配请求B. 技术改进协议转换：OpenAI Chat 格式OpenAI Responses 格式Anthropic Messages 格式Gemini Generate Content 格式自动同步：定期从 models.dev 同步模型定价数据创建通道时自动同步可用模型列表自动创建未知模型的定价信息C. 统计分析综合请求统计Token 消耗统计成本跟踪定期批量写入数据库（性能优化策略）2. 技术细节A. 系统架构graph TB Client[客户端应用] --> Octopus[Octopus API 网关] Octopus --> LoadBalancer[负载均衡器] LoadBalancer --> Channel1[通道 1] LoadBalancer --> Channel2[通道 2] LoadBalancer --> Channel3[通道 3] Channel1 --> Provider1[提供商 1] Channel2 --> Provider2[提供商 2] Channel3 --> Provider3[提供商 3] Octopus --> Database[(数据库)] Octopus --> PriceSync[价格同步] PriceSync --> ModelsDev[models.dev]B. 数据流程sequenceDiagram participant C as 客户端 participant O as Octopus participant LB as 负载均衡 participant P as LLM 提供商 participant D as 数据库 C->>O: API 请求（model=分组名） O->>LB: 负载均衡选择 LB->>O: 返回选定通道 O->>P: 转发请求（协议转换） P-->>O: 返回响应 O-->>C: 返回结果 O->>D: 异步记录统计C. 配置架构graph LR Config[配置文件] --> Server[服务器配置] Config --> Database[数据库配置] Config --> Log[日志配置] Database --> SQLite[SQLite] Database --> MySQL[MySQL] Database --> PostgreSQL[PostgreSQL]3. 数据与事实A. 支持的 LLM 提供商OpenAI（Chat Completions、Responses）Anthropic（Claude）Google（Gemini）其他兼容 OpenAI 格式的提供商B. 数据库支…

gpt-load 企业级多渠道大模型 API 管理平台技术分析
type: item
date: 2026-01-16T01:48:52+00:00
description: gpt-load 企业级多渠道大模型 API 管理平台技术分析一、平台概述1. 简介gpt-load 是一款基于 Go 语言开发的企业级多渠道大模型 API 管理平台，专为需要集成多种 AI 服务的企业和开发者设计。它作为透明代理服务，完整保留了各 AI 服务商的原生 API 格式，支持智能密钥管理、负载均衡、故障切换和水平扩展，内置 Web 管理界面，提供高效、稳定的多 AI 服务集成管理方案。2. 核心定位企业级 AI 服务聚合中间件，解决多 AI 服务商接入、密钥管理、负载均衡等痛点问题。3. 设计目标简化 AI 服务集成复杂度，提供统一接入层，降低企业使用多种大模型的技术门槛和运维成本。二、核心功能特性1. 透明代理完全保留 OpenAI、Google Gemini 和 Anthropic Claude 等原生 API 格式，无需修改客户端代码即可无缝迁移。支持官方 OpenAI API、Azure OpenAI 以及其他 OpenAI 兼容服务。支持 Gemini Pro、Gemini Pro Vision 等模型的原生 API。支持 Claude 系列模型，支持高质量的对话和文本生成。2. 智能密钥管理支持密钥分组管理、自动轮换和故障恢复，提升密钥可用性与安全性。提供高性能密钥池，确保在高并发场景下密钥的稳定使用。3. 负载均衡支持多上游端点加权负载均衡，优化请求分发，提高服务整体可用性。自动管理密钥黑名单及恢复机制，减少因密钥失效导致的请求失败。4. 动态配置与热重载系统设置和分组配置支持热重载，修改后无需重启即可生效，提升运维效率。分组配置优先级高于系统设置，满足不同场景下的定制化需求。5. 企业级架构支持分布式主从部署和水平扩展，满足高并发场景下的性能需求。提供全面的监控功能，包括实时统计、健康检查和详细请求日志，便于问题排查与系统优化。6. 现代化管理与安全基于 Vue 3 的 Web 管理界面，直观易用，提升管理效率。管理端与代理端认证分离，支持全局和分组级别代理密钥，强化权限管控。提供优雅关闭、错误恢复和完善的安全机制，确保服务稳定运行。三、系统架构1. 架构设计graph TB subgraph 客户端层 A1[OpenAI 客户端] A2[Gemini 客户端] A3[Claude 客户端] end subgraph gpt-load 代理层 B1[API 网关] B2[认证模块] B3[负载均衡器] B4[密钥管理器] B5[健康检查] B6[配置中心] B7[Web 管理界面] end subgraph 上游服务层 C1[OpenAI API] C2[Azure OpenAI] C3[Gemini API] C4[Claude API] C5[其他兼容服务] end subgraph 数据存储层 D1[(MySQL/PostgreSQL)] D2[(SQLite)] D3[Redis 可选] end A1 --> B1 A2 --> B1 A3 --> B1 B1 --> B2 B2 --> B3 B3 --> B4 B4 --> C1 B4 --> C2 B4 --> C3 B4 --> C4 B4 --> C5 B3 --> B5 B5 --> B4 B7 --> B6 B6 --> B4 B6 --> D1 B6 --> D2 B6 --> D32. 请求处理流程sequenceDiagram participant C as 客户端 participant G as gpt-load 网关 participant A as 认证模块 participant L as 负载均衡器 participant K as 密钥管理器 participant P as 上游 AI 服务 C->>G: 发起 API 请求 G->>A: 验证代理密钥 A-->>G: 认证通过 G->>L: 获取可用端点 L->>K: 请求密钥 K-->>L: 返回健康密钥 L->>P: 转发请求 P-->>L: 返回响应 L-->>G: 转发响应 G-->>C: 返回结果3. 密钥管理机制graph LR subgraph 密钥池 A[密钥组 1] B[密钥组 2] C[密钥组 3] end subgraph 密钥状态 D[活跃密钥] E[冷却密钥] F[黑名单密钥] end subgraph 密钥操作 G[自动轮换] H[故障恢复] I[健康检查] end A --> D B --> D C --> D D --> E E --> D D --> F F --> H H --> D I --> D G --> D四、部署与安装1. 环境准备确保服务器已安装 Docker 和 Docker Compose。准备数据库（…

Nginx + LVS + Keepalived 百万并发架构实战技术分析
type: item
date: 2026-01-15T12:13:25+00:00
description: Nginx + LVS + Keepalived 百万并发架构实战技术分析一、新闻概述1. 标题百万并发架构实战：Nginx + LVS + Keepalived 架构2. 发布时间2025 年 1 月 15 日（资料整理）3. 来源架构师陈哥（微信公众号）二、核心内容1. 事件摘要A. 主要内容本文详细介绍了 Nginx + LVS + Keepalived 三层负载均衡架构，该架构是支撑百万级并发访问的主流解决方案。B. 核心亮点三层架构设计：LVS（四层）+ Nginx（七层）+ 业务集群高性能：LVS 运行在内核态，可支撑百万级并发连接高可用：Keepalived 提供主备切换和健康检查灵活性：Nginx 提供丰富的七层路由功能2. 关键信息A. 涉及技术LVS（Linux Virtual Server）NginxKeepalivedVRRP 协议DR 模式（Direct Routing）B. 性能指标LVS 可支撑数十万甚至上百万并发连接适用于互联网业务快速发展的场景3. 背景介绍A. 技术需求在互联网业务快速发展的大背景下，支撑百万并发访问成为大型网站和分布式应用设计的关键目标。B. 解决方案Nginx + LVS + Keepalived 架构以其高性能、可扩展性和高可用性，成为常见的解决方案。三、详细报道1. 架构概述A. 整体架构graph TD Client[客户端] -->|请求| LVS[LVS 四层负载均衡] LVS -->|转发| Nginx1[Nginx 七层代理 1] LVS -->|转发| Nginx2[Nginx 七层代理 2] Nginx1 -->|HTTP路由| App1[业务服务器1] Nginx1 -->|HTTP路由| App2[业务服务器2] Nginx2 -->|HTTP路由| App3[业务服务器3] Nginx2 -->|HTTP路由| App4[业务服务器4]B. 架构分层客户端 ↓ LVS（四层负载，抗并发） ↓ Nginx（七层负载，协议处理） ↓ 业务集群2. LVS 负载入口A. 技术特点LVS（Linux Virtual Server）是四层负载均衡解决方案，运行在内核态。核心优势：性能极高：运行在内核态，零拷贝技术抗并发能力强：轻松支撑数十万甚至上百万并发连接只负责转发：不解析 HTTP 协议内容，仅处理 TCP/UDP 数据包B. 工作模式LVS 支持多种工作模式，本文主要介绍 DR 模式（Direct Routing）：DR 模式特点：请求经过 LVS，响应不经过 LVS真实服务器直接响应客户端性能最优，要求 LVS 和服务器在同一物理网络C. LVS Director 架构graph TB subgraph "LVS Director 集群" LVSMaster[LVS Master 主节点] LVSSlave[LVS Slave 备节点] end subgraph "Keepalived 管理" VRRP[VRRP 协议 VIP 管理] Health[健康检查] end subgraph "ipvsadm 规则" Rules[DR 模式 负载均衡规则] end LVSMaster --> VRRP LVSSlave --> VRRP VRRP --> Rules Health --> LVSMaster Health --> LVSSlave3. Keepalived 高可用保障A. 核心功能Keepalived 是 LVS 集群的高可用保障组件。主要功能：VIP（Virtual IP）管理：通过 VRRP 协议实现虚拟 IP 漂移主备切换：当主节点故障时，备节点自动接管 VIP健康检查：自动检测后端节点状态，剔除异常节点B. VRRP 协议VRRP（Virtual Router Redundancy Protocol）是虚拟路由器冗余协议。工作原理：主节点定期发送 VRRP 广播备节点监听广播主节点故障时，备节点根据优先级接管 VIP客户端始终通过 VIP 访问服务C. 故障切换流程sequenceDiagram participant C as 客户端 participant VIP as 虚拟IP (VIP) participant M as LVS Master participant S as LVS Slave C->>VIP: 正常访问 VIP->>M: 转发请求 M->>C: 返回响应 Note over M: 主节点故障 S->>VIP: 检测到主节点故障 S->>VIP: 接管 VIP VIP->>S: VIP 绑定到备节点 C->>VIP: 继续访问 VIP->>S: 转发请求 S->>C: 返回响应4. Nginx 七层反向代理…

Patroni + HAProxy + Keepalived + watchdog + ETCD PostgreSQL 高可用集群架构分析
type: item
date: 2026-01-15T11:07:25+00:00
description: Patroni + HAProxy + Keepalived + watchdog + ETCD PostgreSQL 高可用集群架构分析一、背景与目标1. 项目背景A. 业务场景PostgreSQL 作为主流开源关系型数据库，在企业核心业务系统中扮演着关键角色。传统单节点部署存在单点故障风险，主从复制方案在主节点故障时需要手动切换，影响业务连续性。B. 痛点分析单点故障：主节点宕机导致服务中断手动切换：故障恢复需要人工介入，耗时长脑裂风险：网络分区可能导致多主节点数据一致性问题：主备切换时数据可能丢失2. 设计目标A. 功能目标实现自动故障检测与切换保障数据一致性和完整性提供读写分离能力B. 非功能目标高可用性：99.99% 以上故障切换时间：毫秒级业务无感知：透明切换防止脑裂：分布式共识保障二、总体架构1. 设计原则分层架构：客户端应用层、负载均衡层、数据库集群层、分布式一致性层自动化运维：故障自动检测、自动切换、自动恢复防止脑裂：基于分布式共识的选举机制读写分离：智能路由优化性能2. 系统架构graph TB Client[客户端应用层] --> VIP[虚拟 IP 192.168.231.140] VIP -->|VRRP 协议| Keep1[Keepalived Master] VIP -->|VRRP 协议| Keep2[Keepalived Backup] Keep1 --> HA1[HAProxy 主节点] Keep2 --> HA2[HAProxy 备节点] HA1 -->|读写分离| Patroni1[Patroni Leader] HA1 -->|只读| Patroni2[Patroni Follower] HA1 -->|只读| Patroni3[Patroni Follower] HA2 --> Patroni1 HA2 --> Patroni2 HA2 --> Patroni3 Patroni1 --> PG1[(PostgreSQL 主节点)] Patroni2 --> PG2[(PostgreSQL 备节点)] Patroni3 --> PG3[(PostgreSQL 备节点)] Patroni1 -.分布式共识.-> ETCD1[(ETCD 节点 1)] Patroni2 -.分布式共识.-> ETCD2[(ETCD 节点 2)] Patroni3 -.分布式共识.-> ETCD3[(ETCD 节点 3)] WD1[Watchdog 监控] -.心跳检测.-> Patroni1 WD2[Watchdog 监控] -.心跳检测.-> Patroni2 WD3[Watchdog 监控] -.心跳检测.-> Patroni33. 组件说明客户端应用层：业务系统通过统一 VIP 访问，对底层架构无感知负载均衡层：HAProxy + Keepalived 实现智能路由和负载均衡层高可用数据库集群层：PostgreSQL + Patroni 实现数据高可用和自动故障转移分布式一致性层：ETCD 集群提供强一致性保障，防止脑裂进程监控层：Watchdog 监控 Patroni 进程状态，异常时强制重启三、负载均衡层设计1. HAProxy 组件A. 组件职责HAProxy（High Availability Proxy）是开源高性能代理软件，在架构中负责：接收客户端连接请求根据 PostgreSQL 节点角色进行读写分离路由执行健康检查，自动剔除故障节点实现负载均衡，优化资源利用B. 核心架构graph LR Client[客户端请求] --> Frontend[Frontend 前端处理] Frontend --> LB[Load Balancer 负载均衡] LB --> Backend[Backend 后端管理] Backend --> HC[Health Checker 健康检查] Backend --> CM[Connection Manager 连接管理] Backend --> Server1[(PostgreSQL 主节点)] Backend --> Server2[(PostgreSQL 备节点 1)] Backend --> Server3[(PostgreSQL 备节点 2)] HC -->|健康检查| Server1 HC -->|健康检查| Server2 HC -->|健康检查| Server3 CM --> SE[Statistics Engine 统计引擎]C. 请求处理流程sequenceDiagram participant C as 客户端 participant H as HAProxy participant P as Patroni/PostgreSQL C->>…

自建CA 手动生成rsa1024的证书并配置nginx实现嵌入式设备ssl加密
type: item
date: 2024-05-09T02:43:00+00:00
description: 一、自建证书+nginx ssl配置使用openssl创建rsa1024根证书，并签发*.example.cn 30年有效期证书要使用 OpenSSL 创建一个 RSA 1024 位的根证书，并签发一个包含通配符的域名证书，可以按照以下步骤进行：（1）创建 RSA 1024 位的根证书（Root CA）：生成根密钥（私钥）：openssl genrsa -out root.key 1024生成自签名的根证书（公钥）：openssl req -x509 -new -nodes -key root.key -days 10950 -out root.crt在证书请求期间，填写相关证书信息。10950 天是根证书的有效期，约合30年。（2）创建通配符域名证书（Wildcard Certificate）：生成域名私钥：openssl genrsa -out domain.key 1024生成域名证书签名请求（CSR）：openssl req -new -key domain.key -out domain.csr在证书请求期间，填写通配符域名 *.example.cn 作为 Common Name (CN)。使用根证书签署域名证书：openssl x509 -req -in domain.csr -CA root.crt -CAkey root.key -CAcreateserial -out domain.crt -days 10950现在，您已经创建了包含通配符域名的证书 domain.crt，其有效期为30年，同时也拥有一个根证书 root.crt 用于签署该域名证书。确保在真实环境中使用更强大的密钥长度和更合适的证书有效期。此外，在生产环境中建议谨慎保管您的私钥和根证书，以防止密钥泄露或篡改。（3）如何调整nginx以允许rsa 1024的证书server { listen 192.168.23.225:3001 ssl; server_name example.cn; access_log /var/log/nginx/example.cn.a.log main; error_log /var/log/nginx/example.e.log; ssl_certificate /etc/nginx/cert.d/test/example.cn.crt; ssl_certificate_key /etc/nginx/cert.d/test/example.cn.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:AES128-SHA:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE; ssl_prefer_server_ciphers on; location / { proxy_pass http://example; proxy_set_header Host $host; proxy_http_version 1.1; proxy_read_timeout 120s; proxy_set_header X-real-ip $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 二、TCP后端+Nginx Stream做完上面的配置后，后端是不通的，询问同事后端跑的啥业务，测试不通过，心底没底。后来得知，后端直接是TCP协议，用于接收物联网设备的数据。具体说，这个TCP已经实现了端到端AES对称加密，但是用户还想用SSL来一层非对称加密。而且指明了使用RSA 1024。然后，同事还给了一个方案，通过使用Nginx的Stream模块，加上SSL证书实现安全通信。这个吗，听说过stream作为TCP负载均衡，还真没听说过这个里面还有SSL。不过，经过搜索，还真有，而且在官网也看到了相关资料。走运的是，本来以为还得下载编译nginx模块，没想到直接带了。nginx version: nginx/1.22.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/…

配置nginx for一些验证的场景
type: item
date: 2024-04-19T07:56:00+00:00
description: 在一些认证网站域名所主的时候，经常会要求在网站根目录下面放置一个特殊的txt文件。但是，有些时候网站是一个反向代理，可以通过如下一个简单的小技巧实现这种验证需求。location /N7dcmP1dsD.txt { return 200 "7eb1d5db3520bd7c8ebbf3a0dc55c06e"; }假设对方让把一个文件名称为N7dcmP1dsD.txt，内容为7eb1d5db3520bd7c8ebbf3a0dc55c06e的文件放在网站根目录下。那么，我们可以在nginx里面的server配置里面，通过增加location的形式增加内容。

nginx配置wss
type: item
date: 2024-04-16T02:48:00+00:00
description: 一、背景公司接了一个项目，其中一个模块使用websocket连接，但是配置过后还是不行。经过排查，最终实现了websocket的配置和验证。配置中需要注意的是：配置nginx的时候，注意是否配置了证书，以及证书是否正确。使用curl 后端程序+websocket端口+websocket路径是否正确。使用postman或者在线测试是否工作正常。二、拓扑2024-04-16T02:44:41.png（1）nginxupstream ws-xxx { server 127.0.0.1:7003 weight=2 max_fails=3 fail_timeout=20s; } map $http_upgrade $conn_upgrade { default upgrade; '' close; } server { listen 80; server_name xxx; access_log /var/log/nginx/xxx.a.log main; error_log /var/log/nginx/xxx.e.log; location /ngx_status { stub_status on; access_log off; } location / { proxy_passhttp://xxx; proxy_redirect off; proxy_set_headerHost $host; proxy_set_headerX-real-ip $remote_addr; proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for; } } server { listen xxx ssl; server_name xxx; access_log /var/log/nginx/xxx main; error_log /var/log/nginx/xxxe.log; ssl_certificate /etc/nginx/cert.d/xxx; ssl_certificate_key /etc/nginx/cert.d/xxx; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE; ssl_prefer_server_ciphers on; location / { proxy_passhttp://xxx; proxy_set_header Host $host; proxy_http_version 1.1; proxy_read_timeout 120s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header X-real-ip $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; add_header Set-Cookie "Path=/; HttpOnly; Secure"; if ($request_uri ~* "css$|js$|png$|jpg$") { add_header Cache-Control max-age=86400; } } location /ws { proxy_pass http://xxx; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connetion $conn_upgrade; } } （2）后端程序使用curl本地测试后端服务程序正常。[root@xxx-test]# curl 192.168.177.66:2301/ws not a WebSocket handshake request: missing upgrade （3）frpc使用frpc打通内网websocket端口到带有公网ip地址的公网服务器。serverAddr = "xxx" serverPort = 7000 proxies name = "user-comet" type = "tcp" localIP = "192.168.177.66" localPort = 2301 remotePort = 7003 其他在线ng…

nginx server 一般配置
type: item
date: 2024-02-22T08:08:00+00:00
description: server { listen 80 default_server; listen 443 ssl http2 default_server; server_name www.sddts.cn sddts.cn; index index.php index.html index.htm default.php default.htm default.html; root /www/wwwroot/www.sddts.cn; ssl_certificate /www/server/panel/vhost/cert/www.sddts.cn/fullchain.pem; ssl_certificate_key /www/server/panel/vhost/cert/www.sddts.cn/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; add_header Strict-Transport-Security "max-age=31536000"; error_page 497 https://$host$request_uri; #清理缓存规则 location ~ /purge(/.*) { proxy_cache_purge cache_one $host$1$is_args$args; #access_log /www/wwwlogs/www.sddts.cn_purge_cache.log; } #PROXY-START/ location ^~ / { proxy_pass http://172.18.19.31; 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 REMOTE-HOST $remote_addr; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_http_version 1.1; # proxy_hide_header Upgrade; add_header X-Cache $upstream_cache_status; #Set Nginx Cache set $static_file4w7i7J04 0; if ( $uri ~* "\.(gif|png|jpg|css|js|woff|woff2)$" ) { set $static_file4w7i7J04 1; expires 1m; } if ( $static_file4w7i7J04 = 0 ) { add_header Cache-Control no-cache; } } #禁止访问的文件或目录 location ~ ^/(\.user.ini|\.htaccess|\.git|\.env|\.svn|\.project|LICENSE|README.md) { return 404; } #一键申请SSL证书验证目录相关设置 location ~ \.well-known{ allow all; } access_log /www/wwwlogs/www.sddts.cn.log; error_log /www/wwwlogs/www.sddts.cn.error.log; }