缓存不经常更新的动态信息：策略与 Nginx 配置指南
文章评论、排行榜、投票结果这类内容虽然是动态生成的，更新频率却不高，每次请求都打到后端太浪费。把它们缓存在 Nginx 代理层，后端压力和页面加载速度都会明显改善。这篇在 nginx:1.28 容器里把这套配置实跑一遍：命中、过期、后端宕机时的兜底，以及一个会让用户读到别人数据的缓存键错误。 哪些内容适合这样缓存判据只有一条：动态生成、但更新频率以分钟或小时计。文章评论、排行榜、投票结果都在此列——每次请求实时计算是浪费；反过来，余额、订单状态这类时效敏感数据不适用，缓存换来的一致性代价不划算。 缓存策略对这类内容推荐两层组合：较长的缓存时间 + 更新时主动清理。用户绝大多数请求命中缓存，内容更新后靠清理动作保证及时可见。缓存时间是”最差情况下用户读到多旧的数据”，清理机制才是实时性的来源，两者缺一不可。 Nginx 配置实例缓存路径与键（http 块）： 1234proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=7d ...
Nginx proxy_cache 实战：HIT、MISS、BYPASS 各是什么意思
接口慢，第一反应是扩后端，但很多响应其实压根不变——列表页、配置项、公开详情，十次请求九次内容一样。Nginx 的 proxy_cache 模块把这些上游响应缓存到本地磁盘，命中后直接返回，后端少扛一次是一次。 结论先行：proxy_cache 用三条指令搭起来——proxy_cache_path 划一块磁盘（只能放 http 层），proxy_cache 在 location 里启用，proxy_cache_valid 定缓存多久；真正决定行为的是缓存键怎么写、哪些请求要绕开。 本文用一个双容器实验把 MISS、HIT、BYPASS 三种状态各跑一遍，再给两组错误写法的实测翻车现场。所有输出均为实跑结果，未跑过的结论会明确标注。 实验环境可复现是前提，先交代条件： nginx/1.31.5（docker 镜像 nginx:alpine），两个容器跑在同一个自定义网络里：cache-backend 当上游，cache-proxy 当缓存代理； proxy 容器把配置挂载到 /etc/nginx/conf.d/default.conf，每轮改完 nginx -s rel...
Nginx autoindex：让目录在浏览器里直接可浏览
服务器上有一批文件想让同事在浏览器里直接翻，又不想专门写页面——autoindex 就是 Nginx 自带的目录列表功能：请求指向的目录里没有 index.html 这类默认索引文件时，Nginx 自动生成一个列出全部文件和子目录链接的 HTML 页面。这篇在 nginx:1.28 容器里把开关、两个显示选项、JSON 输出和两个典型”为什么看到的不是列表”实跑一遍。 实验环境 Docker 容器 nginx:1.28-alpine（nginx/1.28.3，2026-09 实测，autoindex 是标准模块，默认编译）。 三个测试目录：files/（放 readme.txt、big-archive.tar、app.log 三个文件）、plain/（空目录，什么都不配）、with-index/（同时放了 index.html 和 other.txt）。 核心机制一句话Nginx 收到指向目录的请求时，先按 index 指令找默认索引文件；找不到时，autoindex on 决定是生成目录列表页（on）还是返回 403 Forbidden（默认 off）。列表页是 N...
Nginx root 与 alias：一个是追加，一个是替换
配置静态文件服务时，root 和 alias 都负责告诉 Nginx 去文件系统的哪个目录找文件。这俩指令长得像、干的活不同，混淆的后果很直接：请求 404，或者拿到的根本不是你想要的文件。最经典的翻车现场是——配置怎么看怎么对，error_log 里却躺着一个从未写过的路径。 本文按配置实战组织：先交代实验环境，再用三组配置加真实输出把”追加”和”替换”两种行为跑给你看，然后实测两个最容易踩的路径拼接坑。所有输出均为 nginx/1.31.5 实跑结果。 实验环境所有实例在容器里可复现： nginx/1.31.5（docker 镜像 nginx:alpine）； 文档目录 /usr/share/nginx/html（含 index.html 和 images/logo.png，内容分别为 INDEX、LOGO）； 独立资源目录 /data/uploads/logo.png（内容 UPLOAD），供 alias 映射； 配置挂载到 /etc/nginx/conf.d/，改动后 reload，容器内 curl 验证。 机制一句话：root 追加，alias ...
Nginx 日志切割：Bash 脚本与 logrotate 两种做法
Nginx 跑久了，access.log 会一路膨胀，大到 grep 都卡。日志切割要解决两件事：把旧日志按时间归档压缩，同时让 nginx 换一个新文件继续写。这篇文章给出两种做法：一个手写 Bash 脚本，一个用系统自带的 logrotate。两种方案都在 nginx/1.31.5 容器（logrotate 3.22.0）里实测通过，输出均来自实跑。 实验环境nginx/1.31.5 容器（nginx:alpine），日志为普通文件（非容器默认的 stdout 软链——这个区别本身就是后文的一组坑）；logrotate 取 apk 源的 3.22.0。 方案一：Bash 脚本假设访问日志位于 /var/log/nginx/access.log： 1234567891011121314151617#!/bin/bashLOG_FILE="/var/log/nginx/access.log"ARCHIVE_DIR="/var/log/nginx/archive"# 判断归档目录是否存在，如果不存在则创建if [ ! -d...
Windows 服务器关闭危险端口 135、137、138、139、445 的方法
135、137、138、139、445 是 Windows 服务器上被扫得最勤的五个端口，WannaCry、EternalBlue 这类大规模勒索事件的主要入口都在这里。公网上开放的 445 端口被自动化扫描工具盯上通常撑不过一天，内网里它们则是横向移动的标准跳板。封掉这五个端口不需要任何第三方工具，Windows 自带防火墙就能完成。这篇先讲清每个端口对应什么服务、为什么危险，再给图形界面和命令行两种封法，最后是封完怎么验证、封之前要查什么依赖。 注：Windows 无法容器化实跑，本文操作步骤与命令语法来源为微软官方文档及原文生产环境操作记录，未在实机复测；执行前请在测试机上过一遍。 这五个端口各是什么封端口之前得知道自己封的是什么。这五个端口分属两套机制：135 是 RPC 的入口，137/138/139 是 NetBIOS 家族，445 是 SMB 直接承载。 端口 协议 对应服务 危险在哪 135 TCP RPC Endpoint Mapper 远程过程调用入口，WMI/DCOM 依赖它；被利用做横向移动和远程代码执行 ...
CVE-2015-1635（MS15-034）HTTP.sys 远程代码执行漏洞处置
运维收到 MS15-034 漏洞通报时，最关心两件事：我的服务器在不在受影响范围里，以及暂时打不了补丁怎么办。这篇按”确认影响范围 → 处置（补丁为主、缓解为辅）→ 验证修复”的顺序，把 CVE-2015-1635 的处置路子走完。 漏洞现象与影响范围CVE-2015-1635 对应微软安全公告 MS15-034：Windows 的 HTTP 协议栈组件 HTTP.sys 在解析特制 HTTP 请求时处理不当，攻击者构造恶意请求发送给受影响系统，就能以 System 权限执行任意代码——这是内核级 HTTP 栈漏洞，IIS 网站服务恰好架在它上面，所以所有跑 IIS 的服务器都直接暴露在风险面里。 受影响的环境是固定的几代 Windows（微软公告原文列表）： Windows 7 SP1（32 位 / x64） Windows Server 2008 R2 SP1（x64 / Itanium，含 Server Core） Windows 8、Windows 8.1（32 位 / x64） Windows Server 2012、Windows Se...
3389 端口 SSL/TLS 协议信息泄露漏洞（CVE-2016-2183）修复方法
漏洞扫描经常在 Windows 服务器的 3389 端口（RDP）上报出 CVE-2016-2183，也就是 SSL/TLS 协议信息泄露（SWEET32）。根因是 Windows 默认启用了一组弱密码套件，其中 3DES 使用 64 位分组，长会话流量积累到一定量后就可能被生日攻击还原出敏感内容，扫描器因此报警。 这个问题不用装补丁：在本地组策略里把 SSL 密码套件顺序替换成一份去掉弱项的清单，再重启即可。本文按排错的顺序展开——现象、原因、修复步骤、修复后怎么验证。 原因分析CVE-2016-2183 针对的是 3DES 这类 64 位分组的块密码。TLS 会话里同一个密钥加密的数据量超过分组空间的一定比例后，攻击者靠碰撞分析就能猜出内容片段，这就是 SWEET32 攻击的名字由来。RDP 会话长时间保持连接、流量持续增长，恰好踩在这个场景上。 Windows 的 TLS 栈由 SChannel 统一提供，默认套件清单里包含 TLS_RSA_WITH_3DES_EDE_CBC_SHA 这类 3DES 条目——扫描器报的正是它。所以修复思路不是打补丁，而是把这份清单...
Linux 禁用 rm 等危险命令，防止误操作
在服务器上敲错一个 rm -rf 的代价可能是一整块数据盘。与其事后恢复，不如提前把 rm 这类高危命令在 shell 层面拦住。这篇用 alias 做两层防护：把 rm 换成无害提示，再用”回收站 + 定时清理”兜住真要删的场景，顺带把 shutdown/reboot 这类误触即发火的命令一并禁掉。所有行为在 Rocky 9 容器实测，过程中挖出三个方案自带的坑（嵌套拦截、清理周期语义、root 默认别名覆盖），逐个给出修正。 实验环境 Rocky Linux 9.3 一次性容器，bash 5.1.8、findutils 4.8.0； alias 只在交互 shell 里展开，实测用普通用户 + 登录 shell（bash -l）模拟日常终端——非登录的交互 shell 不加载 /etc/profile，别名不会生效，这是实测踩到的第一个细节，写进方案前必须确认自己测的是哪种 shell； /etc/profile 对登录 shell 生效、影响所有用户；~/.bashrc 对每个交互 shell 生效、只影响单个用户。全机拦截用 profile，...
YUM/DNF DownloadOnly：只下载不安装，预载软件更新
有一类需求很常见：想在带宽空闲的时段把软件更新先下载好，等维护窗口再真正安装。DownloadOnly 模式就是干这个的——只执行下载动作，不立即安装或更新。这篇以 Rocky Linux 9 的 dnf 为主线（全部命令在 rockylinux:9 容器实测，dnf 4.14.0，aarch64），CentOS 7 的插件玩法作为历史差异单列一节，老环境对照着用。 这功能解决什么问题生产服务器的变更要挑维护窗口，但更新包几个 G，窗口里现下载时间根本不够。DownloadOnly 把”传输”和”变更”拆开：低峰期把包拉到本地，维护窗口只做本地安装，窗口时间从”下载+安装”缩短为”安装”。 适用的典型场景： 维护窗口短、更新包大 多台服务器装同一批更新，下载一次分发复用（配合内网源或 scp） 想先审查将安装的包清单，再决定是否执行 场景一：预下载系统全部可用更新RHEL 8/9 / Rocky / Alma 系的 dnf 原生支持 --downloadonly，无需任何插件。全系统更新的包拉到指定目录： 1dnf update --downlo...
