Ungoogled Chromium Binaries 离线部署实战指南 Ungoogled Chromium Binaries 离线部署实战指南—— 跨发行版、多架构服务器环境下的"绿色版"精准获取与使用1. 为什么选择 Ungoogled Chromium Binaries？在离线、多发行版（EulerOS / Kylin / Ubuntu）、多版本且混合架构（x86_64 + ARM64）的服务器环境中部署 Chrome，官方 .deb/.rpm 包因对 glibc、NSS、GTK 等系统库的严格版本锁定而完全不可用。Ungoogled Chromium Binaries 是 ungoogled-software/ungoogled-chromium 主仓库官方推荐的预编译二进制分发页面。它专门解决了以下核心痛点：零/低系统依赖：Portable（便携）版本静态链接了大部分运行时库，不绑定特定版本的 glibc，真正实现"解压即用"。双架构全覆盖：同时提供 x86_64 和 aarch64 (ARM64) 构建，完美适配信创鲲鹏/飞腾及传统 Intel/AMD 服务器。去 Google 化：移除了所有 Google 私有服务、追踪器和 API 依赖，符合内网及信创环境的安全合规要求。免 Root 权限：无需系统级安装，普通用户即可运行，避免污染宿主系统环境。⚠️ 安全声明该页面的二进制由社区贡献者构建，非可重现构建（non-reproducible）。若用于高安全合规环境，建议在隔离环境中自行从源码审计构建。对于一般内网服务器自动化、渲染、截图等场景，此方案是当前兼容性最优解。2. 读懂下载页：没有搜索框，如何找到"绿色版"？很多用户首次打开该页面时会困惑：没有搜索框，也没有"绿色版/安装版"的中文标签。这是因为该页面遵循开源社区惯例，按 平台 + 架构 + 构建类型 分类。你需要建立以下概念映射：页面表格中的名称实际含义对应 Windows 概念是否推荐离线多系统环境Portable Linux 64-bit解压后直接运行的 tar.xz 包，自带依赖库✅ 真·绿色版强烈推荐Linux AppImage 64-bit自包含的 .AppImage 单文件✅ 绿色版推荐（仅 x86_64）Portable Linux 64-bit (musl)针对 Alpine/Void 等轻量系统的静态构建✅ 超级绿色版老旧系统兜底Debian/Ubuntu (unportable).deb 包，需 dpkg 安装，强依赖系统库❌ 安装版绝对不要用Fedora/RHEL (unportable).rpm 包，需 rpm 安装，强依赖系统库❌ 安装版绝对不要用💡 核心原则只认准 Portable 和 AppImage 字样。凡是带有 unportable、.deb、.rpm 后缀的，一律跳过。快速定位技巧页面为静态生成，无搜索功能。请使用浏览器 Ctrl+F 搜索以下关键词：x86_64 绿色版 → 搜索 Portable Linux 64-bitARM64 绿色版 → 搜索 Portable Linux 64-bit ARM 或 aarch64自包含单文件 → 搜索 AppImage3. 下载与离线部署全流程第一步：联网机下载访问 Ungoogled Chromium Binaries在表格中找到目标架构对应的 Portable 行，点击版本号链接（如 150.0.7871.128-1），跳转至 GitHub Release 页面。下载对应文件：目标架构文件名示例x86_64ungoogled-chromium-150.0.7871.128-1-linux-portable.tar.xzARM64ungoogled-chromium-150.0.7871.128-1-linux-arm64-portable.tar.xz务必同时下载中文字体（离线服务器无 CJK 字体必然乱码）：wget https://github.com/notofonts/noto-cjk/raw/main/Sans/SubsetOTF/SC/NotoSansSC-Regular.otf第二步：离线服务器部署将下载的文件通过 U 盘或内网传输至目标服务器后执行：# 1. 创建目录并解压（无需 root） mkdir -p /opt/chromium tar -xf ungoogled-chromium-*-portable.tar.xz -C /opt/chromium --strip-components=1 # 2. 放置字体 mkdir -p /opt/chromium/fonts cp NotoSansSC-Regular.otf /opt/chromium/fonts/ # 3. 赋予执行权限 chmod +x /opt/chromium/chrome # 4. 验证动态链接库完整性（应全部显示 found 或 static） ldd /opt/chromium/chrome第三步：运行测试/opt/chromium/chrome \ --headless=new \ --no-sandbox \ --disable-gpu \ --disable-dev-shm-usage \ --font-path=/opt/chromium/fonts \ --screenshot=/tmp/test.png \ https://example.com确认 /tmp/test.png 生成且中文渲染正常，即部署成功。4. 多架构统一启动脚本（生产环境推荐）在混合架构集群中，建议封装 wrapper 脚本自动适配，屏蔽底层差异：#!/bin/bash # /usr/local/bin/chrome-headless ARCH=$(uname -m) CHROME_DIR="/opt/chromium" FONT_DIR="${CHROME_DIR}/fonts" case "$ARCH" in x86_64) CHROME_BIN="${CHROME_DIR}/chrome-x86_64" ;; aarch64) CHROME_BIN="${CHROME_DIR}/chrome-aarch64" # ARM64 二进制缺失时回退到容器 if [ ! -f "$CHROME_BIN" ]; then exec docker run --rm \ -v "${FONT_DIR}:/usr/share/fonts/custom:ro" \ zenika/alpine-chrome \ --headless=new --no-sandbox --disable-gpu \ --disable-dev-shm-usage \ --font-path=/usr/share/fonts/custom \ "$@" fi ;; *) echo "Unsupported architecture: $ARCH" >&2 exit 1 ;; esac exec "$CHROME_BIN" \ --headless=new \ --no-sandbox \ --disable-gpu \ --disable-dev-shm-usage \ --font-path="$FONT_DIR" \ "$@"调用方式统一为：chrome-headless --screenshot=/tmp/output.png https://example.com5. 常见问题速查表问题现象根因解决方案GLIBC_2.xx not found宿主机 glibc 版本过低换用 musl Portable 构建，或使用容器方案中文显示方块/乱码缺少 CJK 字体添加 --font-path 指向 Noto Sans SC 或文泉驿字体Out of memory / 崩溃/dev/shm 空间不足必须加 --disable-dev-shm-usageRunning as root without --no-sandboxroot 用户运行加 --no-sandbox（容器内或 root 下必需）ARM64 无可用 Portable 构建社区未覆盖该架构使用 zenika/alpine-chrome ARM64 容器镜像替代ldd 显示大量 not foundPortable 版仍依赖少量系统库安装缺失基础库（如 libnss3），或换用完全静态构建6. 参考链接二进制下载页：https://ungoogled-software.github.io/ungoogled-chromium-binaries/主仓库（源码/补丁）：https://github.com/ungoogled-software/ungoogled-chromium容器替代方案：https://hub.docker.com/r/zenika/alpine-chromeCJK 字体下载：https://github.com/notofonts/noto-cjk

AutoJs开心版 {cloud title="github" type="github" url="https://github.com/Azek431/AutoJsPro-Crd" password=""/}{cloud title="123网盘" type="default" url="https://1815547653.share.123pan.cn/123pan/0ztiVv-yFA1d" password=""/}{cloud title="天翼网盘" type="ty" url="https://cloud.189.cn/web/share?code=7ZVBjaZV3EV3" password="（访问码：kt0o）"/}

宝塔 + WordPress 安全加固完整方案 宝塔 + WordPress 安全加固完整方案从「面板 → 系统 → 网站/PHP → WordPress → 数据库 → 备份 → 监控 → 应急」8 层纵深防御。优先级：必须 > 推荐 > 可选。① 宝塔面板自身（必须）面板被破 = 整台服务器沦陷，是第一道防线。面板设置 → 修改端口：默认 8888 改高位非常用端口（如 35821）。面板设置 → 安全入口：设复杂随机路径，如 /bt_8f3k（默认 /btpanel 立即失效）。面板设置 → 绑定授权 IP：只放行你自己的固定 IP（无固定 IP 则跳过，别锁死自己）。面板设置 → 开启面板 SSL：用 https 访问面板。面板设置 → 两步验证(2FA)：手机令牌，强烈建议开。面板设置 → 修改管理员用户名 + 强密码（16 位以上，含大小写数字符号）。软件商店 → phpMyAdmin：不用时关闭，或加「基础认证」密码；不要长期公开。② 服务器系统层（推荐）安全（左侧）→ 系统防火墙：只放行 22 / 80 / 443 / 面板端口，其余拒绝。安全 → SSH 管理：改默认 22 端口；禁用 root 直接登录；改用密钥登录。软件商店 → 安装 fail2ban（或宝塔「系统防火墙」的防暴力破解）：自动封禁爆破 IP。定期执行系统补丁更新（yum update / apt update）。③ 网站 / PHP 层（必须，最关键，锁死破坏面）网站 → 设置 → 防跨站攻击 → ✅ 开启：本质是给 PHP 设 open_basedir，黑客拿到 shell 也出不了网站目录。这一项最重要。软件商店 → PHP 升级到 8.1 / 8.2（旧版漏洞多）。PHP → 设置 → 禁用函数：加入以下函数（WordPress 正常运行不需要）：exec, system, passthru, proc_open, popen, shell_exec, pcntl_exec, proc_get_status, proc_close, eval网站 → 设置 → 伪静态：追加「禁止 uploads 执行 PHP」规则（见下方配置区）。文件管理：目录 755、文件 644；wp-config.php 设为 600。网站 → SSL → Let's Encrypt 一键申请，开启「强制 HTTPS」。④ WordPress 应用层（必须）清理陌生管理员：后台「用户」确认无陌生账号；改掉默认 admin 用户名。装 Limit Login Attempts Reloaded：限制登录失败次数，挡暴破。在 wp-config.php 加两行，关闭后台主题/插件在线编辑（防黑客改主题挂马）：define( 'DISALLOW_FILE_EDIT', true ); define( 'DISALLOW_FILE_MODS', false ); // 想彻底禁止自动改文件改 true删掉 cholame222 副本、所有停用主题/插件（只留 active 的 cholame + 在用的插件）。更新 WP 核心 + 主题 + 插件到最新。装 Wordfence / Sucuri（免费版足够）：文件完整性监控 + 恶意流量拦截。不用就禁用 XML-RPC（黑客暴破常用）：用安全插件关，或 nginx 规则 deny 掉 xmlrpc.php。⑤ 数据库安全（推荐）强口令：wp-config.php 里的 DB_PASSWORD 用 16 位以上随机串。表前缀：新装站用非常规前缀（如 kr_ 而非 wp_）；已建站可用插件修改（有风险，先备份）。phpMyAdmin 用独立强口令，平时关闭。⑥ 备份（必须，被黑后能秒回滚）计划任务 → 建两条：网站备份 + 数据库备份，每日自动跑。备份存储到云存储（阿里云 OSS / 腾讯云 COS / FTP 异地），不要只存本机。保留至少 7 天滚动备份。也可用 UpdraftPlus 插件自动备份到云端。⑦ 监控告警（可选）监控（左侧）→ 开启，定期看 CPU/带宽异常。安全插件的邮件/微信告警打开，文件变更/登录异常即通知你。⑧ 应急响应（必须，怀疑被黑时）立即改全站密码（WP 管理员 / 主机 / 数据库 / phpMyAdmin），并撤销所有用户会话。从干净备份恢复，或按「正确重装核心」：只重传 wp-admin/ + wp-includes/ + 根目录 php 文件，不要动 wp-content（那会冲掉你的主题/插件/上传）。活动主题若被破坏：把你本地这份干净的 cholame 整目录重新传上去覆盖。扫描 wp-content/uploads/ 下有无异常 .php（正常不该有）。查数据库 wp_options 是否被注入跳转 JS、wp_users 有无陌生管理员。附：可直接复制的配置Nginx 伪静态（禁止 uploads 执行 PHP + 封 xmlrpc）# 禁止 uploads / cache / languages 执行 PHP（防挂马后门） location ~* ^/wp-content/(uploads|cache|languages)/.*\.(php|php3|php4|php5|phtml|pht)$ { deny all; return 403; } # 禁用 XML-RPC（防暴破） location = /xmlrpc.php { deny all; return 403; }Apache（.htaccess 放 uploads 目录）<FilesMatch "\.(?i:php|php3|php4|php5|phtml|pht)$"> Require all denied </FilesMatch> php_flag engine offwp-config.php 加固片段define( 'DISALLOW_FILE_EDIT', true ); define( 'FORCE_SSL_ADMIN', true ); define( 'WP_AUTO_UPDATE_CORE', 'minor' );验证 uploads 禁执行是否生效在 wp-content/uploads/ 新建 test.php，写 <?php echo "PHP_STILL_RUNS"; ?>访问 https://你的域名/wp-content/uploads/test.php✅ 正确：显示 403 Forbidden（看不到 PHP_STILL_RUNS）❌ 错误：直接显示了 PHP_STILL_RUNS → 规则未生效，检查服务器类型测完删掉 test.php⚠️ 最高性价比三件事（10 分钟，挡掉 80% 自动攻击）面板改端口 + 安全入口 + 2FA网站开防跨站攻击 + PHP 禁用危险函数 + uploads 禁执行 PHP宝塔设每日自动备份到云⚠️ 重装核心的正确姿势（避免再次白屏）只重传 wp-admin/、wp-includes/ 和根目录几个 php 文件。不要重传 wp-content/——里面装的是你的主题、插件和上传的图片，重传会覆盖/冲掉它们，正是上次前台白屏的原因。

Nginx平滑升级离线编译与零停机热替换完整手册 Nginx 1.30.4 离线编译与零停机热替换完整手册⚠️ 前置条件确认当前身份：root旧版 Nginx 前缀：/usr/local/nginx编译依赖：gcc、make、pcre-devel、zlib-devel、openssl-devel 等必须已在离线环境中提前安装。若未安装，需先通过 rpm/deb 包离线安装依赖，否则 ./configure 会失败。📥 第一阶段：获取源码与解压1. 下载 Nginx 1.30.4 源码包在有网络的机器上下载后，通过 U盘/SCP 等方式传入服务器 /home/zjgzwyjsadmin/ 目录：# 在联网机器执行示例 wget https://nginx.org/download/nginx-1.30.4.tar.gz2. 解压并进入源码目录cd /home/nginx-1.30.4 tar -zxvf nginx-1.30.4.tar.gz cd nginx-1.30.4路径约定后续所有命令均假设源码位于 /home/nginx-1.30.4。若您实际路径不同，请全局替换。🔧 第二阶段：编译构建（仅编译，不安装）1. 提取旧版编译参数OLD_ARGS= $ (nginx -V 2>&1 | grep "configure arguments:" | sed 's/configure arguments: //') echo "📋 旧版参数: $ OLD_ARGS"2. 配置编译选项# 使用旧版参数确保模块完全兼容 ./configure $ OLD_ARGS3. 编译生成新二进制# 利用多核加速编译，绝不执行 make install！ make -j $ (nproc)4. 编译后双重验证（必做）# 验证1：参数一致性（注意 -- 分隔符防止 grep 误解析） ./objs/nginx -V 2>&1 | grep "configure arguments:" | grep -F -- " $ OLD_ARGS" \ && echo "✅ 编译参数一致" || { echo "❌ 参数不一致，停止！"; exit 1; } # 验证2：新二进制能正确解析现有配置 ./objs/nginx -t # 期望输出: syntax is ok / test is successful只有两个验证均通过，才能继续。 若失败，检查 $OLD_ARGS 完整性或重新 make clean && make。🔒 第三阶段：全量备份（不可跳过）BACKUP_TIME= $ (date +%Y%m%d_%H%M%S) NGINX_BIN= $ (which nginx) # 备份二进制 cp " $ NGINX_BIN" " $ {NGINX_BIN}.bak. $ {BACKUP_TIME}" # 备份配置目录 cp -a /usr/local/nginx/conf "/usr/local/nginx/conf.bak. $ {BACKUP_TIME}" echo "✅ 备份完成:" ls -lh " $ {NGINX_BIN}.bak. $ {BACKUP_TIME}" ls -ld "/usr/local/nginx/conf.bak. $ {BACKUP_TIME}"🔄 第四阶段：零停机热替换执行💡 原理：USR2 启动新 Master → 新 Worker 接管新请求 → WINCH 优雅关闭旧 Worker→ QUIT 退出旧 Master。全程无连接中断。# 确保在源码目录下 cd /home/zjgzwyjsadmin/nginx-1.30.4 NGINX_BIN= $ (which nginx) # 步骤1：覆盖二进制（旧进程在内存中运行，不受磁盘影响） cp ./objs/nginx " $ NGINX_BIN" # 步骤2：启动新 Master 进程 kill -USR2 $ (cat /usr/local/nginx/logs/nginx.pid) sleep 3 # 步骤3：确认双 Master 共存（必须看到两行 master） ps aux | grep "[n]ginx: master" # 步骤4：优雅关闭旧 Worker kill -WINCH $ (cat /usr/local/nginx/logs/nginx.pid.oldbin) # 步骤5：业务健康检查（关键决策点！） curl -sI http://localhost | head -3 tail -20 /usr/local/nginx/logs/error.log | grep -E "emerg|crit|alert" # ✅ 正常 → 继续步骤6 # ❌ 异常 → 立即执行下方【紧急回滚预案】 # 步骤6：彻底退出旧 Master kill -QUIT $ (cat /usr/local/nginx/logs/nginx.pid.oldbin) # 步骤7：最终版本确认 nginx -v # 期望输出: nginx version: nginx/1.30.4✅ 第五阶段：升级后验证矩阵检查项命令合格标准版本号nginx -vnginx/1.30.4进程唯一性`ps aux \grep "[n]ginx: master" \wc -l`输出 1配置语法nginx -ttest is successful错误日志tail -20 /usr/local/nginx/logs/error.log无新增 emerg/crit业务响应curl -sI http://localhostHTTP 2xx/3xx监听端口`ss -tlnp \grep nginx`所有预期端口 LISTEN🔙 紧急回滚预案（30秒内恢复）仅在第四阶段步骤5健康检查失败时执行：NGINX_BIN= $ (which nginx) # ⚠️ 将下方时间戳替换为第三阶段输出的实际 BACKUP_TIME BACKUP_TIME="YYYYMMDD_HHMMSS" # 1. 终止新进程组 kill -QUIT $ (cat /usr/local/nginx/logs/nginx.pid) 2>/dev/null # 2. 恢复旧二进制 cp " $ {NGINX_BIN}.bak. $ {BACKUP_TIME}" " $ NGINX_BIN" # 3. 重启旧版本 nginx -t && nginx # 4. 验证回滚成功 nginx -v && curl -sI http://localhost⚠️ Root 环境安全警告SELinux：若启用，覆盖二进制后必须执行 restorecon -v "$NGINX_BIN"，否则新 Master 无法绑定端口。WINCH 耐心等待：WebSocket/大文件下载等长连接可能导致旧 Worker 持续数分钟。用 watch -n1 'ps aux | grep "[n]ginx: worker"' 监控，绝不要 kill -9。PID 路径：以上命令假设 PID 在 /usr/local/nginx/logs/nginx.pid。若不同，通过 nginx -V 2>&1 | grep -oP '(?<=--pid-path=)\S+' 获取实际路径并全局替换。操作窗口：尽管零停机，仍建议在业务低峰期执行。离线依赖：若 ./configure 报错缺少库，需在离线环境中提前准备好对应的 devel 包（如 pcre2-devel、zlib-devel、openssl-devel）并通过 rpm -ivh 或 dpkg -i 安装。

告别破解！用Aspose.Words实现Java版Word转PDF的实战指南 Aspose.Words 实现 Word 转 PDF 实战指南1. 为什么选择 Aspose.Words 进行 Word 转 PDF？在 Java 开发中处理 Office 文档转换，很多开发者第一反应是使用 Apache POI。但实际用过的朋友都知道，POI 对复杂格式的 Word 文档支持有限，特别是处理表格、图表、页眉页脚时经常出现格式错乱。而 Aspose.Words 作为专业的文档处理库，能完美保留原文档的所有格式细节。我去年接手过一个政府部门的文档电子化项目，需要将十几年的历史 Word 档案批量转成 PDF。最初尝试用开源方案，结果发现：复杂表格转换后出现错位特殊字体显示为方框文档中的矢量图形丢失换成 Aspose.Words 后这些问题迎刃而解。更关键的是，它不需要像某些商业软件那样手动破解 license，使用社区提供的 Maven 依赖就能开箱即用。下面我会分享具体实现方案，包含我在实际项目中踩过的坑和优化经验。2. 环境准备与依赖配置2.1 破解版依赖的正确引入方式原始文章中提到的 com.luhuiguo 组件的确可以免破解使用，但需要注意版本兼容性。经过实测，目前最稳定的版本是 23.1：<dependency> <groupId>com.luhuiguo</groupId> <artifactId>aspose-words</artifactId> <version>23.1</version> </dependency>这个版本支持：Word 97-2003格式（.doc）新版.docx格式加密文档处理超过200页的大文件转换注意：不建议使用更高版本，部分23.3+版本在Linux环境下会出现字体加载异常。2.2 字体库的预处理方案Windows环境下字体问题较少，但Linux服务器需要特别注意。推荐在部署前执行：# CentOS/RedHat sudo yum install -y dejavu-sans-fonts # Ubuntu/Debian sudo apt-get install -y ttf-mscorefonts-installer这样能确保基础字体可用，避免出现中文乱码。更专业的做法是建立字体映射：FontSettings.getDefaultInstance().setFontsFolder( "/usr/share/fonts/win", // Windows字体目录 true

NGINX 零停机平滑升级全流程实操指南 一、 概述在生产环境下，升级 NGINX 二进制文件通常面临一个挑战：如何升级而不需要停止服务（零停机）？NGINX 通过一套精巧的信号量（Signals）机制实现了平滑升级。其核心原理是：启动一个新的主进程（Master Process）接管监听端口，让旧进程在处理完现有请求后优雅退出，从而实现无缝切换。二、 升级前置准备与环境摸底在升级之前，必须确保新版本的编译参数与当前运行的版本完全一致，否则会导致启动失败或功能缺失。1. 查询当前版本及编译参数# 查看当前版本号 nginx -v # 查看详细编译参数 (极其重要，升级时必须使用相同的参数) nginx -V记录项： 重点记录 configure arguments 之后的所有内容（如 --prefix=/usr/local/nginx）。2. 确认二进制文件路径与 PID# 确认 nginx 可执行文件路径 which nginx # 确认当前运行的主进程 PID ps aux | grep nginx 记录项： 记录 master process 的 PID。3. 配置文件语法检查在任何操作前，确保当前配置文件没有语法错误。nginx -t三、 新版本编译准备核心原则：只编译→→不安装。 严禁直接执行 make install，因为这会覆盖您生产环境的配置文件。1. 下载并解压wget http://nginx.org/download/nginx-x.x.x.tar.gz tar -zxvf nginx-x.x.x.tar.gz cd nginx-x.x.x2. 配置与编译使用第一阶段记录的编译参数进行配置：# 使用之前 nginx -V 记录的参数 ./configure --prefix=/usr/local/nginx [其他参数...] # 编译生成二进制文件 make编译完成后，新的二进制文件位于 objs/nginx。四、 执行平滑升级（核心步骤）步骤 1：二进制文件替换由于 Linux 内核禁止覆盖正在运行的二进制文件（会报 Text file busy），我们必须使用 mv 命令通过改变 inode 的方式进行替换。 # 1. 备份旧文件 cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak # 2. 使用 mv 替换新文件 (绕过 Text file busy) mv objs/nginx /usr/local/nginx/sbin/nginx # 3. (可选) 如果系统中有快捷路径 /usr/local/bin/nginx，请同步更新 cp /usr/local/nginx/sbin/nginx /usr/local/bin/nginx步骤 2：启动新主进程 (USR2)向旧主进程发送 USR2 信号，通知其启动新版本的二进制进程。 kill -USR2 <旧MasterPID> 状态： 此时，旧主进程和新主进程同时存在，它们共同监听端口，但新请求将开始分发给新进程。 步骤 3：优雅停止旧工作进程 (WINCH) 向旧主进程发送 WINCH 信号，通知旧的工作进程（Worker Processes）在处理完当前请求后立即退出。 code Bash kill -WINCH <旧MasterPID> 状态： 此时，所有新流量已全部由新版本进程处理。步骤 4：业务验证（关键环节） 在彻底删除旧版本前，必须进行全方位验证： 本地验证： curl -I http://127.0.0.1:端口 外部验证： telnet IP 端口 或 浏览器访问。 日志验证： tail -f /usr/local/nginx/logs/error.log 检查是否有 [emerg] 报错。 ### 步骤 5：彻底关闭旧主进程 (QUIT) 确认业务运行稳定后，关闭不再需要的旧主进程。 ```text kill -QUIT ``` 五、 异常处理与回滚方案 1. 怎么回滚？ 如果在 步骤 3 之后发现新版本运行异常，可以通过以下指令将流量瞬间切回旧版本： code Bash # 向新主进程发送 WINCH 信号，让新 worker 退出 kill -WINCH # 此时流量会自动切回尚未关闭的旧 worker 进程 2. 常见坑点排查 ```text Text file busy： 不要用 cp 覆盖运行中的文件，必须用 mv。 版本显示不一致： 如果 nginx -v 显示旧版而 ps 显示新版，说明 /usr/local/bin/nginx 和 /usr/local/nginx/sbin/nginx 两者不一致，请同步覆盖。 Telnet 不通： 若 curl 内部通但外部不通，请检查防火墙（Firewalld/Security Group）策略，这通常与 NGINX 升级无关，而是网络层波动。 ``` 六、 总结流程图 备份→→编译→→mv替换→→USR2(启动新版)→→WINCH(切流量)→→验证→→QUIT(删旧版)

2026 最新实战：在单卡 48GB GPU 上部署 Qwen3.5-35B-A3B MoE 模型（vLLM + Open WebUI 完整指南） 一、为什么选择 Qwen3.5-35B-A3B？Qwen3.5-35B-A3B 是阿里通义千问团队于 2026 年初发布的 混合专家（MoE）模型，具备以下优势：小体积，大能力：总参数量 35B，但每次推理仅激活约 3B 参数，显存占用远低于同级别 Dense 模型。超长上下文：原生支持 262,144 tokens，轻松处理长文档、代码库。开源免费：采用 Apache 2.0 协议，可商用，权重已在 ModelScope 魔搭社区 公开。性能卓越：在多项基准测试中超越前代 Qwen3-235B-A22B，推理成本更低。对于拥有 单张 48GB GPU（如 A6000、RTX 6000 Ada）的用户，它是目前能本地部署的 最强 MoE 模型。二、环境配置（无需虚拟环境，全局安装即可）重要提示：经大量用户反馈，vLLM 与 Open WebUI 必须在同一 Python 环境中运行，否则会出现模块缺失或 API 不兼容问题。因此，直接使用全局环境是最简单可靠的方案。# 升级 pip（避免旧版 pip 的编译问题） pip install --upgrade pip #安装魔塔社区的包 pip install modelscope # 安装 vLLM（自动匹配 CUDA 版本） pip install vllm # 安装 FlashAttention（加速注意力计算） pip install flash-attn --no-build-isolation # 安装webui聊天界面 pip install open-webui三、单卡部署：Qwen3.5-35B-A3B 快速启动1. 下载模型（以 Qwen3.5-35B-A3B 为例）#模型下载 from modelscope import snapshot_download model_dir = snapshot_download('Qwen3.5-35B-A3B',cache_dir='./')四、单卡部署：启动 vLLM 服务vllm serve ./Qwen3.5-35B-A3B \ --dtype bfloat16 \ --port 5000 \ --max_model_len 262144 \ --gpu_memory_utilization 0.85参数详解（针对 MoE 模型优化）：参数推荐值说明--dtypebfloat16MoE 模型必须用 bfloat16，auto 可能导致精度下降--port5000API 服务端口（可自定义）--max_model_len262144启用模型最大上下文长度（爆显存时可降至 131072）--gpu_memory_utilization0.8548GB 显存安全值（若爆显存，逐步降至 0.8 → 0.75）显存占用参考（48GB GPU）：上下文 262K：~41GB上下文 131K：~38GB上下文 65K：~35GB五、集成 Open WebUI（图形化聊天界面）# 启用网络加速（AutoDL 用户必备） source /etc/network_turbo # 设置环境变量（关键！） export HF_ENDPOINT=https://hf-mirror.com # Hugging Face 镜像加速 export ENABLE_OLLAMA_API=False # 禁用 Ollama 兼容层 export OPENAI_API_BASE_URL=http://127.0.0.1:5000/v1 # 指向 vLLM API export DEFAULT_MODELS="Qwen3.5-35B-A3B" # 必须与模型文件夹名一致 # 启动 WebUI（默认端口 8080，此处改为 6006） open-webui serve --port 6006访问界面浏览器打开：👉 http://你的服务器IP:6006六、多卡部署（扩展参考）注意：Qwen3.5-35B-A3B 仅支持张量并行（Tensor Parallelism），不支持流水线并行。# 2 卡示例（如 2×A6000） vllm serve ./Qwen3.5-35B-A3B \ --dtype bfloat16 \ --port 5000 \ --tensor-parallel-size 2 \ --gpu_memory_utilization 0.8 \ --max_model_len 262144并行策略：--tensor-parallel-size N：必须等于 GPU 数量（如 2 卡设为 2）。不要设置 --pipeline-parallel-size：MoE 模型不兼容。七、OpenAI 格式 API 调用启动兼容 API 服务（等效于 vllm serve）python -m vllm.entrypoints.openai.api_server \ --served-model-name Qwen3.5-35B-A3B \ --model ./Qwen3.5-35B-A3B \ --dtype bfloat16 \ --port 5000 \ --max_model_len 262144 \ --gpu_memory_utilization 0.85Python 调用示例from openai import OpenAI client = OpenAI( base_url="http://localhost:5000/v1", api_key="not-needed" ) response = client.chat.completions.create( model="Qwen3.5-35B-A3B", messages=[{"role": "user", "content": "请用 262K 上下文分析以下代码库..."}], max_tokens=500 ) print(response.choices[0].message.content)

从Google Authenticator解密获取2FA密钥备份教程 前言启用2FA可以有效的保证账户安全，但一旦手机丢失或者换手机等操作不当丢失2FA密钥就会导致账户可能再也无法找回。Google Authenticator是一个常用的二步验证动态口令生成工具，支持设备间转移和google云备份，但是在软件内不能直接查看到密钥，不能很方便的进行密钥的本地保存和备份，或者是迁移到其它2FA平台。这里介绍一个从Google Authenticator解密获取到2FA密钥的工具和使用方法。操作过程导出配置文件二维码打开Google Authenticator，点击左上角的三条横线按钮，选择转移账号选择导出账号勾选需要导出的账号并点击下一步这里我们会看到一个二维码，截图保存为文件，比如ga.jpg使用decodeGoogleOTP工具解码为了方便整个过程，我写了一个命令行工具decodeGoogleOTP，前往Github下载页面，根据自己的平台，下载最新版本的工具。https://github.com/Kuingsmile/decodeGoogleOTP/releases下载后解压，为了方便操作可以重命名一下，比如windows平台重命名为decodeGoogleOTP.exe，然后和ga.jpg放在一个文件夹下。decodeGoogleOTP支持将结果导出为csv文件、json文件、txt文件或者二维码图片等多种格式。如果我们需要将结果导出为json文件，运行如下命令即可decodeGoogleOTP -i ga.jpg -c output.json输出的结果格式如下：[ { "issuer": "", "name": "xx", "secret": "AAAAAAAAAAA", "type": "totp", "counter": 0, "url": "otpauth://totp/xx?secret=AAAAAAAAAAA" } ]其中secret字段就是2FA密钥，有了密钥就可以方便的转移到其它平台。而url可以用来生成二维码供其它2FA软件扫描导入，也可以使用decodeGoogleOTP直接导出二维码图片供扫描