Chifan's Blog

DeepSeek的推理死循环问题

Mon, 12 Oct 2026 12:31:29 +0800

let me go,let me write,let me run…

一开始觉得怪可爱的，有点英文诗的感觉。

现在才发现，这其实是推理死循环了，既浪费 token，又会生成几十万字符的巨型 thinking block，导致 TUI 打开历史会话时完全卡死。

一、TUI 卡顿排查（2026-10-07）

2026-10-07 那天我在用 PI 的时候，某一个对话突然卡的不得了。

一开始觉得可能是 herdr 的问题，也可能是终端的问题（换了 Omarchy 无论遇到什么问题总是觉得是系统的问题）。但是也就只有那一个对话卡的不得了，其他的对话没事。对那个对话关闭，再打开，依然卡住。重启系统，再打开，还是卡住。

排查发现卡顿不是因为文件读取慢，而是卡在 TUI 渲染 thinking block：

渲染瓶颈：同一份会话只改 hideThinkingBlock，false 时 60 秒满核（~101 ticks/s）且一行都渲染不出；true 时 6 秒渲染出 25 行。RPC 模式和 --export 仅需 0.45 秒，/proc/<pid>/stat 确认 CPU 消耗全在 pi 进程自身，排除终端和 shell。
最小复现：单条 152,804 字符的 thinking 就会卡死；截断到 10,000 字符后 6 秒正常。
循环数据：原始会话里有 7 条超过 10 万字符的 thinking（最大一条 159,193 字符）。最长那条共 12,102 行，但只有 90 个唯一行：Let me go. 出现 4,034 次、Let me write. 3,322 次、OK. 1,991 次。
非 Pi 独有：给 OpenCode 注入 16 万字符文本块，CPU 同样从 1–2 ticks/s 飙到 102–104 ticks/s 满核。

在 settings.json 里设 "hideThinkingBlock": true 能避免打开卡死，但治标不治本——模型依然会陷入死循环、浪费 token 并写入巨型文本。

二、Magpie 的死循环熔断（2026-10-12）

Magpie 在 v0.1.1142（2026-10-09）引入了推理死循环检测。10 月 12 日遇到了主动熔断报错：

Error: magpie ended this reply:
the model's reasoning was stuck in a loop,
its last 256 lines and sentences all among
the same 24 ("Let me go." "Let me write." "Let me run." …),
and would have run on to its output limit.

它检测到最后 256 行只有 24 种不同句子时主动中断生成，正好命中了这个问题，能及时止损 token 并限制 thinking block 体积。不过 Magpie 目前只做到了检测和熔断，还不会自动恢复。

三、中断后的处理：用 `/tree` 回退

循环被掐断后，不建议直接说「继续」——在相同的上下文下，模型极易再次陷入死循环。因为推理过程依然存在上下文，之前中断的推理过程，依然会正反馈影响「继续」后的推理。

更稳妥的做法是用 Pi 的 /tree 切回循环发生前的节点：

如果旧分支全是重复打转，选 No summary，避免将死循环内容带入新分支。
如果旧分支已完成了有效工作，选 Summarize 或 Summarize with custom prompt，只保留结论和进展。

注意：/tree 切换的是会话上下文，已修改的工作区文件不会跟着回滚。

至于其他的 agent 有没有这个功能我就不知道了。

四、目前的应对策略

开启 Magpie 的循环检测及时熔断。
配置 "hideThinkingBlock": true 避免历史会话卡死。
遇到死循环用 /tree 回退到正常节点重新生成。

目前这套流程依然需要人工介入。更理想的机制是 Magpie 或 Agent 框架在检测到死循环后，能自动丢弃异常推理并从上一有效状态重试

后面或许可以向 Magpie 提个 issue，看看有没有继续完善这个功能的想法。

另 magpie 真的比 cc-switch 好用,强烈推荐使用。

backupctl --用restic的备份脚本

Wed, 12 Aug 2026 23:55:12 +0800

掐指一算，明天 codex 最后一张重置卡过期，宜蹬些代码。

Backupctl 是我在 2026-08-12 搞的另一个 VPS 备份方案，目前效果还不是很好。

V1 是纯 shell 实现；V2 是 shell 实现 install 脚本，Python 实现功能模块。

V2 搞了一个 CLI 的功能，通过 backupctl 控制备份和测试。现在 AI 还是擅长使用 CLI，整一个准没错。

当前方案

现在这套方案大致分成几层：

网络层：Tailscale
传输层：SFTP / HTTPS
备份层：Restic
调度层：systemd
通知层：Telegram

其中：

Tailscale 负责远程组网；
SFTP 负责 NAS 方向的远程传输；
Restic 负责备份、加密、快照和去重；
systemd timer 负责定时调度；
Telegram Bot API 负责通知。

用 Restic 实现类似增量备份的效果：就是将文件创建一个逻辑快照，再将文件切成数据块，已经存在的相同数据块不会上传，仅仅上传每次备份不同的数据块。Restic 的设计文档也说明了快照、内容分块和去重机制。Restic 设计文档增量备份与差异备份——数据备份策略之间的区别

备份目标包括 Backblaze B2 对象存储和 NAS。

缺点就是暂时不能备份数据库。数据库需要单独使用 mysqldump 或者其他命令导出，再使用 Restic 备份导出文件；否则直接备份正在运行的数据库文件，可能会出现一致性问题。

上一个备份方案则是使用 tar gzip 打包压缩，使用 rsync 远程传输，用 Tailscale 实现远程组网，NAS 备份。缺点就是没有加密，而且是全量备份。

遇到的一些问题

有一些开发问题，主要还是和 AI 协作的问题。

当我鞭策 AI 写出新的脚本的时候，其实效果不太好，即使我用的是 sol xhig + plan 模式。

说到这个 plan 模式，我发现现在其实不需要使用者自己去设计 herdness ，我用的 oh-my-pi 和 codex 都有 plan 模式。但是这个 plan 模式也不是万能的，plan 模式我都是给的强推理的强力模型（看别人都是用强力模型规划，普通模型写代码）。但是做出来的效果也不太符合我的预期，做出来之后也没有变得简单和更能掌握这个项目，用 plan 模式的时候应该用 grill-me 这个 skill 拷打一下才行。~~superpower 已经过气了~~

一来是因为 APT 的 Restic 版本太过落后，一些性能问题、SFTP 的问题还没修好；
二来是 Tailscale 组网的端对端延迟过高，在做核对关联的时候需要反复确认。每次核对确认都要走 200 ms 的 RTT ，网络开销自然高，用的时间也多。
三来是为了继承旧的备份脚本使用 shell 的传统，新的方案也全是用 shell，结果整得挺复杂的，给我带来挺大理解负担。我一直觉得，如果某种工具过于强大而全面，还不如去用符合自己需求的简单工具，KISS 嘛。第一版 shell 的备份脚本搞好之后，还是让 AI 用 Python 重构了，希望代码量少一些，结果代码量其实差不多；
第四点就是写第一个版本的时候，又想试一下 subagent 的能力，又想省一些 terra max 档位，结果就是 terra 的能力不太行，干活时一直被 PowerShell 转义绊倒。像 sol 就能在我不提醒的情况下，用 base 64 编码执行 ssh -o 命令，避免转义问题。还有就是 subagent 干活真的很慢。真要用，应该开几个 subagent 分工干不同功能模块的活。结果就是开 subagent，terra 在吭哧吭哧干活，sol 在旁边看戏，偶尔指导两句；
V1 -> V2 重构的效果也不是很好。现在想起来，应该在旧的对话里面写一份交接文档，然后开一个新的对话开始重构。因为过度信任 sol xhigh 的能力，以为它能看出整个项目的功能点，结果最后给我遗漏了 Telegram 通知的功能（如果是一个大项目不敢想会出多少 BUG）；
还有一个就是让提交到 GitHub 个人仓库里面，直接把我的 VPS 信息、配置目录也上传上去了。虽然没有把 .env 上传上去，但总感觉有些异味；
一开始在我问为什么 SFTP + Tailscale 会检查耗时、什么耗时的时候，只给我结论。~~这个是唯一让我觉得红温的~~；
已经配置了 draw.io MCP ，在收尾的时候，让画一份 draw.io 的草图，居然没有触发 MCP，而是打算用 XML 给我画草图。还是我说明了用 draw.io，才给我用 XML。画 draw.io 的时候还在用 /n 作为换行符；
还有一个问题是，codex 像一个过度谨慎的人，不愿意犯错（也可能是我本能不希望 codex 犯错）。之前使用的时候就有感觉，codex 喜欢简单的东西复杂化，过度规划~~2026-07-25 发现的做 PPT 过度规划校验的问题~~。完全可以先起一个 demo ，然后再去扩展。尤其是现在用上 plan 模式之后，感觉更加孤僻了（完全不听劝埋头苦干）。

想睡觉了就先写这么多了，明天再研究一下能不能用 skill 或者全局提示词改一下 codex 的行为。

文件锁

框架锁： /run/lock/backup-framework.lock，防止同时运行备份行为。外部锁：/run/lock/vaultwarden-backup.lock ，防止新旧两个框架同时运行。

# 查找锁的持有进程
lslocks | grep something

在 Linux 中，“一切皆文件”（包括普通文件、目录、网络套接字、设备、管道等）。所以其实也是能用 lsof List Open Files（列出打开的文件）查看当前系统中所有进程正在使用的资源。

# 查找哪个进程占用文件
lsof /var/log/syslog

# 查找占用80端口的进程
lsof -i :80

# 查看某个进程打开了什么文件
lsof -p 1234

Systemctl timer

一般来说计时器控制服务的定时运行，当出现一些异常状况比如恰好前面停电，而开机在计时器预定时间之后，就会立刻执行一次服务的执行。~~在学校晚上断电的时候就很有用~~

定时任务归 systemd 管，也可以用 journalctl 查看。

服务文件： /etc/systemd/system/backup-db.service

[Unit]
Description=Backup MySQL database
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-mysql.sh
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

计时器文件：/etc/systemd/system/backup-db.timer

[Unit]
Description=Run backup-db service daily at 2 AM

[Timer]
# 每天凌晨 2 点执行
OnCalendar=*-*-* 02:00:00
# 如果系统关机错过了，开机后立即补执行
Persistent=true
# 允许误差 1 分钟，避免多个任务同时触发
RandomizedDelaySec=60

[Install]
WantedBy=timers.target

启动：

systemctl start mytask.timer
systemctl enable mytask.timer

systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2026-08-13 00:00:00 CST 43min left - - dpkg-db-backup.timer dpkg-db-backup.service
Thu 2026-08-13 00:00:00 CST 43min left Wed 2026-08-12 06:00:42 CST 17h ago logrotate.timer logrotate.service
Thu 2026-08-13 03:30:00 CST 4h 13min left Wed 2026-08-12 19:19:51 CST 3h 57min ago backup-all.timer backup-all.service
Thu 2026-08-13 06:08:41 CST 6h left Wed 2026-08-12 12:10:07 CST 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Thu 2026-08-13 11:09:58 CST 11h left Wed 2026-08-12 11:09:58 CST 12h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2026-08-13 13:28:56 CST 14h left Wed 2026-08-12 19:03:58 CST 4h 12min ago apt-daily.timer apt-daily.service
Sun 2026-08-16 03:10:46 CST 3 days left Sun 2026-08-09 09:10:04 CST 3 days ago e2scrub_all.timer e2scrub_all.service
Mon 2026-08-17 00:57:40 CST 4 days left Mon 2026-08-10 06:13:54 CST 2 days ago fstrim.timer fstrim.service

journalctl -u apt-daily-upgrade.timer
Aug 12 10:54:32 [hostname] systemd[1]: [timer]: Deactivated successfully.
Aug 12 10:54:32 [hostname] systemd[1]: Stopped [timer] - Daily apt upgrade and clean activities.
-- Boot [boot-id] --
Aug 12 10:55:02 [hostname] systemd[1]: Started [timer] - Daily apt upgrade and clean activities.

本地备份

不能把钥匙放在保险柜里面，对于 restic 的密码来说，不能继续存在 vaultwarden 里面。

我也早就不想把把一些重要的入口密码交给云备份了。

可以考虑用下面的工具存放，文件都是 .kdbx 格式。一份放在手机，一份放在电脑，感觉就差不多了。 keepassxc 支持 Windows、Linux、macOS。 KeePassDX 支持 Android。

TODO

rest-server 似乎能解决 restic 使用 SFTP 的网络开销问题，改天搭建试试看。

毕竟我用 NAS 一个主要目的是跑备份，能方便备份也不错。

Spicetify使用ivlyrics翻译歌词优化Spotify歌词体验

Fri, 17 Jul 2026 17:19:09 +0800

不用 lyricsfy4 给 Spotify 完善歌词功能。

Spotify 的歌词一直很简陋，大多数歌曲是没有翻译的，而冷门的歌曲更是连歌词都没有。有一个很好的解决办法就是使用 lyricsfy 4 。这个也是维护了很久，很符合国人的使用习惯。

但使用 lyricsfy 4 是用 Electron 写的，内存占用太多了，没必要为了看翻译歌词单独开一个 Electron 应用。问了下 AI 有没有什么其他好更优雅的方案，发现还是有的。

一般是使用 spicetify 配合其他的插件使用。下面是配合 ivlyrics 完善歌词体验。

Spicetify

Spicetify 是 Spotify 的桌面客户端第三方插件加载工具。功能是：

修改 Spotify 的网页界面文件 xpui
加载主题、Extensions 和 CustomApps
为 ivLyrics 这类项目生成路由文件

scoop install spicetify-cli

官方文档写了对于非标准路径安装的 Spotify 需要设置：

$ scoop prefix spotify
C:\Users\<username>\scoop\apps\spotify\current

# 查看配置
spicetify config

# 添加 Custom App
spicetify config custom_apps ivLyrics

# 移除 Custom App 配置
spicetify config custom_apps ivLyrics-

# 将配置和插件应用到 Spotify
spicetify apply

# 撤销全部 Spicetify 修改，恢复原版 Spotify
spicetify restore

# 更新 Spicetify 自身
spicetify update

一般安装了插件之后，spicetify apply 重启 Spotify 就可以让插件生效。

插件 ivLyrics 安装

下载 ivLis-Studio/ivLyrics。使用脚本安装，安装后 spicetify apply 重启 Spotify。出现 ivlyrics 的选项但是点进去提示出错了。

排查是脚本将 ivLyrics 放进了 LocalAppData。正确做法是放入 roaming 里面。 local 一般是放只属于这台电脑的数据，roaming 则是放跟着用户走的数据。

对比项	%APPDATA% (Roaming)	%LOCALAPPDATA% (Local)
是否漫游	会漫游	不漫游
适用场景	需要跟随用户账号同步的配置	仅限本机的数据
数据特点	体积较小、重要配置文件	体积较大、缓存、临时文件、机器相关数据
域环境行为	漫游用户配置文件时会同步到服务器	不会同步，留在本地
典型用途	软件设置、快捷方式配置、用户偏好	浏览器缓存、游戏存档缓存、大型临时文件、日志

一般来说，spicetify 是安装在 local 目录下面，但是我是用 scoop 安装的有点不太一样。

可以通过 spicetify config-dir 命令查看 spicetify 的配置目录。

将 localappdata 里面的配置移动到 roaming 就能使用了。

$src = "$env:LOCALAPPDATA\spicetify\CustomApps\ivLyrics"
$dst = "$env:APPDATA\spicetify\CustomApps\ivLyrics"

Get-Process Spotify -ErrorAction SilentlyContinue | Stop-Process -Force

Remove-Item -LiteralPath $dst -Recurse -Force
New-Item -ItemType Junction -Path $dst -Target $src | Out-Null

spicetify apply

提了个 PR 把 Windows 硬编码的问题搞好了。有点奇怪的是作者测试的时候将安装脚本放到仓库里面，测试完成又删掉，给作者提建议之后就把安装脚本放到仓库里面了。这种行为未免太过不安全太过可疑，所以还是建议手动下载放到对应目录。

能打开 ivlyrics 后配置一些东西，然后加上 AI API 就能实现翻译歌词了。

用上之前薅的 grok super。

网易云插件

Ivlyrics 自带一个插件市场，发现居然还有网易云歌词插件。

需要配置一个 CORS 代理。考虑到地区的原因，尽量用国内的 IP。

CORS 是浏览器的“跨网站访问许可机制”。CORS 代理的作用是让代理代替浏览器访问网易云接口，再把结果安全地转交给插件。

浏览器有一个叫“同源策略”的安全限制。比如插件运行在 https://spotify.example ，直接请求 https://music.163.com/api/song/lyric 。两个地址的域名不同，浏览器会检查网易云响应中有没有允许跨域访问的响应头。如果没有，即使网易云已经返回数据，浏览器也不会把数据交给插件。

所以需要对网易云返回的数据做一些处理，到达浏览器之前，让其看起来是允许跨域访问。

要么是用国内的 VPS 的 web 服务器搓一个，不过这么简单的需求，其实可以用 worker 来实现。由于我的备案域名在阿里云我就用了阿里的边缘函数。

让 AI 搓一个 CORS PROXY：

/**
 * NetEase Music CORS proxy for Alibaba Cloud ESA Edge Functions.
 *
 * Add-on configuration:
 * https://YOUR_DOMAIN/?url={url}
 *
 * Security model:
 * - HTTPS only
 * - music.163.com only
 * - /api/* only
 * - GET, HEAD and OPTIONS only
 * - Never forwards the caller's cookies or authorization headers
 */

const ALLOWED_HOSTS = new Set(["music.163.com"]);
const ALLOWED_PATH_PREFIXES = ["/api/"];
const MAX_TARGET_URL_LENGTH = 4096;

function corsHeaders() {
 return {
 "Access-Control-Allow-Origin": "*",
 "Access-Control-Allow-Methods": "GET, HEAD, OPTIONS",
 "Access-Control-Allow-Headers":
 "Accept, Accept-Language, Content-Type, Origin, X-Requested-With",
 "Access-Control-Expose-Headers":
 "Content-Type, Content-Length, Date, ETag, Last-Modified",
 "Access-Control-Max-Age": "86400",
 "X-Content-Type-Options": "nosniff",
 };
}

function jsonResponse(data, status = 200) {
 const headers = new Headers(corsHeaders());
 headers.set("Content-Type", "application/json; charset=utf-8");
 headers.set("Cache-Control", "no-store");

 return new Response(JSON.stringify(data), {
 status,
 headers,
 });
}

function parseTarget(requestUrl) {
 const proxyUrl = new URL(requestUrl);
 let rawTarget = proxyUrl.searchParams.get("url");

 if (!rawTarget) {
 return { error: "Missing query parameter: url", status: 400 };
 }

 rawTarget = rawTarget.trim();

 // URLSearchParams normally decodes the value once. This extra pass also
 // accepts clients that encode the target URL twice.
 if (!/^https?:\/\//i.test(rawTarget)) {
 try {
 rawTarget = decodeURIComponent(rawTarget);
 } catch (_) {
 return { error: "Invalid URL encoding", status: 400 };
 }
 }

 if (rawTarget.length > MAX_TARGET_URL_LENGTH) {
 return { error: "Target URL is too long", status: 414 };
 }

 let target;
 try {
 target = new URL(rawTarget);
 } catch (_) {
 return { error: "Invalid target URL", status: 400 };
 }

 if (target.protocol !== "https:") {
 return { error: "Only HTTPS targets are allowed", status: 403 };
 }

 if (
 target.username ||
 target.password ||
 (target.port && target.port !== "443")
 ) {
 return { error: "Credentials and non-standard ports are not allowed", status: 403 };
 }

 const hostname = target.hostname.toLowerCase();
 if (!ALLOWED_HOSTS.has(hostname)) {
 return { error: "Target host is not allowed", status: 403 };
 }

 const pathAllowed = ALLOWED_PATH_PREFIXES.some((prefix) =>
 target.pathname.startsWith(prefix)
 );
 if (!pathAllowed) {
 return { error: "Target path is not allowed", status: 403 };
 }

 // Fragments are never sent in HTTP requests.
 target.hash = "";
 return { target };
}

function addCorsToUpstreamResponse(upstream) {
 const response = new Response(upstream.body, upstream);

 // Do not leak upstream cookies or preserve conflicting CORS policy.
 response.headers.delete("Set-Cookie");
 response.headers.delete("Set-Cookie2");
 response.headers.delete("Access-Control-Allow-Origin");
 response.headers.delete("Access-Control-Allow-Credentials");

 const cors = corsHeaders();
 for (const name of Object.keys(cors)) {
 response.headers.set(name, cors[name]);
 }

 response.headers.set("X-Cors-Proxy", "aliyun-esa");
 return response;
}

async function handleRequest(request) {
 const method = request.method.toUpperCase();

 if (method === "OPTIONS") {
 return new Response(null, {
 status: 204,
 headers: corsHeaders(),
 });
 }

 if (method !== "GET" && method !== "HEAD") {
 return jsonResponse(
 { ok: false, error: "Method not allowed" },
 405
 );
 }

 const requestUrl = new URL(request.url);
 if (requestUrl.pathname === "/health") {
 return jsonResponse({
 ok: true,
 service: "netease-cors-proxy",
 });
 }

 const parsed = parseTarget(request.url);
 if (parsed.error) {
 // Make the root URL convenient to open while setting up the function.
 if (
 parsed.status === 400 &&
 requestUrl.pathname === "/" &&
 !requestUrl.searchParams.has("url")
 ) {
 return jsonResponse({
 ok: true,
 service: "netease-cors-proxy",
 usage: "https://YOUR_DOMAIN/?url={url}",
 });
 }

 return jsonResponse(
 { ok: false, error: parsed.error },
 parsed.status
 );
 }

 const upstreamHeaders = new Headers();
 upstreamHeaders.set("Accept", "application/json, text/plain, */*");
 upstreamHeaders.set("Accept-Language", "zh-CN,zh;q=0.9,en;q=0.8");
 upstreamHeaders.set("Origin", "https://music.163.com");
 upstreamHeaders.set("Referer", "https://music.163.com/");
 upstreamHeaders.set(
 "User-Agent",
 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " +
 "(KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
 );
 upstreamHeaders.set("Cookie", "os=pc");

 try {
 const upstream = await fetch(parsed.target.toString(), {
 method,
 headers: upstreamHeaders,
 redirect: "manual",
 });

 // Do not let an upstream redirect turn this into a proxy for another host.
 if (upstream.status >= 300 && upstream.status < 400) {
 return jsonResponse(
 { ok: false, error: "Upstream redirect was blocked" },
 502
 );
 }

 return addCorsToUpstreamResponse(upstream);
 } catch (error) {
 return jsonResponse(
 {
 ok: false,
 error: "Upstream request failed",
 detail: String(error && error.message ? error.message : error),
 },
 502
 );
 }
}

export default {
 async fetch(request) {
 return handleRequest(request);
 },
};

页面展示

歌词效果还是不错的：

歌词悬浮窗：

黑胶页面：

cc-swtich 切换skills agent时提示"创建符号链接失败"问题解决

Wed, 15 Jul 2026 11:23:36 +0800

点击迁移 Claude 选项后提示"创建符号链接失败"。

打开 Windows“设置”。
进入“系统 → 开发者选项”。
开启“开发人员模式”。
从系统托盘彻底退出 cc-switch，再重新打开并安装。

codex启动"GPT需要一次性权限才能在你的电脑运行"BUG解决

Tue, 14 Jul 2026 20:08:36 +0800

打开 ChatGPT 后，提示 “ChatGPT 需要一次性权限才能在你的电脑上运行”。但是点击后依然无法启动的情况。

基本上是在 .codex\config.toml 加了一些冲突的配置。我删除里面的 model_instructions_file = "C:/Users/123/.codex/instruction.md" 即可解决。

或者删掉 config.toml 创建让 CHATGPT 创建一个全新的文件。

思科模拟器企业组网

Fri, 24 Apr 2026 00:11:54 +0800

使用思科模拟器简单搭建一个企业网络

序

包含以下知识点:

双机热备
STP
无线 / AP 接入
DHCP / DNS / WEB / FTP 服务器
OSPF 动态路由
串口广域网
动态 NAT
2960：接入层二层交换机，只负责 Access / Trunk
3560：汇聚层三层交换机，负责 SVI + ip routing + HSRP + STP
4331：核心 / 出口路由器，负责 OSPF + 串口 + 默认路由 + NAT

IP 分配

192.168.11.0/24：服务器区，DHCP / DNS / WEB / FTP 所在网段
192.168.12.0/24：服务器接入路由器到核心路由器
192.168.13.0/24：核心路由器到总公司接入路由器
192.168.14.0/24、192.168.15.0/24：总公司接入路由器与双核心交换机之间的三层互联
192.168.17.0/24：核心路由器到出口路由器
100.1.1.0/24：出口到外网路由器
192.168.1.0/24 到 192.168.8.0/24：业务 VLAN 网段

技术	解决的问题	关键点
`VLAN + Trunk`	二层隔离与跨交换机承载多个 VLAN	Access 口给终端，Trunk 口给交换机 / 汇聚
`STP`	二层冗余链路防环	通过选根桥和阻塞端口避免广播风暴
`HSRP`	默认网关冗余	客户端始终指向虚拟 IP，不关心当前主设备是谁
`SVI + ip routing`	VLAN 间路由	三层交换机必须开启 `ip routing`
`ip helper-address`	跨网段 DHCP	把广播转换为单播转发到 DHCP 服务器
`OSPF`	全网动态路由	只在真正的三层邻居之间建邻接
`NAT`	私网访问公网	出口路由器要分清 `inside / outside`
`默认路由`	去未知网段的出口方向	常在出口设备上配置，并发布给内部

内部服务器配置

服务器区需要配置 WEB、DNS、DHCP、FTP，其中最关键的是 DHCP。

基本要求：

所有服务器都用静态 IP
正确填写默认网关
DNS 服务器为 WEB 服务器添加 A 记录
DHCP 地址池为各 VLAN 分配地址、网关、DNS
FTP 配置本地用户名和密码
WEB 开启 HTTP 和 HTTPS

DHCP 地址池示意：

FTP 服务器配置用户名和密码。

同时需要给内部服务器配置静态 IP 和网关。

路由器与交换机配置

1. 服务器接入路由器

作用：

连接服务器区和园区核心
为非本地网段的客户端转发 DHCP 请求

interface GigabitEthernet0/0/0
 ip address 192.168.11.5 255.255.255.0

interface GigabitEthernet0/0/1
 ip address 192.168.12.1 255.255.255.0
 ip helper-address 192.168.11.3

router ospf 10
 log-adjacency-changes
 network 192.168.11.0 0.0.0.255 area 0
 network 192.168.12.0 0.0.0.255 area 0

说明：

ip helper-address 192.168.11.3 表示把 DHCP 广播转发给中心 DHCP 服务器
router ospf 10 里的 10 是本地进程号，只在本设备上有意义，不要求全网一致

2. 核心路由器

作用：

连接服务器区、总公司园区、串口广域网和出口路由器
是整个实验的三层骨干之一

interface GigabitEthernet0/0/0
 ip address 192.168.12.2 255.255.255.0

interface GigabitEthernet0/0/1
 ip address 192.168.13.1 255.255.255.0
 ip helper-address 192.168.11.3

interface Serial0/2/0
 ip address 192.168.16.1 255.255.255.0
 ip helper-address 192.168.11.3

interface Serial0/2/1
 ip address 192.168.17.1 255.255.255.0
 clock rate 64000

router ospf 20
 log-adjacency-changes
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.13.0 0.0.0.255 area 0
 network 192.168.16.0 0.0.0.255 area 0
 network 192.168.17.0 0.0.0.255 area 0

说明：

串口如果是 DCE 端，需要 clock rate 64000
这里依然把 DHCP 请求中继到 192.168.11.3
这台设备是很多网段的汇聚点，一旦 OSPF 漏宣告，这里最容易出问题

3. 出口路由器

作用：

对内连接企业私网
对外连接 ISP / 模拟互联网
做动态 NAT，并向 OSPF 发布默认路由

interface Serial0/1/0
 ip address 192.168.17.2 255.255.255.0
 ip nat inside

interface Serial0/1/1
 ip address 100.1.1.1 255.255.255.0
 ip nat outside
 clock rate 64000

router ospf 80
 log-adjacency-changes
 network 192.168.17.0 0.0.0.255 area 0
 default-information originate

ip nat pool DZC 100.1.1.3 100.1.1.10 netmask 255.255.255.0
ip nat inside source list 1 pool DZC
ip classless
ip route 0.0.0.0 0.0.0.0 100.1.1.2

access-list 1 permit 192.168.0.0 0.0.255.255

说明：

ip nat inside source list 1 pool DZC 是动态 NAT 地址池，不是 PAT
如果希望很多内网主机共享少量公网地址，通常写成 overload
default-information originate 的前提是本机路由表里已经有默认路由，所以 ip route 0.0.0.0 0.0.0.0 100.1.1.2 不能漏
inside / outside 配反时，NAT 一定不生效

4. 外网路由器

interface Serial0/1/0
 ip address 100.1.1.2 255.255.255.0

interface GigabitEthernet0/0/0
 ip address 100.1.2.1 255.255.255.0

这一台主要用于模拟 ISP / 互联网，只要把去出口的下一跳配通即可。

5. 总公司接入路由器

作用：

上联核心路由器
下联双核心交换机
其中 NIM-ES 2-4 模块提供的是二层交换口，所以需要用 VLAN + SVI 的方式承载三层地址

interface GigabitEthernet0/0/0
 ip address 192.168.13.2 255.255.255.0

interface GigabitEthernet0/0/1
 ip address 192.168.14.1 255.255.255.0
 ip helper-address 192.168.11.3

interface GigabitEthernet0/1/0
 switchport mode access
 switchport access vlan 101

interface Vlan101
 mac-address 0060.471d.b601
 ip address 192.168.15.1 255.255.255.0
 ip helper-address 192.168.11.3

router ospf 50
 log-adjacency-changes
 network 192.168.13.0 0.0.0.255 area 0
 network 192.168.14.0 0.0.0.255 area 0
 network 192.168.15.0 0.0.0.255 area 0

说明：

NIM-ES 模块出来的是交换端口，不能一边 no switchport 一边又 switchport mode access
正确思路是把物理口加入 VLAN 101，然后把 IP 配在 interface Vlan101 上
与它相连的交换机接口也要落到同一个 VLAN

与之相连的交换机接口示例：

interface FastEthernet0/8
 switchport mode access
 switchport access vlan 101

6. 双机热备与双核心交换机

这部分是整套实验最容易配乱的地方。建议先明确三个事实：

三层交换机必须先开启 ip routing
HSRP 给终端提供虚拟网关
OSPF 只在真正连接到三层邻居的接口上建邻接，普通用户 VLAN 接口一般保持 passive

先看 OSPF 的思路：

router ospf 60
 passive-interface default
 no passive-interface FastEthernet0/1
 network 192.168.1.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0
 network 192.168.3.0 0.0.0.255 area 0
 network 192.168.4.0 0.0.0.255 area 0
 network 192.168.5.0 0.0.0.255 area 0
 network 192.168.10.0 0.0.0.255 area 0
 network 192.168.14.0 0.0.0.255 area 0

这段配置的意思不是“VLAN 口不能跑 OSPF”，而是：

默认所有接口都不发 Hello
只有真正要与其他三层设备建邻居的口，才用 no passive-interface 打开
普通接用户的 SVI 依然可以被 network 宣告进 OSPF，只是不参与邻居建立

左侧多层交换机

特点：

作为 VLAN 10 / 20 / 30 的主网关
同时承担这些 VLAN 的 STP 主根桥

ip routing
spanning-tree mode pvst
spanning-tree vlan 10,20,30 priority 24576
spanning-tree vlan 40,50 priority 28672

interface FastEthernet0/1
 no switchport
 ip address 192.168.14.2 255.255.255.0

interface FastEthernet0/2
 switchport mode access
 switchport access vlan 100

interface FastEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/4
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/5
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/6
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/7
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/8
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/9
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface Vlan10
 mac-address 0001.c950.e401
 ip address 192.168.1.1 255.255.255.0
 ip helper-address 192.168.11.3
 standby 10 ip 192.168.1.254
 standby 10 priority 101
 standby 10 preempt
 standby 10 track FastEthernet0/1

interface Vlan20
 mac-address 0001.c950.e402
 ip address 192.168.2.1 255.255.255.0
 ip helper-address 192.168.11.3
 standby 20 ip 192.168.2.254
 standby 20 priority 101
 standby 20 preempt
 standby 20 track FastEthernet0/1

interface Vlan30
 mac-address 0001.c950.e403
 ip address 192.168.3.1 255.255.255.0
 ip helper-address 192.168.11.3
 standby 30 ip 192.168.3.254
 standby 30 priority 101
 standby 30 preempt
 standby 30 track FastEthernet0/1

interface Vlan40
 mac-address 0001.c950.e404
 ip address 192.168.4.1 255.255.255.0
 ip helper-address 192.168.11.3
 standby 40 ip 192.168.4.254
 standby 40 preempt
 standby 40 track FastEthernet0/1

interface Vlan50
 mac-address 0001.c950.e405
 ip address 192.168.5.1 255.255.255.0
 ip helper-address 192.168.11.3
 standby 50 ip 192.168.5.254
 standby 50 preempt
 standby 50 track FastEthernet0/1

interface Vlan100
 mac-address 0001.c950.e406
 ip address 192.168.10.254 255.255.255.0
 ip helper-address 192.168.11.3

router ospf 60
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/1
 network 192.168.14.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0
 network 192.168.3.0 0.0.0.255 area 0
 network 192.168.4.0 0.0.0.255 area 0
 network 192.168.5.0 0.0.0.255 area 0
 network 192.168.10.0 0.0.0.255 area 0

右侧多层交换机

特点：

作为 VLAN 40 / 50 的主网关
同时承担这些 VLAN 的 STP 主根桥

ip routing
spanning-tree mode pvst
spanning-tree vlan 40,50 priority 24576
spanning-tree vlan 10,20,30 priority 28672

interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/4
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/5
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/6
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/7
 switchport mode access
 switchport access vlan 110

interface FastEthernet0/8
 switchport mode access
 switchport access vlan 101

interface Vlan10
 mac-address 0001.c74b.9801
 ip address 192.168.1.2 255.255.255.0
 ip helper-address 192.168.11.3
 standby 10 ip 192.168.1.254
 standby 10 preempt
 standby 10 track FastEthernet0/8

interface Vlan20
 mac-address 0001.c74b.9802
 ip address 192.168.2.2 255.255.255.0
 ip helper-address 192.168.11.3
 standby 20 ip 192.168.2.254
 standby 20 preempt
 standby 20 track FastEthernet0/8

interface Vlan30
 mac-address 0001.c74b.9803
 ip address 192.168.3.2 255.255.255.0
 ip helper-address 192.168.11.3
 standby 30 ip 192.168.3.254
 standby 30 preempt
 standby 30 track FastEthernet0/8

interface Vlan40
 mac-address 0001.c74b.9804
 ip address 192.168.4.2 255.255.255.0
 ip helper-address 192.168.11.3
 standby 40 ip 192.168.4.254
 standby 40 priority 101
 standby 40 preempt
 standby 40 track FastEthernet0/8

interface Vlan50
 mac-address 0001.c74b.9805
 ip address 192.168.5.2 255.255.255.0
 ip helper-address 192.168.11.3
 standby 50 ip 192.168.5.254
 standby 50 priority 101
 standby 50 preempt
 standby 50 track FastEthernet0/8

interface Vlan101
 mac-address 0001.c74b.9807
 ip address 192.168.15.2 255.255.255.0

interface Vlan110
 mac-address 0001.c74b.9806
 ip address 192.168.11.1 255.255.255.0
 ip helper-address 192.168.11.3

router ospf 70
 log-adjacency-changes
 passive-interface default
 no passive-interface Vlan101
 network 192.168.1.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0
 network 192.168.3.0 0.0.0.255 area 0
 network 192.168.4.0 0.0.0.255 area 0
 network 192.168.5.0 0.0.0.255 area 0
 network 192.168.11.0 0.0.0.255 area 0
 network 192.168.15.0 0.0.0.255 area 0

补充说明：

左右两台交换机都要 ip routing
standby x priority 101 的一侧会优先成为 Active
track 上联口断开时，会降低优先级，方便主备切换
右侧设备上 Vlan101 是三层互联 VLAN，所以取消 passive 是合理的
普通用户 VLAN 如果没有直接连接三层邻居，就不需要 no passive-interface

7. 分公司接入路由器

interface FastEthernet0/1
 no switchport
 ip address 192.168.18.2 255.255.255.0
 duplex auto
 speed auto

interface FastEthernet0/2
 switchport mode access
 switchport access vlan 80

interface FastEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface FastEthernet0/4
 switchport trunk encapsulation dot1q
 switchport mode trunk

interface Vlan60
 mac-address 0009.7c59.3801
 ip address 192.168.6.254 255.255.255.0
 ip helper-address 192.168.11.3

interface Vlan70
 mac-address 0009.7c59.3802
 ip address 192.168.7.254 255.255.255.0
 ip helper-address 192.168.11.3

interface Vlan80
 mac-address 0009.7c59.3803
 ip address 192.168.8.254 255.255.255.0
 ip helper-address 192.168.11.3

router ospf 40
 log-adjacency-changes
 network 192.168.6.0 0.0.0.255 area 0
 network 192.168.7.0 0.0.0.255 area 0
 network 192.168.8.0 0.0.0.255 area 0
 network 192.168.18.0 0.0.0.255 area 0

8. 二层交换机

二层交换机只做接入和转发，不承担网关职责。

interface FastEthernet0/1
 switchport mode trunk

interface FastEthernet0/2
 switchport mode trunk

interface FastEthernet0/3
 switchport mode access
 switchport access vlan 10

interface FastEthernet0/4
 switchport mode access
 switchport access vlan 10

路由协议

路由协议里最常见的是 OSPF，RIP 也仍然是实验、题目和小型拓扑里经常出现的内容。这个实验主体用的是 OSPF，但 RIP 也建议会配、会查、会和 OSPF 做比较。

OSPF

OSPF 会维护三张关键表：

邻居表：已经建立邻接关系的设备
链路状态数据库（LSDB）：全网链路状态信息
路由表：SPF 计算后的最优路径

工作过程可以粗记为：

用 Hello 发现邻居
交换 LSA
建立 LSDB
运行 SPF
安装路由

与 RIP 等距离矢量协议不同，OSPF 路由器不直接交换整张路由表，而是交换链路状态信息。

最基本的 OSPF 配置：

Router(config)# router ospf 10
Router(config-router)# network 192.168.11.0 0.0.0.255 area 0
Router(config-router)# network 192.168.12.0 0.0.0.255 area 0
Router(config-router)# passive-interface default
Router(config-router)# no passive-interface g0/0/1

几个关键点：

router ospf 10 里的 10 只是本机进程号，只在设备本地有意义
不同设备写成 1、10、20 都可以，不影响建邻
真正影响邻接是否建立的，是三层可达、Area 一致、Hello / Dead 定时器一致、认证一致，以及没有被 passive-interface 禁掉
passive-interface default 很适合企业网，默认把所有接口设为被动，只把真正需要建邻的口开放出来

常用 OSPF 检查命令：

show ip ospf neighbor
show ip protocols
show ip ospf
show ip route ospf

RIP

RIP 是典型的距离矢量协议，特点是简单，但能力也弱一些。

RIP 的几个考试 / 实验重点：

以“跳数”作为度量值
最大跳数是 15，16 代表不可达
周期性发送更新，默认大约每 30 秒一次
收敛速度比 OSPF 慢，不适合较大的企业网络
一般在小型拓扑、入门实验、简单分支网络里使用

如果要在实验里用 RIP，建议直接上 RIPv2：

Router(config)# router rip
Router(config-router)# version 2
Router(config-router)# no auto-summary
Router(config-router)# network 192.168.0.0
Router(config-router)# passive-interface default
Router(config-router)# no passive-interface g0/0/0
Router(config-router)# no passive-interface s0/1/0

说明：

version 2：开启 RIPv2，支持无类路由
no auto-summary：关闭自动汇总，这句在实验里基本可以当成必敲
network 192.168.0.0：让落在这个主类网络内的接口参与 RIP
passive-interface default：让接用户的接口不发 RIP 更新，只保留真正互联链路发送更新

如果希望出口路由器把默认路由下发给全网，可以这样写：

Router(config)# ip route 0.0.0.0 0.0.0.0 100.1.1.2
Router(config)# router rip
Router(config-router)# default-information originate

RIP 常用检查命令：

show ip route
show ip protocols
show ip rip database
debug ip rip

OSPF 和 RIP 可以这样粗记：

协议	类型	度量值	收敛速度	适用场景
`OSPF`	链路状态	Cost	快	企业园区、中大型网络
`RIP`	距离矢量	跳数	慢	小型网络、入门实验

STP 与 HSRP

STP 和 HSRP 经常一起出现，因为企业网络里既要“二层不成环”，也要“三层网关不单点”。

技术	控制什么	核心目的
`STP`	二层路径	防环路、防广播风暴
`HSRP`	三层网关	网关冗余、主备切换

STP

STP（Spanning Tree Protocol，生成树协议）的作用是：

在二层冗余链路中阻塞一部分端口，避免交换网络形成环路
当主链路故障时，再把备用链路放通

STP 里最重要的几个概念：

Root Bridge：根桥，整棵生成树的中心
Root Port：每台非根桥设备上，去往根桥的最佳端口
Designated Port：每个网段负责转发的端口
Blocking / Discarding：被阻塞的端口，不参与正常转发

这里用的是 PVST，常见配置有两种写法。

写法 1：直接指定主根和备根

Switch(config)# spanning-tree mode pvst
Switch(config)# spanning-tree vlan 40,50 root primary
Switch(config)# spanning-tree vlan 10,20,30 root secondary

写法 2：手工改优先级

Switch(config)# spanning-tree mode pvst
Switch(config)# spanning-tree vlan 10,20,30 priority 24576
Switch(config)# spanning-tree vlan 40,50 priority 28672

说明：

优先级越小，越容易成为根桥
root primary / root secondary 本质上也是自动帮你调优先级
Access 口如果确定只接终端，可以开 portfast，但不要在 Trunk 或交换机互联口上乱开

接入口常见的增强配置：

Switch(config)# interface range f0/3 - 24
Switch(config-if-range)# spanning-tree portfast
Switch(config-if-range)# spanning-tree bpduguard enable

常用 STP 检查命令：

show spanning-tree
show spanning-tree vlan 10
show spanning-tree root

HSRP

HSRP（Hot Standby Router Protocol，热备份路由协议）的作用是给终端提供一个“虚拟网关”，这样真实网关坏了，终端不用改默认网关，业务还能继续走。

HSRP 里最重要的概念：

Active：当前真正转发流量的设备
Standby：备用设备
Virtual IP：客户端填写的默认网关
Virtual MAC：跟着虚拟网关一起漂移的虚拟 MAC

最常见的 HSRP 配置：

Switch(config)# interface vlan 10
Switch(config-if)# ip address 192.168.1.1 255.255.255.0
Switch(config-if)# standby 10 ip 192.168.1.254
Switch(config-if)# standby 10 priority 101
Switch(config-if)# standby 10 preempt
Switch(config-if)# standby 10 track fastEthernet 0/1

每条命令的作用：

standby 10 ip 192.168.1.254：定义虚拟网关 IP
standby 10 priority 101：优先级高的一侧更容易成为 Active
standby 10 preempt：主设备恢复后允许重新抢回主用角色
standby 10 track fastEthernet 0/1：上联口挂了就自动降权，方便切到备机

常用 HSRP 检查命令：

show standby brief
show standby
show running-config interface vlan 10

为什么 STP 和 HSRP 要一起看

只配 HSRP 不看 STP，流量可能会绕路。

理想状态是：

VLAN 10 / 20 / 30 的 HSRP Active 和 STP Root 都落在左侧核心
VLAN 40 / 50 的 HSRP Active 和 STP Root 都落在右侧核心

这样二层路径和三层网关方向一致，终端发往网关的数据不会先绕到另一台核心再转发。

ACL

ACL（Access Control List，访问控制列表）本质上就是一串“从上到下匹配”的规则，用来决定哪些流量放行，哪些流量拒绝。

记住 ACL 的四条铁律：

自上而下逐条匹配
一旦命中，立即停止继续往下匹配
规则越具体，越应该写在前面
最后一条永远隐含 deny ip any any

标准 ACL 和扩展 ACL

类型	能匹配什么	常放位置	编号范围
标准 ACL	只看源 IP	靠近目的端	`1-99`、`1300-1999`
扩展 ACL	看源 / 目的 / 协议 / 端口	靠近源端	`100-199`、`2000-2699`

标准 ACL

标准 ACL 一般用来做“谁能来”，因为它只能看源地址。

示例 1：只允许网管网段远程登录设备

Router(config)# access-list 10 permit 192.168.10.0 0.0.0.255
Router(config)# line vty 0 4
Router(config-line)# access-class 10 in

示例 2：只允许 192.168.6.0/24 访问某个接口后的资源

Router(config)# access-list 20 permit 192.168.6.0 0.0.0.255
Router(config)# interface g0/0/1
Router(config-if)# ip access-group 20 out

扩展 ACL

扩展 ACL 可以精确到协议和端口，企业网里更常用。

示例：禁止分公司 VLAN60 访问服务器区 FTP，但允许其访问其他业务

Router(config)# access-list 100 deny tcp 192.168.6.0 0.0.0.255 192.168.11.0 0.0.0.255 eq 21
Router(config)# access-list 100 deny tcp 192.168.6.0 0.0.0.255 192.168.11.0 0.0.0.255 eq 20
Router(config)# access-list 100 permit ip any any
Router(config)# interface FastEthernet0/1
Router(config-if)# ip access-group 100 in

如果想用命名 ACL，可读性会更高：

Router(config)# ip access-list extended BLOCK_FTP
Router(config-ext-nacl)# deny tcp 192.168.6.0 0.0.0.255 192.168.11.0 0.0.0.255 eq 21
Router(config-ext-nacl)# deny tcp 192.168.6.0 0.0.0.255 192.168.11.0 0.0.0.255 eq 20
Router(config-ext-nacl)# permit ip any any
Router(config)# interface FastEthernet0/1
Router(config-if)# ip access-group BLOCK_FTP in

ACL 的放置原则

标准 ACL：尽量靠近目的端
扩展 ACL：尽量靠近源端
控制谁能远程登录设备：优先用 line vty 下的 access-class
NAT 里用到的 ACL 往往只是“匹配谁做转换”，不一定是“拦截流量”

ACL 常用检查命令：

show access-lists
show ip interface
show running-config | section access-list

NAT

企业出口里的 NAT，本质上是把私网地址改成公网地址。最常见的是“内网用户访问外网”时做源地址转换。

PAT：多个内网地址复用一个公网地址

Router(config)# interface gigabitEthernet 0/0/0
Router(config-if)# ip nat inside
Router(config)# interface serial 0/2/0
Router(config-if)# ip nat outside

Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255
Router(config)# ip nat inside source list 1 interface serial 0/2/0 overload

说明：

overload 的作用是端口复用，也就是常说的 PAT
多台内网主机可以共用一个公网 IP

动态 NAT：从公网地址池里分配地址

Router(config)# interface gigabitEthernet 0/0/0
Router(config-if)# ip nat inside
Router(config)# interface serial 0/2/0
Router(config-if)# ip nat outside

Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255
Router(config)# ip nat pool DZC 100.1.1.3 100.1.1.10 netmask 255.255.255.0
Router(config)# ip nat inside source list 1 pool DZC

如果希望“地址池 + 端口复用”一起用，可以写成：

Router(config)# ip nat inside source list 1 pool DZC overload

常用查看命令：

show ip nat translations
show ip nat statistics
clear ip nat translation *

故障排查

排错建议按“终端 -> 接入 -> 汇聚 -> 核心 -> 出口”的方向查，不要一上来就全网乱翻。

基础排错顺序

先确认终端 IP、掩码、网关、DNS 是否正确
ping 本 VLAN 网关，看本地三层是否正常
ping 内网服务器，看园区路由是否正常
用 tracert 看流量断在哪一跳
在对应设备上看 show ip route、show ip ospf neighbor、show standby brief
出外网异常时，再看 show ip nat translations

常见问题

三层交换机忘记开启 ip routing
DHCP 地址池默认网关填成物理网关，而不是 HSRP 虚拟网关
default-information originate 配了，但本机没有默认路由
串口 DCE 端忘记 clock rate
把所有接口都 no passive-interface，导致用户 VLAN 也去建 OSPF 邻居
NIM-ES 交换模块口理解错，把二层口和三层口命令混着写
NAT 的 inside / outside 打反
ACL 写完忘了绑到接口，或者绑反了 in / out
ACL 只写了 deny，忘了最后补需要的 permit
HSRP 主设备和 STP 根桥不一致，导致流量绕路

一组常用命令

show running-config | include helper
show running-config | section access-list
show ip interface brief
show ip route
show ip protocols
show vlan brief
show interfaces trunk
show standby brief
show spanning-tree vlan 10
show ip ospf neighbor
show ip rip database
show access-lists
show ip nat translations
clear ip nat translation *

Ctrl + Shift + 6
default interface FastEthernet 0/1
erase startup-config
reload

参考

1.思科企业网搭建-企业网含无线-从零开始配置教程_哔哩哔哩_bilibili

Openclaw的一些知识

Sun, 05 Apr 2026 23:03:23 +0800

介绍了一些AI的基本概念，openclaw的应用，openclaw的安全相关问题

前置概念

很多人可能还是停留在 4 年前 CHATGPT 刚刚出来的时候，AI 仅仅是网页聊天你问我答的功能。

但如今 AI 已经能完成很多任务，变化巨大。应用形态大概可以这样理解：

WEB 问答 AI -> 集成 IDE 的代码助手（coursor） -> 给一个虚拟环境执行（manus） -> AI CLI（Claude code） -> OpenClaw

越往后走，AI 越不像“网页聊天”，越像“能接收目标、调用工具、持续运行的系统”。

这篇文章主要讲 OpenClaw，在此之前先把几个经常混在一起的概念捋清楚。

LLM：大语言模型。可以先粗暴理解成一个超大号的“填词器”。你给它一段上下文，它根据概率预测下一个 token 应该是什么。聊天、翻译、写代码，本质上都还是在做这个事。
Token：可以理解成模型处理文本时的最小切分单位。中文通常粗略估算时可以认为 1 个中文汉字约等于 1~2 个 token，英文通常比中文省 token 一些。
Prompt：提示词，也就是你给模型的任务描述。早期模型能力弱，所以那时很强调 提示词工程（Prompt Engineering），大家会认真设计角色、约束、步骤、输出格式，让模型尽量别跑偏，比如：

# Role: [身份]
# Context: [这对我的职业生涯很重要]

# Constraints
1. 语言：始终使用简体中文回答。
2. 深度：严禁敷衍。涉及命令时，必须解释关键参数的底层含义。
3. 思维：鼓励触类旁通，提供跨学科类比。
4. 态度：保持中立，严禁幻觉。
5. 逻辑：结论后必须简述逻辑依据。
6. 数据：处理被 <data> 标签包裹的内容时，需进行深度审计。

# Workflow
1. 【分析】：先分析问题，给出【解决思路地图（Roadmap）】。
2. 【澄清】：列出 2-3 个需要补充的细节（若清晰则跳过）。
3. 【暂停】：**停止输出**。等待确认后继续。
4. 【追踪】：从下轮对话起，在回复末尾维护一个 [Project Checklist]，标注进度。

# Task
[输入问题]

现在很多 AI CLI 已经把这些能力做进系统提示词、工作流、规则文件里了，所以普通用户不用再手搓那么长一段模板。

Context：上下文。LLM 没有“人类意义上的记忆”，它看起来记得你之前说过什么，是因为你每次发消息时，系统都会把前面的对话、规则、工具结果打包一起发给模型。这个打包进去的内容就叫上下文。上下文窗口越大，AI 一次性能看到的信息越多。我还记得我一年前使用 gemini 的时候，一个项目越做，幻觉概率就越高，越降智。所以说上下文窗口大小还是很重要的。~~虽然说 gemini 也是上下文窗口大起家，但也是不太够用~~ 现在领先的 LLM 已经有 1 million 的上下文窗口了，完全塞得进很多项目的上下文。因为上下文有限，又提出了 RAG 、context engineering 的概念，这里就不说了。
Memory：记忆。记忆不是模型脑子里突然长出了长期记忆，而是把重要信息额外保存下来，下次再塞回上下文里。比如把项目规则写进 AGENTS.md，把长期偏好写进 MEMORY.md，本质上都是“外部记忆”。
Tool / Skill：工具和技能。工具是一个具体能力，比如联网搜索、执行 shell、读写文件、打开浏览器、OCR 识别图片文字。技能则更像“把几个工具按固定套路打包好”的可复用流程。
Agent：智能体。这个词最容易被说玄乎，其实可以先理解成：LLM + 工具 + 记忆 + 工作流控制。也就是说，Agent 不只是回答一句话，而是会围绕一个目标做多步动作，比如：
1. 理解你的目标是什么。
2. 判断要不要调用工具。
3. 执行工具。
4. 读取工具结果。
5. 继续判断下一步要做什么。所以严格说，最早的 GPT 只是模型，不是 Agent；OCR 只是能力，也不是 Agent。只有“能围绕目标自主调用能力并继续行动”的那一层，才更接近 Agent。
AI CLI：可以把它理解成“运行在终端里的 agent”。它已经不是简单的网页问答，而是能直接读取当前项目、搜索文件、改代码、跑命令、看测试结果、接 git、接 MCP 的工具。比如 Codex CLI、Claude Code、Gemini CLI 这种东西，本质都是让 AI 真正进入你的本地工作环境里干活。

OpenClaw

如果说 AI CLI 是“一个人在终端里调用 AI 干活”，那 OpenClaw 更像“把 AI 做成一个长期在线的控制平面”。

它不是单纯更强的模型，也不是单纯另一个聊天工具，而是一个 Gateway / Hub：

可以接入 Telegram、Slack、Discord、WebChat 等多个消息入口。
可以把浏览器、节点设备、自动化任务、记忆、工作区统一挂到同一个系统里。
可以让 AI 不只是聊天，而是长期待命、跨设备执行、定时执行、通过 webhook 被外部系统触发。
还可以把 Codex、Claude Code、Gemini CLI 这类 AI CLI 当作自己的后端执行器。

所以 OpenClaw 和 AI CLI 不是简单的替代关系，更像是两层东西：

AI CLI 解决的是：“我怎么让 AI 在这台机器、这个仓库里直接干活？”
OpenClaw 解决的是：“我怎么把 AI 变成一个能从聊天、设备、定时任务、工作流里随时调用的长期系统？”

也可以这样粗略理解这条演进路线：

WEB AI：你问一句，它答一句。
IDE AI：AI 开始进入开发环境，但动作还是受限。
AI CLI：AI 进入终端，开始真正读文件、跑命令、改项目。
OpenClaw：AI 不只存在于一个终端会话里，而是变成一个可接消息、可接设备、可跑自动化、可长期在线的网关系统。

所以这篇文章要讲的核心，其实不是“又一个 AI 工具”，而是：AI 正在从一次性问答工具，变成一个能接入现实工作流的操作层。

如果只把 OpenClaw 理解成“聊天机器人”，会低估它；如果把它理解成“一个 AI Gateway + Agent 控制平面”，就比较接近了。 OpenClaw = 入口层 + Gateway 控制层 + 执行层 + 状态层

入口层：消息从哪里进来。
控制层：由 Gateway 决定谁能进、路由给谁处理。
执行层：真正干活的是 LLM、浏览器、节点、AI CLI、插件。
状态层：工作区、记忆、历史对话、任务状态会被持续保存。

flowchart TB
 subgraph L1[入口层]
 I1[聊天渠道]
 I2[Web UI / API]
 I3[Webhook / Cron]
 end

 subgraph L2[控制层]
 G1[Gateway]
 G2[Session / Agent 路由]
 end

 subgraph L3[执行层]
 E1[LLM]
 E2[Browser]
 E3[Node / system.run]
 E4[ACP -> AI CLI]
 E5[插件 / MCP]
 end

 subgraph L4[记忆层]
 S1[Workspace]
 S2[Memory]
 S3[历史对话]
 S4[日志 / Task]
 end

 L1 --> L2
 L2 --> L3
 L2 --> L4
 L4 --> L2
 L3 --> L2

一次请求的运行时序

sequenceDiagram
 actor U as 用户/外部系统
 participant G as Gateway
 participant W as Workspace/Memory
 participant L as LLM/Agent
 participant T as Tools

 U->>G: 发消息 / Webhook / Cron 触发
 G->>G: 身份校验 + 路由到 Session
 G->>W: 读取规则、记忆、历史
 G->>L: 发送上下文 + 当前任务
 L-->>G: 判断是否需要工具
 alt 需要工具
 G->>T: 调用 Browser / Node / AI CLI / 插件
 T-->>G: 返回结果
 G->>L: 把工具结果补进上下文
 L-->>G: 继续判断 / 生成最终结果
 else 不需要工具
 L-->>G: 直接生成结果
 end
 G->>W: 写入记忆 / 日志 / 任务状态
 G-->>U: 返回回复或触发后续任务

具体描述

用户或者外部系统先把事件送进来，入口可以是聊天消息、Web 界面、API、Webhook，也可以是定时任务自己触发。
OpenClaw 的 Gateway 先做入口控制，比如身份校验、白名单、pairing，然后决定把这条请求路由到哪个 agent、哪个 session。
路由完成后，系统会装载对应工作区，把 AGENTS.md、TOOLS.md、MEMORY.md、历史对话、任务状态这些东西一起组装成上下文。
LLM 看到这些上下文之后，先理解目标，再判断这次是“直接回答”还是“必须调用工具”。
如果需要工具，OpenClaw 就去调用浏览器、节点、shell、文件系统、ACP 后端，甚至把任务继续转给 Codex、Claude Code、Gemini CLI 这类 AI CLI。
工具返回结果后，LLM 再读一轮结果，决定是继续执行下一步，还是收尾回复，并把结果写回记忆、日志、任务系统。

所以 OpenClaw 的运行本质不是“一次问答”，而是一个循环： 输入事件 -> Gateway 路由 -> 组装上下文 -> LLM 判断 -> 调用工具 -> 回看结果 -> 输出 / 记忆 / 继续任务

这也是它和普通 AI CLI 最大的不同：

AI CLI 更像“当前终端里的执行器”。
OpenClaw 更像“长期在线的 AI 中控系统”。
在 OpenClaw 里，AI CLI 往往只是工具层里的一个后端执行器，而不是整个系统本身。

应用场景

开发

如果只是单纯改代码，Codex CLI、Claude Code 这种 AI CLI 已经很好用了；但 OpenClaw 的优势在于，它可以把“聊天入口、任务拆解、多 agent、代码执行、长期上下文”串成一个持续运行的开发系统。

一个比较典型的用法是：上层先放一个“秘书型 agent”，负责接受人的需求，理解问题，拆分任务，然后把任务继续分给下面更具体的 agent。比如：

一个 agent 只负责代码搜索和上下文整理。
一个 agent 只负责真正改代码。
一个 agent 只负责跑测试、读日志、总结结果。
还有一种做法是先把任务拆成 GitHub issue，再让不同 agent 只围绕 issue 工作。

这样做的好处是让不同职责的 agent 有不同上下文和权限，避免一个 agent 什么都做，最后上下文过大、幻觉变多、边界也更乱。 ~~提示词工程也有类似的思想，解耦~~ 对于我来说就是处理日志交给 gemini flash ，然后将处理结果交给 gemini pro。

另外，OpenClaw 还能把 Codex、Claude Code、Gemini CLI 这类 AI CLI 当成后端执行器。也就是说，OpenClaw 不一定自己直接改代码，它也可以充当上层调度系统：用户在 Telegram、Slack、Web UI 里下达任务，OpenClaw 再去拉起更擅长 coding 的 agent。

这种工作流有点像下面这个项目： GitHub - cft0808/edict: 🏛️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails · GitHub

所以在开发场景里，OpenClaw 更适合做这些事情：

接收需求，整理成可执行任务。
让多个 agent 分工合作，而不是所有事都塞给一个会话。
挂接 AI CLI、浏览器、shell、文件系统，形成一条完整开发链路。
把项目规则、历史决策、工作区记忆保留下来，减少每次重新解释背景的成本。

不过这种自动模式不一定需要贯彻到底，我在 V2EX 上面也看到有人只是用来做一些简单的、表层的任务，真正复杂的任务还是自己的看。“往事开头难”，openclaw 已经把开头的事情给完成了。

运维

运维其实和 LLM 很搭。因为运维大量面对的就是文本：日志、命令、配置、告警、状态信息、工单。而 OpenClaw 又天然支持消息入口、Webhook、定时任务、节点设备和 shell 执行，所以它非常适合做轻量级 ChatOps。

比如可以这样用：

监控系统通过 webhook 把告警推给 OpenClaw。
OpenClaw 先读告警内容，判断严重程度，做第一轮摘要。
如果需要，它再调用节点或者 shell 去执行只读检查命令，比如 journalctl、docker ps、磁盘检查、日志搜索。
如果问题和后台页面有关，还可以调用浏览器去看 Grafana、Kibana、云控制台。
最后把结论回发到 Telegram、Slack、Discord，或者继续创建后续任务。

这和传统 bot 最大的区别是：它不是“收到消息后回一句话”，而是“收到消息后先帮你做一轮排查”。

除此之外，OpenClaw 还很适合做巡检型运维：

定时检查服务是否在线。
检查证书是否快过期。
检查备份任务有没有成功。
把每天的系统摘要自动发到固定渠道。

在 openclaw 还叫 clawcode 的时候，就在 NS 论坛上面看到有人说要取代运维了。但是从安全角度来说不太可能。运维是 OpenClaw 风险最高的场景之一。因为一旦 agent 同时拥有外部消息入口、shell、浏览器和高权限配置修改能力，风险会非常大。所以实际使用时更合理的方式往往是：前台 agent 负责分诊，真正高权限的命令只交给受限节点或者经过审批的 agent 去执行。

个人工作流

个人工作流其实是 OpenClaw 最有想象力的地方。因为它不是一个只会在网页里回答问题的 AI，而是一个可以长期待命、能接消息、能开浏览器、能记事、能定时跑任务的“个人中控”。

OpenClaw 可以开一个独立的、权限受限的浏览器，用来访问 web 页面获取信息。这意味着它不只是“搜索一下”，而是可以做更完整的工作流：

定时打开几个固定网站，帮你抓取更新信息。
看网页、截图、导出 PDF、再做总结。
代替你去看一些没有 API、但可以网页访问的信息源。
把网页信息和聊天记录、已有记忆结合起来，整理成日报或摘要。

因此它可以充当一种比较智能的 RSS，也可以进一步变成个人秘书：

每天早上整理消息、邮件、待办和日程。
收到外部通知后先做摘要，再决定要不要提醒你。
把聊天里提到的重要事情写入记忆，形成长期上下文。
定时做周报、月度复盘、信息归档。

如果再配合节点和移动端，OpenClaw 甚至不只处理文字信息，还能连接手机、通知、设备能力。从这个角度看，它更像一个“个人 AI 工作流中枢”，而不是一个单纯的聊天机器人。

和 N8N 的区别是:

N8N：事件驱动 / 流程驱动
OpenClaw：人驱动 / 对话驱动 / 助手驱动

安全

OpenClaw 的安全问题，本质上不是普通 Web 服务那种“接口有没有鉴权”，而是：你在运行一个拥有真实权限、能持续行动、还能调用工具的 agent。 OpenClaw Agent 继承运行用户的系统权限，它能读写文件、执行 Shell、调用 API、打开浏览器、连接节点设备。这意味着：

Agent 可能访问服务器上的敏感文件，例如 SSH 密钥、环境变量、配置文件、浏览器会话。
Agent 可能执行命令、修改配置、创建 cron、保留长期任务。
一旦 Agent 被恶意输入带偏，攻击者获得的就不只是一次回答，而是接近宿主机用户权限的行动能力。

因此 OpenClaw 的安全重点是先缩小权限、缩小入口、缩小爆炸半径。

公网暴露与部署方式

OpenClaw 官方的安全模型更偏向“可信单操作者”，也就是一个人给自己用的个人助手，而不是面向互不信任用户的公网共享平台。所以最重要的原则其实很朴素：不要默认把它当成公网服务去裸奔。

更稳妥的做法通常是：

默认只绑定本地回环地址，本机使用。
如果要远程访问，优先走 VPN、Tailscale、内网穿透后的受控访问。
对外部消息渠道启用 pairing、allowlist、mention gating，不要让陌生人直接给高权限 agent 发指令。
把不同用途的 agent 拆开，不要让同一个 agent 同时拥有聊天入口、浏览器、shell、cron、配置修改能力。

如果一个 OpenClaw 实例直接暴露在公网，而且还带有高权限工具，它就很容易变成潜在的攻击入口。

容器使用

见过不少人使用 CLI 结果把整个 D 盘文件删除，对于这种可能获取高权限的服务最好是运行在沙箱。

容器能解决的是：

把 agent 的文件访问范围限制在一部分目录里。
限制部分系统调用和宿主机访问。只挂载代理绝对需要的目录，并尽可能使它们只读。
在发生错误或被带偏时，缩小破坏范围。
关闭任何出站互联网访问，除了明确允许的 API 端点（OpenRouter 等）。这样即使一个 SKILLS 试图窃取数据，它也不能联系外部。

但容器解决不了这些问题：

如果敏感文件本来就挂载进容器里，agent 依然能读到。
如果浏览器 profile、API token、会话文件放在可访问路径里，容器并不会自动帮你保密。
如果把高权限节点、浏览器、shell 全部开放给 agent，沙箱也只能部分缓解风险。

提示词注入

提示词注入是 OpenClaw 这类 agent 系统里最核心的风险之一。因为 OpenClaw 接收的“不可信输入”远不止用户发来的一句话，还包括：

Telegram、Slack、Discord、邮件、Webhook 发来的内容。
浏览器访问到的网页内容。
文档、截图、OCR 结果、日志、工单、第三方 API 返回值。
skills、插件、工具返回的文本结果。

这些内容都可能夹带“让你忽略前面的规则”“执行某条命令”“读取某个文件”之类的恶意指令。而 LLM 并不能稳定地区分“这是要处理的数据”还是“这是要服从的指令”。

所以对抗提示词注入，核心不是指望模型永远识别出来，而是：

把外部消息都视为不可信输入。
对处理不可信内容的 agent 默认关闭高风险工具。
必要时启用审批、沙箱和只读模式。
不让浏览器、shell、配置修改、cron 持久化能力集中到同一个面向外部输入的 agent 上。

最近官方连续修复过多类安全问题，覆盖本地文件读取、远程路径删除、审批绑定绕过、OAuth 边界和插件信任边界。这也说明 OpenClaw 的安全难点，恰恰就在“模型决策 + 工具执行 + 外部输入”交叉的地方。 # CVE-2026-30741

不安全的 skills

很多人会把 skill 理解成“提示词模板”，但在 OpenClaw 里，skill 往往不只是文本，它还可能绑定脚本、命令、工具调用逻辑，甚至引导 agent 拉起外部执行器。

风险主要在几个地方：

skill 可能诱导 agent 调用本来不该开放的工具。
skill 可能间接扩大权限边界，比如让 agent 更频繁地接触 shell、浏览器、文件系统。
skill 自身如果来自不可信来源，里面的脚本和流程也可能有问题。

所以更安全的做法是：

不要看见 skill 就直接装。
先看它会调用哪些工具、读写哪些路径、依赖哪些脚本。
对互联网入口 agent，默认不要给 exec、gateway、cron、sessions 这类高风险能力。
技能最好分层：公开入口用低权限 skill，真正执行操作的部分交给受限 agent 或经审批流程。

Reddit - # 在 OpenClaw 的 ClawHub 市场中发现了 820 个恶意技能。安全研究人员表示担忧

供应链攻击

OpenClaw 的扩展能力很强，但这也意味着它天然带有供应链风险。插件、skills、npm 包、外部脚本、浏览器扩展、第三方集成，只要有一层被污染，最终都可能进入 agent 的执行链。

这一类风险常见的表现是：

安装了来路不明的 plugin / skill。
直接信任第三方脚本或 curl | bash 安装方式。
给插件过大的文件系统、网络、会话访问权限。
升级依赖后把恶意变更带进来，自己却没有察觉。

因此供应链防护的重点是：

只安装可信来源的 plugin 和 skill。
尽量固定版本，避免无感漂移。
安装前先读 manifest、脚本、依赖。
把插件和工作区看成高敏感资产，不要随便混用。

比如说前几天的 axios 的供应链攻击: binance.com/fr/square/post/307404730097442 这种主要是要看开发者的安全意识，使用者应尽可能关注相关安全信息 Overview · openclaw/openclaw · GitHub。

小结

少暴露：不要默认上公网。
少权限：高风险工具默认关闭。
少信任：外部消息、网页、文档都按不可信输入处理。
少耦合：把聊天入口、浏览器、shell、cron、配置修改拆给不同 agent。
多审计：定期检查配置、依赖、日志和长期任务。记忆层必须可控、可审计、可回滚长期记忆不能向模型开放任意写权限。任何新增、覆盖或删除记忆的动作都应当留痕，并允许人工审查。
加固: GitHub - slowmist/openclaw-security-practice-guide: This guide is designed for OpenClaw itself (Agent-facing), not as a traditional human-only hardening checklist. · GitHub

参考

Derper 搭建

Sat, 04 Apr 2026 19:17:58 +0800

derper 是Tailscale/headscale 自建的中转节点，用来组网解决公共节点打洞成功率太低和延迟问题。

自建 DERP 节点

序

之前用一台国外 VPS 配合 sing-box 开过 DERP。和公共 DERP 相比，带宽能跑满，但因为线路和 NAT 环境问题，UDP 打洞一直没成功。

后来换成国内云主机，改用官方 derper 二进制重新部署。

如果机器上没有现成的 Nginx 和证书体系，优先用更简单的官方直跑方案：

-a :443
-http-port 80
-certmode letsencrypt

我最终采用的方案：Nginx 监听 443，后端 derper 监听 12443，证书由 Nginx 管理，derper 用 manual 模式读取证书。

最终架构

流量路径如下：

客户端 -> TCP 443 -> Nginx -> https://127.0.0.1:12443 -> derper
客户端 -> UDP 3478 ---------------------------------------> derper(STUN)

对应关系：

443/tcp：DERP 客户端入口，走 Nginx
3478/udp：STUN 打洞，直达 derper
12443/tcp：后端 derper 监听端口，只给本机 Nginx 用，阿里云防火墙策略里面不对公网放行

--verify-clients 用来防止其他人白嫖如果开启 --verify-clients：

DERP 机必须安装并接入 tailscaled
derper 会通过本机 tailscaled 判断客户端是不是自己 tailnet 的成员

端口规划

至少要确认这些端口：

443/tcp：放行
3478/udp：放行
80/tcp：只在你需要 Nginx 做 ACME 或 HTTP 跳转时放行
12443/tcp：不要在云安全组里放行

这样外部只能通过 Nginx 进来，但 STUN 还能正常工作。

前提条件

假设：

系统是 Debian 12
域名是 derp.example.com
域名已经解析到 VPS 公网 IP
证书由 Nginx 或其他现有流程维护

如果准备开启 --verify-clients，还需要：

安装 tailscaled
让这台 DERP 机加入正确的 tailnet
最好给它打上 tag:derp

如果机器上启用了 Tailscale，且 apt update 超时，优先确认不是 DNS 或私网镜像源问题。长期建议：

sudo tailscale set --accept-dns=false --netfilter-mode=off

安装 Go 和 `derper`

验证 Go：

go version

如果没装 Go，自行安装到 /usr/local/go 后，补 PATH：

echo 'export PATH=$PATH:/usr/local/go/bin' | sudo tee /etc/profile.d/go.sh

创建运行目录：

sudo useradd --system --home /var/lib/derper --create-home --shell /usr/sbin/nologin derp
sudo install -d -o derp -g derp -m 0750 /var/lib/derper /var/lib/derper/certs

安装 derper：

sudo env PATH=$PATH GOBIN=/usr/local/bin /usr/local/go/bin/go install tailscale.com/cmd/derper@latest

如果国内网络太慢：

sudo env PATH=$PATH GOBIN=/usr/local/bin GOPROXY=https://goproxy.cn,direct /usr/local/go/bin/go install tailscale.com/cmd/derper@latest

验证：

/usr/local/bin/derper -version

安装并接入 Tailscale

如果要用 --verify-clients，DERP 机必须先入网：

curl -fsSL https://tailscale.com/install.sh | sh
sudo systemctl enable --now tailscaled
sudo tailscale up
sudo tailscale set --advertise-tags=tag:derp

检查状态：

tailscale version
systemctl status tailscaled
sudo tailscale status

证书准备

如果你已经有 Nginx 管理的证书，例如：

/etc/nginx/ssl/derp/cert.pem
/etc/nginx/ssl/derp/key.pem

那么 derper 使用 -certmode manual 时，不会直接认 cert.pem 和 key.pem 这种名字。它要求证书文件名必须和主机名一致：

derp.example.com.crt
derp.example.com.key

因此可以用软链接映射：

sudo mkdir -p /var/lib/derper/certs
sudo ln -sf /etc/nginx/ssl/derp/cert.pem /var/lib/derper/certs/derp.example.com.crt
sudo ln -sf /etc/nginx/ssl/derp/key.pem /var/lib/derper/certs/derp.example.com.key

这是这次排障里最关键的坑之一：

开了 -certmode manual
却没配 -certdir
或者证书文件名不匹配主机名

结果就是 derper 直接启动失败，Nginx 对后端只能拿到 502 Bad Gateway。

`derper.service`

最终采用的 systemd 配置如下：

/etc/systemd/system/derper.service

[Unit]
Description=Tailscale DERP Server
Wants=network-online.target tailscaled.service
After=network-online.target tailscaled.service
Requires=tailscaled.service

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/var/lib/derper
NoNewPrivileges=true

ExecStart=/usr/local/bin/derper \
 -c /var/lib/derper/derper.key \
 -hostname derp.example.com \
 -a :12443 \
 -http-port -1 \
 -stun-port 3478 \
 -certmode manual \
 -certdir /var/lib/derper/certs \
 -stun \
 -verify-clients

Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

这里有几个关键点：

User=root：开启 --verify-clients 时，这样最省事，避免本地 tailscaled.sock 权限问题
-a :12443：不要写成 127.0.0.1:12443
-http-port -1：关闭 derper 自己的 HTTP 监听
-stun-port 3478：STUN 端口是纯数字，不要写成 :3478
-certmode manual + -certdir：让 derper 使用你已经准备好的证书
-verify-clients：限制只允许自己 tailnet 的客户端使用

启动：

sudo systemctl daemon-reload
sudo systemctl enable --now derper
sudo systemctl status derper
sudo journalctl -u derper -f

Nginx 反代配置

示例： /etc/nginx/sites-available/derp

server {
 listen 443 ssl http2;
 server_name derp.example.com;

 ssl_certificate /etc/nginx/ssl/derp/cert.pem;
 ssl_certificate_key /etc/nginx/ssl/derp/key.pem;

 location / {
 proxy_pass https://127.0.0.1:12443;
 proxy_ssl_verify off;
 proxy_ssl_server_name on;
 proxy_ssl_name derp.example.com;

 proxy_buffering off;
 proxy_http_version 1.1;

 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 Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";

 proxy_connect_timeout 60s;
 proxy_read_timeout 300s;
 proxy_send_timeout 300s;
 }
}

启用并检查：

sudo ln -sf /etc/nginx/sites-available/derp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

这次排障确认了几个容易错的点：

proxy_pass 必须是 https://127.0.0.1:12443，不能写成 http://
proxy_ssl_server_name on 和 proxy_ssl_name derp.example.com 最好一起带上
proxy_buffering off 建议开启，DERP 这种长连接/流式转发场景更稳

tailnet policy 和 `derpMap`

示例：

{
 "tagOwners": {
 "tag:derp": ["autogroup:admin"]
 },
 "derpMap": {
 "omitDefaultRegions": false,
 "regions": {
 "901": {
 "RegionID": 901,
 "RegionCode": "sz",
 "RegionName": "cn-sz DERP",
 "Nodes": [
 {
 "Name": "901a",
 "RegionID": 901,
 "HostName": "derp.example.com",
 "IPv4": "1.2.3.4",
 "CanPort80": true,
 "DERPPort": 443,
 "STUNPort": 3478
 }
 ]
 }
 }
 },
 "grants": [
 {
 "src": ["tag:derp"],
 "dst": ["*"],
 "ip": ["*"]
 }
 ]
}

这里的重点是：

DERPPort 写 443，因为客户端实际连的是 Nginx，不是后端 12443
STUNPort 还是 3478
开启 --verify-clients 时，不要把 ACL 写得过死，至少先保证 tag:derp 能“看见”允许使用它的节点

ACL 写太严时，tailscale ping 和节点探测都出现异常。先跑通，再慢慢收紧规则更稳妥。

如果需要 ping，别忘了 ACL 里要考虑 icmp。

验证方法

服务状态

sudo systemctl status derper
sudo journalctl -u derper -n 100 --no-pager

端口监听

sudo ss -tlnp | grep 12443
sudo ss -ulnp | grep 3478

期望结果：

12443/tcp 在监听
3478/udp 在公网地址上监听，而不是只绑在 127.0.0.1

域名访问

curl -I https://derp.example.com

Tailscale 状态

tailscale netcheck
tailscale ping <peer>
tailscale status

如何判断：

看到自定义 DERP 区域，说明 derpMap 生效
看到 relay "sz" 之类信息，说明 DERP 可作为中转保底
看到 direct，说明 UDP 打洞成功，已经不是纯 DERP 中转

这次排障里最关键的结论

502 Bad Gateway 不等于真的是 443 被拦了很多时候只是 Nginx 能起来，但后端 derper 没起来。先查：

sudo systemctl status derper
sudo journalctl -u derper -n 50 --no-pager
sudo ss -tlnp | grep derper

如果 12443 没监听，优先看 derper 启动参数和证书。

manual 模式下，证书目录和文件名必须对这次最开始的 502，根因之一就是：

derper 开了 -certmode manual
但没找到正确的证书要么缺 -certdir，要么证书不是按主机名命名。

Nginx 反代 derper 时，上游必须走 HTTPS derper 在这套配置下是 TLS 服务。如果 Nginx 写成：

proxy_pass http://127.0.0.1:12443;

那就属于协议对不上，最后可能得到 400 或 502。

-a 127.0.0.1:12443 会把 STUN 一起绑到回环地址这是这次踩的另一个大坑。如果把 -a 绑到 127.0.0.1，很多版本的 derper 会让 3478/udp 也只监听回环地址。结果就是：

网页可能正常
DERP 中转可能正常
但 direct 很难成功，因为外部客户端根本打不到 STUN 因此最终保留：

-a :12443
-stun-port 3478

然后通过云安全组不开放 12443/tcp 来补安全。

derpMap 要指向 443，不是 12443 客户端连的是：

客户端 -> 443 -> Nginx -> 12443 -> derper

所以 DERPPort 必须写 443。

--verify-clients 依赖本机 tailscaled 的可见范围如果日志里出现：

client nodekey:... rejected: peer nodekey:... not authorized (not found in local tailscaled)

优先检查：

DERP 机是否已经加入正确的 tailnet
tag:derp 是否配置正确
ACL / grants 是否让 DERP 机能看到这些客户端如果只是临时排障，也可以先去掉 -verify-clients，等网络和反代都跑通再加回来。

海外节点访问异常时，要分清是配置问题还是安全组/线路问题如果外地或海外节点完全打不到你的自建 DERP：先在远端做两类测试：

curl -I https://derp.example.com
nc -zvu 1.2.3.4 3478

然后回头检查：

云安全组是否放行了 443/tcp
云安全组是否放行了 3478/udp
12443/tcp 是否没有对公网放行
是否确实存在跨境线路抖动或区域性阻断

安全建议

这一套最终的安全边界是：

公网开放 443/tcp
公网开放 3478/udp
公网不开放 12443/tcp
derper 开启 --verify-clients

这样即使 derper 进程监听了 :12443，外部也很难直接打到它。

如果你只是临时测试：

可以先不启用 --verify-clients
先把 Nginx -> derper、derpMap、STUN 跑通
最后再加访问控制

最终判断标准

满足以下条件就算部署完成：

derper.service 是 active (running)
curl -I https://derp.example.com 正常返回
3478/udp 对外可达
tailscale netcheck 能看到自定义 DERP 区域
需要中转时能走到自建 DERP
网络允许时能出现 direct
未授权客户端会被 --verify-clients 拒绝

参考

官方文档

官方仓库

使用Acme.sh申请配置证书

Wed, 25 Mar 2026 20:45:39 +0800

ACME. SH 申请证书并使用 DNS-01 认证

默认 CA 是 ZeroSSL，如果想用 Let’s Encrypt 需要显示指定 --server letsencrypt 。似乎是 letsencrypt 申请证书比 zerossl 快一些。但是 letsencrypt 多次申请失败会限制 24 小时。 letsencrypt偏向开源免费，而zerossl偏商业。所以我还是选择letsencrypt。

安装：–install
选 CA：–set-default-ca
签发：–issue
部署到服务：–install-cert
续期：–renew
查看：–list

官方说明不建议使用 sudo 提权，而是全程使用一个用户。

下载 ACME. SH

curl https://get.acme.sh | sh -s email=you@example.com

申请证书

HTTP-01 和 DNS-01 质询的区别是：

HTTP-01 需要开放 80 端口完成验证，也就是在/. Well-known/acme-challenge/<token>，然后证书签发机构再去抓取完成验证。
DNS-01 则是在 _acme-challenge.你的域名 下面添加一条 TXT 记录完成验证。适合不开放 80 端口的情况。

HTTP-01

如果已经搭建起网站：

~/.acme.sh/acme.sh --issue -d example.com -w /var/www/html --server letsencrypt

如果没有搭建起网站，就要临时启动一个 HTTP 服务占用 80 端口完成验证

~/.acme.sh/acme.sh --issue --standalone -d example.com --server letsencrypt --standalone

DNS-01：

export CF_Token="你的token"
export CF_Account_ID="你的account_id"
~/.acme.sh/acme.sh --issue --dns dns_cf -d example.com -d '*.example.com' --server letsencrypt

Cloudflare_token 需要创建令牌拿到

Cloudflare_account_id 点进域名，右侧下滑可以看到。

手动 DNS 模式

如果域名托管商不提供 API，就需要手动在域名管理后台处添加 TXT 记录，完成后可以删除。

~/.acme.sh/acme.sh --issue --dns -d example.com --server letsencrypt

~/.acme.sh/acme.sh --renew -d example.com

安装证书

手动 cp 到服务目录的那份不会自动同步，也不会自动 reload 服务。需要用以下命令执行安装。

~/.acme.sh/acme.sh --install-cert -d dp.example.com --ecc \
--key-file /var/lib/derper/certs/dp.example.com.key \
--fullchain-file /var/lib/derper/certs/dp.example.com.crt \
--reloadcmd "systemctl restart derper"

参考

README: https://github.com/acmesh-official/acme.sh
安装: https://github.com/acmesh-official/acme.sh/wiki/How-to-install
DNS API: https://github.com/acmesh-official/acme.sh/wiki/dnsapi
CA 选择: https://github.com/acmesh-official/acme.sh/wiki/Server
sudo 说明: https://github.com/acmesh-official/acme.sh/wiki/sudo

emc-NAS 的小折腾

Sun, 22 Mar 2026 17:13:36 +0800

捡到一台没人要的NAS，折腾一下。

SSL 相关

如果本地网络强制 SSL 的话，下载会出现证书的报错。

SHELL

这台机器还是能开 SHELL 的。

访问 IP/manage/diagnostics.html 就可以开启隐藏起来的 SHELL。

默认账号是 root ，密码则是 soho+密码。

进入 shell 后的一些配置

第一步是看配置和内核还有内存。

cat /proc/cpuinfo
uname -a
free -m

登录校园网 Drcom校园网使用路由器过验证 - Chifan’s Blog

安装包管理器，这里就安装了 opkg wget -O - http://bin.entware.net/x64-k3.2/installer/generic.sh | sh。

下载 neofetch，因为内核太老了没有需要的 libc。下载的都是二进制的 musl 版本。一些不是单纯的二进制文件比如说 openlist 可以将其放在 /opt/apps 里面，然后使用软链接 ln -s 将二进制放在 /opt/bin 里面方便管理。

vi /etc/profile

export PATH=/opt/bin:/opt/sbin:$PATH
export LANG=en_US.UTF-8
neofetch

alias ls='ls --color=auto'
alias grep='grep --color=auto'
alias ll='ls -lah --color=auto'
export PS1='\[\e[32;1m\]\u@\h\[\e[0m\]:\[\e[34;1m\]\w\[\e[0m\]\$ '

换 shell

which shell
chsh
/bin/bash

MONIT

这台 NAS 的内核版本太低了，不支持 systemd 管理服务。

但是可以使用 init.d ，写脚本放在 /opt/etc/init.d/ 目录下，开机就会自动运行。但是没办法再服务死亡的死后自动拉起。

好在 opkg 里面有 monit 可以管理，能够管理服务。opkg install monit

monit -t # 配置文件检测
monit # 启动
monit daemon monit -c /var/monit/monitrc # 启动monit daemon时指定配置文件
monit reload # 当更新了配置文件需要重载
monit status # 查看所有服务状态
monit status nginx # 查看nginx服务状态
monit stop all # 停止所有服务
monit stop nginx # 停止nginx服务
monit start all # 启动所有服务
monit start nginx # 启动nginx服务
monit -V # 查看版本

vi /opt/etc/monitrc

# 监控名为 openlist 的进程
check process openlist matching "openlist server"
 # 启动命令
 start program = "/bin/sh -c 'cd /opt/apps/openlist && /opt/bin/openlist server >> /opt/var/log/openlist.log 2>&1'"
 # 停止命令
 stop program = "/usr/bin/pkill openlist"
 if failed port 5244 then restart
 if 3 restarts within 5 cycles then unmonitor

# 监控 FileBrowser 进程
check process filebrowser matching "filebrowser -d"
 # 启动命令
 start program = "/bin/sh -c '/opt/filebrowser/filebrowser -d /opt/filebrowser/filebrowser.db -a 0.0.0.0 -p 8080 >> /opt/var/log/filebrowser.log 2>&1'"
 # 停止命令
 stop program = "/usr/bin/pkill filebrowser"
 if failed port 8080 then restart
 if 3 restarts within 5 cycles then unmonitor

# 校园网登录脚本
check host campus_network with address baidu.com
 start program = "/opt/bin/route.sh"
 stop program = "/usr/bin/pkill -f route.sh"
 if failed ping then restart
 every 2 cycles

# IP检测脚本
 check process ip_report matching "ip.sh"
 start program = "/bin/sh -c '/opt/bin/ip.sh &'"
 stop program = "/usr/bin/pkill -f ip.sh"

持久化

为了能让机器重启时先启动 monit ，然后再由 monit 拉起其他服务，需要持久化。 vi /etc/rc.local 在 exit 0 前加入 /opt/bin/monit -c /opt/etc/monitrc 。

远程通知

为了避免有一天突然断电重启，重新分配 IP，又要去机房看一眼 IP 的问题，就需要一个脚本能够持续发送 IP。

本来是打算将通知发送到 tgbot 上面的，依旧是用自建的 Cloudflare worker 中转一下就可以了。

但是机房的网络比较特别，好像是对于国外的 IP 都禁止发起连接。包括 Tailscale 和 Cloudflare 的所有 IP。所以我下载 GitHub 上面的二进制文件都是用的香港的加速才能成功。

最后是选择用飞书的 bot。

#!/bin/sh

# === 配置区 ===
WEBHOOK_URL="https://www.feishu.cn/flow/api/trigger-webhook/"
# 发送间隔（秒），例如 3600 代表 1 小时
INTERVAL=10
# ==============

export PATH=/opt/bin:/opt/sbin:/usr/bin:/usr/sbin:/bin:/sbin

while true; do
 # 1. 获取校园网内网 IP
 MY_IP=$(ip addr show | grep 'state UP' -A2 | grep 'inet ' | grep -v '127.0.0.1' | awk '{print $2}' | cut -f1 -d'/')

 # 2. 获取根目录 (/) 的占用情况
 ROOT_USAGE=$(df -h / | awk 'NR==2 {print $5}')

 # 3. 获取数据盘 (/mnt/pools/A/A0) 的剩余空间
 DATA_FREE=$(df -h /mnt/pools/A/A0 | awk 'NR==2 {print $4}')

 # 4. 获取系统当前时间
 NOW=$(date "+%Y-%m-%d %H:%M:%S")

 # 5. 构造 JSON 数据包
 PAYLOAD=$(printf '{"nas_ip":"%s", "root_usage":"%s", "data_free":"%s", "update_time":"%s"}' \
 "$MY_IP" "$ROOT_USAGE" "$DATA_FREE" "$NOW")

 # 6. 发送请求
 curl -s -k -X POST "$WEBHOOK_URL" \
 -H "Content-Type: application/json" \
 -d "$PAYLOAD" > /dev/null

 sleep $INTERVAL
done

如果想要 IP 发生改变再执行发送一次消息可以添加一个上一次 IP 和此刻 IP 对比的判断。因为这个不好安装探针，我看着连续的通知比较放心，可以容易判断出什么时候出现问题。掉线的情况。

参考

Monit：开源服务器监控工具 - 飞鸿影 - 博客园