跳至主要内容

云服务器(Linux + Nginx)网站服务器优化配置指南


## 一、Linux系统层优化


### 1. 安全基础配置

- **系统更新**:定期执行 `sudo apt update && sudo apt upgrade`(Debian系)或 `sudo dnf update`(RHEL系),保持内核与软件包最新。

- **防火墙**:仅开放必要端口(22/SSH、80/HTTP、443/HTTPS)。  

  Ubuntu:`sudo ufw allow 22,80,443/tcp && sudo ufw enable`  

  RHEL系:`sudo firewall-cmd --permanent --add-service={ssh,http,https} && sudo firewall-cmd --reload`

- **SSH加固**:  

  - 修改默认端口(`/etc/ssh/sshd_config` 中 `Port`)  

  - 禁用root登录(`PermitRootLogin no`)  

  - 启用密钥认证(`PasswordAuthentication no`)  

  - 配置Fail2ban防止暴力破解

- **专用服务账户**:创建非root用户(如 `www-data`)运行Nginx,遵循最小权限原则。


### 2. 内核与资源调优(`/etc/sysctl.conf`)

```conf

# 网络连接优化

net.core.somaxconn = 65535

net.ipv4.tcp_max_syn_backlog = 65535

net.core.netdev_max_backlog = 65535

net.ipv4.ip_local_port_range = 1024 65535

net.ipv4.tcp_fin_timeout = 30

# 注:tcp_tw_reuse 需谨慎使用(仅适用于客户端连接场景,服务器端建议结合业务评估)

```

生效命令:`sudo sysctl -p`  

文件描述符限制:  

- `/etc/security/limits.conf` 添加:  

  `* soft nofile 65535`  

  `* hard nofile 65535`  

- 重启会话后验证:`ulimit -n`


### 3. 运维增强

- **时间同步**:部署 `chrony` 或 `systemd-timesyncd`,确保日志与证书时效准确。

- **日志管理**:配置 `logrotate`(`/etc/logrotate.d/nginx`),避免磁盘占满。

- **SELinux/AppArmor**:建议保留并配置策略(如 `audit2allow` 生成规则),而非直接禁用。


---


## 二、Nginx应用层优化


### 1. 核心性能配置(`nginx.conf`)

```nginx

user www-data;  # 与系统创建的专用用户一致

worker_processes auto;  # 匹配CPU核心数

worker_rlimit_nofile 65535;  # 与系统ulimit对齐


events {

    use epoll;              # Linux高效事件模型

    worker_connections 10240;

    multi_accept on;

}


http {

    sendfile on;            # 零拷贝传输静态文件

    tcp_nopush on;          # 配合sendfile提升吞吐

    tcp_nodelay on;         # 小包实时传输优化

    keepalive_timeout 65;

    types_hash_max_size 2048;

    

    # 隐藏版本信息

    server_tokens off;

    

    # Gzip压缩(按需启用)

    gzip on;

    gzip_vary on;

    gzip_min_length 1024;

    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    

    # 安全响应头(HTTPS场景补充HSTS)

    add_header X-Frame-Options "SAMEORIGIN" always;

    add_header X-Content-Type-Options "nosniff" always;

    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Strict-Transport-Security 仅在全站HTTPS且测试无误后启用

    

    # 静态资源缓存

    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {

        expires 1y;

        add_header Cache-Control "public, immutable";

    }

    

    # 防护基础设置

    client_max_body_size 10M;          # 限制上传大小

    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    

    # 禁止敏感路径访问

    location ~ /\.(env|git|ht|svn) {

        deny all;

        return 404;

    }

}

```


### 2. SSL/TLS专项优化(启用HTTPS时)

- 协议与加密套件:  

  `ssl_protocols TLSv1.2 TLSv1.3;`  

  `ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES128-GCM-SHA256';`  

  `ssl_prefer_server_ciphers on;`

- 会话复用:`ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;`

- OCSP Stapling:`ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 valid=300s;`

- 证书管理:推荐使用 Let's Encrypt + Certbot 实现自动续期。


### 3. 运维支持

- **配置验证与重载**:  

  `nginx -t && nginx -s reload`(避免服务中断)

- **状态监控**(谨慎开放):  

  ```nginx

  location /nginx_status {

      stub_status on;

      allow 127.0.0.1;  # 严格限制访问IP

      deny all;

  }

  ```

- **日志优化**:`access_log /var/log/nginx/access.log main buffer=32k flush=5s;`


---


## 三、持续运维建议

1. **监控体系**:部署 Prometheus + Node Exporter + Grafana,监控CPU、内存、连接数及Nginx指标(需启用stub_status)。

2. **定期审计**:  

   - 每月检查系统与Nginx安全公告  

   - 使用 `lynis` 或 `rkhunter` 进行安全扫描  

   - 验证备份完整性(网站文件、数据库、配置)

3. **压力测试**:上线前使用 `wrk` 或 `ab` 模拟流量,验证优化效果。

4. **云平台特性**:结合云厂商文档启用增强功能(如网络加速、云监控Agent、快照策略)。


> **重要提示**:  

> - 所有修改前务必备份配置文件(`cp /etc/nginx/nginx.conf{,.bak}`)  

> - 参数需依据实际硬件资源、流量模型动态调整,避免“一刀切”  

> - 安全配置(如HSTS、CSP)需充分测试,防止业务阻断  

> - 遵循“最小权限、纵深防御”原则,定期复审策略有效性  


通过系统性优化与持续运维,可显著提升网站服务的可靠性与抗风险能力。如有特定业务场景(高并发API、媒体站等),建议进一步定制专项策略。

此博客中的热门博文

Elasticsearch 读写原理指南

### 1. 什么是 segment,里面装了什么? 在 Lucene(也是 Elasticsearch)里,索引被切分成若干 **segment(段)**,每个 segment 是一个完整的、只读的倒排索引单元。一个 segment 包含: * **倒排词典** —— 用 **FST(Finite‑State Transducer)** 以高度压缩的形式保存每个字段出现的所有 term 以及 term→ord 的映射。对应的磁盘文件是 `*.tim`(新版)或 `*.tis/*.tii`(旧版)。 * **倒排列表(postings)** —— 保存每个 term 出现的文档 ID、频次、位置信息等,文件名通常是 `*.doc`、`*.pos`、`*.pay`。 * **存储字段**(_source、store:true 的字段)—— 以二进制块的形式写入 `*.fdt` / `*.fdx`。 * **doc‑values、norms、向量** 等辅助结构,分别保存在 `*.dv`、`*.norm`、`*.tv` 等文件里。 * **deleted‑docs bitmap**(`*.del`),标记哪些文档已被删除或被更新。 所有这些文件在 segment **写入磁盘后即成为只读**,后续的查询只能读取,永远不会在原文件上进行增删改。 --- ### 2. 原始文档和 FST 为什么都在 segment 里? * **原始文档**:Elasticsearch 默认把完整的 JSON(_source)以及任何 `store:true` 的字段写入 segment 的 `*.fdt/*.fdx` 文件。每个 segment 保存自己的那部分文档,旧的 segment 在合并前仍然保留,直到合并后被删除。 * **FST**:每个字段的词典在每个 segment 中单独维护,采用 FST 进行前缀共享和字节压缩。这样即使同一个 term 在多个 segment 中出现,也会在每个 segment 里拥有独立的映射,查询时只需要在对应 segment 的 FST 中定位即可。 --- ### 3. 查询时到底是怎么遍历 segment 的? 1. **请求入口**      客户端的搜索请求先到达 **协调节点**,协调节点把请求 ...

事务的ACID是什么

 事务的 ACID 是数据库事务必须满足的四个基本性质,用来保证在并发和故障情况下数据的正确性与可靠性: A(Atomicity,原子性) 一个事务中的操作要么 全部成功 ,要么 全部失败回滚 ,不存在“只做了一半”的中间状态。 C(Consistency,一致性) 事务执行前后,数据库都必须处于 一致的合法状态 ,满足约束(如主键、外键、唯一性、业务规则等)。 I(Isolation,隔离性) 并发执行的多个事务之间 相互隔离 ,一个事务未提交的中间结果对其他事务不可见(具体强弱由隔离级别决定)。 D(Durability,持久性) 一旦事务提交成功,其结果会被 永久保存 ,即使系统崩溃也不会丢失(通常依赖 WAL/redo log 等机制)。 一句话记忆: 要么全做完、前后不破坏规则、互不干扰、做完不丢。

LLM缓存详解

 可以把“大模型缓存”理解成: 把已经算过的结果(或中间结果)存下来,下次尽量复用 。但这里面其实分几层,不只是简单的“问题→答案”缓存。 1️⃣ 常见的几种缓存类型 (1)KV Cache(推理内部缓存) Transformer 在生成时,会把前面 token 的 Key/Value 向量 缓存下来。 本质:避免重复计算 attention 作用: 同一请求内部加速 特点: 👉 只对“同一上下文继续生成”有效 👉 不跨用户、不跨请求 这类缓存是你体感“流式输出越来越快”的原因之一。 (2)Prompt Cache(提示词缓存) 缓存的是: 相同(或高度相似)的 prompt → 对应的中间表示 / 输出 典型场景: 系统提示词(system prompt)很长 多轮对话里前文基本不变 👉 这里能省掉 前缀计算成本(prefill) (3)Embedding / 语义缓存(Semantic Cache) 这个才是你问题的关键 👇 不是按“字符串完全一致”,而是: 把问题转成向量 → 找“语义相似”的历史问题 → 直接复用答案 2️⃣ 为什么命中缓存成本低很多? 因为大模型推理成本主要在两块: (1)Prefill(吃 prompt) 复杂度 ~ O(n²) 很贵(尤其长 prompt) (2)Decode(逐 token 生成) 每个 token 都要算一遍模型 而缓存命中后: KV cache:不用重复 attention Prompt cache:不用重新 encode 语义缓存: 直接跳过模型推理 👉 相当于从: 几十~几百毫秒 + GPU算力 变成: 一次向量检索(毫秒级)+ 直接返回 所以成本差一个数量级是正常的。 3️⃣ “每个人问法不同,怎么命中缓存?” 这是核心难点,也是工程重点👇 ❌ 不能靠字符串匹配 比如: “今天天气怎么样” “今天外面热不热” 字符串完全不同 → 必须 miss ✅ 用语义相似度(Embedding) 流程一般是: 把问题转 embedding(向量) 在向量数据库里找 TopK 相似问题 如果相似度 > 阈值(比如 0.9) 直接返回缓存答案 一个简单示意 Q1: 北京天气怎么样 → embedding A Q2: 北京今天热吗 → embedding B cosine(A, B) ≈ 0.95...