记录点滴 - 分享

GitHub 的 Verified 提交、SSH Key 与 noreply 隐私邮箱，一次讲清楚

Sun, 10 May 2026 00:00:00 +0000

很多人第一次配 GitHub 提交签名时，都会被几个词绕晕：邮箱验证、noreply 匿名邮箱、SSH key、Verified，再加上一个经典问题：GitHub 和 GitLab 会不会互相影响。

它们看起来都和“提交身份”有关，但其实管的是不同的事。

这篇文章不聊花哨配置，只想把 4 个最常见的问题说清楚：

Verified 到底是靠什么出现的
auth key 和 sign key 分别管什么
noreply 到底能不能直接让提交变成 Verified
本地同时操作 GitHub 和 GitLab 时应该怎么配

写在前面

如果你只想先记住一句话，可以先看这 4 句：

noreply 解决的是“提交里显示哪个邮箱”。
Verified 解决的是“这个提交有没有被数字签名验证通过”。
auth key 解决的是“你能不能通过 SSH 连上 GitHub 并 push 代码”。
sign key 解决的是“GitHub 会不会把这次 commit 标记成 Verified”。

这几件事彼此有关，但不是一回事。大多数人踩坑，不是因为命令不会敲，而是一开始就把目标搞混了。

如果想更快建立整体判断，可以先看这张对照表：

你想解决的问题	主要看什么	会不会直接影响 `Verified`	会不会影响邮箱是否暴露
让提交显示 `Verified`	是否开启提交签名，公钥是否作为 `Signing Key` 添加到账户	会	不直接决定
让 `git push` / `git pull` 走 SSH	SSH 认证 key 是否可用	不会	不会
不暴露真实邮箱	`user.email` 是否改成 `noreply`	不会直接决定	会
避免 GitHub 和 GitLab 配置互相污染	全局配置和仓库本地配置怎么划分	间接影响排查效率	会

先分清三个最容易混淆的概念

1. 账号邮箱验证

这是 GitHub 账号层面的基础设置，说白了就是让 GitHub 确认“这个邮箱确实是你的”。

它主要解决的是账号通知、找回、身份归属这些问题。

但是它不会让你的提交自动显示 Verified。

2. 提交显示 `Verified`

这指的是“这次提交有没有经过数字签名验证”。

GitHub 会检查这次 commit 是否带有有效签名。当前支持 GPG、SSH 和 S/MIME 三种方式。对大多数个人用户来说，SSH 往往是最省事的一种。

也就是说，Verified 不是看你用了什么邮箱，而是看你有没有对提交做签名，以及 GitHub 能不能验证这个签名。

3. `noreply` 隐私邮箱

这是 GitHub 提供的一种匿名邮箱，用来避免你在 commit 里直接暴露真实邮箱。它常见的格式如下：

1

ID+USERNAME@users.noreply.github.com

它的作用是隐藏真实邮箱，同时让 GitHub 仍然可以把提交归属到你的账号和贡献图。

但它本身不会让 commit 变成 Verified。

`auth key` 和 `sign key` 到底分别做什么

把这两个概念分清楚，后面的设置页面就不会那么绕。

`auth key`：证明“你能操作仓库”

auth key 用在 SSH 连接阶段，也就是你和 GitHub “建立连接”的时候，比如：

1
2
3
4


git clone git@github.com:owner/repo.git
git fetch
git pull
git push

当你执行这些命令时，GitHub 需要确认两件事：

你是不是这个账号的人
你有没有权限访问这个仓库

所以 auth key 的作用很直接：

让你能通过 SSH 连接 GitHub
让你能 clone、fetch、pull、push

如果没有它，SSH 方式下通常连 push 都过不去。

`sign key`：证明“这次提交确实是你签的”

sign key 用在 git commit 阶段。它不是拿来“登录 GitHub”的，而是给 commit 内容附带一个数字签名。

当你执行：

1

git commit -S -m "feat: add signed commit"

或者开启自动签名：

1

git config commit.gpgsign true

Git 会在 commit 里写入一段签名信息。GitHub 收到这个 commit 后，会检查：

签名是否有效
对应公钥是否已添加到你的 GitHub 账号
这把公钥是否被登记为 Signing Key

都通过了，GitHub 才会显示 Verified。

这里有个很容易误会的点。

user.email 会影响提交归属、贡献图统计，以及你有没有暴露真实邮箱；但不要把它直接理解成“SSH 签名能不能显示 Verified 的唯一前提”。对 SSH signing 来说，核心仍然是签名本身能否被你账号里的 Signing Key 验证通过。

一个比喻就够了

auth key 像门禁卡，决定你能不能进大楼
sign key 像签字章，决定这份文件能不能证明是你签的

两者可以是同一把钥匙材料，但职责不同。

为什么同一把 SSH key 可以同时用于 `auth` 和 `sign`

这也是很多人第一次配置时最容易卡住的地方。

答案其实不复杂：同一把 key 可以同时承担认证和签名两种用途，但 GitHub 会把这两种用途分开记录。

比如你本地有这一对 key：

私钥：~/.ssh/id_ed25519
公钥：~/.ssh/id_ed25519.pub

你完全可以只维护这一对密钥，然后在 GitHub 的 Settings -> SSH and GPG keys 页面里按用途决定怎么登记：

如果要让提交显示 Verified，把公钥添加为 Signing Key
如果还要用同一把 key 走 SSH clone、pull、push，再额外把它添加为 Authentication Key

注意，这不是要求你生成两把不同的 key。重点只是 GitHub 会把“认证用途”和“签名用途”分开记录。

所以：

同一把 key 可以同时给 git push 做 SSH 认证
同一把 key 也可以给 git commit 做 SSH 签名
但如果你只关心 Verified，先配 Signing Key 就够了

想让每次 GitHub 新提交都显示 `Verified`，最推荐怎么配

如果你主要是个人开发者，当前最省事的做法通常就是 SSH commit signing。

第一步：确认 Git 版本

GitHub 官方说明，SSH signature verification 需要 Git 2.34 或更高版本。

1

git --version

第二步：确认本机是否已有 SSH key

1

ls -al ~/.ssh

如果你已经有 id_ed25519 和 id_ed25519.pub，大多数情况下可以直接复用。

如果没有，可以生成一把新的：

1

ssh-keygen -t ed25519 -C "你的GitHub邮箱"

第三步：先添加 `Signing Key`，需要 SSH 传输时再补 `Authentication Key`

进入 GitHub：

Settings -> SSH and GPG keys

如果你的目标只是让提交显示 Verified，关键动作是：

一次作为 Signing Key

如果你还想继续用这把 key 走 SSH 方式 clone、pull、push，再额外添加一次：

一次作为 Authentication Key

也就是说：

Verified 主要取决于 Signing Key
Authentication Key 只负责 SSH 传输认证
两者可以是同一把 key，但不是必须为了 Verified 同时都配上

第四步：告诉 Git 以后用这把 key 给提交签名

如果你想让当前仓库自动签名：

1
2
3


git config gpg.format ssh
git config user.signingkey ~/.ssh/id_ed25519.pub
git config commit.gpgsign true

如果你希望所有仓库都默认启用签名，可以把上面的命令都加上 --global。

但如果你同时还在用 GitLab，而且不想让 GitLab 仓库默认签名，我更建议只在 GitHub 仓库里做本地配置，不要一开始就全局打开。

第五步：确认提交邮箱配置正确

这一点很容易被忽略。即使签名没问题，如果 user.email 配置得很混乱，后续在排查贡献归属、邮箱暴露和多平台配置时会非常烦。

先看当前仓库实际使用的邮箱：

1

git config user.email

如果你希望隐藏真实邮箱，可以在 GitHub 仓库里设置成自己的 noreply 地址：

1

git config user.email "你的GitHub-noreply邮箱"

更直白一点说：

user.email 主要决定提交里写入哪个邮箱
它影响隐私暴露和账号归属
但不要把它直接等同于“SSH 签名能不能生效”

第六步：做一次测试提交

1
2


git commit -m "test signed commit"
git push

如果前面的签名配置都已生效，这次新提交推到 GitHub 后，通常就会显示 Verified。

补充：为什么网页上直接改文件，也可能显示 `Verified`

这个问题也很常见。

如果你是在 GitHub 网页端直接编辑文件、合并某些 PR，或者通过 GitHub 提供的受支持界面生成提交，这类提交可能会由 GitHub 代表平台自动签名。所以即使你本地没配 SSH signing，页面上仍然可能看到 Verified。

这和“你在本地命令行里如何配置签名”不是一回事，别把两者混在一起。

同时使用 GitHub 和 GitLab，应该怎么配才不互相干扰

这是实际使用里比“按钮怎么点”更重要的问题。

很多人的真实场景不是“我只用 GitHub”，而是：

一部分仓库推到 GitHub
一部分仓库推到 GitLab
GitHub 想要 Verified
GitLab 不一定想开启签名验证

这种情况下，最稳妥的做法不是一上来就全局把所有东西都打开，而是把“你具备签名能力”和“哪些仓库默认启用签名”分开。

推荐方案：只在 GitHub 仓库开启自动签名

全局只保留基础能力：

1
2


git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub

GitHub 仓库里单独开启：

1
2


git config commit.gpgsign true
git config user.email "你的GitHub-noreply邮箱"

GitLab 仓库里保持普通配置，或者显式关闭：

1
2


git config commit.gpgsign false
git config user.email "你的GitLab邮箱"

这样配置的好处很直接：

GitHub 仓库会自动签名，提交更容易显示 Verified
GitLab 仓库不会被你无意中全局签名
两个平台的邮箱也能分开管理

如果你接受所有仓库都默认签名

那也可以直接全局开启：

1
2
3


git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

这样通常不会影响 GitLab 的正常 push。只是 GitLab 那边如果没有配置对应的签名 key，页面未必会显示它自己的验证状态。

最后一定要会看实际生效配置

这条命令非常实用：

1

git config --list --show-origin

它能直接告诉你当前仓库到底是哪里把 user.email、commit.gpgsign、user.signingkey 这些值设上的。很多“为什么和我想的不一样”的问题，都是靠这条命令排查出来的。

`noreply` 隐私邮箱到底解决什么问题

它只解决一个问题：避免在 commit 里公开暴露真实邮箱。

如果你不想把真实邮箱直接写进 Git 历史里，就可以把 GitHub 仓库的提交邮箱改成 GitHub 提供的匿名地址。

它不会替你完成签名

这一点最容易被误会。

用真实邮箱但不签名，不会有 Verified
用 noreply 但不签名，也不会有 Verified
只有签名通过了，才会显示 Verified

所以最理想的组合通常是：

提交邮箱用 noreply
提交本身用 SSH 或 GPG 签名

也就是同时兼顾“匿名”和“已验证”。

它在网页端和命令行端的行为不一样

如果你在 GitHub 账号设置里开启了：

Keep my email addresses private

那么 GitHub 网页端产生的提交会优先使用 noreply。

但如果你在本地命令行里提交，GitHub 不会自动改写你的 user.email。真正生效的仍然是你本地 Git 配置。

也就是说，如果你本地还是：

1

git config user.email "you@company.com"

那你从命令行提交出去的 commit，依然会带着这个真实邮箱。

这个设置建议一起打开

如果你很在意邮箱泄露，建议在 GitHub 的 Settings -> Emails 中一并开启：

Keep my email addresses private
Block command line pushes that expose my email

第二个选项的意义是：如果你从命令行 push 了会暴露私人邮箱的提交，GitHub 可以直接阻止这次 push，避免你事后才发现配置配错了。

开启 `noreply` 之后，旧 commit 会不会自动变匿名

不会。

这件事没有灰度空间，结论就是：历史提交不会因为你后来改了邮箱策略而自动重写。

原因也不复杂。Git 的 commit 对象里本来就记录了当时的作者和提交者信息。只要那次提交已经生成，它的邮箱元数据也就固定了。

所以：

旧 commit 当时如果用的是真实邮箱，历史里还是那个真实邮箱
你后来开启 Keep my email addresses private，只会影响之后的新提交
GitHub 不会替你重写仓库历史

如果仓库已经公开，工程上就应该默认认为这些旧邮箱已经跟着 Git 历史一起公开过了。

如果想把旧 commit 也改成匿名邮箱，要付出什么代价

真正有效的方法只有一个：重写 Git 历史。

常见做法是用 git-filter-repo 之类的工具，把旧提交里的 author 或 committer email 批量替换掉，然后再强制推送。

但这件事的代价不小：

所有受影响 commit 的 hash 都会变化
依赖这些历史的分支、标签、PR 引用都会受到影响
协作者本地仓库需要重新同步，严重时甚至要重新 clone
如果仓库已经被 fork、镜像或拉取，旧历史也不一定能彻底消失

所以大多数情况下，更现实的做法是：

保留旧历史
从现在开始改用 noreply
开启命令行邮箱泄露拦截
以后新提交全部走签名

什么情况下可以考虑重写历史

私有仓库
协作者很少，最好只有自己
历史不复杂，强推成本可控
你能接受所有 commit hash 变化

什么情况下通常不建议动

公开仓库
多人长期协作仓库
已经有外部分支、fork、PR、issue 引用的仓库

很多人真正需要的，其实不是“把过去全部抹干净”，而是“从今天开始不再继续泄露”。

最后给三个直接可用的结论

场景一：只想让 GitHub 新提交显示 `Verified`

直接配 SSH signing
把公钥作为 Signing Key 加到 GitHub
在 GitHub 仓库里开启 commit.gpgsign

场景二：既想 `Verified`，又不想暴露真实邮箱

提交邮箱用 GitHub 的 noreply
提交继续做 SSH signing
同时打开 Keep my email addresses private

场景三：本地同时操作 GitHub 和 GitLab

全局只配置签名能力，不默认全仓库自动签名
GitHub 仓库本地开启 commit.gpgsign true
GitLab 仓库保持普通邮箱和普通提交

这套方式通常最不容易互相污染。

参考文档

GitHub Docs: About commit signature verification
GitHub Docs: Telling Git about your signing key
GitHub Docs: Adding a new SSH key to your GitHub account
GitHub Docs: Email addresses reference
GitHub Docs: Setting your commit email address
GitHub Docs: Blocking command line pushes that expose your personal email address
GitHub Docs: Removing sensitive data from a repository

如果只保留一句总结，那就是：

noreply 管的是“显示哪个邮箱”，Verified 管的是“这个提交有没有被签名验证通过”，auth key 管的是“你能不能连上仓库”。

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

Fri, 10 Apr 2026 00:00:00 +0000

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

最近看一些 agent 对比资料时，我发现一个很常见但已经过时的说法：Codex 不能定义 agent，Claude Code 才可以。

这个结论现在已经不准确了。

OpenAI 官方已经单独写了 Codex 的 subagents 文档，明确说明可以在 ~/.codex/agents/ 或项目内 .codex/agents/ 定义自定义 agent，而且是用独立的 TOML 文件来配置。

所以现在更值得问的问题，已经不是“Codex 能不能定义 agent”，而是：Codex 和 Claude Code 都能做 agent 之后，它们的设计重点到底差在哪。

如果你之前已经看过我写的 AI 编程 CLI 总览文和 skills 对比文，这篇可以理解成下一层专题：它不再泛谈工具选型，而是专门讲 agent 这一层机制到底怎么分化。

写在前面

先给结论。

Codex 和 Claude Code 现在都支持自定义 agent，但两边的重心并不一样。

Claude Code 的 subagent，更像是一个已经深度融入主工作流的“专门分身系统”。它强调自动委派、上下文隔离、工具边界、权限模式、skills 注入、后台运行、worktree 隔离和持久记忆。

Codex 的 subagent，则更像是一个“可编排的显式多代理机制”。它同样支持自定义 agent，也支持模型、沙箱、MCP、skills 配置继承，但官方文档最强调的点是：只有在你明确要求时，Codex 才会 spawn subagent。

换句话说：

Claude Code 更像“主会话会主动用 agent 帮你拆任务”
Codex 更像“你明确下令后，它再把任务派给子 agent”

这不是谁强谁弱的问题，而是两种很不一样的交互哲学。

核心概念

虽然大家平时都习惯说“agent”，但两边官方文档里更准确的术语其实都是 subagent。

它们共同解决的是一类问题：

主对话不想被大段搜索结果、日志、文件内容淹没
某一类任务会反复出现，希望有固定的专用提示词和工具边界
希望把研究、审查、修改、排查这些工作拆成不同角色处理

从这个角度看，Codex 和 Claude Code 的目标很像，都是把“一个大助手”拆成“一个主会话 + 多个专门助手”。

但一旦继续往下看，就会发现它们在五个地方分化得很明显：

定义文件怎么写
主会话什么时候会委派
子 agent 能拿到哪些能力
配置和上下文怎么继承
工程化边界做到什么程度

先看一张总表

维度	Claude Code	Codex
官方术语	Subagents	Subagents / custom agents
定义位置	`~/.claude/agents/`、`.claude/agents/`、`--agents`	`~/.codex/agents/`、`.codex/agents/`
定义格式	Markdown + YAML frontmatter + Markdown body	TOML
最核心必填项	`name`、`description`，正文作为 system prompt	`name`、`description`、`developer_instructions`
默认委派方式	Claude 可根据 `description` 自动 delegate，也可显式指定	官方明确写明：只有你显式要求时才会 spawn subagent
工具控制	`tools`、`disallowedTools`、`permissionMode` 很细	以 `sandbox_mode`、父会话审批/沙箱继承为主
MCP 支持	支持按 subagent 配 `mcpServers`	支持按 custom agent 配 `mcp_servers`
skills 关系	subagent 可显式加载 `skills`，且不继承父会话 skills	custom agent 可配 `skills.config`，未写时继承父会话
后台运行	支持 `background: true`	官方页重点在线程与并发，不是固定后台 agent 配置
仓库隔离	支持 `isolation: worktree`	官方 subagents 页未把 worktree 隔离作为 custom agent 核心字段
持久记忆	支持 `memory: user/project/local`	官方 subagents 页未把持久记忆列为 custom agent 核心字段
嵌套限制	官方明确：subagent 不能再 spawn subagent	通过 `agents.max_depth` 控制，默认 1

如果只看表格，最醒目的差异其实就两条：

Claude Code 更强调“单个 subagent 的能力边界”
Codex 更强调“多 agent 调度时的显式控制和并发参数”

定义方式：Claude 更像写角色卡，Codex 更像写配置文件

这是两边最直观的区别。

Claude Code：Markdown 文件就是 agent 本体

Claude Code 的 subagent 文件本质上是一段带 frontmatter 的 Markdown。前面写元信息，后面整段正文就是这个 subagent 的 system prompt。

官方支持的字段很多，常用的包括：

name
description
tools
disallowedTools
model
permissionMode
maxTurns
skills
mcpServers
hooks
memory
background
effort
isolation
color
initialPrompt

这种设计的好处是很直观。

你在定义 Claude subagent 时，脑子里的问题往往是：

这个角色是谁
它该在什么时候被调用
它能用哪些工具
它应该遵守什么规则
它需要什么附加技能和记忆

也就是说，Claude 的 subagent 文件天然更接近“角色说明书”。

Codex：TOML 更偏配置驱动

Codex 的 custom agent 是 TOML 文件。官方页目前明确列出的必填项是：

name
description
developer_instructions

常见可选项包括：

nickname_candidates
model
model_reasoning_effort
sandbox_mode
mcp_servers
skills.config

官方还说明，custom agent 文件可以承载其他受支持的 config.toml 键。

这说明 Codex 的思路不是“正文 prompt 外挂一点配置”，而是更明显地把 custom agent 当成一种派生 session 配置层。

换句话说，Claude 更像“定义一个专门助手”；Codex 更像“定义一种被 spawn 出来的工作模式”。

委派机制：这可能是两边最大的分水岭

如果只允许我挑一个最值得写进文章标题下方的差异，那我会选这一条。

Claude Code：可以自动委派

Claude Code 官方文档明确写到，Claude 会根据每个 subagent 的 description 判断什么时候把任务 delegate 给它。

这意味着 Claude 的 agent 系统并不只是“你手动点名才会用”，而是会融入主会话自己的决策流程。

比如：

代码库搜索任务，Claude 可能自动丢给 Explore
计划模式里的研究任务，可能自动丢给 Plan
复杂多步骤操作，可能自动丢给 general-purpose

自定义 subagent 也可以走同样路线，只要 description 写得足够清楚。

Codex：只有显式要求才会 spawn

Codex 这边官方表述更直接：Codex only spawns subagents when you explicitly ask it to.

这句话非常关键，因为它直接决定了使用心智。

在 Codex 里，subagent 更像一个你主动调度的资源，而不是主会话会自动替你判断的分身系统。

这会带来两种体验差异：

第一种差异是可控性更高。

你想并行开几个、让谁做什么、何时停止，基本都更偏显式。

第二种差异是自动化程度更低。

如果你习惯 Claude 那种“我只描述目标，系统自己判断要不要起 agent”的方式，切到 Codex 时会明显感觉它更依赖你的调度意图。

继承规则：Claude 更强调边界，Codex 更强调沿父会话继承

两边都支持“没写的配置从父会话继承”，但重点不太一样。

Claude Code 的继承重点

Claude Code 文档里有几个点特别值得注意。

第一，tools 如果省略，就继承父会话工具；disallowedTools 则是在继承后的工具集上继续扣减。

第二，model 默认是 inherit。

第三，skills 不会从父会话自动继承。只有你在 subagent 文件里显式写了 skills:，它才会在启动时把这些 skill 的内容直接注入上下文。

第四，项目级 subagent 支持从当前工作目录向上发现 .claude/agents/，但 --add-dir 只给文件访问权限，不会顺带扫描 subagent 配置。

这套规则的核心味道很明显：Claude 很在意“一个 subagent 拿到什么，不拿到什么”。

Codex 的继承重点

Codex 当前官方页对继承的描述也很清楚，但口味更偏“子 session 叠层”。

它明确写到，custom agent 里未指定的可选项会从父 session 继承。更重要的是，spawn 子 agent 时，父 turn 当下的 runtime overrides 也会重新套用，包括：

审批设置
沙箱设置
交互过程中临时改过的运行参数
--yolo 这类高权限运行状态

这意味着 Codex 的 custom agent 虽然可以自己声明一些默认配置，但真正运行时，它依然深受当前父会话状态影响。

这种设计很适合“当前会话就是一个大工作流控制器”的用法。

能力边界：Claude Code 在 subagent 这层给的旋钮更多

如果你关心的不是“能不能开多个 agent”，而是“每个 agent 能不能像单独岗位一样严格收口”，那 Claude Code 这边会更有吸引力。

Claude Code 能直接在 subagent 层定义的东西更多

Claude 不只是让你选模型和工具，它还允许你直接在 subagent 里定义：

权限模式 permissionMode
生命周期 hooks
持久记忆 memory
后台运行 background
工作目录隔离 isolation: worktree
effort 等级
初始提示 initialPrompt

这意味着一个 Claude subagent 可以非常像“仓库里的正式岗位”：

代码审查员只能读文件
安全检查员只能用有限工具
某个 agent 永远后台跑
某个 agent 永远在临时 worktree 里改代码
某个 agent 还有自己的长期记忆目录

Codex 的 custom agent 更像核心运行参数覆写

Codex 当然也支持重要能力开关，比如：

sandbox_mode
mcp_servers
model
model_reasoning_effort
skills.config

但从官方页当前呈现出来的重点看，它更像是在告诉你：

这个 agent 用什么模型
推理强度多高
运行在什么沙箱里
接哪些 MCP
技能配置怎么带进去

也就是说，Codex 的 custom agent 已经足够实用，但它在“岗位制度化”这一层，没有 Claude Code 展开得那么细。

工程化能力：Claude 更像内建工作流，Codex 更像多线程调度器

这部分特别适合团队用户看。

Claude Code 的工程化味道

Claude Code 的 subagent 文档会让你明显感觉到，它不是只想解决“多开几个分身”，而是要把 subagent 做进整个 CLI 工作流里。

比如：

/agents 可以直接图形化管理
支持 project / user / managed / plugin 多层来源
同名 agent 有明确优先级覆盖规则
支持后台任务
支持 worktree 隔离
支持 persistent memory
支持和 skills、hooks、MCP 联动

这种设计非常适合长时间维护的团队仓库。

因为团队真正需要的，不只是“多一个 agent”，而是“这个 agent 在组织里怎么分发、怎么收权限、怎么和现有流程接起来”。

Codex 的工程化味道

Codex 这边更突出的，是并发和深度控制。

官方页给了统一的 [agents] 配置段，用来控制：

agents.max_threads
agents.max_depth
agents.job_max_runtime_seconds

其中官方页写得很明确：

agents.max_threads 默认是 6
agents.max_depth 默认是 1

这说明 Codex 对 subagent 的定位，很大一部分就是“可控的并行 worker 体系”。

它非常适合这种场景：

把一堆独立检查任务并发跑出去
做批量审查
做一批对象的一致性核对
让多个 worker 收集证据，再由主线程统一汇总

所以如果你更常见的任务是“把一个复杂问题拆成多个并行检查项”，Codex 的这套设计会很顺手。

一个很实际的判断：谁更适合什么人

如果你平时的使用方式更接近下面这种：

我只说目标，不太想手动编排
我希望系统自己判断什么时候该起 agent
我希望 agent 有明确的工具边界、权限模式和长期角色定义
我希望它和项目里的 skills、hooks、MCP、worktree 一起协同

那 Claude Code 的 subagent 机制通常会更贴手。

如果你的使用方式更接近下面这种：

我要明确地控制何时 spawn 子 agent
我要按任务拆很多并行 worker
我要给不同子任务设置不同模型或沙箱
我更关心线程数、深度、批量 job 这种编排能力

那 Codex 的 subagent 机制会更符合习惯。

常见问题与解决方案

问题一：现在还能说 Codex 不支持自定义 agent 吗

不建议这么说。

更准确的说法应该是：Codex 已经支持自定义 agent / subagents，但它和 Claude Code 的定义方式、委派机制和工程化边界不一样。

如果继续把“Codex 不支持 agent”写进对比文，今天已经容易误导读者。

问题二：Claude Code 和 Codex 的 agent，能不能简单理解成同一种东西

不能完全这样理解。

它们当然都属于“主会话委派子助手”的范畴，但 Claude 更强调自动委派和子 agent 的独立岗位边界，Codex 更强调显式调度和并发执行。

所以它们属于同一类能力，但不是同一种产品哲学。

问题三：如果我要给团队写一套 agent，先选哪边更省事

如果你的重点是“项目里沉淀一套长期可维护的角色体系”，Claude Code 往往更省事，因为字段更完整，和项目工作流结合得也更深。

如果你的重点是“把问题拆成多个并发 worker 来跑”，Codex 往往更顺手，因为它把并发、深度和 job 时限这些控制点摆得更前面。

问题四：agent 和 skills 是一回事吗

不是。

不管在 Claude Code 还是 Codex 里，skills 更像可复用知识包或流程包；agent 更像执行这些事情的专门角色。

这也是为什么我更建议把它们拆开理解：

skills 解决“这件事怎么稳定复用”
agent 解决“由谁、以什么边界、在什么上下文里去做”

关于三家工具的 skills 差异，可以接着看我前面那篇 skills 对比文；如果你想单独理解 CODEX_HOME 为什么会影响 Codex 的 skills、配置和状态目录，也可以再看那篇 CODEX_HOME 专题。

总结

很多旧资料还停留在“Claude Code 有 agent，Codex 没有”的阶段，但现在这个判断已经落后了。

今天更准确的结论应该是：

Codex 可以定义自定义 agent，而且 OpenAI 已经给了官方 subagents 文档
Claude Code 也可以定义 subagent，而且工程化边界展开得更完整
真正的差异不在“有没有”，而在“怎么定义、何时委派、边界收得多细、工作流整合有多深”

如果把一句话压缩到最短：

Claude Code 更像带权限、记忆、skills、worktree 的角色化 subagent 系统
Codex 更像由你显式调度的多线程 subagent 编排系统

也正因为如此，后面再看到有人把 Codex 写成“不能定义 agent”，你就要多留一个心眼了：问题很可能不是结论本身，而是资料已经过期了。

参考资料：

MoviePilot订阅与通知配置指南：目录、整理与Webhook一次讲清

Mon, 23 Mar 2026 00:00:00 +0000

写在前面

很多人在把 MoviePilot 跑起来之后，真正卡住的往往不是“搜不到资源”，而是下面这些更细碎、也更折腾人的问题：

为什么电影整理后会通知，电视剧却没通知
为什么已经下载完成了，但文件没有自动整理进媒体库
手动加到下载器里的种子，到底会不会被 MoviePilot 接管
目录明明都配了，为什么总是落到不想要的那个目录

如果你也在这些地方来回试错，这篇文章就是给你准备的。

上一篇文章我已经把订阅识别流程和规则执行顺序拆开讲过了，这一篇不再重复“规则怎么匹配”，而是把目录配置、通知逻辑、整理流程和 Webhook 触发机制一次讲清楚。

先说结论

如果你只想先拿结论，可以先记住这几条：

MoviePilot 的通知不是一个总开关，而是全局通知开关 + 目录通知开关两层同时生效。
目录配置里如果有多个目录都能匹配，会优先命中排在前面的目录。
想让下载完成后自动整理，目录的“自动整理”方式必须配对，尤其是“下载器监控”。
qBittorrent 的 Webhook 只是“加速触发整理”，不是唯一机制；即使不配 Webhook，定时任务也会兜底。
手动加到下载器里的种子，也有机会被自动整理，只要它最终落在 MoviePilot 正在监控的目录里。

目录配置：先决定文件会落到哪里

MoviePilot 在订阅时如果不手动指定目录，会按照目录规则自动匹配。

你可以把这个过程理解成：系统先看“这是电影还是电视剧”，再看“更具体属于哪一类”，最后再决定应该送进哪个目录。

常见的匹配维度通常包括：

媒体类型：电影 / 电视剧
媒体类别：国产剧、欧美剧、综艺、动画电影这类细分
存储类型：本地还是网络存储
同盘优先：源文件和目标目录尽量在同一块盘上

这里最容易忽略的，是目录顺序本身就是规则的一部分。

为什么目录顺序会影响结果

如果有多个目录都满足条件，MoviePilot 往往会优先使用配置顺序里更靠前的那个。

所以一个常见的错误写法是：

1
2
3


1. TV（类别：全部）
2. 国产剧（类别：国产剧）
3. 欧美剧（类别：欧美剧）

这会导致“TV（全部）”把后面的具体分类提前拦走，结果国产剧、欧美剧这些目录几乎没有机会生效。

更合理的顺序应该是：

1
2
3
4
5


1. 国产剧
2. 欧美剧
3. 日韩剧
4. 综艺
5. TV（全部，兜底）

一句话总结就是：具体分类在前，全部分类在后。

目录怎么配更省心

如果你想精细管理，可以给电影、电视剧都配完整分类；如果你更在意稳定和省事，反而建议简化。

一个比较实用的思路是：

电影保留一个“全部”兜底目录
电视剧只拆最常用的几个分类
其他都交给一个 TV 总目录兜底

这样做的好处是：

目录不会配得太复杂
错误匹配时更容易排查
后期维护成本更低

通知系统：为什么有时有通知，有时没有

MoviePilot 的通知逻辑，最容易让人误解的地方在于：它不是只看一个总开关。

如果只盯着 Telegram、企业微信这种通知渠道，很容易把问题看偏。真正决定“有没有通知”的，通常还是站内这两层配置有没有同时满足。

第一层：全局通知类型

在系统通知设置里，你会看到这类总开关：

资源下载
整理入库
订阅
媒体服务器

这些开关决定“这个类型的通知要不要发”。

第二层：目录自己的通知开关

目录配置里通常还有一个“通知”选项。

它决定的是：整理进这个目录的内容，要不要发通知。

这就是为什么很多人会遇到一个经典现象：

并不是 MoviePilot 天生对电影和电视剧区别对待，而是电视剧对应的目录很可能没有勾选“通知”。

排查顺序

如果你遇到“某些内容通知正常，某些内容完全没通知”，优先按下面顺序查：

全局“整理入库”通知有没有开
目标目录的“通知”有没有开
文件最后到底落进了哪个目录

这第三点很关键，因为如果目录匹配顺序出了问题，文件可能根本没有进入你以为的那个目录，自然也就不会按你预期发送通知。

自动整理与 Webhook：到底是谁在推动文件入库

从使用体验上看，很多人会把“下载完成”和“自动整理”看成一件事，但实际上它们是两步：

下载器把文件下载完
MoviePilot 再去识别和整理它

第二步能不能发生，取决于你的目录监控方式有没有配对。

如果你经常遇到“资源已经下完了，但媒体库里就是没出现”，这一节基本就是排查重点。

最常见也最推荐的方式：下载器监控

如果你的资源主要来自 qBittorrent、Transmission 这类下载器，最常见的做法就是给目录配置“下载器监控”。

它的核心思想很简单：

下载器先把文件下载到“资源目录”
MoviePilot 定期扫描这些目录
确认下载完成后，再把文件整理到“媒体库目录”

一个典型配置可以理解成这样：

1
2
3
4
5
6


目录别名：电影
媒体类型：电影
自动整理：下载器监控
资源目录：下载器保存位置
媒体库目录：整理后的最终位置
整理方式：硬链接

只要“资源目录”和“监控方式”配对了，整理流程通常就能跑起来。

为什么有时下载完了却一直不整理

这种情况大多数不是“MoviePilot 不会整理”，而是它判断下来，这个文件不在它要监控的目录里。

也就是说，最常见的问题不在下载器，而在目录配置本身：

资源目录填错了
配的是目录监控，但实际走的是下载器监控思路
文件实际下载到了另一个分类目录

所以如果你发现“任务完成了，但没整理”，先别急着怀疑识别逻辑，先确认：

下载器实际保存路径
MoviePilot 配置的资源目录
自动整理方式

这三者是不是同一套。

很多教程会教你在 qBittorrent 里配置完成任务后的 Webhook，这当然是有价值的，但它更准确的定位应该是：

让整理从“几分钟后”变成“几秒后”。

如果你已经把目录和监控方式配对好了，Webhook 带来的主要变化其实不是“能不能整理”，而是“整理发生得有多快”。

不配 Webhook 会怎样

不配也不代表完全不能整理。

因为 MoviePilot 通常还有定时任务在兜底，它会周期性地扫描下载器中已完成但尚未整理的任务。

区别只是：

配了 Webhook：种子完成后几乎立刻就触发整理
不配 Webhook：等下一轮定时任务来扫

所以如果你是重视实时性的人，Webhook 很值得配；但如果你只是想先把流程跑通，哪怕晚几分钟再整理，也不一定非配不可。

qBittorrent 怎么理解最简单

你可以把 qBittorrent 里的这个外部程序看成一个“提醒器”：

1
2
3
4


下载完成
→ 立刻通知 MoviePilot
→ MoviePilot 开始扫描已完成任务
→ 能识别并命中监控目录的文件就开始整理

它本身并不直接决定某个文件能不能整理，它只是把“开始检查”的时机提前了。

手动添加种子：会不会被接管

这是另一个很常见的问题。

比如你在 PT 站里看到了一个很满意的种子，直接手动丢进 qBittorrent，而不是从 MoviePilot 的订阅流程里发起下载。

这种情况下，MoviePilot 还有没有机会自动整理？

先说结论：有机会，而且很常见。

关键条件不是“这个任务是不是 MoviePilot 发起的”，而是：

文件最终有没有进入它正在监控的资源目录
MoviePilot 能不能识别出媒体信息

如果这两个条件成立，手动种子同样可能被整理。

为什么有时手动种子也能识别

因为对于 MoviePilot 来说，识别媒体信息并不总是依赖“下载历史记录”。

当没有现成的订阅上下文时，它仍然可能根据：

文件名
种子名称
目录结构

去尝试识别媒体信息。

这也是为什么你会看到一种现象：

某些手动种子能顺利整理
某些手动种子完全识别不出来

区别往往不在“是不是手动添加”，而在于名称够不够规范、信息够不够完整。

搜索关键词和自定义识别词：什么时候值得用

如果你已经读过订阅流程那篇文章，应该知道 MoviePilot 在识别和搜索时很依赖标题质量。

所以这一篇里我只给一个更偏实战的建议：

默认情况下，先不要过度依赖自定义识别词

因为很多问题根本不在“识别词不够多”，而在于：

目录配置顺序不合理
通知没开
监控方式没配对
资源目录不对

这些问题如果没先解决，你再怎么补识别词，也只是把排查复杂度继续往上抬。

更稳的顺序通常是：

先把目录和通知链路跑通
再去处理识别词、关键词和特殊规则

如果你想进一步理解“为什么资源明明搜到了却被过滤”，建议接着看上一篇：

MoviePilot订阅识别流程详解：从入门到精通

深入解析MoviePilot订阅识别的完整流程，详解自定义规则与优先级规则组的关系，帮助你彻底理解前置过滤、规则引用机制，解决订阅失败问题，打造完美的自动追剧体验。

2025-12-03nas

另外，很多“为什么这条资源不匹配”的问题，最后其实又会回到资源名称本身。如果你对资源标题里的 BluRay、WEB-DL、Remux、H265、Atmos 这些概念还不够熟，推荐再看这一篇：

视频资源术语完全指南：从入门到精通

全面解析视频资源中的各种术语，包括蓝光原盘、Remux、H265、Dolby Atmos、HDR 等概念，帮助你理解资源命名规则，配置 MoviePilot 过滤规则，下载到最适合自己的高质量资源。

2025-12-13nas

最后给一套排查顺序

如果你的订阅、通知或整理流程出了问题，建议按这个顺序排：

第一步：先看目录

第二步：再看通知

全局通知类型有没有开
目标目录的通知有没有开

第三步：再看整理方式

第四步：最后再看识别和规则

文件名是不是规范
识别词有没有必要补
订阅规则是不是把资源提前过滤掉了

按这个顺序排，通常比一上来就改一堆关键词和规则更有效。

总结

MoviePilot 的订阅与通知问题，很多时候不是“系统坏了”，而是几个看起来独立的小配置其实串成了一条链：

目录匹配决定文件去哪里
监控方式决定会不会整理
通知开关决定有没有提醒
文件名和识别逻辑决定能不能顺利入库

一旦你把这条链想清楚，很多之前看起来很玄学的问题，其实都能落回到很具体的配置点上。

简单记住一句话：

先把目录、监控和通知链路跑通，再去折腾识别词和高级规则。

AI 编程 CLI 的权限怎么配：Claude Code、Codex CLI 与 OpenCode 对比

Sat, 21 Mar 2026 00:00:00 +0000

AI 编程 CLI 的权限怎么配：Claude Code、Codex CLI 与 OpenCode 对比

这篇文章只聚焦一个问题：三款 AI 编程 CLI 分别怎样控制权限，规则写在哪里，真正生效时又按什么顺序匹配。

如果还没决定用哪一款工具，建议先看总览文，先把选型框架建立起来，再回来研究权限细节。

总览文入口：AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比

写在前面

如果把指令文件比作 AI 的“项目说明书”，那权限配置更像机房门禁。说明书决定它应该怎么做，权限系统决定它到底能做什么。

三款工具的差别主要集中在三个地方：

Claude Code 侧重“配置层级 + 白名单规则”，适合需要严格边界的场景。
Codex CLI 侧重“审批模式 + OS 沙箱”，概念最少，上手最快。
OpenCode 侧重“工具级权限 + 命令匹配”，灵活度高，但也更依赖使用者自己设计规则。

如果你还在研究项目说明文件怎么加载、怎么合并，可以配合下面这篇专题一起看：

AI 编程 CLI 的指令文件怎么生效：CLAUDE.md、AGENTS.md 与 OpenCode 对比

三款工具的权限机制概览

维度	Claude Code	Codex CLI	OpenCode
权限配置文件	`settings.json`	无	`opencode.json`
控制粒度	细粒度（工具 + 路径模式）	粗粒度（三种模式）	细粒度（工具 + 命令模式）
沙箱机制	规则白名单	macOS Seatbelt / Docker	规则白名单
企业管控	✅ managed 层不可覆盖	❌	⚠️ 远程配置

配置文件层级

Claude Code — `settings.json`（4 层级，固定路径，不遍历目录）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


优先级从高到低：

① 系统托管（不可被任何层级覆盖）
 macOS: /Library/Application Support/ClaudeCode/managed-settings.json
 Linux: /etc/claude-code/managed-settings.json
 Windows: C:\Program Files\ClaudeCode\managed-settings.json
 HKLM\SOFTWARE\Policies\ClaudeCode（注册表）

② 命令行参数（临时会话级覆盖）

③ 本地项目（个人私有，git 忽略）
 <repo>/.claude/settings.local.json

④ 共享项目（团队共享，git 追踪）
 <repo>/.claude/settings.json

⑤ 用户全局（最低优先级）
 ~/.claude/settings.json

与 CLAUDE.md 加载行为的核心差异：

1
2


CLAUDE.md → 目录向上遍历，沿途所有文件全部加载（越过 git root 继续）
settings.json → 固定路径，不做任何目录遍历

关键限制：~/projects/.claude/settings.json 这样的路径即使存在也不会被加载，跨项目共享权限只能放入 ~/.claude/settings.json。

Codex CLI — 无配置文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


权限控制完全依赖启动参数，三种模式：

 --approval-mode suggest 所有操作需用户确认（默认）
 --approval-mode auto-edit 文件编辑自动批准，shell 命令需确认
 --approval-mode full-auto 全自动执行（依赖 OS 沙箱隔离）

沙箱机制：
 macOS：Seatbelt（系统调用级别隔离）
 Linux：Docker 容器隔离

full-auto 模式：网络访问被完全禁止，文件系统受 OS 限制

OpenCode — `opencode.json`（多层级，支持目录遍历）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


加载顺序（优先级从低到高）：

① 远程组织配置（最低）
 .well-known/opencode（通过 HTTP 拉取，组织级默认值）

② 用户全局配置
 ~/.config/opencode/opencode.json

③ 环境变量指定路径
 $OPENCODE_CONFIG 指向的文件

④ 项目配置（从当前目录向上遍历查找，停在 git root）
 ./opencode.json

⑤ .opencode 目录（agents/, commands/ 等子目录）

⑥ 内联配置（最高）
 $OPENCODE_CONFIG_CONTENT 环境变量内容

OpenCode 特点：opencode.json 支持目录向上遍历查找（不同于 Claude Code 的固定路径），且多层级配置深度合并而非替换。

权限规则语法

Claude Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// .claude/settings.json
{
 "permissions": {
 "allow": [
 "Bash(npm run *)", // Bash 命令，支持通配符
 "Bash(git commit *)",
 "Read(./src/**)", // 文件读取，gitignore 风格
 "Read(~/data/work/**)", // 波浪号路径（指定目录免确认）
 "Edit(./src/**/*.java)", // 文件编辑
 "WebFetch(domain:github.com)", // 域名匹配
 "Glob(**/*.ts)", // 文件搜索
 "Grep(./src/**)" // 内容搜索
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl *)",
 "Read(./.env*)", // 拒绝读取环境变量文件
 "Read(./secrets/**)"
 ],
 "ask": [
 "Bash(git push *)", // 敏感操作需二次确认
 "Bash(docker *)",
 "Bash(kubectl *)"
 ]
 }
}

匹配规则：deny → ask → allow，首个匹配生效，后续规则忽略。

支持的工具名：

工具	说明	路径模式
`Bash(pattern)`	Shell 命令执行	命令通配符，如 `npm run *`
`Read(pattern)`	文件读取	gitignore 风格，如 `./src/**`
`Edit(pattern)`	文件编辑	gitignore 风格
`Write(pattern)`	文件写入	gitignore 风格
`Glob(pattern)`	文件名搜索	glob 模式
`Grep(pattern)`	内容搜索	目录路径
`WebFetch(domain:x)`	HTTP 请求	域名匹配
`Agent(name)`	子 Agent 调用	Agent 名称
`mcp__srv__tool`	MCP 工具	服务名__工具名

路径写法规则：

写法	含义
`Read(./src/**)`	项目内相对路径
`Read(~/data/work/**)`	家目录下的路径
`Read(//absolute/path/**)`	双斜杠开头表示绝对路径
`Read(./.env*)`	精确匹配特定文件

OpenCode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// opencode.json
{
 "permission": {
 // 工具级别全局设置
 "read": "allow",
 "edit": "allow",
 "glob": "allow",
 "grep": "allow",
 "list": "allow",
 "webfetch": "ask",
 "lsp": "allow",

 // bash 细粒度规则（最后匹配生效）
 "bash": {
 "*": "ask", // 默认所有命令需确认
 "git *": "allow", // git 命令放行
 "npm run *": "allow", // npm 命令放行
 "rm *": "deny", // 拒绝 rm
 "curl *": "deny" // 拒绝 curl
 }
 }
}

匹配规则：最后匹配生效（Last Match Wins），与 Claude Code 相反。

支持的工具名：

工具	说明	默认值
`read`	文件读取	`allow`
`edit`	文件编辑	`allow`
`glob`	文件搜索	`allow`
`grep`	内容搜索	`allow`
`list`	目录列表	`allow`
`bash`	Shell 命令	`ask`
`webfetch`	HTTP 请求	`allow`
`task`	任务执行	`allow`
`lsp`	语言服务器	`allow`
`skill`	技能调用	`allow`
`external_directory`	外部目录访问	`ask`
`doom_loop`	循环执行	`ask`

特殊默认行为：即使 read 为 allow，.env 文件默认仍为 deny，需显式解除。

Codex CLI

1
2
3
4


# 无配置文件，仅启动参数
codex --approval-mode suggest # 全部询问（默认）
codex --approval-mode auto-edit # 文件编辑自动放行
codex --approval-mode full-auto # 沙箱内全自动

合并策略

Claude Code — 数组合并 + 标量覆盖

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


数组类字段（跨层级合并，去重）：
 permissions.allow / deny / ask

示例：
 managed-settings.json: allow: ["Bash(//opt/company-tools/*)"]
 ~/.claude/settings.json: allow: ["Bash(npm run *)", "Bash(mvn *)"]
 .claude/settings.json: allow: ["Bash(git *)", "Read(./src/**)"]

 最终生效：
 allow: [
 "Bash(//opt/company-tools/*)", ← 来自 managed
 "Bash(npm run *)", ← 来自用户全局
 "Bash(mvn *)", ← 来自用户全局
 "Bash(git *)", ← 来自项目
 "Read(./src/**)" ← 来自项目
 ]

标量字段（高优先级完全覆盖低优先级）：
 model、theme 等

deny 的特殊地位：
 任何层级的 deny 均生效，低层级无法解除
 managed 层设置的 deny 不可被任何层级覆盖

OpenCode — 深度合并 + 最后匹配

规则一：多层级配置文件深度合并

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


~/.config/opencode/opencode.json（用户全局）：
{
 "permission": {
 "read": "allow",
 "edit": "allow",
 "bash": {
 "*": "ask",
 "git *": "allow"
 }
 }
}

./opencode.json（项目级）：
{
 "permission": {
 "webfetch": "deny", // 项目级新增字段
 "bash": {
 "npm run *": "allow" // 项目级追加规则
 }
 }
}

合并结果：
{
 "permission": {
 "read": "allow", // 来自全局
 "edit": "allow", // 来自全局
 "webfetch": "deny", // 来自项目（新增）
 "bash": {
 "*": "ask", // 来自全局
 "git *": "allow", // 来自全局
 "npm run *": "allow" // 来自项目（追加）
 }
 }
}

规则二：bash 规则内部按"最后匹配"生效

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


合并后的 bash 规则：
 "*": "ask"
 "git *": "allow"
 "npm run *": "allow"

执行 "git commit -m fix" 时：
 匹配 "*" → ask
 匹配 "git *" → allow ← 最后匹配，最终生效 ✅

执行 "curl http://..." 时：
 匹配 "*" → ask ← 唯一匹配，最终生效 ✅

执行 "rm -rf /tmp" 时：
 匹配 "*" → ask ← 唯一匹配，最终生效 ✅

规则三：Agent 级别直接覆盖全局（不合并）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
 "permission": {
 "bash": { "*": "ask", "git *": "allow" } // 全局权限
 },
 "agent": {
 "reviewer": {
 "permission": {
 "read": "allow",
 "bash": "deny", // 直接覆盖，全局的 git * allow 被完全忽略
 "edit": "deny"
 }
 }
 }
}

1
2
3
4
5
6
7


reviewer agent 最终权限：
 read: allow ← agent 定义
 bash: deny ← agent 定义（全局 git * allow 失效）
 edit: deny ← agent 定义

默认 agent 最终权限：
 bash: { "*": "ask", "git *": "allow" } ← 使用全局规则

与 Claude Code 的关键区别：Claude Code 的 deny 一旦设置不可逆；OpenCode 的 agent 级别可以完全覆盖全局规则，包括把全局的 deny 改回 allow。

多仓库场景实践

Claude Code 配置示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


~/projects/
├── CLAUDE.md ✅ 指令文件，目录遍历自动加载
├── .claude/settings.json ❌ 不会被加载（不在固定路径）
│
├── order-service/
│ ├── CLAUDE.md ✅ 指令文件，自动加载
│ └── .claude/
│ ├── settings.json ✅ 项目级权限（团队共享）
│ └── settings.local.json ✅ 本地个人权限（git 忽略）
│
└── notify-service/
 ├── CLAUDE.md ✅ 指令文件，自动加载
 └── .claude/
 └── settings.json ✅ 项目级权限（团队共享）

~/.claude/settings.json（跨所有项目生效）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
 "permissions": {
 "allow": [
 "Bash(git *)",
 "Bash(mvn *)",
 "Bash(npm run *)",
 "Read(~/data/work/**)",
 "Read(~/.claude/**)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Read(./.env*)",
 "Read(./secrets/**)"
 ],
 "ask": [
 "Bash(git push *)",
 "Bash(kubectl *)",
 "Bash(docker *)"
 ]
 }
}

~/projects/order-service/.claude/settings.json（仅 order-service 生效）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
 "permissions": {
 "allow": [
 "Bash(java *)",
 "Bash(mvn spring-boot:run)",
 "Read(./src/**)",
 "Edit(./src/**)"
 ]
 }
}

~/projects/order-service/.claude/settings.local.json（个人本地，不提交 git）：

1
2
3
4
5
6
7
8


{
 "permissions": {
 "allow": [
 "Bash(ssh *)",
 "Read(~/.ssh/config)"
 ]
 }
}

合并结果：三个文件的 permissions 数组跨层级合并去重，最终生效的是三者的并集。

OpenCode 配置示例

~/.config/opencode/opencode.json（跨所有项目生效）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{
 "permission": {
 "read": "allow",
 "edit": "allow",
 "bash": {
 "*": "ask",
 "git *": "allow",
 "mvn *": "allow",
 "rm -rf *": "deny",
 "curl *": "deny"
 }
 }
}

~/projects/order-service/opencode.json（仅 order-service 生效，与全局深度合并）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "permission": {
 "bash": {
 "java *": "allow",
 "mvn spring-boot:run": "allow"
 }
 },
 "agent": {
 "reviewer": {
 "permission": {
 "read": "allow",
 "edit": "deny",
 "bash": "deny"
 }
 }
 }
}

横向对比总表

配置文件对比

特性	Claude Code	Codex CLI	OpenCode
配置文件	`settings.json`	无	`opencode.json`
层级数量	4层（managed/user/project/local）	无	多层（remote/global/project/inline）
目录向上遍历	❌ 固定路径	❌	✅ 向上遍历查找（停在 git root）
企业管控层	✅ managed 不可覆盖	❌	⚠️ 远程配置（需 HTTPS）
跨项目共享	`~/.claude/settings.json`	无	`~/.config/opencode/opencode.json`

权限规则对比

特性	Claude Code	Codex CLI	OpenCode
细粒度 allow/deny/ask	✅	❌	✅
匹配规则逻辑	首个匹配（deny→ask→allow）	无	最后匹配
数组跨层合并	✅ permissions 数组跨层合并去重	❌	✅ 深度合并
deny 可逆性	❌ 任意层级 deny 不可被低层解除	❌	✅ agent 级可覆盖全局
Agent 级别权限	❌	❌	✅ 可覆盖全局
.env 文件保护	⚠️ 需手动 deny	❌	✅ 默认 deny

规则匹配逻辑对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Claude Code（首个匹配）：
 规则检查顺序：deny → ask → allow
 第一个匹配的规则立即生效，后续规则忽略

 陷阱示例：
 deny: ["Bash(rm *)"]
 allow: ["Bash(rm -rf /tmp/*)"] ← 永远不会生效（已被 deny 首先匹配）

 正确写法：把宽泛的 deny 放后面，具体的 allow 放前面
 allow: ["Bash(rm -rf /tmp/*)"] ← 先匹配，放行 /tmp 下的删除
 deny: ["Bash(rm *)"] ← 再匹配其他 rm 命令

OpenCode（最后匹配）：
 越靠后的规则优先级越高，适合从宽泛默认逐步精细化

 示例：
 "bash": {
 "*": "ask", // 默认询问
 "rm *": "deny", // 拒绝 rm
 "rm /tmp/*": "allow" // 最后匹配：/tmp 下 rm 允许 ✅
 }

总结

如果你的首要目标是把风险压到最低，Claude Code 的层级和规则模型更容易建立清晰边界。

如果你更看重简单直接，不想维护额外配置，Codex CLI 的审批模式更适合快速上手。

如果你需要更自由的命令匹配和多 Agent 权限设计，OpenCode 的可塑性会更强，但也更考验配置习惯。

文中的规则和行为基于 2026-03-18 左右公开资料与实测整理，工具迭代很快，真正上线前仍然建议再对照一次官方文档。

参考资料：

Claude Code、Codex、OpenCode 对 Skills 的支持现状对比

Sat, 21 Mar 2026 00:00:00 +0000

Claude Code、Codex、OpenCode 对 Skills 的支持现状对比

如果把 AGENTS.md、CLAUDE.md 看作“项目说明书”，那 skills 更像“可复用的专用工具箱”。

它们解决的是两类问题：

指令文件解决“这个项目有哪些约定”
skills 解决“某类任务怎样稳定重复执行”

这篇文章只聚焦一个问题：Claude Code、Codex、OpenCode 到底怎么支持 skills，它们分别放在哪，AI 又是怎么发现这些 skill 的。

如果你想先看三款工具在指令文件和权限模型上的整体差异，可以先读这两篇：

写在前面

先说一个容易混淆的点：三家对 skills 的支持程度并不对称。

Claude Code：已经把 skills 做成了完整的本地能力系统，目录、自动发现、嵌套发现、附加目录、权限限制都有文档。
OpenCode：同样有明确的 skill 机制，而且原生 skill 工具会把可用 skills 暴露给 agent。
Codex：OpenAI 已经明确在产品层面支持 skills，也有官方 openai/skills 仓库和 $skill-installer；但就我在 2026 年 3 月 21 日查到的公开资料看，Codex 的本地技能目录与发现规则，没有像 Claude Code 和 OpenCode 那样集中写成一篇单独文档。因此这部分需要区分“官方公开信息”和“本机实测行为”。

这篇文章会把两类信息明确分开写，避免把实测结论误写成官方规范。

先说结论

如果你只想要结论，可以先记住下面这三点：

Claude Code

有完整、明确、文档化的本地 skills 机制。
最核心目录是 ~/.claude/skills/ 和项目内 .claude/skills/。
Claude 会根据 skill 的 description 自动决定何时加载，也可以手动用 /skill-name 调用。

OpenCode

有完整、明确、文档化的 skills 机制，而且是原生能力。
最核心目录是 ~/.config/opencode/skills/ 和项目内 .opencode/skills/。
它还兼容 .claude/skills/ 与 .agents/skills/，这点对跨工具复用很有价值。

Codex

OpenAI 已经明确表示 Codex 支持 skills，且有官方 skill 仓库和安装器。
就当前我查到的公开材料，最明确的是：系统 skill 会内置安装，其他 skill 可通过 $skill-installer 安装，安装后通常要重启 Codex 才会被识别。
就我当前本机环境的实测，Codex 的用户级 skill 目录是 $CODEX_HOME/skills，未设置时通常就是 ~/.codex/skills。
但项目级目录如何扫描、是否像 Claude/OpenCode 那样有清晰的向上发现规则，公开资料不如前两者明确。

Claude Code：支持最完整

Skills 放在哪里

根据 Anthropic 当前文档，Claude Code 的 skill 位置分为三类：

范围	目录	用途
个人级	`~/.claude/skills/<skill-name>/SKILL.md`	所有项目可用
项目级	`.claude/skills/<skill-name>/SKILL.md`	当前项目可用
插件级	`<plugin>/skills/<skill-name>/SKILL.md`	插件启用时可用

这意味着 Claude Code 的思路很清楚：个人 skill 和项目 skill 是并列的一等公民。

Claude 怎么发现已安装的 skills

Claude Code 的发现机制也很完整：

skill 的 description 会帮助 Claude 判断什么时候自动加载
用户也可以直接通过 /skill-name 手动触发
如果 skill 在子目录下，Claude Code 还会自动发现嵌套的 .claude/skills/
如果你用 --add-dir 增加工作目录，那个目录里的 .claude/skills/ 也会自动加载

这几点组合起来，意味着 Claude Code 的 skill 系统不只是“能放文件”，而是已经形成了完整的目录层级 + 自动触发 + 手动调用模型。

Claude Code 还有一个容易忽略的变化

Anthropic 现在把自定义 slash commands 和 skills 放到了同一条演进路径上。官方文档明确提到：

旧的 .claude/commands/ 仍然能工作
但推荐优先用 .claude/skills/
如果 command 和 skill 同名，skill 优先

这其实很关键，因为它意味着 Claude Code 已经不再把 skills 仅仅看作“一个补充特性”，而是把它当成了统一的可扩展行为层。

OpenCode：原生技能系统最开放

Skills 放在哪里

OpenCode 的官方 skills 文档把目录写得非常明确，而且比 Claude Code 更开放：

范围	目录
项目级	`.opencode/skills/<name>/SKILL.md`
全局级	`~/.config/opencode/skills/<name>/SKILL.md`
Claude 兼容项目级	`.claude/skills/<name>/SKILL.md`
Claude 兼容全局级	`~/.claude/skills/<name>/SKILL.md`
Agent 兼容项目级	`.agents/skills/<name>/SKILL.md`
Agent 兼容全局级	`~/.agents/skills/<name>/SKILL.md`

这代表 OpenCode 的一个明显特点：它既支持自己的目录规范，也愿意兼容 Claude 和 agent-compatible 的目录结构。

OpenCode 怎么发现已安装的 skills

OpenCode 的官方说明同样很清楚：

对项目内目录，它会从当前工作目录向上走，直到 git worktree
途中加载 .opencode/skills/，以及兼容目录 .claude/skills/、.agents/skills/
同时也会加载全局目录里的 skill

这套机制的好处是，项目内 skill 真正可以做成分层发现，而不仅仅是一个固定全局目录。

OpenCode 怎么把 skills 暴露给 agent

OpenCode 文档里还有一个很值得注意的点：它会把可用 skills 列进原生 skill 工具的描述里，也就是 agent 天然知道“现在有哪些 skill 可用”。

从文档给出的示意来看，OpenCode 会在工具描述里暴露类似：

1
2
3
4
5
6


<available_skills>
 <skill>
 <name>git-release</name>
 <description>Create consistent releases and changelogs</description>
 </skill>
</available_skills>

这和 Claude Code 的 slash 风格不一样，但对 agent 来说反而更直接：它不需要靠用户记忆某个命令名，而是可以在工具上下文里直接看到技能列表。

Codex：已经支持，但目录口径要分开看

OpenAI 官方已经明确 Codex 支持 skills

这一点不需要猜。

OpenAI 在 2026 年 2 月 2 日发布的 Introducing the Codex app 文章里已经明确写到：

Codex 支持 skills
skills 可以打包 instructions、resources、scripts
Codex app 内置了创建和管理 skill 的界面
你可以显式要求 Codex 使用某个 skill，也可以让它按任务自动使用
新建的 skill 可以在 app、CLI、IDE extension 等不同界面复用

换句话说，产品层面“Codex 是否支持 skills”这个问题，答案已经是明确的“支持”。

OpenAI 官方 skill 仓库也已经成立

OpenAI 还有一个公开仓库：openai/skills。

它说明了几件很关键的事：

这是 Codex 的官方 skill catalog
.system 里的 skill 会自动安装
其他 curated 或 experimental skill 可以通过 $skill-installer 安装
安装后通常要重启 Codex 才能识别新 skill

这说明 Codex 对 skill 的支持并不是停留在营销文案，而是已经形成了：

官方仓库
官方安装器
官方内置系统 skill

Codex 的本地目录怎么理解

这部分要谨慎一点。

就我当前这台机器的实际环境来说：

当前 Codex 可自动发现的用户级 skill 目录是 ~/.codex/skills/
如果设置了 CODEX_HOME，则对应为 $CODEX_HOME/skills/

这和 Codex 内置 skill 创建/安装工具的默认路径是一致的。

但需要强调的是：

我在本轮能查到的 OpenAI 公开网页里，没有像 Claude Code 和 OpenCode 那样，把“项目级 skill 放在哪、如何向上扫描发现”单独写清楚
因此，~/.codex/skills 这一点我愿意写成“本机实测 + 官方仓库工具链默认路径一致”
但如果要写成“Codex 公共文档明确规定了完整的项目级技能目录扫描规则”，那就不严谨了

如果你想进一步理解为什么很多 Codex 本地 skill 最后会落到 ~/.codex/skills/，以及 CODEX_HOME 一旦改变会连配置、认证、历史和状态一起迁移，可以继续看这篇专题文：

Codex 的 CODEX_HOME 是什么？会影响哪些目录和行为

那 Codex 怎么发现已安装的 skills

基于当前公开信息与本机行为，可以把 Codex 的发现逻辑理解成两层：

第一层：安装层

系统 skill：最新版本 Codex 自动带上
其他 skill：用 $skill-installer 安装
安装后通常要重启 Codex，官方仓库 README 明确写了这一点

第二层：会话层

新会话启动后，Codex 会把可用 skill 纳入当前环境
在我当前环境里，已安装 skill 会出现在会话的可用技能列表中，并可按名称触发

因此，Codex 当前更像是：

产品上已经支持 skills
用户级 skill 目录已经可用
但公开文档对本地目录发现规则，没有 Claude/OpenCode 那么完整和集中

三者最大的差异，不在“有没有 skills”，而在“本地目录机制是否清楚”

如果把三家的本地技能支持放在同一张表里，差异会更直观：

维度	Claude Code	Codex	OpenCode
是否支持 skills	✅ 明确支持	✅ 明确支持	✅ 明确支持
官方是否单独写 skills 文档	✅ 是	⚠️ 产品与仓库层面较明确，目录文档不如前两者集中	✅ 是
全局目录	`~/.claude/skills/`	`$CODEX_HOME/skills/` 或 `~/.codex/skills/`（本机实测）	`~/.config/opencode/skills/`
项目目录	`.claude/skills/`	公开资料不如前两者明确	`.opencode/skills/`
兼容其他目录	旧 `.claude/commands/`	公开资料未见完整兼容矩阵	✅ 兼容 `.claude/skills/`、`.agents/skills/`
自动向上发现	✅ 有	公开资料不够集中	✅ 有，直到 git worktree
手动触发方式	`/skill-name`	当前会话内按可用 skill 触发	原生 `skill` 工具
新安装后是否需要重启	文档重心不在这里	✅ 官方仓库 README 明确建议重启	一般按当前配置即时发现或新会话生效

如果你最关心“项目里能不能版本控制一套 skills”

这里的答案也不一样：

Claude Code：最直接，提交 .claude/skills/ 即可
OpenCode：也很直接，甚至还能顺带兼容 .claude/skills/
Codex：当前更适合两种做法
- 用户级放 ~/.codex/skills/
- 项目里版本控制一份，再通过软链接或同步脚本接到 ~/.codex/skills/

也正因为这个差异，如果你的目标是“一套 SKILL.md 尽量跨工具复用”，OpenCode 和 Claude Code 目前更顺手，而 Codex 更像是“产品能力已经成熟，但本地目录实践还需要自己整理工程化习惯”。

我的建议

如果你只是想在一个工具里稳定使用 skills：

只用 Claude Code：直接围绕 .claude/skills/ 建
只用 OpenCode：优先 .opencode/skills/，需要兼容时再映射到 .claude/skills/
只用 Codex：优先维护 ~/.codex/skills/，项目内如需版本控制，再做软链接

如果你想让一套 skill 尽量复用到三者：

我更建议采用下面这个思路：

skill 内容统一使用 SKILL.md
项目里保留一份“源技能目录”
Claude Code 和 OpenCode 直接使用项目级目录
Codex 通过 ~/.codex/skills/ 软链接到项目里的 skill

这样做的好处是：

项目内可版本控制
Claude Code 能直接发现
OpenCode 能直接发现
Codex 也能继续自动识别用户级 skill

这比为三家各写一套独立技能目录要干净得多。

总结

如果只看“有没有 skills”，三家的答案现在都已经不是“没有”了。

真正拉开差距的地方，是：

Claude Code 把本地 skills 系统做得最完整，目录和触发机制最清楚
OpenCode 在本地 skill 体系上最开放，兼容性最好
Codex 在产品层面已经明确支持 skills，也有官方仓库和安装器，但本地目录与发现规则的公开文档化程度，目前不如前两者集中

如果你的重点是“写一套技能，尽量多工具复用”，OpenCode 和 Claude Code 目前更顺手；如果你的重点是“把 Codex 也纳入同一套技能体系”，最好提前接受一件事：Codex 这边更适合用用户级目录 + 项目内版本控制 + 软链接这种工程化方案。

本文基于 2026 年 3 月 21 日查到的公开资料与本机环境实测整理。工具迭代很快，尤其是 Codex，后续很可能继续补齐更正式的本地 skills 文档。

参考资料：

Codex 的 CODEX_HOME 是什么？会影响哪些目录和行为

Sat, 21 Mar 2026 00:00:00 +0000

Codex 的 CODEX_HOME 是什么？会影响哪些目录和行为

很多人第一次接触 Codex 的 skills，会先注意到 ~/.codex/skills/。接着很自然就会问一句：如果把 skill 放进项目里，或者把 CODEX_HOME 改掉，Codex 会不会自动识别？

这个问题表面上看像在问 skills，实际上问的是另一层东西：Codex 的本地工作根目录到底是什么，它会影响哪些文件。

如果你还没看过三家工具对 skills 支持方式的横向对比，建议先读这篇：

Claude Code、Codex、OpenCode 对 Skills 的支持现状对比

先说结论

CODEX_HOME 不是一个“只改技能目录”的小开关，它更像是 Codex 的主数据目录。

如果不设置它，Codex 默认会把自己的很多运行数据放到：

1

~/.codex

如果你显式设置了：

1

CODEX_HOME=/path/to/somewhere

那 Codex 往往就会把 skills、配置、认证、全局 AGENTS.md、历史、日志、状态等内容都切到这个新目录下，而不是只移动其中某一项。

很多人真正踩坑的地方不是“skill 没生效”，而是：

为什么之前的 skill 不见了
为什么模型配置和 trust 配置像重新初始化了一样
为什么历史和日志不连续了
为什么好像又要重新登录
为什么全局 AGENTS.md 的规则也跟着变了

如果你只想快速判断是否该改 CODEX_HOME，可以先看这几条：

如果你的目标只是“把 skill 放进项目里并让 Codex 识别”，通常不建议先动 CODEX_HOME
如果你的目标是“切换一整套独立的 Codex 环境”，那才适合用 CODEX_HOME
如果你的目标是“同一台电脑切多套 Codex 账号、API Key 或全局 AGENTS.md”，CODEX_HOME 就很适合
对大多数已经稳定使用 ~/.codex 的用户来说，CODEX_HOME 更像“环境隔离工具”，而不是“skills 管理工具”

默认情况下，Codex 在哪里存东西

如果只讲“默认值”，那就是：

1

~/.codex

在默认情况下，这个目录里通常会集中存放：

config.toml
auth.json
history.jsonl
log/
logs_*.sqlite
state_*.sqlite
shell_snapshots/
skills/

这几个目录和文件本身已经说明问题了：Codex 会把本地配置和运行状态集中放在同一个根目录里。

所以，CODEX_HOME 的真正影响范围，天然就不只是一项。

CODEX_HOME 到底会影响什么

1. Skills 自动发现目录

这是最容易观察到的一项。

Codex 内置的 skill 创建/安装工具说明得很明确：

skills 默认安装到 $CODEX_HOME/skills
如果没有设置 CODEX_HOME，那就回退到 ~/.codex/skills

这也是为什么当前这台机器上的用户级 skill 实际落在：

1

~/.codex/skills/

换句话说，如果你改了 CODEX_HOME，最先变化的一定是 skill 自动发现目录。

2. 配置文件位置

你当前机器上的配置文件在：

1

~/.codex/config.toml

里面不仅有模型与 provider 配置，还有项目信任状态。

一旦 CODEX_HOME 换到别处，Codex 往往就会去新根目录下找新的 config.toml。

这意味着：

原来的模型配置不会自动带过去
原来的 trust level 不会自动带过去
你会感觉像切到了一套新的 Codex 环境

3. 认证状态

当前这台机器的认证文件在：

1

~/.codex/auth.json

如果新 CODEX_HOME 下没有对应文件，Codex 很可能会把自己当作一个新环境。

这通常意味着：

认证状态不共用
有可能需要重新登录或重新读认证配置

这也是为什么如果你想在同一台电脑上切换多套 Codex 账号或多组 API Key，最直接的做法通常不是来回改一个 auth.json，而是直接切不同的 CODEX_HOME。

4. 历史、日志和状态数据库

当前目录里还存在：

history.jsonl
log/
logs_*.sqlite
state_*.sqlite
shell_snapshots/

这说明本地运行期状态同样挂在 ~/.codex 下面。

所以切换 CODEX_HOME 之后，通常还会带来这些变化：

历史会话不连续
本地日志不连续
状态数据库是另一套
shell 快照也是另一套

从实际效果上看，这更像“换了一整个 Codex 用户目录”，而不是“换了一个技能目录”。

5. 用户全局 `AGENTS.md`

这也是很多人一开始没意识到，但在团队协作里非常关键的一项。

如果你使用默认环境，那么用户全局指令文件通常就在：

1

~/.codex/AGENTS.md

而当你像我现在这样切到：

1

CODEX_HOME=~/data/work/.codex codex

对应的全局指令文件就会一起切到：

1

~/data/work/.codex/AGENTS.md

这个变化的价值非常实际：

个人环境可以保留自己的写作风格、偏好、实验规则
公司环境可以维护公司项目通用的协作约束、文档索引、代码规范
两边互不污染

如果你在同一台电脑上同时处理个人项目和公司项目，这通常比把所有规则都硬塞进 ~/.codex/AGENTS.md 更干净。

为什么很多人会误解 CODEX_HOME

因为最先暴露出来的问题，往往就是 skill。

例如：

原来 ~/.codex/skills/ 里的 skill 能自动识别
改了 CODEX_HOME 之后突然不见了

这时候很容易得出一个错误结论：

CODEX_HOME 就是 skills 目录变量

但从实际目录结构看，它显然不只是这个作用。

更准确的理解应该是：

CODEX_HOME 是 Codex 的本地根目录，而 skills/ 只是这个根目录下面的一个子目录。

这两个层级如果不分清，后面做项目隔离、skill 迁移或者环境切换时就很容易误判。

什么时候适合修改 CODEX_HOME

场景一：多环境隔离

这是最适合改 CODEX_HOME 的情况。

比如你想做下面这种彻底隔离：

公司项目一套环境
个人项目一套环境
实验项目一套环境

这时候你可以分别准备：

1
2
3


~/data/codex-home/work
~/data/codex-home/personal
~/data/codex-home/lab

然后按场景切换。

我现在这台机器就是这种思路的一个实际变体：

1
2


codex
codexwork

其中 codexwork 的定义就是：

1

alias codexwork='CODEX_HOME=~/data/work/.codex codex'

这种做法的优点是：

skill、配置、日志、历史全部隔离
可以隔离不同账号或不同 API Key
可以隔离不同的全局 AGENTS.md
不容易相互污染

它的代价也很明显：

更重
要维护多套配置
很多东西需要重新初始化

场景二：多账号与全局规则隔离

这是我认为很多人会低估，但其实很有价值的场景。

如果你的公司项目都集中在：

1

~/data/work/

那你完全可以专门准备：

1

~/data/work/.codex/AGENTS.md

把公司通用约束放进去，例如：

公司内部项目目录结构
统一技术栈约定
文档索引入口
代码评审口径
Git 提交约定

然后通过：

1

alias codexwork='CODEX_HOME=~/data/work/.codex codex'

把这套规则只作用在公司环境里。

这样做的好处是：

公司项目有一份稳定的“全局协作规则”
个人项目不必被公司规则干扰
你不需要在每个公司仓库里都重复写一遍相同背景

场景三：项目级完整隔离

比如你想直接这样启动：

1

CODEX_HOME=$PWD/.codex codex

这意味着你要的不是“项目级 skill 目录”，而是“项目级 Codex home”。

好处：

项目里可以封装一套完整环境
非常适合高度隔离或团队统一方案

坏处：

不只是 skill 变了，认证、配置、状态、历史也都可能跟着变
如果目标只是复用一套 skill，这种方案太重

什么时候不建议改 CODEX_HOME

1. 你只是想把 skill 放进项目里并版本控制

这是最典型的“没必要改”的场景。

如果你的目标只是：

项目里保存一份 skill
Codex 还能自动发现并使用它

更稳的方式通常是：

项目里保留一份 skill 源目录
~/.codex/skills/ 里做软链接指向项目里的目录

例如：

1
2


~/data/github/iminling-pages/tools/codex-skills/hugo-easyimage-cover-publisher/
~/.codex/skills/hugo-easyimage-cover-publisher -> 项目里的 skill 目录

这样你能同时得到：

项目内可版本控制
Codex 继续自动识别
不影响现有配置、认证、trust、日志和历史

如果你已经在用多套 CODEX_HOME，这里还有一个很实用的折中方案：

把不同环境的 config.toml、auth.json、history.jsonl、AGENTS.md 分开
但把多个环境的 skills/ 指向同一份目录

我当前机器上的公司环境就是类似做法：~/data/work/.codex/skills 直接软链接到 ~/.codex/skills。

这能减少重复维护，又不会破坏环境隔离的主体目标。

如果把这个思路再说得更明确一点，其实可以直接采用下面这种结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


~/.codex/
├── auth.json
├── config.toml
├── AGENTS.md
└── skills/

~/data/work/.codex/
├── auth.json
├── config.toml
├── AGENTS.md
└── skills -> ~/.codex/skills

这套结构的实际含义是：

~/.codex/skills 作为公共 skills 中心
其他 CODEX_HOME 通过软链接复用这一套 skills
但每个 CODEX_HOME 仍然保留自己的 AGENTS.md
每个 CODEX_HOME 也保留自己的认证信息和配置

这样做我认为很不错，原因很简单：

通用 skill 只维护一份
多套 Codex 环境都能直接用
公司规则和个人规则不会混在一起
账号、Key、trust、历史也能继续各自独立

2. 你已经有一套稳定的全局配置

对已经在长期使用 ~/.codex 的用户来说，贸然修改 CODEX_HOME 的副作用通常比收益大。

因为你改掉的不是一个局部目录，而是一整套根目录逻辑。

实际案例：我现在怎么用 CODEX_HOME

按我现在这台机器的真实使用方式，已经不是“只有一个 ~/.codex”这么简单了。

当前同时存在两套 Codex home：

1
2


~/.codex
~/data/work/.codex

其中：

个人环境继续保留 ~/.codex
公司环境单独放在 ~/data/work/.codex
直接执行 codex，默认走个人环境
我在 ~/.bash_profile 里定义了一个快捷方式：

1

alias codexwork='CODEX_HOME=~/data/work/.codex codex'

执行 codexwork 时，就会切到公司环境

这两套目录下目前都实际存在这些文件：

config.toml
auth.json
history.jsonl
log/
logs_*.sqlite
state_*.sqlite
shell_snapshots/
skills/

除此之外，公司环境里还额外维护了：

AGENTS.md

另外还有一个非常有代表性的细节：当前 ~/data/work/.codex/skills 并不是单独维护一份，而是软链接到 ~/.codex/skills。

这说明 CODEX_HOME 并不是“所有东西都必须完全复制一套”。

你完全可以：

把账号、认证、配置、历史、全局 AGENTS.md 隔离开
但把 skills/ 继续共享

如果结合这台机器的实际情况，我的建议会分成两层：

第一层，当前这套“双 CODEX_HOME”思路本身是合理的：

用多套 CODEX_HOME 隔离账号、Key、配置和全局 AGENTS.md
用快捷命令按场景切换

第二层，不要为了“看起来更独立”就把所有东西都复制一份：

如果 skill 本身不涉及账号隔离，可以继续共享
如果只是想让 skill 项目化，优先用“项目目录 + 软链接”
没必要把“skills 共享”和“环境隔离”硬绑定成二选一

这比直接把所有项目都切成 CODEX_HOME=$PWD/.codex 更稳，也更容易维护。

换句话说：

如果你要的是“技能项目化”，优先做软链接
如果你要的是“账号 / Key / 全局规则隔离”，优先考虑多套 CODEX_HOME
如果你既要隔离又不想重复维护 skill，可以做“隔离 home + 共享 skills”

这两个目标不要混成一个问题。

和 skills 支持那篇文章怎么配合看

如果你从 skills 对比文过来，最容易记住的一句话是：

skills 对比文回答的是：三家工具怎么支持 skills
这篇 CODEX_HOME 文回答的是：Codex 本地环境为什么会把技能目录、配置和状态绑定在一起

前者是横向对比，后者是 Codex 的本地环境专题。

两篇配合起来，基本就能把这类问题讲透：

skill 到底该放哪
为什么 Codex 常见目录是 ~/.codex/skills
为什么只想迁移 skill 时，不一定应该先动 CODEX_HOME
为什么一台电脑上多套账号或多套全局 AGENTS.md，反而很适合用 CODEX_HOME

总结

如果把 CODEX_HOME 只看成“skills 目录变量”，很容易做出错误决策。

更准确的理解是：

CODEX_HOME 是 Codex 的本地根目录
skills/ 只是这个根目录下的一部分
一旦切换它，通常会连配置、认证、全局 AGENTS.md、历史、日志和状态一起切换

所以：

想隔离一整套 Codex 环境，改 CODEX_HOME
想在同一台电脑上切多套账号、API Key 或全局 AGENTS.md，也很适合改 CODEX_HOME
只想把 skills 放进项目并继续自动发现，优先考虑“项目目录 + 软链接”而不是直接改 CODEX_HOME
如果你既要隔离环境又不想重复维护 skill，可以让不同 CODEX_HOME 共享同一份 skills/

本文基于 2026 年 3 月 21 日的本机环境实测，以及当前可见的 Codex skill 工具链说明整理。后续如果 OpenAI 公开补充了更完整的本地目录发现文档，这部分结论也值得再更新一次。

参考资料：

AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比

Fri, 20 Mar 2026 00:00:00 +0000

AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比

如果把这三款工具都装到本地，第一眼看上去它们都像“命令行里的 AI 编程助手”，但真正拉开差距的地方，往往不是聊天体验，而是项目说明文件、权限边界、配置方式和多仓库协作能力。

这篇文章承担的是“总览文”角色，目标不是把每个细节一次讲完，而是帮你快速建立判断框架：哪一款更适合企业团队，哪一款更适合个人开发，哪一款在多模型和灵活性上更有优势。

如果你已经确定自己更关心某一个专题，可以直接跳到下面两篇文章继续看：

写在前面

选这类工具时，最容易掉进的坑，是只看“模型能力”而忽略“机制成本”。真正影响日常体验的，通常是下面几个问题：

项目规则文件会不会自动继承，能不能覆盖多仓库场景。
权限模型是白名单式、审批式，还是命令规则式。
配置写法是否足够简单，团队成员能不能长期维护。
当项目规模变大时，规则和权限会不会越来越难收拾。

如果先把这些问题想清楚，后面的表格和细节就不会只剩“参数对参数”的堆砌。

工具概览

维度	Claude Code	Codex CLI	OpenCode
开发方	Anthropic	OpenAI	SST（开源）
语言实现	Node.js	Node.js	Go
开源	❌ 闭源	✅ 开源	✅ 开源
发布时间	2025 年初	2025 年 4 月	2025 年中
界面形式	终端交互	终端交互	TUI + 终端 + 桌面应用
多模型支持	❌ 仅 Claude	❌ 仅 OpenAI	✅ 支持多家提供商
定位	企业级编程助手	轻量代码助手	开源全能编程 Agent

指令文件机制

指令文件用于向 AI 提供项目上下文、编码规范、工作流约定等自然语言说明，相当于 AI 的"项目说明书"。

文件名与位置

Claude Code — `CLAUDE.md`

层级	路径	说明
系统托管	`/etc/claude-code/CLAUDE.md`（Linux） `/Library/Application Support/ClaudeCode/CLAUDE.md`（macOS）	IT 管理员下发，最高优先级
用户全局	`~/.claude/CLAUDE.md`	对当前用户所有项目生效
项目根目录	`./CLAUDE.md` 或 `./.claude/CLAUDE.md`	提交到 git，团队共享
子目录	`./src/CLAUDE.md`、`./pkg/foo/CLAUDE.md` 等	懒加载，按需触发

Codex CLI — `AGENTS.md`

层级	路径	说明
用户全局	`~/.codex/AGENTS.md`	对所有项目生效
仓库根目录	`<git repo root>/AGENTS.md`	提交到 git，团队共享
当前工作目录	`<cwd>/AGENTS.md`	与仓库根不同时单独加载

注意：Codex CLI 不做目录向上遍历，只从以上三个固定路径加载，按顺序合并。可用 --no-project-doc 或 CODEX_DISABLE_PROJECT_DOC=1 禁用项目文件加载。

OpenCode — `AGENTS.md`（优先）/ `CLAUDE.md`（兼容回退）

层级	路径	说明
用户全局	`~/.config/opencode/AGENTS.md`	对所有项目生效，不提交 git
项目根目录	`./AGENTS.md`	提交到 git，团队共享
Claude 兼容（回退）	`./CLAUDE.md`（无 AGENTS.md 时）	迁移兼容，两者同时存在时忽略 CLAUDE.md
扩展引用	通过 `opencode.json` 的 `instructions` 字段 glob 引入任意文件	跨文件聚合

OpenCode 兼容说明：若同时存在 AGENTS.md 和 CLAUDE.md，只读取 AGENTS.md，CLAUDE.md 被忽略。

目录继承行为

三个工具都支持向上遍历目录查找指令文件，但行为有所不同：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


多仓库场景示例（每个服务是独立的 git repo）：

~/projects/
├── CLAUDE.md / AGENTS.md ← 多仓库共享层（projects 目录）
├── order-service/ ← git repo ①
│ ├── CLAUDE.md / AGENTS.md ← 项目级
│ └── src/
│ └── order/
│ └── CLAUDE.md ← 子模块级（当前工作目录）
└── notify-service/ ← git repo ②
 └── CLAUDE.md / AGENTS.md ← 项目级

Claude Code 遍历行为

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


当前工作目录：~/projects/order-service/src/order/

加载顺序（启动时全量加载）：
 1. ~/.claude/CLAUDE.md ← 用户全局（独立加载，非遍历结果）
 2. ~/projects/CLAUDE.md ← 多仓库共享层（实测验证：越过 git root 继续向上）
 3. ~/projects/order-service/CLAUDE.md ← 项目根目录
 4. ~/projects/order-service/src/CLAUDE.md ← 遍历沿途（如存在）
 5. ~/projects/order-service/src/order/CLAUDE.md ← 当前工作目录

子目录懒加载（按需）：
 当 Claude 读取 src/payment/ 中的文件时，
 才加载 src/payment/CLAUDE.md（如果存在）

遍历终止条件：官方文档未明确说明，但经实测验证：Claude Code 不会停在 git root，会继续向上遍历父目录。例如工作目录为 /data/work/ai-mvn（git repo），/data/work/CLAUDE.md（repo 外的上级目录）同样会被加载。~/.claude/CLAUDE.md 是独立的用户全局配置，并非遍历结果。可通过 /context 命令查看当前会话实际加载的文件列表。

多仓库场景下的文件职责划分：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


~/.claude/CLAUDE.md → 个人偏好，所有项目通用（语言、风格）

~/projects/CLAUDE.md → 多仓库共享约定
 - 技术栈统一规范
 - 服务目录（所有服务地址、职责）
 - 跨服务 HTTP 调用约定
 - 接口变更协作流程

~/projects/order-service/CLAUDE.md → 本服务内容
 - 本服务职责与模块结构
 - 本服务对外暴露的接口
 - 本服务依赖的上游接口契约（重点！）

~/projects/order-service/src/*/CLAUDE.md → 子模块特殊说明（可选）

示例：~/projects/CLAUDE.md（多仓库共享层）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 多服务共享规范

## 技术栈
- Java 8 + Spring Boot 2.x
- 服务间通信：HTTP REST，统一使用 Feign Client
- 统一响应结构：{ code: int, message: String, data: T }

## 服务目录
| 服务 | 职责 | 内网地址 |
|------|------|----------|
| user-service | 用户账户、余额管理 | http://user-service:8001 |
| order-service | 订单生命周期管理 | http://order-service:8002 |
| notify-service | 短信/Push 通知 | http://notify-service:8003 |

## 跨服务开发约定
- 修改任何对外接口前，先确认所有下游调用方
- Feign Client 定义在各服务的 api 模块，不在 core 模块直接 HTTP 调用
- 接口字段变更（新增除外）需同步更新所有调用方

示例：~/projects/order-service/CLAUDE.md（项目层）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# order-service

## 本服务职责
管理订单全生命周期：创建 → 支付确认 → 发货 → 完成 / 取消

## 模块结构
- order-api 对外 Feign Client 接口定义（供其他服务引用）
- order-core 业务逻辑层
- order-server 启动入口 + Controller

## 本服务对外接口
- POST /api/orders 创建订单
- PUT /api/orders/{id}/pay 支付回调
- GET /api/orders/{id} 查询订单详情

## 依赖的上游接口（修改时需同步）

### user-service
- GET /api/users/{id}/balance
 响应：{ code: 0, data: { balance: BigDecimal } }
- POST /api/users/{id}/balance/freeze
 请求：{ amount: BigDecimal, orderId: String }
 响应：{ code: 0, data: { freezeId: String } }

### notify-service
- POST /api/notify/send
 请求：{ userId: String, type: "ORDER_CREATED"|"ORDER_PAID", bizId: String }
 响应：{ code: 0, data: { msgId: String } }

Codex CLI 加载行为（固定路径，无目录遍历）

1
2
3
4
5
6
7
8


当前工作目录：~/projects/order-service/src/order/

加载顺序（仅三个固定路径，按顺序合并）：
 1. ~/.codex/AGENTS.md ← 用户全局
 2. ~/projects/order-service/AGENTS.md ← git 仓库根目录
 3. ~/projects/order-service/src/order/AGENTS.md ← 当前工作目录（与仓库根不同时）

不会加载 ~/projects/AGENTS.md（不在固定路径内，直接忽略）。

多仓库限制：Codex CLI 无法加载 ~/projects/ 层级的共享文件。跨项目共享内容只能放入 ~/.codex/AGENTS.md 用户全局文件，token 有限时需精简。

多仓库场景下的文件职责划分：

1
2
3
4
5
6
7
8
9


~/.codex/AGENTS.md → 必须承担所有跨项目内容
 - 技术栈规范
 - 服务目录
 - 跨服务约定
 （内容较多时注意 token 消耗）

~/projects/order-service/AGENTS.md → 本服务内容
 - 本服务职责与接口
 - 依赖的上游接口契约

OpenCode 遍历行为

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


当前工作目录：~/projects/order-service/src/order/

加载顺序：
 1. ~/.config/opencode/AGENTS.md ← 用户全局
 2. 从当前目录向上遍历至 git root，每层取一个文件
 - ~/projects/order-service/src/order/AGENTS.md ← 当前目录
 - ~/projects/order-service/src/AGENTS.md ← 若存在
 - ~/projects/order-service/AGENTS.md ← git root，停止
 3. opencode.json 中 instructions 字段引用的额外文件

不会加载 ~/projects/AGENTS.md（遍历止于 git root）。

多仓库限制：与 Codex CLI 类似，OpenCode 停在 git root，无法自动读取 ~/projects/ 层级的共享文件。但可通过 opencode.json 的 instructions 字段显式引入。

多仓库场景下推荐用 instructions 引入共享文件：

1
2
3
4
5
6
7
8
9


~/projects/
├── _shared/ ← 共享契约目录（非 git repo）
│ ├── conventions.md ← 技术栈、服务目录、跨服务约定
│ └── api-contracts/
│ ├── user-service.md
│ └── notify-service.md
└── order-service/
 ├── AGENTS.md ← 本服务职责与对外接口
 └── opencode.json ← 通过 instructions 引入共享内容

1
2
3
4
5
6
7
8
9


// ~/projects/order-service/opencode.json
{
 "instructions": [
 "./AGENTS.md",
 "~/_shared/conventions.md",
 "~/_shared/api-contracts/user-service.md",
 "~/_shared/api-contracts/notify-service.md"
 ]
}

多文件合并策略

工具	合并方式	优先级规则
Claude Code	✅ 全部合并，所有层级的文件都加入上下文	越具体的层级（越靠近当前目录）优先级越高；冲突指令 Claude 可能随机选择一个
Codex CLI	✅ 全部合并，沿途所有文件拼接	越靠近当前目录的文件内容排列在后，隐式优先
OpenCode	⚠️ 每层级取一个文件，不跨文件合并；但可通过 `instructions` 字段显式引入多文件	越靠近当前目录优先级越高

OpenCode instructions 字段示例（显式多文件合并）

1
2
3
4
5
6
7
8
9


// opencode.json
{
 "instructions": [
 "./AGENTS.md",
 "./docs/coding-standards.md",
 "packages/*/AGENTS.md",
 "https://example.com/shared-rules.md"
 ]
}

权限与设置文件机制

配置文件层级

Claude Code — `settings.json`（4 层级，固定路径，不遍历目录）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


优先级从高到低：

① 系统托管（不可被覆盖）
 macOS: /Library/Application Support/ClaudeCode/managed-settings.json
 Linux: /etc/claude-code/managed-settings.json
 Windows: C:\Program Files\ClaudeCode\managed-settings.json
 HKLM\SOFTWARE\Policies\ClaudeCode（注册表）

② 命令行参数（临时会话级覆盖）

③ 本地项目（个人私有，git 忽略）
 .claude/settings.local.json

④ 共享项目（团队共享，git 追踪）
 .claude/settings.json

⑤ 用户全局（最低优先级）
 ~/.claude/settings.json

注意：settings.json 不走目录遍历，只从上述固定路径加载。这与 CLAUDE.md 的行为完全不同——即使 ~/projects/.claude/settings.json 这样的路径存在，也不会被加载。

与 CLAUDE.md 加载行为的核心差异：

1
2


CLAUDE.md → 目录向上遍历，沿途所有文件全部加载（越过 git root 继续）
settings.json → 固定 4 个路径，不做任何目录遍历

多仓库场景下的配置策略：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


~/projects/
├── CLAUDE.md ✅ 会被加载（目录遍历）
├── .claude/settings.json ❌ 不会被加载（不在固定路径）
│
├── order-service/ git repo ①
│ ├── CLAUDE.md ✅ 会被加载
│ └── .claude/
│ ├── settings.json ✅ 项目级权限（团队共享）
│ └── settings.local.json ✅ 本地个人权限（git 忽略）
│
└── notify-service/ git repo ②
 ├── CLAUDE.md ✅ 会被加载
 └── .claude/
 └── settings.json ✅ 项目级权限（团队共享）

跨多个项目共享权限配置，只能放入用户全局文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// ~/.claude/settings.json（对所有项目生效）
{
 "permissions": {
 "allow": [
 "Bash(git *)",
 "Bash(mvn *)",
 "Bash(npm run *)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Read(./.env*)"
 ],
 "ask": [
 "Bash(git push *)",
 "Bash(kubectl *)"
 ]
 }
}

1
2
3
4
5
6
7
8
9


// ~/projects/order-service/.claude/settings.json（仅 order-service 生效）
{
 "permissions": {
 "allow": [
 "Bash(java *)",
 "Bash(mvn spring-boot:run)"
 ]
 }
}

1
2
3
4
5
6
7
8
9


// ~/projects/order-service/.claude/settings.local.json（个人本地，不提交 git）
{
 "permissions": {
 "allow": [
 "Bash(ssh *)",
 "Read(~/.ssh/config)"
 ]
 }
}

合并结果：三个文件的 permissions 数组会跨层级合并去重，最终生效的规则是三者的并集。deny 规则任意层级设置后，低层级无法解除。

Codex CLI — 无配置文件

1
2
3
4
5
6
7
8
9


Codex CLI 没有权限配置文件，权限控制完全依赖启动参数：

 --approval-mode suggest 所有操作需用户确认（默认）
 --approval-mode auto-edit 文件编辑自动批准，shell 命令需确认
 --approval-mode full-auto 全自动执行（依赖 OS 沙箱隔离）

沙箱机制：
 macOS：Seatbelt（系统调用级别隔离）
 Linux：Docker 容器隔离

OpenCode — `opencode.json`（2 层级 + 远程配置，支持目录遍历）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


加载顺序（优先级从低到高）：

① 远程组织配置（最低）
 .well-known/opencode（通过 HTTP 拉取，组织级默认值）

② 用户全局配置
 ~/.config/opencode/opencode.json

③ 环境变量指定路径
 $OPENCODE_CONFIG 指向的文件

④ 项目配置（从当前目录向上遍历查找）
 ./opencode.json

⑤ .opencode 目录（agents/, commands/, plugins/ 等子目录）

⑥ 内联配置（最高）
 $OPENCODE_CONFIG_CONTENT 环境变量内容

OpenCode 特点：opencode.json 支持目录向上遍历查找（不同于 Claude Code 的固定路径），且多层级配置深度合并而非替换。

权限规则语法

Claude Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// .claude/settings.json
{
 "permissions": {
 "allow": [
 "Bash(npm run *)", // Bash 命令，支持通配符
 "Bash(git commit *)",
 "Read(./src/**)", // 文件读取，gitignore 风格
 "Read(~/.zshrc)", // 波浪号路径
 "Edit(/src/**/*.java)", // 文件编辑
 "WebFetch(domain:github.com)", // 域名匹配
 "Glob(**/*.ts)", // 文件搜索
 "Grep(./src/**)", // 内容搜索
 "mcp__server__toolname" // MCP 工具
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl *)",
 "Read(./.env*)", // 拒绝读取环境变量文件
 "Read(./secrets/**)"
 ],
 "ask": [
 "Bash(git push *)", // 敏感操作需二次确认
 "Bash(docker *)"
 ]
 }
}

匹配规则：deny → ask → allow，首个匹配生效，后续规则忽略。

支持的工具名：

工具	说明	模式示例
`Bash(pattern)`	Shell 命令执行	`Bash(npm run *)`
`Read(pattern)`	文件读取	`Read(./src/**)`
`Edit(pattern)`	文件编辑	`Edit(*/.java)`
`Write(pattern)`	文件写入	`Write(./tmp/**)`
`Glob(pattern)`	文件名搜索	`Glob(*/.ts)`
`Grep(pattern)`	内容搜索	`Grep(./src/**)`
`WebFetch(domain:x)`	HTTP 请求	`WebFetch(domain:api.github.com)`
`Agent(name)`	子 Agent 调用	`Agent(general-purpose)`
`mcp__srv__tool`	MCP 工具	`mcp__filesystem__read`

OpenCode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


// opencode.json
{
 "permission": {
 // 工具级别全局设置
 "read": "allow",
 "edit": "ask",
 "glob": "allow",
 "grep": "allow",
 "list": "allow",
 "webfetch": "ask",
 "task": "allow",
 "lsp": "allow",

 // bash 细粒度规则（最后匹配生效）
 "bash": {
 "*": "ask", // 默认：所有命令需确认
 "git status": "allow", // 精确匹配
 "git *": "allow", // 通配符
 "npm run *": "allow",
 "rm *": "deny", // 拒绝危险命令
 "rm -rf *": "deny"
 },

 // 全局快捷设置（覆盖所有工具）
 // "permission": "allow" // 全部放行
 // "permission": "ask" // 全部询问
 // "permission": "deny" // 全部拒绝
 }
}

匹配规则：最后匹配生效（Last Match Wins），与 Claude Code 相反。

支持的工具名：

工具	说明	默认值
`read`	文件读取	`allow`
`edit`	文件编辑	`allow`
`glob`	文件搜索	`allow`
`grep`	内容搜索	`allow`
`list`	目录列表	`allow`
`bash`	Shell 命令	`ask`
`webfetch`	HTTP 请求	`allow`
`task`	任务执行	`allow`
`lsp`	语言服务器	`allow`
`skill`	技能调用	`allow`
`external_directory`	外部目录访问	`ask`
`doom_loop`	循环执行	`ask`

特殊默认行为：即使 read 为 allow，.env 文件默认仍为 deny，需显式解除。

Codex CLI

1
2
3
4
5
6
7


# 无配置文件，仅启动参数
codex --approval-mode suggest # 全部询问（默认）
codex --approval-mode auto-edit # 文件编辑自动放行
codex --approval-mode full-auto # 沙箱内全自动

# 沙箱说明：
# full-auto 模式下网络访问被完全禁止，文件系统访问受 OS 限制

合并策略

Claude Code settings.json 合并规则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


数组类字段（跨层级合并，去重）：
 permissions.allow
 permissions.deny
 permissions.ask
 sandbox.filesystem.allowWrite / denyWrite / denyRead
 hooks（各事件的 hook 列表）
 环境变量数组

示例：
 managed-settings.json: allow: ["Bash(//opt/company-tools/*)"]
 ~/.claude/settings.json: allow: ["Bash(npm run *)"]
 .claude/settings.json: allow: ["Bash(git *)"]
 最终生效： allow: ["Bash(//opt/company-tools/*)", "Bash(npm run *)", "Bash(git *)"]

标量字段（高优先级完全覆盖低优先级）：
 model、theme 等配置项

deny 的特殊地位：
 任何层级的 deny 规则均生效，低层级无法解除 managed 的 deny

OpenCode opencode.json 合并规则

OpenCode 使用深度合并（Deep Merge），同时注意最后匹配生效（Last Match Wins）的规则逻辑，这两点组合起来决定了最终权限行为。

规则一：多层级配置文件深度合并

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


~/.config/opencode/opencode.json（用户全局）：
{
 "permission": {
 "read": "allow",
 "edit": "allow",
 "bash": {
 "*": "ask", // 默认所有 bash 命令需确认
 "git *": "allow" // git 命令放行
 }
 }
}

./opencode.json（项目级）：
{
 "permission": {
 "webfetch": "deny", // 项目级禁止 HTTP 请求
 "bash": {
 "npm run *": "allow" // 项目级追加：npm 命令放行
 }
 }
}

合并结果：
{
 "permission": {
 "read": "allow", // 来自全局
 "edit": "allow", // 来自全局
 "webfetch": "deny", // 来自项目（新增字段）
 "bash": {
 "*": "ask", // 来自全局
 "git *": "allow", // 来自全局
 "npm run *": "allow" // 来自项目（追加）
 }
 }
}

规则二：bash 规则内部按"最后匹配"生效

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


合并后的 bash 规则：
 "*": "ask" ← 通配兜底
 "git *": "allow" ← 覆盖通配，git 命令放行
 "npm run *": "allow" ← 覆盖通配，npm 命令放行

执行 "git commit -m fix" 时：
 匹配 "*" → ask
 匹配 "git *" → allow ← 最后匹配，最终生效 ✅

执行 "curl http://..." 时：
 匹配 "*" → ask ← 只有这一条匹配，最终生效 ✅

执行 "rm -rf /tmp" 时：
 匹配 "*" → ask ← 最终生效 ✅（没有更具体的规则覆盖）

规则三：Agent 级别的 permission 覆盖全局（不合并）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


opencode.json：
{
 "permission": {
 "bash": { "*": "ask", "git *": "allow" } // 全局权限
 },
 "agent": {
 "reviewer": {
 "permission": {
 "read": "allow",
 "bash": "deny", // ← 直接覆盖，不与全局 bash 规则合并
 "edit": "deny"
 }
 }
 }
}

reviewer agent 最终权限：
 read: "allow" ← 来自 agent 定义
 bash: "deny" ← 来自 agent 定义（全局的 git * allow 被完全忽略）
 edit: "deny" ← 来自 agent 定义

默认 agent 最终权限：
 bash: { "*": "ask", "git *": "allow" } ← 使用全局规则

与 Claude Code 的关键区别：Claude Code 的 deny 一旦设置任意层级均不可逆；OpenCode 的 agent 级别可以完全覆盖全局规则，包括把全局的 deny 改回 allow。

详细配置参考

Claude Code

完整 settings.json 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


// .claude/settings.json（项目级，团队共享）
{
 "model": "claude-opus-4-6",

 "permissions": {
 "allow": [
 "Bash(npm run *)",
 "Bash(mvn *)",
 "Bash(git add *)",
 "Bash(git commit *)",
 "Bash(git status)",
 "Bash(git diff *)",
 "Bash(git log *)",
 "Read(./**)",
 "Edit(./src/**)",
 "Glob(**/*.java)",
 "Grep(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push *)",
 "Bash(curl *)",
 "Read(./.env*)",
 "Read(./secrets/**)",
 "Read(./credentials/**)"
 ],
 "ask": [
 "Bash(git push *)",
 "Bash(docker *)",
 "Bash(kubectl *)",
 "WebFetch(*)"
 ]
 },

 "env": {
 "JAVA_HOME": "/usr/lib/jvm/java-8-openjdk",
 "MAVEN_OPTS": "-Xmx2g"
 }
}

1
2
3
4
5
6
7
8
9


// .claude/settings.local.json（本地私有，git 忽略）
{
 "permissions": {
 "allow": [
 "Bash(ssh *)",
 "Read(~/.ssh/config)"
 ]
 }
}

CLAUDE.md 加载顺序完整示意

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


启动时加载（全量，按优先级从低到高）：
 /etc/claude-code/CLAUDE.md → 系统策略
 ~/.claude/CLAUDE.md → 用户全局
 ~/projects/CLAUDE.md → 中间路径（如存在）
 ~/projects/my-app/CLAUDE.md → 项目根目录
 ~/projects/my-app/src/api/CLAUDE.md → 当前工作目录

按需加载（访问时触发）：
 ~/projects/my-app/src/auth/CLAUDE.md → 当 Claude 读取 auth/ 中文件时加载
 ~/projects/my-app/test/CLAUDE.md → 当 Claude 读取 test/ 中文件时加载

CLAUDE.md Import 语法

1
2
3
4
5


<!-- CLAUDE.md 中引用其他文件 -->
@./docs/coding-standards.md
@./docs/api-guidelines.md
@~/.claude/personal-preferences.md
@/absolute/path/to/shared-rules.md

Codex CLI

启动参数参考

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 基础使用
codex "帮我重构这个函数"
codex --model gpt-4o "解释这段代码"

# 权限模式
codex --approval-mode suggest # 默认：所有操作需确认
codex --approval-mode auto-edit # 文件编辑自动批准
codex --approval-mode full-auto # 全自动（需沙箱支持）

# 沙箱控制
codex --no-sandbox # 禁用沙箱（不推荐）

# 上下文控制
codex --context ./README.md # 指定额外上下文文件
codex --cwd ./src # 指定工作目录

AGENTS.md 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Project Rules

## Tech Stack
- Node.js 18+, TypeScript 5.x
- Express.js for REST APIs
- Prisma ORM with PostgreSQL

## Coding Standards
- Use async/await, avoid callbacks
- All functions must have TypeScript types
- Test files: *.test.ts

## Git Conventions
- Commit format: feat/fix/docs/refactor: description
- Never commit directly to main

OpenCode

完整 opencode.json 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


// opencode.json（项目级）
{
 // 默认模型
 "model": "anthropic/claude-sonnet-4-6",
 "small_model": "anthropic/claude-haiku-4-5",

 // 权限配置
 "permission": {
 "read": "allow",
 "edit": "allow",
 "glob": "allow",
 "grep": "allow",
 "list": "allow",
 "webfetch": "ask",
 "bash": {
 "*": "ask",
 "git *": "allow",
 "npm run *": "allow",
 "yarn *": "allow",
 "cat *": "allow",
 "ls *": "allow",
 "find *": "allow",
 "rm -rf *": "deny",
 "curl *": "deny",
 "wget *": "deny"
 }
 },

 // 额外指令文件（支持 glob 和 URL）
 "instructions": [
 "./AGENTS.md",
 "./docs/coding-standards.md",
 "packages/*/AGENTS.md"
 ],

 // 自定义 Agent
 "agent": {
 "reviewer": {
 "model": "anthropic/claude-opus-4-6",
 "prompt": "You are a strict code reviewer focused on security and performance.",
 "permission": {
 "read": "allow",
 "edit": "deny",
 "bash": "deny"
 }
 }
 },

 // MCP 服务器
 "mcp": {
 "filesystem": {
 "type": "local",
 "command": ["mcp-server-filesystem", "./"]
 }
 },

 // 自动更新
 "autoupdate": true,

 // 文件快照（用于变更追踪）
 "snapshot": true
}

Agent 权限继承示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


{
 // 全局权限：bash 默认询问
 "permission": {
 "bash": { "*": "ask" }
 },

 "agent": {
 // build agent：继承全局 + 扩展允许
 "build": {
 "permission": {
 "bash": {
 "*": "ask", // 继承全局
 "npm *": "allow", // agent 扩展
 "make *": "allow"
 }
 }
 },
 // plan agent：只读，覆盖全局
 "plan": {
 "permission": {
 "read": "allow",
 "edit": "deny",
 "bash": "deny"
 }
 }
 }
}

横向对比总表

指令文件对比

特性	Claude Code	Codex CLI	OpenCode
文件名	`CLAUDE.md`	`AGENTS.md`	`AGENTS.md`（优先） `CLAUDE.md`（兼容回退）
用户全局路径	`~/.claude/CLAUDE.md`	`~/.codex/AGENTS.md`	`~/.config/opencode/AGENTS.md`
项目路径	遍历中找到的所有层级	git 仓库根目录 `AGENTS.md`	`./AGENTS.md`
向上目录遍历	✅ 全部加载（越过 git root 继续向上，实测验证）	❌ 三个固定路径	✅ 每层取一个（停在 git root）
子目录懒加载	✅ 按需触发	❌	❌
多文件全量合并	✅	✅（三个固定文件合并）	⚠️ 需借助 instructions 字段
Import 语法	✅ `@path`	❌	❌（用 instructions 代替）
系统级策略文件	✅	❌	⚠️ 远程 `.well-known/opencode`
兼容对方格式	❌	❌	✅ 兼容 CLAUDE.md

权限设置对比

特性	Claude Code	Codex CLI	OpenCode
权限配置文件	`settings.json`	无	`opencode.json`
层级数量	4层（managed/user/project/local）	无	2层 + 远程（remote/global/project）
目录向上遍历	❌ 固定路径	❌	✅ 向上遍历查找
企业管控层	✅ managed 不可覆盖	❌	⚠️ 远程配置（需 HTTPS）
细粒度 allow/deny/ask	✅	❌	✅
匹配规则逻辑	首个匹配生效（deny→ask→allow）	无	最后匹配生效
数组跨层合并	✅ permissions 数组跨层合并	❌	✅ 深度合并
Agent 级别权限	❌	❌	✅ 可覆盖全局
沙箱机制	规则白名单	macOS Seatbelt / Docker	规则白名单
.env 文件保护	⚠️ 需手动 deny	❌	✅ 默认 deny

规则匹配逻辑对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Claude Code（首个匹配）：
 规则顺序：deny → ask → allow
 第一个匹配的规则立即生效，后续规则被忽略
 适合：明确的白名单/黑名单，规则顺序无歧义

 示例：
 deny: ["Bash(rm *)"]
 allow: ["Bash(rm -rf /tmp/*)"] ← 永远不会生效（已被 deny 首先匹配）

OpenCode（最后匹配）：
 同一工具下，越靠后的规则优先级越高
 适合：从宽泛默认逐步精细化覆盖

 示例：
 "bash": {
 "*": "ask", // 默认询问
 "rm *": "deny", // 拒绝 rm
 "rm /tmp/*": "allow" // 最后匹配：/tmp 下 rm 允许 ✅
 }

选型建议

按场景推荐

场景	推荐工具	理由
企业团队，需严格权限管控	Claude Code	managed 层不可覆盖，4层细粒度管控
个人开发，快速上手	Codex CLI	无配置负担，沙箱保底安全
开源项目，多模型切换	OpenCode	多 Provider 支持，配置灵活，TUI 体验好
已有 CLAUDE.md 迁移	OpenCode	内置 CLAUDE.md 兼容回退
需要 Agent 分角色权限	OpenCode	原生支持多 Agent 差异化权限

成熟度评估

1
2
3
4
5
6
7
8
9


权限体系成熟度：
 Claude Code ████████████ 最完整，企业级
 OpenCode ████████░░░░ 快速迭代，功能完善
 Codex CLI ████░░░░░░░░ 简单，靠 OS 沙箱兜底

指令文件机制：
 Claude Code ████████████ 最完整，懒加载 + Import
 Codex CLI ████████░░░░ 简单直接，全量合并
 OpenCode ███████░░░░░ 灵活，兼容性好，合并需显式配置

总结

如果你所在的是团队协作环境，并且很在意规则继承、权限边界和企业级治理，Claude Code 的整体体系更成熟。

如果你想以最低学习成本进入 AI 编程 CLI，Codex CLI 更像“先跑起来再说”的选择，简单但边界也更粗。

如果你既在意多模型能力，又愿意自己维护规则和权限，OpenCode 的灵活性会更有吸引力。

总览文适合用来完成第一轮选型，真正准备落地时，建议再回到指令文件和权限两篇专题文，把细节啃透。

参考资料：

AI 编程 CLI 的指令文件怎么生效：CLAUDE.md、AGENTS.md 与 OpenCode 对比

Fri, 20 Mar 2026 00:00:00 +0000

AI 编程 CLI 的指令文件怎么生效：CLAUDE.md、AGENTS.md 与 OpenCode 对比

很多人第一次接触 AI 编程 CLI 时，最容易混淆的不是模型，而是“项目规则到底写在哪个文件里”“子目录会不会继承”“多层文件同时存在时怎么合并”。

这篇文章只讲指令文件机制，不展开权限控制。如果你想先看整体选型，再判断自己该深入哪一块，建议先从总览文开始。

总览文入口：AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比

写在前面

可以把指令文件理解成给 AI 准备的一份“项目作战手册”：

文件名和存放位置，决定工具能不能找到它。
目录继承规则，决定子目录是否自动拿到上层约定。
多文件合并策略，决定不同层级的规则会不会互相覆盖。

如果这些机制没搞清楚，多仓库项目里最常见的问题就是“规则明明写了，AI 却像没看见一样”。而这恰好是三款工具差异最明显的地方之一。

如果你后面还准备配置权限边界，可以接着看这篇：

AI 编程 CLI 的权限怎么配：Claude Code、Codex CLI 与 OpenCode 对比

工具概览

维度	Claude Code	Codex CLI	OpenCode
开发方	Anthropic	OpenAI	SST（开源）
指令文件名	`CLAUDE.md`	`AGENTS.md`	`AGENTS.md`（优先）/ `CLAUDE.md`（兼容）
开源	❌ 闭源	✅ 开源	✅ 开源
多模型支持	❌ 仅 Claude	❌ 仅 OpenAI	✅ 支持多家提供商

文件名与位置

指令文件用于向 AI 提供项目上下文、编码规范、工作流约定等自然语言说明，相当于 AI 的"项目说明书"。

Claude Code — `CLAUDE.md`

层级	路径	说明
系统托管	`/etc/claude-code/CLAUDE.md`（Linux） `/Library/Application Support/ClaudeCode/CLAUDE.md`（macOS）	IT 管理员下发，最高优先级
用户全局	`~/.claude/CLAUDE.md`	对当前用户所有项目生效，独立加载，非目录遍历结果
目录遍历	从当前工作目录向上逐级查找	沿途所有层级全部加载，越过 git root 继续向上（实测验证）
子目录	`./src/CLAUDE.md` 等	懒加载，Claude 读取该目录文件时才加载

可通过 /context 命令查看当前会话实际加载的文件列表。

Codex CLI — `AGENTS.md`

层级	路径	说明
用户全局	`~/.codex/AGENTS.md`	对所有项目生效
仓库根目录	`<git repo root>/AGENTS.md`	提交到 git，团队共享
当前工作目录	`<cwd>/AGENTS.md`	与仓库根不同时单独加载

注意：Codex CLI 不做目录向上遍历，只从以上三个固定路径加载，按顺序合并。可用 --no-project-doc 或 CODEX_DISABLE_PROJECT_DOC=1 禁用项目文件加载。

OpenCode — `AGENTS.md`（优先）/ `CLAUDE.md`（兼容回退）

层级	路径	说明
用户全局	`~/.config/opencode/AGENTS.md`	对所有项目生效，不提交 git
目录遍历	从当前目录向上遍历至 git root	每层取一个文件（AGENTS.md 优先，无则找 CLAUDE.md）
Claude 兼容（回退）	`./CLAUDE.md`（无 AGENTS.md 时）	两者同时存在时忽略 CLAUDE.md
扩展引用	`opencode.json` 的 `instructions` 字段	支持 glob 模式和远程 URL

兼容说明：若同时存在 AGENTS.md 和 CLAUDE.md，只读取 AGENTS.md。

目录继承行为

场景结构

1
2
3
4
5
6
7
8
9


~/projects/
├── CLAUDE.md / AGENTS.md ← 多仓库共享层
├── order-service/ ← git repo ①
│ ├── CLAUDE.md / AGENTS.md ← 项目级
│ └── src/
│ └── order/
│ └── CLAUDE.md ← 子模块级（当前工作目录）
└── notify-service/ ← git repo ②
 └── CLAUDE.md / AGENTS.md ← 项目级

Claude Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


当前工作目录：~/projects/order-service/src/order/

加载顺序（启动时全量加载）：
 1. ~/.claude/CLAUDE.md ← 用户全局（独立加载）
 2. ~/projects/CLAUDE.md ← 越过 git root 继续向上（实测验证）
 3. ~/projects/order-service/CLAUDE.md ← 项目根目录
 4. ~/projects/order-service/src/CLAUDE.md ← 沿途（如存在）
 5. ~/projects/order-service/src/order/CLAUDE.md ← 当前工作目录

子目录懒加载（按需）：
 当 Claude 读取 src/payment/ 中的文件时，
 才加载 src/payment/CLAUDE.md（如果存在）

关键特性：

遍历终止条件官方未明确，但实测越过 git root 继续向上
~/.claude/CLAUDE.md 是独立的用户全局配置，并非遍历结果
子目录采用懒加载策略，不影响启动性能

Codex CLI

1
2
3
4
5
6
7
8


当前工作目录：~/projects/order-service/src/order/

加载顺序（仅三个固定路径）：
 1. ~/.codex/AGENTS.md ← 用户全局
 2. ~/projects/order-service/AGENTS.md ← git 仓库根目录
 3. ~/projects/order-service/src/order/AGENTS.md ← 当前工作目录（与仓库根不同时）

不会加载 ~/projects/AGENTS.md（不在固定路径内，直接忽略）。

关键特性：

无目录遍历，固定三个路径
中间层级的文件（如 src/AGENTS.md）不会被加载
~/projects/ 层的共享文件无法被自动加载

OpenCode

1
2
3
4
5
6
7
8
9


当前工作目录：~/projects/order-service/src/order/

加载顺序：
 1. ~/.config/opencode/AGENTS.md ← 用户全局
 2. ~/projects/order-service/src/order/AGENTS.md ← 当前目录
 3. ~/projects/order-service/src/AGENTS.md ← 若存在
 4. ~/projects/order-service/AGENTS.md ← git root，停止

不会加载 ~/projects/AGENTS.md（遍历止于 git root）。

关键特性：

停在 git root（源码验证：const root = git ?? input.cwd）
无 git 仓库时不向上遍历，以 cwd 为根
~/projects/ 层无法自动加载，需借助 instructions 字段显式引入

多文件合并策略

工具	合并方式	优先级规则
Claude Code	✅ 全部合并，所有层级的文件都加入上下文	越靠近当前目录优先级越高；冲突指令 Claude 可能随机选择一个
Codex CLI	✅ 全部合并，三个固定文件拼接	越靠近当前目录的文件内容排列在后，隐式优先
OpenCode	⚠️ 每层级取一个文件；可通过 `instructions` 字段显式引入多文件	越靠近当前目录优先级越高

Claude Code — Import 语法

在 CLAUDE.md 中可用 @ 引用其他文件，启动时一并加载：

1
2
3
4


@./docs/coding-standards.md
@./docs/api-guidelines.md
@~/.claude/personal-preferences.md
@/absolute/path/to/shared-rules.md

OpenCode — instructions 字段

通过 opencode.json 显式引入多个文件，支持 glob 和远程 URL：

1
2
3
4
5
6
7
8


{
 "instructions": [
 "./AGENTS.md",
 "./docs/coding-standards.md",
 "packages/*/AGENTS.md",
 "https://example.com/shared-rules.md"
 ]
}

多仓库场景实践

多服务项目中，每个服务是独立的 git repo，服务间通过 HTTP 调用。核心问题是：AI 每次只在一个 repo 里工作，如何获取其他服务的接口信息？

Claude Code 方案（推荐）

利用目录遍历越过 git root 的特性，在 ~/projects/ 下放共享文件：

文件职责划分：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


~/.claude/CLAUDE.md
 → 个人偏好（沟通语言、代码风格）

~/projects/CLAUDE.md
 → 多仓库共享约定（技术栈、服务目录、跨服务调用约定）

~/projects/order-service/CLAUDE.md
 → 本服务职责、对外接口、依赖的上游接口契约

~/projects/order-service/src/*/CLAUDE.md
 → 子模块特殊说明（可选）

~/projects/CLAUDE.md 示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 多服务共享规范

## 技术栈
- Java 8 + Spring Boot 2.x
- 服务间通信：HTTP REST，统一使用 Feign Client
- 统一响应结构：{ code: int, message: String, data: T }

## 服务目录
| 服务 | 职责 | 内网地址 |
|------|------|----------|
| user-service | 用户账户、余额管理 | http://user-service:8001 |
| order-service | 订单生命周期管理 | http://order-service:8002 |
| notify-service | 短信/Push 通知 | http://notify-service:8003 |

## 跨服务开发约定
- 修改任何对外接口前，先确认所有下游调用方
- Feign Client 定义在各服务的 api 模块，不在 core 模块直接调用
- 接口字段变更（新增除外）需同步更新所有调用方

~/projects/order-service/CLAUDE.md 示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# order-service

## 本服务职责
管理订单全生命周期：创建 → 支付确认 → 发货 → 完成 / 取消

## 模块结构
- order-api 对外 Feign Client 接口定义（供其他服务引用）
- order-core 业务逻辑层
- order-server 启动入口 + Controller

## 本服务对外接口
- POST /api/orders 创建订单
- PUT /api/orders/{id}/pay 支付回调
- GET /api/orders/{id} 查询订单详情

## 依赖的上游接口（修改时需同步）

### user-service
- GET /api/users/{id}/balance
 响应：{ code: 0, data: { balance: BigDecimal } }
- POST /api/users/{id}/balance/freeze
 请求：{ amount: BigDecimal, orderId: String }
 响应：{ code: 0, data: { freezeId: String } }

### notify-service
- POST /api/notify/send
 请求：{ userId: String, type: "ORDER_CREATED"|"ORDER_PAID", bizId: String }
 响应：{ code: 0, data: { msgId: String } }

Codex CLI 方案

无法加载 ~/projects/ 层，跨项目共享内容只能放进用户全局文件：

文件职责划分：

1
2
3
4
5
6


~/.codex/AGENTS.md
 → 必须承担所有跨项目内容（技术栈、服务目录、跨服务约定）
 → 内容较多时注意 token 消耗，保持精简

~/projects/order-service/AGENTS.md
 → 本服务职责、对外接口、依赖的上游接口契约

~/.codex/AGENTS.md 示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 全局规范

## 技术栈
- Java 8 + Spring Boot 2.x，Feign Client 跨服务调用
- 统一响应结构：{ code, message, data }

## 服务目录
- user-service:8001 用户账户余额管理
- order-service:8002 订单生命周期
- notify-service:8003 消息通知

## 约定
- Feign Client 定义在 api 模块
- 接口变更必须同步更新调用方

OpenCode 方案

遍历止于 git root，通过 _shared/ 目录 + instructions 字段共享内容：

推荐目录结构：

1
2
3
4
5
6
7
8
9


~/projects/
├── _shared/ ← 共享契约目录（非 git repo）
│ ├── conventions.md ← 技术栈、服务目录、跨服务约定
│ └── api-contracts/
│ ├── user-service.md
│ └── notify-service.md
└── order-service/
 ├── AGENTS.md ← 本服务职责与对外接口
 └── opencode.json ← 通过 instructions 引入共享内容

opencode.json 示例：

1
2
3
4
5
6
7
8


{
 "instructions": [
 "./AGENTS.md",
 "~/_shared/conventions.md",
 "~/_shared/api-contracts/user-service.md",
 "~/_shared/api-contracts/notify-service.md"
 ]
}

三方案对比

维度	Claude Code	Codex CLI	OpenCode
共享层位置	`~/projects/CLAUDE.md`（自动加载）	`~/.codex/AGENTS.md`（手动维护）	`_shared/` + `instructions`（显式引入）
跨项目一致性	✅ 单一来源，自动同步	⚠️ 靠人工保证	✅ 单一来源，显式引入
配置成本	最低（放文件即生效）	最高（全塞全局文件）	中等（需配置 instructions）

横向对比总表

特性	Claude Code	Codex CLI	OpenCode
文件名	`CLAUDE.md`	`AGENTS.md`	`AGENTS.md`（优先） `CLAUDE.md`（兼容回退）
用户全局路径	`~/.claude/CLAUDE.md`	`~/.codex/AGENTS.md`	`~/.config/opencode/AGENTS.md`
向上目录遍历	✅ 越过 git root 继续（实测）	❌ 三个固定路径	✅ 停在 git root
多仓库共享层	✅ `~/projects/CLAUDE.md` 自动加载	❌ 不支持	⚠️ 需 `instructions` 显式引入
子目录懒加载	✅ 按需触发	❌	❌
多文件全量合并	✅ 全部合并	✅ 三个文件合并	⚠️ 每层取一个
Import / 引用语法	✅ `@path`	❌	✅ `instructions` 字段
系统级策略文件	✅	❌	⚠️ 远程 `.well-known/opencode`
兼容对方格式	❌	❌	✅ 兼容 CLAUDE.md
禁用项目文件	`claudeMdExcludes`	`--no-project-doc`	无

总结

如果你最看重“目录向上继承 + 多仓库共享层”，Claude Code 的行为最完整，也最接近“放对位置就能生效”的体验。

如果你更接受固定路径、简单规则，Codex CLI 会更容易理解，但跨项目共享内容需要自己精简维护。

如果你想兼顾兼容性和灵活性，OpenCode 的 instructions 能补足很多场景，只是配置成本会比前两者更高一些。

文中的加载行为和合并策略基于 2026-03-18 左右公开资料与实测整理，真正落地前还是建议对照一下最新官方文档。

参考资料：

视频资源术语完全指南：从入门到精通

Sat, 13 Dec 2025 00:00:00 +0000

写在前面

如果你在下载电影、配置 MoviePilot 订阅时，面对这样的资源名称感到困惑：

1

The Movie 2024 2160p UHD BluRay REMUX HEVC DTS-HD MA 7.1 Atmos TrueHD 7.1 DOVI HDR -FGT

不知道这些英文缩写是什么意思，哪个版本质量更好，应该选择哪个，那么这篇文章就是为你准备的。

我将用通俗易懂的语言，系统地讲解视频资源中的所有常见术语，帮助你：

理解资源命名规则，看懂种子标题
根据自己的需求选择合适的版本
配置 MoviePilot 过滤规则，自动下载最优资源
在画质、体积、兼容性之间找到最佳平衡

核心概念框架

视频资源的命名包含多个维度的信息，理解这个框架是掌握所有术语的基础：

1
2
3
4
5
6
7


视频资源 = 基本信息 + 视频属性 + 音频属性 + 特殊属性 + 制作组

基本信息：标题、年份
视频属性：来源、处理方式、编码、分辨率、色彩技术
音频属性：编码格式、声道配置、音频技术
特殊属性：字幕、3D、帧率等
制作组：发布者标识

典型示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


资源名称：
The Shawshank Redemption 1994 2160p BluRay REMUX HEVC TrueHD 7.1 Atmos DV HDR10 -FGT

逐一解析：
├─ 标题：The Shawshank Redemption (肖申克的救赎)
├─ 年份：1994
├─ 分辨率：2160p (4K)
├─ 来源：BluRay (蓝光)
├─ 处理：REMUX (无损重封装)
├─ 编码：HEVC (H.265)
├─ 音频编码：TrueHD 7.1 (杜比无损 7.1 声道)
├─ 音频技术：Atmos (杜比全景声)
├─ 色彩技术：DV HDR10 (杜比视界 + HDR10 降级兼容)
└─ 制作组：FGT

接下来，我将按照这个框架，逐一详细讲解每个维度。

视频属性

视频来源（Source）

视频来源决定了资源的原始质量上限。无论后续如何处理，都不可能超越原始来源的质量。

BluRay / Blu-ray（蓝光）

定义：从蓝光光盘提取的视频

特点：

画质最好，是家庭影院的黄金标准
码率高（1080p 通常 20-40 Mbps，4K 通常 50-100 Mbps）
包含完整的音轨、字幕
发布较慢（通常在院线下映后 3-6 个月）

关键词：BluRay、Blu-ray、BD、BDRip

通俗理解：就像买了一张蓝光光盘，从光盘里提取出来的视频。

WEB-DL（流媒体下载）

定义：从流媒体平台（Netflix、Disney+、Amazon Prime 等）直接下载的视频

特点：

画质接近蓝光（4K WEB-DL 尤其优秀）
更新极快（通常与平台同步上线）
码率略低于蓝光（1080p 通常 10-15 Mbps，4K 通常 30-50 Mbps）
现代主流选择

关键词：WEB-DL、WEBRip、WEB

平台标识：

NF/Netflix：Netflix 源
AMZN/Amazon：Amazon Prime 源
DSNP/Disney+：Disney+ 源
ATVP/AppleTV+：Apple TV+ 源
HMAX：HBO Max 源

通俗理解：从视频网站上下载的正版高清视频，不是录屏，而是直接获取源文件。

HDTV（电视录制）

定义：从电视台高清信号录制

特点：

画质一般
可能包含台标、广告
主要用于电视剧、综艺节目
电影很少用此来源

关键词：HDTV、PDTV

通俗理解：用录像机录下电视台播出的节目。

质量对比

1
2
3
4
5


BluRay 4K ████████████ 100% (50-100 Mbps)
WEB-DL 4K ███████████ 90% (30-50 Mbps)
BluRay 1080p ██████████ 85% (20-40 Mbps)
WEB-DL 1080p █████████ 75% (10-15 Mbps)
HDTV 1080p ██████ 50% (5-10 Mbps)

处理方式（Process）

视频来源获取后，可以进行不同方式的处理，这决定了最终的体积和质量。

原盘（BDMV / ISO）

定义：蓝光光盘的完整拷贝，未经任何处理

特点：

保留光盘的所有内容（菜单、字幕、音轨、花絮、预告片等）
体积巨大
播放需要特殊软件（PowerDVD、VLC 等）
完全无损

关键词：BDMV、ISO、BD25、BD50、BD66、BD100、COMPLETE、FULL

体积参考：

BD25：单层蓝光，约 25GB
BD50：双层蓝光，约 50GB
BD66：4K 蓝光，约 66GB
BD100：4K 双层蓝光，约 100GB

通俗理解：把整张光盘原封不动地拷贝到硬盘，包括光盘上的所有东西。

典型命名：

1

The Movie 2024 2160p UHD BluRay COMPLETE HEVC TrueHD 7.1 Atmos-TAG

Remux（重新封装）

定义：从原盘中提取视频和音频流，不重新编码，仅重新打包成单个文件

特点：

视频和音频质量与原盘完全相同（100% 无损）
去除了菜单、花絮等额外内容
体积比原盘小 20-40%
保留所有音轨和字幕
现代影音爱好者的主流选择

关键词：REMUX、Remux

体积参考：

1080p Remux：15-40GB
4K Remux：40-80GB

通俗理解：从光盘里把电影主体抽出来，去掉菜单、花絮等"废料"，但电影本身一点都没动，质量和光盘完全一样。

典型命名：

1

The Movie 2024 2160p BluRay REMUX HEVC DTS-HD MA 7.1-FGT

关键对比：

1
2
3
4
5
6
7


原盘 (BD50) = 50GB
├─ 电影主体：30GB
├─ 菜单：2GB
├─ 花絮：10GB
└─ 其他：8GB

Remux = 30GB（仅电影主体，质量完全相同）

Encode / Rip（压制 / 重编码）

定义：使用视频编码器重新编码，压缩体积

特点：

画质有损失（但优秀的压制组损失很小）
体积大幅减小
制作需要时间和技术
不同压制组质量差异大

关键词：x264、x265、BDRip、BluRayRip

体积参考：

1080p 压制：2-15GB
4K 压制：10-30GB

通俗理解：用压缩软件把电影压缩，就像把照片从 10MB 压到 1MB，画质会有损失，但技术好的话肉眼看不出来。

质量梯度：

1
2
3
4
5
6
7


Remux (30GB) 质量：100%
 ↓ 压制（优秀组，高码率）
High Quality (12GB) 质量：95-98% (肉眼难以区分)
 ↓ 压制（普通组，中码率）
Medium Quality (8GB) 质量：85-90% (部分场景有差异)
 ↓ 压制（低码率）
Low Quality (3GB) 质量：70-80% (明显差异)

典型命名：

1

The Movie 2024 1080p BluRay x265 10bit AAC 5.1-CMCT

视频编码（Codec）

视频编码决定了压缩算法，影响体积和兼容性。

H.264 / AVC / x264

三个名词，同一种编码：

H.264：ITU-T 标准的官方名称
AVC：Advanced Video Coding，MPEG-4 Part 10 的名称
x264：开源编码器软件的名称

特点：

最成熟的编码标准（2003 年发布）
兼容性极好，所有设备都支持
体积较大
解码容易，性能要求低

关键词：H264、H.264、x264、AVC

适用场景：

老旧设备播放
追求最佳兼容性
不在乎体积

通俗理解：就像 MP3 之于音乐，H.264 是最普及的视频压缩标准。

H.265 / HEVC / x265

三个名词，同一种编码：

H.265：ITU-T 标准的官方名称
HEVC：High Efficiency Video Coding 的缩写
x265：开源编码器软件的名称

特点：

更先进的编码标准（2013 年发布）
相同画质下体积约为 H.264 的 50%
解码需要更强的硬件（2016 年后的设备基本都支持）
4K 视频的标配
现代主流选择

关键词：H265、H.265、x265、HEVC

适用场景：

4K 视频（必选）
节省硬盘空间
较新设备（2016 年后）

通俗理解：新一代压缩技术，同样质量只需要一半空间，但需要更好的播放器。

对比示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


同一部电影 1080p BluRay

H.264 压制：
体积：10GB
画质：⭐⭐⭐⭐
兼容性：⭐⭐⭐⭐⭐
解码性能要求：⭐⭐

H.265 压制：
体积：5GB（减少 50%）
画质：⭐⭐⭐⭐（相同）
兼容性：⭐⭐⭐⭐
解码性能要求：⭐⭐⭐⭐

AV1

定义：下一代开源视频编码标准

特点：

比 H.265 更高效（体积再减少 30%）
完全免费，无专利费
支持度较低（2020 年后的高端设备）
编码极慢
未来的方向，目前还不成熟

关键词：AV1

建议：目前不推荐，兼容性问题较多

分辨率（Resolution）

分辨率决定了画面的清晰度。

常见分辨率对比

名称	分辨率	像素总数	关键词	常见场景
4K / UHD	3840×2160	830 万	`4K`、`2160p`、`UHD`、`x2160`	现代主流
1080p / FHD	1920×1080	207 万	`1080p`、`1080i`、`FHD`、`x1080`	传统高清
720p / HD	1280×720	92 万	`720p`、`HD`、`x720`	入门高清
480p / SD	720×480	35 万	`480p`、`SD`	标清

清晰度对比：

1
2
3


4K ████████████ (830 万像素)
1080p ███ (207 万像素)
720p █ (92 万像素)

选择建议：

大屏幕（65 寸以上）或投影仪 → 选择 4K
中等屏幕（40-65 寸）→ 1080p 足够
小屏幕（40 寸以下）→ 1080p 或 720p

色彩技术（Color Technology）

色彩技术决定了画面的色彩范围和对比度。

SDR（Standard Dynamic Range）

定义：标准动态范围，传统的色彩标准

特点：

所有设备都支持
亮度范围：100 nits
色域：Rec.709

关键词：SDR（通常不标注）

HDR（High Dynamic Range）

定义：高动态范围，更广的亮度和色彩范围

特点：

亮度范围：1000-4000 nits（是 SDR 的 10-40 倍）
色域：Rec.2020
画面更接近人眼所见
需要支持 HDR 的设备（电视、显示器）

常见标准：

HDR10

最基础的 HDR 标准
免费开放
静态元数据（整部电影使用相同的 HDR 参数）
支持度最广

关键词：HDR、HDR10

HDR10+

HDR10 的增强版
动态元数据（每个场景都有独立的 HDR 参数）
三星主导
支持度一般

关键词：HDR10+、HDR10Plus

Dolby Vision（杜比视界）

最高级的 HDR 标准
动态元数据 + 12bit 色深
亮度可达 10000 nits
需要专利授权，设备较贵
画质最佳

关键词：DV、DOVI、Dolby Vision、杜比视界

对比：

1
2
3
4


SDR ████ 亮度 100 nits
HDR10 ████████ 亮度 1000 nits，静态元数据
HDR10+ █████████ 亮度 1000+ nits，动态元数据
Dolby Vision ████████████ 亮度 4000-10000 nits，动态元数据 + 12bit

兼容性说明：

如果设备不支持 Dolby Vision，播放 DV 资源可能会出现：
- 色彩过暗或过亮
- 色彩偏色
- 无法播放
建议：不确定设备是否支持时，选择 HDR10 版本

典型命名：

1
2
3


The Movie 2024 2160p BluRay REMUX HEVC DV HDR10-FGT
 ↑ ↑
 Dolby Vision HDR10（降级兼容）

音频属性

音频质量对观影体验的影响不亚于画质，尤其是动作片、科幻片。

音频编码（Audio Codec）

无损音频编码

TrueHD（Dolby TrueHD）

定义：杜比开发的无损音频编码

特点：

完全无损，与原始录音室母带相同
支持最多 7.1 声道
码率：通常 3-6 Mbps
蓝光标配音频格式
可以携带 Dolby Atmos 元数据

关键词：TrueHD、Dolby TrueHD

通俗理解：就像音乐中的 FLAC 无损格式，音质完美还原。

DTS-HD MA（DTS-HD Master Audio）

定义：DTS 公司开发的无损音频编码

特点：

完全无损
支持最多 7.1 声道
码率：通常 3-6 Mbps
蓝光标配音频格式
可以携带 DTS:X 元数据

关键词：DTS-HD MA、DTS-HD、DTSHD

TrueHD vs DTS-HD MA：

都是无损，质量相同
TrueHD 是杜比的，DTS-HD MA 是 DTS 的
选哪个都可以，看个人偏好

有损音频编码

DDP / DD+（Dolby Digital Plus）

定义：杜比数字增强版

特点：

有损压缩
支持最多 7.1 声道
码率：通常 224-768 kbps
WEB-DL 常用音频格式
可以携带 Dolby Atmos 元数据
质量接近无损

关键词：DDP、DD+、EAC3、E-AC3

通俗理解：压缩版的杜比音频，但质量仍然很好，就像 MP3 320kbps。

AC3（Dolby Digital）

定义：杜比数字，传统的有损编码

特点：

有损压缩
支持最多 5.1 声道
码率：通常 448-640 kbps
DVD 标配音频格式
质量一般

关键词：AC3、DD、Dolby Digital

DTS

定义：DTS 的有损编码

特点：

有损压缩
支持最多 7.1 声道
码率：通常 768-1536 kbps
质量好于 AC3

关键词：DTS、DTS Core

AAC

定义：先进音频编码

特点：

有损压缩
支持最多 7.1 声道
码率：通常 128-512 kbps
压制版常用音频格式
效率高，小体积高质量

关键词：AAC

音频编码质量对比：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


无损级别：
TrueHD ████████████ (3-6 Mbps)
DTS-HD MA ████████████ (3-6 Mbps)

高质量有损：
DDP ██████████ (384-768 kbps)
DTS █████████ (768-1536 kbps)

中等质量：
AC3 ███████ (448-640 kbps)
AAC ███████ (256-512 kbps)

声道配置（Channel Layout）

声道数决定了音频的空间感和环绕效果。

常见配置

配置	说明	扬声器布局	适用场景
2.0	立体声	左 + 右	普通音箱、耳机
5.1	5.1 环绕声	左 + 中 + 右 + 左环 + 右环 + 低音炮	入门家庭影院
7.1	7.1 环绕声	左 + 中 + 右 + 左环 + 右环 + 左后环 + 右后环 + 低音炮	高级家庭影院

扬声器布局示意：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


5.1 布局：
 左环 ← → 右环
 ↘ ↙
 左 → [观众] ← 右
 ↓ ↓ ↓
 中 低音炮

7.1 布局：
 左环 ← → 右环
 ↘ ↙
 左 → [观众] ← 右
 ↓ ↓ ↓
 中 低音炮
 ↙ ↘
 左后环 右后环

关键词：

2.0、Stereo
5.1
7.1

沉浸式音频技术

Dolby Atmos（杜比全景声）

定义：基于对象的音频技术，突破传统声道限制

革命性创新：

传统环绕声：基于声道（5.1、7.1），声音固定在特定扬声器
Dolby Atmos：基于对象，声音可以精确定位在三维空间的任意位置

特点：

支持天空声道（顶置扬声器或反射式扬声器）
最多支持 128 个音频对象
沉浸感极强
需要支持 Atmos 的设备（功放、音响）

关键词：Atmos、Dolby Atmos、杜比全景声

通俗理解：

1
2
3
4
5


传统 5.1 环绕声：
飞机从左边飞到右边 → 声音在左环绕和右环绕之间切换（离散）

Dolby Atmos：
飞机从左边飞到右边 → 声音平滑地在空间中移动，还能感受到高度变化（连续）

典型场景体验：

直升机在头顶飞过 → 真的能听到从正上方传来的声音
雨点落下 → 感觉雨从天上落到地面
子弹从耳边飞过 → 精确定位子弹的轨迹

载体：

TrueHD Atmos：无损 + Atmos
DDP Atmos：有损 + Atmos（WEB-DL 常见）

典型命名：

1
2
3


The Movie 2024 2160p BluRay REMUX HEVC TrueHD 7.1 Atmos-FGT
 ↑ ↑
 7.1 声道 Atmos 元数据

DTS:X

定义：DTS 公司的沉浸式音频技术，Dolby Atmos 的竞争对手

特点：

同样基于对象的音频
技术原理类似 Atmos
支持天空声道
市场占有率低于 Atmos

关键词：DTS:X、DTSX

Atmos vs DTS:X：

技术原理相似，效果接近
Atmos 支持度更广，资源更多
DTS:X 资源较少

音频选择建议

根据设备选择

入门级（电视内置音箱、普通音箱）：

1
2


优先级：AAC 2.0 > AC3 5.1
理由：设备不支持多声道，选择立体声即可

中级（5.1 家庭影院）：

1
2


优先级：DDP 5.1 > AC3 5.1 > DTS 5.1
理由：DDP 质量更好，体积适中

高级（7.1 家庭影院，支持 Atmos）：

1
2


优先级：TrueHD Atmos > DTS-HD MA > TrueHD 7.1
理由：充分发挥设备性能，享受极致音效

极客级（顶级家庭影院）：

1
2


只选择：TrueHD Atmos 或 DTS-HD MA DTS:X
理由：追求极致

根据片源类型选择

动作片、科幻片、战争片：

强烈建议 Atmos 或 DTS:X
示例：《敦刻尔克》、《1917》、《沙丘》

文艺片、剧情片：

普通 5.1 或 7.1 即可
示例：《肖申克的救赎》、《阿甘正传》

音乐会、演唱会：

建议无损音频（TrueHD、DTS-HD MA）
示例：《波西米亚狂想曲》演唱会

特殊属性

3D

定义：立体 3D 视频

特点：

需要 3D 电视 + 3D 眼镜
体积翻倍（左右眼各一个画面）
大部分人不需要

关键词：3D、Half-SBS（左右半宽）、Half-OU（上下半高）

建议：除非有 3D 设备，否则在前置过滤中排除

1
2
3
4


{
 "name": "前置过滤",
 "rule_string": "!3D & filterGlobal"
}

帧率（Frame Rate）

定义：每秒显示的画面数量

常见帧率：

23.976 fps / 24 fps：电影标准帧率
25 fps：PAL 制式（欧洲）
29.97 fps / 30 fps：NTSC 制式（美国、日本）
50 fps / 60 fps：高帧率

关键词：60fps、60帧、HFR（High Frame Rate）

选择建议：

电影 → 选择 24fps（原生帧率）
体育赛事、演唱会 → 可以考虑 60fps

色彩深度（Bit Depth）

定义：每个像素的色彩信息量

常见配置：

8bit：1677 万色，SDR 标准
10bit：10.7 亿色，HDR 标准

关键词：10bit、10-bit

通俗理解：就像画笔的颜色，8bit 有 1677 万种颜色，10bit 有 10 亿种颜色，色彩过渡更平滑。

制作组与发布标识

制作组类型

原盘组

专注于发布蓝光原盘，通常不做处理。

代表性组：

TAG
EPSiLON

Remux 组

专注于 Remux 发布。

代表性组：

FGT
FRAMESTOR
DON
CMRG

压制组

专注于高质量压制。

代表性组：

国际组：

CMCT：中文字幕组，质量稳定
FRDS：繁体字幕组
CHD：华语高清
WiKi：优质压制组
HDC

WEB 组：

HHWEB：憨憨 WEB 组，高质量
NTb：Next-Gen WEB 组
FLUX
SiGMA

字幕标识

中文字幕

简体中文：

CHS：简体中文
GB：国标（简体）
SC：Simplified Chinese

繁体中文：

CHT：繁体中文
BIG5：大五码（繁体）
TC：Traditional Chinese

双语：

CHS.ENG：简英双语
CHT.ENG：繁英双语
简英、繁英

多语：

简繁英、CHS.CHT.ENG

通用：

中字、中文字幕
内封、内嵌

特效字幕

关键词：特效、SPECSUB

说明：在关键剧情处添加特效字幕，增强观影体验

资源命名实例解析

实例 1：4K 蓝光 Remux

1

The Shawshank Redemption 1994 2160p UHD BluRay REMUX HEVC TrueHD 7.1 Atmos DV HDR10-FGT

逐一解析：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


The Shawshank Redemption → 标题（肖申克的救赎）
1994 → 年份
2160p UHD → 分辨率（4K）
BluRay → 视频来源（蓝光）
REMUX → 处理方式（无损重封装）
HEVC → 视频编码（H.265）
TrueHD 7.1 → 音频编码（杜比无损 7.1 声道）
Atmos → 音频技术（杜比全景声）
DV HDR10 → 色彩技术（杜比视界 + HDR10 降级兼容）
FGT → 制作组

总结：顶级质量的 4K 资源，无损画质 + 无损音频 + Atmos + 杜比视界

体积：约 60-80GB

适合人群：有顶级家庭影院设备，追求极致体验

实例 2：4K WEB-DL

1

The Matrix Resurrections 2021 2160p WEB-DL H265 DDP 5.1 Atmos-HHWEB

逐一解析：

1
2
3
4
5
6
7
8


The Matrix Resurrections → 标题（黑客帝国：矩阵重启）
2021 → 年份
2160p → 分辨率（4K）
WEB-DL → 视频来源（流媒体下载）
H265 → 视频编码（H.265）
DDP 5.1 → 音频编码（杜比数字增强版 5.1 声道）
Atmos → 音频技术（杜比全景声）
HHWEB → 制作组

总结：高质量 WEB-DL，更新快，体积适中，画质接近蓝光

体积：约 15-25GB

适合人群：追求画质 + 更新速度 + 节省空间的平衡

实例 3：1080p 蓝光压制

1

Inception 2010 1080p BluRay x265 10bit TrueHD 7.1-CMCT

逐一解析：

1
2
3
4
5
6
7
8


Inception → 标题（盗梦空间）
2010 → 年份
1080p → 分辨率
BluRay → 视频来源（蓝光）
x265 → 视频编码（H.265 压制）
10bit → 色彩深度（10bit）
TrueHD 7.1 → 音频编码（杜比无损 7.1 声道）
CMCT → 制作组

总结：优质压制版本，保留无损音频，体积和质量平衡好

体积：约 8-15GB

适合人群：1080p 设备，追求质量和体积平衡

实例 4：4K 蓝光原盘

1

Dune 2021 2160p UHD BluRay COMPLETE HEVC TrueHD 7.1 Atmos-TAG

逐一解析：

1
2
3
4
5
6
7
8


Dune → 标题（沙丘）
2021 → 年份
2160p UHD → 分辨率（4K）
BluRay → 视频来源（蓝光）
COMPLETE → 处理方式（完整原盘）
HEVC → 原盘编码（4K 原盘通常是 H.265）
TrueHD 7.1 Atmos → 音频编码（无损 + 全景声）
TAG → 制作组

总结：完整原盘，包含所有菜单、花絮，完全未处理

体积：约 80-100GB

适合人群：极客、收藏爱好者

MoviePilot 规则配置实战

基础配置思路

根据你的设备和需求，设计优先级梯度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


设备评估：
├─ 显示设备：是否支持 4K？是否支持 HDR/DV？
├─ 音频设备：是否支持 Atmos？最多几声道？
└─ 硬盘空间：是否充足？

↓

确定优先级：
├─ 分辨率：4K > 1080p
├─ 来源：BluRay > WEB-DL
├─ 编码：H265 > H264（节省空间）
├─ 音频：根据设备选择
└─ 体积：设置合理限制

示例配置 1：顶级家庭影院

设备：

4K 投影仪，支持 Dolby Vision
Atmos 全景声音响
硬盘空间充足

规则配置：

自定义规则：

1
2
3
4
5
6
7


{
 "id": "filterMovie",
 "name": "filterMovie",
 "include": "",
 "exclude": "",
 "size_range": "0-80000" // 允许到 80GB
}

优先级规则组（外语电影）：

1
2
3
4
5


4K & BLURAY & REMUX & H265 & filterMovie >
4K & BLURAY & H265 & filterMovie >
4K & WEBDL & H265 & filterMovie >
1080P & BLURAY & REMUX & filterMovie >
1080P & BLURAY & H265 & filterMovie

说明：优先 4K Remux，接受大体积，追求极致画质

示例配置 2：中端家庭影院

设备：

4K 电视，支持 HDR10
5.1 音响
硬盘空间有限

规则配置：

自定义规则：

1
2
3
4
5
6
7


{
 "id": "filterMovie",
 "name": "filterMovie",
 "include": "",
 "exclude": "",
 "size_range": "0-25000" // 限制 25GB
}

前置过滤：

1

filterGlobal & !REMUX & !DOLBY & !3D & filerGroup

优先级规则组（外语电影）：

1
2
3
4


4K & BLURAY & H265 & filterMovie >
4K & WEBDL & H265 & filterMovie >
1080P & BLURAY & H265 & filterMovie >
1080P & WEBDL & H265 & filterMovie

说明：

排除 Remux（体积太大）
排除 Dolby Vision（设备不支持）
优先 4K 压制版，节省空间

示例配置 3：普通用户

设备：

1080p 电视
电视内置音箱
硬盘空间紧张

规则配置：

自定义规则：

1
2
3
4
5
6
7


{
 "id": "filterMovie",
 "name": "filterMovie",
 "include": "",
 "exclude": "",
 "size_range": "0-10000" // 限制 10GB
}

前置过滤：

1

filterGlobal & !4K & !REMUX & !3D & !DOLBY & !ATMOS & filerGroup

优先级规则组（外语电影）：

1
2
3


1080P & BLURAY & H265 & filterMovie >
1080P & WEBDL & H265 & filterMovie >
1080P & H265 & filterMovie

说明：

排除 4K（设备不支持，浪费空间）
排除 Remux、Atmos 等高级特性
只选择 1080p H265 压制版

音频优先级配置

如果你想控制音频格式，可以添加音频相关的自定义规则：

自定义规则：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "id": "AtmosAudio",
 "name": "AtmosAudio",
 "include": "Atmos|ATMOS",
 "exclude": ""
},
{
 "id": "LosslessAudio",
 "name": "LosslessAudio",
 "include": "TrueHD|DTS-HD MA|DTSHD",
 "exclude": ""
}

优先级规则组（有 Atmos 设备）：

1
2
3


4K & BLURAY & H265 & AtmosAudio & filterMovie >
4K & BLURAY & H265 & LosslessAudio & filterMovie >
4K & BLURAY & H265 & filterMovie

常见问题

Remux 和原盘有什么区别？

原盘：

完整的蓝光光盘拷贝
包含菜单、花絮、预告片等
体积巨大

Remux：

只提取电影主体（视频 + 音频 + 字幕）
不重新编码，质量与原盘完全相同
体积比原盘小 20-40%

选择建议：除非你是收藏爱好者，否则选择 Remux 即可

WEB-DL 和 BluRay 哪个好？

画质对比：

4K WEB-DL ≈ 4K BluRay（差距很小）
1080p WEB-DL < 1080p BluRay（BluRay 更好）

优势对比：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


BluRay：
✅ 画质略好
✅ 音频通常是无损（TrueHD、DTS-HD MA）
❌ 更新慢（院线下映后 3-6 个月）
❌ 体积大

WEB-DL：
✅ 更新快（与平台同步）
✅ 体积适中
❌ 音频通常是有损（DDP）
❌ 画质略逊（尤其是 1080p）

选择建议：

追求极致画质 → BluRay
追求更新速度 + 体积平衡 → WEB-DL
4K 分辨率下两者差距不大，可以选择 WEB-DL

H265 设备兼容性如何判断？

支持 H265 的设备：

2016 年后的智能电视
2017 年后的电脑（CPU 需要 7 代酷睿或更新）
2018 年后的手机
Fire TV Stick 4K、Apple TV 4K、Nvidia Shield 等

判断方法：

查看设备规格，看是否支持 HEVC
下载一个 H265 样片测试
如果播放卡顿，说明硬件解码不支持

不支持怎么办：

选择 H264 版本
或升级播放设备

Dolby Vision 资源能在普通设备上播放吗？

分两种情况：

1. 双层 DV（DV HDR10）：

包含 DV 和 HDR10 两层
不支持 DV 的设备会降级到 HDR10
可以正常播放

典型命名：

1
2
3


The Movie 2024 2160p REMUX HEVC DV HDR10-FGT
 ↑ ↑
 Dolby Vision HDR10 降级兼容

2. 单层 DV（仅 DV）：

只有 DV 层
不支持 DV 的设备可能无法播放或画面异常

典型命名：

1
2
3


The Movie 2024 2160p REMUX HEVC DOVI-FGT
 ↑
 仅 Dolby Vision（无降级）

建议：

如果设备不支持 DV，选择 HDR10 版本
或选择 DV HDR10 双层版本

如何选择合适的体积？

参考标准：

电影：

1
2
3
4
5


4K Remux： 50-80GB → 极致画质
4K 压制高码： 20-30GB → 优秀画质
4K 压制中码： 10-20GB → 良好画质
1080p Remux： 20-40GB → 极致画质
1080p 压制： 5-15GB → 优秀画质

剧集（单季）：

1
2


4K 压制： 50-100GB
1080p 压制： 20-50GB

设置建议：

1
2
3
4


{
 "id": "filterMovie",
 "size_range": "0-25000" // 25GB，适合大部分用户
}

为什么有的资源体积特别小但标注 4K？

可能原因：

1. 低码率压制：

过度压缩，画质严重损失
名不副实的"假 4K"

2. 短片/动画：

片长很短
动画内容，压缩率高

3. 诈骗资源：

实际不是 4K，标题造假

判断方法：

1
2
3
4
5
6


正常 4K 电影体积：
Remux： 50-80GB
高码压制： 20-30GB
中码压制： 10-20GB

如果 4K 电影只有几个 GB → 大概率质量很差或造假

建议：在自定义规则中设置最小体积限制

1
2
3
4
5


{
 "id": "filter4K",
 "name": "filter4K",
 "size_range": "10000-80000" // 4K 电影至少 10GB
}

总结

掌握视频资源术语的关键是理解多维度组合的概念：

维度 1：视频属性

来源（BluRay、WEB-DL）
处理（原盘、Remux、压制）
编码（H264、H265）
分辨率（4K、1080p）
色彩（HDR、Dolby Vision）

维度 2：音频属性

编码（TrueHD、DTS-HD MA、DDP）
声道（2.0、5.1、7.1）
技术（Atmos、DTS:X）

维度 3：其他

字幕、制作组、特殊标记

配置原则：

根据设备能力选择合适的版本
在画质、体积、兼容性之间找平衡
用优先级梯度表达偏好，不要一刀切
定期检查日志，根据实际情况调整

推荐起点配置：

中端用户：4K/1080p BluRay/WEB-DL H265 压制版
体积限制：电影 10-25GB，剧集 50-100GB/季
音频：DDP 5.1 或以上
排除：Remux（除非空间充足）、3D、Dolby Vision（除非设备支持）

希望这篇指南能帮助你彻底理解视频资源术语，配置出最适合自己的 MoviePilot 规则，享受高质量的观影体验！

Ubuntu/Debian 防火墙 UFW 完全使用指南

Sat, 06 Dec 2025 00:00:00 +0000

写在前面

你是不是遇到过这样的情况：刚买的云服务器，想限制一下访问端口提高安全性，但面对复杂的 iptables 命令却无从下手？或者配置了半天防火墙规则，一不小心把自己的 SSH 连接也给封掉了，只能重启服务器恢复？

UFW（Uncomplicated Firewall）就是为了解决这个痛点而生的。它是 Ubuntu 官方推荐的防火墙工具，把复杂的 iptables 命令封装成简单易懂的语法，让普通用户也能轻松管理防火墙规则。

这篇文章将带你从零开始掌握 UFW，不仅教你基本的命令操作，还会分享实际场景中的配置技巧和常见问题的解决方案。

UFW 是什么

与 iptables 的关系

可以把 iptables 想象成汽车的手动挡，功能强大但操作复杂；而 UFW 就是自动挡，底层还是同一套系统，但使用起来简单多了。

iptables：Linux 内核级别的防火墙，功能强大但命令复杂
UFW：对 iptables 的友好封装，提供简单的命令行界面
关系：UFW 的每条规则最终都会转换成 iptables 规则执行

适用场景

✅ Ubuntu/Debian 服务器的日常防火墙管理
✅ 简单的端口开放和访问控制
✅ 快速配置常见服务（SSH、HTTP、HTTPS 等）
❌ 极其复杂的网络策略（建议直接用 iptables）
❌ 需要高级 NAT 转发的场景

安装与初始配置

检查安装状态

Ubuntu 16.04 及以后版本默认已安装 UFW，可以先检查一下：

1
2
3
4
5


# 检查是否安装
which ufw

# 查看版本
ufw version

安装 UFW

如果没有安装，使用以下命令：

1
2
3
4
5


# Debian/Ubuntu
sudo apt update
sudo apt install ufw

# 其他发行版可能需要从源码编译

首次启用前的安全配置

重要提醒：如果你是通过 SSH 远程连接服务器，在启用 UFW 之前必须先放行 SSH 端口，否则会把自己锁在门外！

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 第一步：设置默认策略（拒绝所有入站，允许所有出站）
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 第二步：放行 SSH（默认 22 端口）
sudo ufw allow ssh
# 或者如果你改了 SSH 端口（假设改成 2222）
sudo ufw allow 2222/tcp

# 第三步：启用防火墙
sudo ufw enable

启用后会提示可能中断现有连接，输入 y 确认即可。

查看状态

1
2
3
4
5
6
7
8


# 查看防火墙状态
sudo ufw status

# 查看详细状态（包含规则编号）
sudo ufw status numbered

# 查看详细信息（包含原始 iptables 规则）
sudo ufw status verbose

基本规则管理

允许和拒绝端口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 允许指定端口
sudo ufw allow 80 # 允许 80 端口（TCP 和 UDP）
sudo ufw allow 443/tcp # 只允许 443 端口的 TCP 流量
sudo ufw allow 53/udp # 只允许 53 端口的 UDP 流量

# 允许端口范围
sudo ufw allow 6000:6007/tcp # 允许 6000-6007 端口

# 拒绝指定端口
sudo ufw deny 3306 # 拒绝 MySQL 端口
sudo ufw deny 3306/tcp # 只拒绝 TCP 连接

使用服务名称

UFW 预定义了常见服务的端口，可以直接使用服务名：

1
2
3
4
5
6
7
8


# 允许常见服务
sudo ufw allow ssh # 22 端口
sudo ufw allow http # 80 端口
sudo ufw allow https # 443 端口
sudo ufw allow ftp # 21 端口

# 查看所有可用的服务名称
less /etc/services

IP 地址访问控制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 允许特定 IP 访问
sudo ufw allow from 192.168.1.100

# 允许特定 IP 访问特定端口
sudo ufw allow from 192.168.1.100 to any port 22

# 允许整个子网
sudo ufw allow from 192.168.1.0/24

# 拒绝特定 IP
sudo ufw deny from 203.0.113.100

基于网卡的规则

1
2
3
4
5


# 允许特定网卡的流量
sudo ufw allow in on eth0 to any port 80

# 允许从 eth1 进入的 MySQL 连接（内网访问数据库）
sudo ufw allow in on eth1 to any port 3306

删除和修改规则

删除规则的方法

方法一：使用规则编号（推荐）

1
2
3
4
5


# 查看规则编号
sudo ufw status numbered

# 删除指定编号的规则
sudo ufw delete 3

方法二：重复添加规则的命令

1
2
3


# 如果之前添加了：sudo ufw allow 80
# 删除时使用：
sudo ufw delete allow 80

重置所有规则

1
2
3
4
5


# 禁用防火墙
sudo ufw disable

# 重置所有规则（会删除所有自定义规则）
sudo ufw reset

实际场景配置

Web 服务器配置

假设你要部署一个网站服务器，需要开放 HTTP、HTTPS 和 SSH：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 重置默认策略
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 允许 SSH（远程管理）
sudo ufw allow ssh

# 允许 HTTP 和 HTTPS（网站访问）
sudo ufw allow http
sudo ufw allow https

# 启用防火墙
sudo ufw enable

# 验证配置
sudo ufw status verbose

数据库服务器配置

数据库服务器通常不应该对外开放，只允许特定应用服务器访问：

1
2
3
4
5


# 假设应用服务器 IP 是 192.168.1.50
sudo ufw allow from 192.168.1.50 to any port 3306

# 或者允许整个内网段
sudo ufw allow from 192.168.1.0/24 to any port 3306

SSH 暴力破解防护

虽然 UFW 本身不支持动态封禁，但可以配合限速功能：

1
2
3
4


# 限制 SSH 连接频率（防止暴力破解）
sudo ufw limit ssh

# 这会限制同一 IP 在 30 秒内最多 6 次连接尝试

Docker 容器端口映射

如果你使用 Docker，可能会发现 Docker 会绕过 UFW 规则。解决方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 编辑 UFW 配置文件
sudo nano /etc/ufw/after.rules

# 在文件末尾添加（假设 Docker 使用 172.17.0.0/16 网段）
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j RETURN
COMMIT

然后重启 UFW：

1

sudo ufw reload

允许 Ping（ICMP）

默认情况下 UFW 允许 ping，如果你手动禁用了，可以这样恢复：

1
2
3
4
5


# 编辑配置文件
sudo nano /etc/ufw/before.rules

# 确保有以下规则（通常默认就有）
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

高级功能

日志记录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 开启日志（默认级别）
sudo ufw logging on

# 设置日志级别
sudo ufw logging low # 低
sudo ufw logging medium # 中（默认）
sudo ufw logging high # 高
sudo ufw logging full # 完整

# 关闭日志
sudo ufw logging off

# 查看日志
sudo tail -f /var/log/ufw.log

应用配置文件

UFW 支持创建应用配置文件，方便管理复杂的规则组合：

1
2
3
4
5
6
7
8


# 查看已有的应用配置
sudo ufw app list

# 查看应用详情
sudo ufw app info 'Nginx Full'

# 允许应用
sudo ufw allow 'Nginx Full'

创建自定义应用配置：

1
2
3
4
5
6
7
8


# 创建配置文件
sudo nano /etc/ufw/applications.d/myapp

# 内容示例：
[MyApp]
title=My Application
description=Custom app with multiple ports
ports=8080,8443/tcp

然后就可以使用：

1

sudo ufw allow 'MyApp'

IPv6 支持

UFW 默认支持 IPv6，确保配置文件中已启用：

1
2
3
4
5
6
7
8
9


# 编辑配置
sudo nano /etc/default/ufw

# 确保有这一行
IPV6=yes

# 重启 UFW
sudo ufw disable
sudo ufw enable

常见问题与解决方案

规则不生效怎么办？

检查以下几点：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 确认 UFW 已启用
sudo ufw status

# 查看规则顺序（UFW 从上到下匹配）
sudo ufw status numbered

# 重新加载规则
sudo ufw reload

# 查看底层 iptables 规则（排查问题）
sudo iptables -L -n -v

误把自己锁在外面了怎么办？

如果你无法 SSH 连接服务器：

云服务器：通过云控制台的 VNC/控制台功能登录
物理服务器：通过 IPMI 或直连显示器登录

登录后执行：

1
2
3


sudo ufw disable
sudo ufw allow ssh
sudo ufw enable

Docker 容器端口无法访问

Docker 默认会修改 iptables 规则，可能绕过 UFW。解决方案参考前面的"Docker 容器端口映射"章节。

如何查看被阻止的连接？

1
2
3
4
5
6
7
8


# 开启日志
sudo ufw logging medium

# 实时查看被拒绝的连接
sudo tail -f /var/log/ufw.log | grep BLOCK

# 分析特定 IP 的访问
sudo grep "192.168.1.100" /var/log/ufw.log

UFW 和其他防火墙工具冲突

如果你同时使用了 firewalld、nftables 等工具，可能会冲突：

1
2
3
4
5
6


# 停用其他防火墙
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# 只使用 UFW
sudo ufw enable

端口转发怎么做？

UFW 本身不直接支持端口转发，需要修改配置文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 编辑配置
sudo nano /etc/ufw/before.rules

# 在 *filter 之前添加 NAT 规则
*nat
:PREROUTING ACCEPT [0:0]
# 将外部 8080 端口转发到内部 192.168.1.100:80
-A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.100:80
COMMIT

# 启用转发
sudo nano /etc/ufw/sysctl.conf
# 取消注释：
net/ipv4/ip_forward=1

# 重启 UFW
sudo ufw disable
sudo ufw enable

常用命令速查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# 状态管理
sudo ufw status # 查看状态
sudo ufw enable # 启用防火墙
sudo ufw disable # 禁用防火墙
sudo ufw reload # 重新加载规则
sudo ufw reset # 重置所有规则

# 规则管理
sudo ufw allow 80 # 允许端口
sudo ufw deny 3306 # 拒绝端口
sudo ufw limit ssh # 限速（防暴力破解）
sudo ufw delete allow 80 # 删除规则
sudo ufw status numbered # 显示规则编号
sudo ufw delete 3 # 删除指定编号的规则

# 高级规则
sudo ufw allow from 192.168.1.100 # 允许 IP
sudo ufw allow from 192.168.1.0/24 to any port 22 # 子网访问特定端口
sudo ufw allow in on eth0 to any port 80 # 指定网卡

# 默认策略
sudo ufw default deny incoming # 默认拒绝入站
sudo ufw default allow outgoing # 默认允许出站

# 日志管理
sudo ufw logging on # 开启日志
sudo ufw logging medium # 设置日志级别
sudo tail -f /var/log/ufw.log # 查看日志

总结

UFW 把复杂的防火墙管理变得简单直观，特别适合 Ubuntu/Debian 服务器的日常安全维护。核心要点回顾：

启用前必须先放行 SSH，避免把自己锁在外面
遵循最小权限原则：默认拒绝入站，只开放必要的端口
规则有优先级：从上到下匹配，第一条匹配的规则生效
定期检查规则：使用 ufw status numbered 审查配置
配合日志使用：出问题时通过日志排查

对于大多数场景，UFW 已经足够用了。如果遇到特别复杂的需求，再考虑深入学习 iptables 或 nftables。记住，安全配置没有一劳永逸，要根据实际需求不断调整优化。

MoviePilot订阅识别流程详解：从入门到精通

Wed, 03 Dec 2025 00:00:00 +0000

写在前面

如果你在使用 MoviePilot 订阅功能时遇到过这些问题：

搜索到资源但全部被过滤，不知道为什么
明明定义了自定义规则，但好像没有生效
想要某个制作组的资源，但总是被过滤掉
配置了很多规则，但不知道它们的执行顺序

那么这篇文章就是为你准备的。我将通过实际案例，深入浅出地讲解 MoviePilot 的订阅识别机制，帮你彻底理解规则是如何工作的，让你能够精准配置订阅规则，实现完美的自动追剧体验。

核心概念

自定义规则 vs 优先级规则组

关键理解：

自定义规则（界面上半部分）
- 作用：定义可复用的过滤条件
- 特点：定义后不会自动生效
- 示例：HHWEB、filterMovie、Netflix 等
优先级规则组（界面下半部分）
- 作用：真正执行过滤和评分的地方
- 特点：通过 &规则名 引用自定义规则
- 分类：
  - 前置过滤（全部类型）：对所有资源生效，最先执行
  - 类型规则组：外语电影、日番、国产剧等，针对特定类型

工作机制（通俗理解）：

可以把这个关系理解为：

自定义规则 = 工具箱里的工具（定义好但不会自动使用）
优先级规则 = 使用工具的人（主动拿工具来用）

打个比方：

你在工具箱里准备了"HHWEB 规则"这把锤子（定义），但如果你在优先级规则中不说"我要用这把锤子"（引用），这把锤子就永远躺在工具箱里，不会被使用。

实际例子：

✅ 正确做法：

定义自定义规则：HHWEB（包含关键词 “HHWEB”）
在优先级规则中引用：4K & H265 & HHWEB & filterMovie
结果：✅ HHWEB 规则生效，只下载包含 HHWEB 的资源

❌ 常见错误：

定义自定义规则：HHWEB（包含关键词 “HHWEB”）
优先级规则中没有引用 HHWEB
结果：❌ HHWEB 规则不生效，白定义了

完整处理流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


订阅任务开始
 ↓
检查订阅状态（是否已完成）
 ↓
【阶段1】搜索资源
 ↓
从索引器/站点搜索关键词
 ↓
【阶段2】附加参数过滤（基础过滤）
 ├─ 分辨率匹配检查
 ├─ 视频编码检查
 ├─ 音频编码检查
 └─ 质量来源检查
 ↓
【阶段3】优先级规则组过滤（核心）
 ├─ 步骤1: 应用前置过滤（全部类型）
 │ └─ 全局排除规则（如 !REMUX、!3D）
 ├─ 步骤2: 匹配媒体类型规则组
 │ └─ 根据媒体类型选择对应规则组
 ├─ 步骤3: 遍历优先级规则
 ├─ 步骤4: 在优先级规则中调用自定义规则
 │ ├─ 包含关键词检查
 │ ├─ 排除关键词检查
 │ ├─ 文件体积范围检查
 │ ├─ 做种人数检查
 │ └─ 发布时间检查
 └─ 步骤5: 计算匹配分数
 ↓
按优先级排序选择最佳资源
 ↓
下载 / 继续订阅

各阶段详细说明

阶段1: 搜索资源

从配置的索引器（PT站点、公开tracker等）搜索资源。

搜索策略:

使用媒体标题作为关键词
可能包含年份、IMDB ID 等信息
支持多站点并发搜索

返回信息:

资源标题
文件大小
做种人数
发布时间
下载链接

阶段2: 附加参数过滤（基础过滤）

这是订阅设置中指定的基础要求，最先执行。

检查项目

参数	说明	示例
分辨率	视频分辨率要求	4K, 2160p, 1080p, 720p
视频编码	视频编码格式	H265, H264, x265, x264, AV1
音频编码	音频编码格式	DTS, DTS-HD, TrueHD, AAC, AC3
质量来源	视频来源类型	BluRay, WEB-DL, HDTV, Remux

匹配规则

1
2
3
4


IF 资源属性 匹配 订阅要求:
 ✅ 通过，进入下一阶段
ELSE:
 ❌ 过滤掉，不再处理

示例

1
2
3
4
5
6
7


订阅要求: 分辨率 = 4K|2160p|x2160

资源1: The Movie 2024 1080p BluRay
 → ❌ 分辨率不匹配（1080p）

资源2: The Movie 2024 2160p WEB-DL
 → ✅ 通过（2160p = 4K）

阶段3: 优先级规则组过滤（核心阶段）

根据媒体类型匹配对应的规则组，然后按优先级评分。在评分过程中会调用自定义规则。

自定义规则（定义阶段）

自定义规则（如 HHWEB, Netflix, DDP, filterMovie 等）是可复用的过滤条件定义，本身不会自动生效，必须在优先级规则中通过 &规则名 引用才会被调用。

规则配置示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


规则ID: HHWEB
规则名称: HHWEB
包含:
 - HHWEB  # 必须包含的关键词
排除:
 - [] # 不能包含的关键词
资源体积: 0/1-10  # 最小/最大体积（GB），0表示不限
做种人数: 0/1-10  # 最小/最大做种人数，0表示不限
发布时间: 0/1-10  # 最小/最大发布时间（分钟），0表示不限

---

规则ID: filterMovie
规则名称: filterMovie
包含: ""
排除: ""
资源体积: 0-22000 # 电影体积限制 0-22GB
做种人数: ""
发布时间: ""

自定义规则的检查逻辑

当优先级规则中引用了自定义规则（如 &filterMovie），系统会执行以下检查：

✓ 包含关键词检查：资源标题必须包含指定的关键词
✓ 排除关键词检查：资源标题不能包含排除的关键词
✓ 体积范围检查：资源大小必须在设定范围内
✓ 做种人数检查：做种人数必须满足要求
✓ 发布时间检查：发布时间必须在设定范围内

规则组分类

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


优先级规则组:
├─ 前置过滤（全局） ← 对所有类型生效，最先执行
├─ 动画电影
├─ 华语电影
├─ 外语电影 ← 《肖申克的救赎》匹配这个
├─ 日番
├─ 国漫
├─ 纪录片
├─ 综艺
├─ 国产剧
├─ 欧美剧
├─ 日韩剧
└─ 现场

前置过滤规则组（特殊规则组）

作用范围：对所有媒体类型的资源都生效（电影、剧集、动画等）

执行时机：在其他特定类型规则组（如"外语电影"、“日番”）之前执行

配置原理：

1
2
3
4
5
6


{
 "name": "前置过滤",
 "rule_string": "filterGlobal & !REMUX & !3D & !DOLBY & filerGroup",
 "media_type": "", // 空字符串 = 适用于所有媒体类型
 "category": "" // 空字符串 = 适用于所有分类
}

典型用途：

1
2
3
4
5
6
7
8
9


优先级表达式示例：
filterGlobal & !REMUX & !3D & !DOLBY & filerGroup

含义：
├─ filterGlobal: 引用全局过滤自定义规则
├─ !REMUX: 排除所有原盘资源（!表示排除）
├─ !3D: 排除所有3D资源
├─ !DOLBY: 排除杜比视界资源
└─ filerGroup: 引用组过滤规则

常见应用场景：

全局排除体积过大的格式（如 REMUX 原盘）
全局排除特定字幕组
全局排除特定关键词（如"日语无字"、“MiniBD”）
全局排除特殊格式（如 3D、HDR10+）

执行流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


资源通过阶段2过滤
 ↓
【第一步】前置过滤（全部类型）
 检查：filterGlobal & !REMUX & !3D
 ↓
 如果资源标题包含 "REMUX" → ❌ 直接过滤，不再检查后续规则
 如果资源标题包含 "3D" → ❌ 直接过滤
 ↓
【第二步】根据媒体类型进入对应规则组
 ├─ 外语电影 → 外语电影规则组
 ├─ 日本动画 → 日番规则组
 └─ 国产剧集 → 国产剧规则组
 ↓
【第三步】在规则组内按优先级评分

重要提醒：

前置过滤中的 !关键词 表示排除（exclude）
被前置过滤排除的资源，不会进入后续的类型规则组
确保前置过滤不要过于严格，否则可能误杀想要的资源

优先级规则结构

每个规则组包含多个优先级，分数从高到低。每个优先级通过 & 符号组合多个条件，包括引用自定义规则：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


外语电影规则组:
├─ 优先级1 (分数: 100)
│ 表达式: SPECSUB & 4K & BLURAY & H265 & filterMovie
│ 含义:
│ ├─ SPECSUB: 特效字幕标识
│ ├─ 4K: 分辨率要求
│ ├─ BLURAY: 质量来源要求
│ ├─ H265: 视频编码要求
│ └─ filterMovie: 引用自定义规则（检查体积 0-22GB）
│
├─ 优先级2 (分数: 90)
│ 表达式: CNSUB & 4K & BLURAY & H265 & filterMovie
│ 含义:
│ ├─ CNSUB: 中文字幕标识
│ ├─ 4K: 分辨率要求
│ ├─ BLURAY: 质量来源要求
│ ├─ H265: 视频编码要求
│ └─ filterMovie: 引用自定义规则
│
├─ 优先级3 (分数: 80)
│ 表达式: CNSUB & 1080P & BLURAY & filterMovie
│ 含义:
│ ├─ CNSUB: 中文字幕标识
│ ├─ 1080P: 分辨率要求
│ ├─ BLURAY: 质量来源要求
│ └─ filterMovie: 引用自定义规则
│
├─ 优先级4 (分数: 70)
│ 表达式: CNSUB & 4K & filterMovie
│ 含义:
│ ├─ CNSUB: 中文字幕标识
│ ├─ 4K: 分辨率要求
│ └─ filterMovie: 引用自定义规则
│
└─ 优先级5 (分数: 60)
 表达式: CNSUB & 1080P & filterMovie
 含义:
 ├─ CNSUB: 中文字幕标识
 ├─ 1080P: 分辨率要求
 └─ filterMovie: 引用自定义规则

关键点：

& 连接的所有条件必须同时满足
filterMovie 等自定义规则通过 &规则名 引用
只有当优先级表达式中引用了自定义规则，该规则才会被调用
资源必须匹配优先级中的所有条件（包括引用的自定义规则）才能获得该优先级的分数

优先级匹配逻辑

系统会从优先级1开始，逐个检查资源是否符合条件。只要找到第一个匹配的优先级，就用那个优先级的分数，不再检查后面的。如果所有优先级都不匹配，资源就会被过滤掉。

举例说明：

假设优先级2的条件是：CNSUB & 4K & BLURAY & H265 & filterMovie

对于资源 “The Shawshank Redemption 1994 2160p WEB-DL H265 HQ AAC-HHWEB”：

检查 CNSUB（中文字幕）→ ❌ 标题中没有字幕标识
第一个条件就不满足，直接判定为不匹配
跳到下一个优先级继续检查

资源选择策略

1
2
3
4


1. 计算每个资源的优先级分数
2. 过滤掉分数为 0 的资源（不匹配任何优先级）
3. 按分数从高到低排序
4. 选择分数最高的资源下载

中文字幕标识规则

常见标识符

类型	标识符	说明
简体中文	CHS, GB, GB2312, 简体, 简中, SC	简体中文字幕
繁体中文	CHT, BIG5, 繁体, 繁中, TC	繁体中文字幕
双语	CHS.ENG, CHT.ENG, 简英, 繁英, 双语, 中英	中英双语字幕
多语	简繁英, CHS.CHT.ENG	三语或更多
通用	中字, 中文字幕, Chinese, 内封, 内嵌	泛指中文字幕

识别示例

有中文字幕标识

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


The Shawshank Redemption 1994 2160p BluRay x265 CHS.ENG TrueHD-CMCT
 ^^^^^^^^
 简中英双语

肖申克的救赎 1994 2160p WEB-DL H265 简繁英 AAC-HHWEB
 ^^^
 三语字幕

The.Shawshank.Redemption.1994.2160p.BluRay.CHT.x265-FRDS
 ^^^
 繁体中文

The Movie 2024 1080p WEB-DL H264 中字 AAC
 ^^
 中文字幕

没有中文字幕标识

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


The Shawshank Redemption 1994 2160p WEB-DL H265 HQ AAC-HHWEB
 ^^
 HQ = High Quality
 没有字幕标识

The Movie 2024 1080p BluRay x264 DTS-WIKI
 ^^^^
 制作组名称
 没有字幕标识

The Film 2024 2160p WEB-DL H265 AAC-Team
 ^^^^
 制作组名称
 没有字幕标识

注意事项

标题无标识 ≠ 实际无字幕
- 有些资源实际内封了中文字幕，但标题中未标注
- WEB-DL 资源尤其如此（从流媒体平台抓取）
- PT 站点详情页可能有说明
制作组习惯不同
- CMCT、FRDS、CHD 等组通常会标注字幕信息
- HHWEB、WiKi、NTb 等 WEB 组可能不标注
- 需要熟悉各制作组的命名规范
MoviePilot 只看标题
- MoviePilot 依赖种子标题进行过滤
- 不会解析种子详情页或内部文件信息
- 所以标题中必须有标识才能被识别

实际案例分析

案例：《肖申克的救赎》订阅失败

订阅配置

1
2
3
4
5


媒体: 肖申克的救赎 (1994)
类型: 电影 - 外语电影
要求:
 分辨率: 4K|2160p|x2160
 其他: 默认

搜索结果

从憨憨站搜索，共找到 11 个资源。

过滤过程

阶段1: 搜索

1

✅ 找到 11 个资源

阶段2: 附加参数过滤（分辨率: 4K）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


❌ The Shawshank Redemption 1994 Blu-ray 1080p VC-1 DTS-HD MA 5.1-CMCT
 → 不匹配：1080p

❌ The Shawshank Redemption 1994 BluRay 1080p x265 10bit 5Audio MNHD-FRDS
 → 不匹配：1080p

❌ The Shawshank Redemption 1994 BluRay x264 DTS 4Audios MiniBD1080P-CMCT
 → 不匹配：1080p

❌ The Shawshank Redemption 1994 1080p BluRay x265 10bit DTS-ADE
 → 不匹配：1080p

❌ The Shawshank Redemption 1994 1080p WEB-DL H264 AAC-HHWEB
 → 不匹配：1080p

✅ The Shawshank Redemption 1994 2160p WEB-DL H265 HQ AAC-HHWEB
 → 通过：2160p = 4K

（其他5个资源未在日志中显示分辨率，可能也被过滤）

阶段3: 优先级规则组过滤

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


自定义规则已定义：Complete, filterGlobal, filerGroup, Audiences,
 HHWEB, Netflix, DDP, MWeb, filterMovie
（注意：这些规则只是定义，不会自动应用）

资源: The Shawshank Redemption 1994 2160p WEB-DL H265 HQ AAC-HHWEB

【步骤1】前置过滤（全部类型）
 假设前置过滤规则：filterGlobal & !REMUX & !3D & filerGroup
 ✓ 资源不包含 "REMUX"：通过
 ✓ 资源不包含 "3D"：通过
 ✓ filterGlobal 规则检查：通过
 → 通过前置过滤，继续检查

【步骤2】匹配媒体类型 → 进入"外语电影"规则组

【步骤3】在外语电影规则组中，按优先级顺序检查：

【优先级1】SPECSUB & 4K & BLURAY & H265 & filterMovie
 ✓ 4K: 2160p 匹配
 ✓ H265: 匹配
 ✗ SPECSUB: 无特效字幕标识
 → 不匹配，检查下一优先级

【优先级2】CNSUB & 4K & BLURAY & H265 & filterMovie
 ✗ CNSUB: 标题中没有 CHS/CHT/中字 等标识
 → 不匹配，检查下一优先级
 → filterMovie 规则未被调用（因为前置条件已失败）

【优先级3】CNSUB & 1080P & BLURAY & filterMovie
 ✗ CNSUB: 无字幕标识
 → 不匹配，检查下一优先级

【优先级4】CNSUB & 4K & filterMovie
 ✗ CNSUB: 无字幕标识
 → 不匹配，检查下一优先级
 → filterMovie 规则未被调用

【优先级5】CNSUB & 1080P & filterMovie
 ✗ CNSUB: 无字幕标识
 → 不匹配

所有优先级都不匹配 → 分数 = 0 → ❌ 资源被过滤

关键分析：

虽然资源标题包含 “HHWEB”，但优先级规则中没有引用 HHWEB 自定义规则
所有优先级都要求 CNSUB（中文字幕），而该资源标题无字幕标识
filterMovie 规则虽然已定义，但因为前置条件（CNSUB）失败，从未被调用

最终结果

1
2


⚠️ 没有符合过滤规则的资源
订阅状态：未下载完整，继续订阅

问题总结

根本原因

“外语电影"规则组的所有优先级都要求 CNSUB（中文字幕标识），但这个 4K 资源标题中没有字幕标识。就像你设置了一个门槛，要求"必须有准考证才能进考场”，而这个资源没带准考证，自然就被拦在门外了。

为什么 1080p 资源也没通过

你可能会想：“那些 1080p 的资源有中文字幕标识啊，为什么也没下载？”

答案是：虽然某些 1080p 资源可能有中文字幕标识，但它们在更早的阶段（附加参数过滤）就被过滤掉了，因为你的订阅要求分辨率必须是 4K。它们连进入优先级规则组的机会都没有。

关键发现

这个案例揭示了三个重要事实：

定义≠生效：虽然定义了 HHWEB 自定义规则，但优先级规则中没有引用它，所以完全没起作用
顺序很重要：filterMovie 规则虽然被引用了，但因为前面的 CNSUB 条件就失败了，根本没机会执行
严格=失败：所有优先级都要求中文字幕，导致很多优质资源被错过

常见问题与解决方案

问题1: 搜索到资源但全部被过滤

症状:

1
2


共搜索到 X 个资源
没有符合过滤规则的资源

可能原因:

附加参数要求过于严格（如只要 4K，但只有 1080p 资源）
优先级规则条件太苛刻（如所有优先级都必须中文字幕）
优先级规则中引用的自定义规则包含/排除条件不合理

解决方案:

放宽附加参数要求（如 4K 改为 1080p+4K）
在规则组中添加更宽松的优先级（如不要求字幕）
检查优先级规则中引用的自定义规则配置

问题2: 需要特定制作组但被过滤

场景: 想要某个特定制作组的资源，但总是被过滤掉。

原因分析:

制作组的自定义规则虽然已定义，但优先级规则中未引用
优先级规则中的其他条件（如字幕、质量来源）过于严格

解决方案:

步骤1: 定义制作组规则

1
2
3
4


规则ID: 制作组名称
规则名称: 制作组名称
包含: 制作组关键词
排除: ""

步骤2: 在优先级规则中引用

1
2
3
4
5


在对应规则组中新增优先级：

优先级X (分数自定):
 表达式: 4K & H265 & 制作组名称 & filterMovie
 说明: 专门针对该制作组的优先级

关键点：定义自定义规则后，必须在优先级规则中引用才会生效

问题3: 搜索不到任何资源

症状:

1

站点搜索完成，有效资源数：0

可能原因:

站点没有该资源
搜索关键词不对
站点连接失败或需要登录

解决方案:

手动到站点搜索验证是否有资源
检查站点配置和 Cookie 是否过期
尝试修改搜索关键词

问题4: 想要原盘但只找到压制版

症状: 搜索到的都是 x265 压制版，没有原盘（Remux/BluRay）。

解决方案:

调整优先级:

1
2
3
4
5
6
7
8


优先级1:
 - 质量: BLURAY|Remux （只接受原盘）
 - 分辨率: 4K

优先级2:
 - 质量: BLURAY
 - 分辨率: 4K
 - 编码: H265

添加自定义规则:

1
2
3


规则: OnlyRemux
包含: Remux|BDMV|COMPLETE
排除: x265|x264|HEVC|AVC

问题5: 不需要中文字幕但被要求

场景: 想看原版外语电影（不需要中文字幕），但规则要求中文字幕。

解决方案:

方法1: 单独订阅覆盖 在订阅详情中，指定不要求中文字幕。

方法2: 创建新规则组

1
2
3
4
5


规则组: 外语电影（原版）
├─ 优先级1: 4K + BLURAY + H265
├─ 优先级2: 4K + H265
└─ 优先级3: 1080P + BLURAY
（所有优先级都不要求字幕）

方法3: 修改现有规则组 在需要的优先级中删除"中文字幕"标签。

问题6: 想同时接受多种质量

场景: 既要 BluRay 也接受 WEB-DL，只要是 4K 即可。

解决方案:

创建优先级梯度：

1
2
3
4
5


优先级1 (90分): 4K + BLURAY + H265 + 中文字幕
优先级2 (80分): 4K + WEB-DL + H265 + 中文字幕
优先级3 (70分): 4K + BLURAY + 中文字幕
优先级4 (60分): 4K + WEB-DL + 中文字幕
优先级5 (50分): 4K + 中文字幕（任何来源）

调试技巧

1. 查看详细日志

日志级别设置为 INFO 或 DEBUG，观察：

搜索到的资源数量
每个过滤阶段的结果
被过滤资源的原因

2. 测试搜索

使用"搜索 & 下载"功能手动搜索：

不应用订阅过滤规则
查看实际有哪些资源
对比订阅为什么没下载

3. 逐步放宽规则

从严格到宽松逐步测试：

1
2
3
4


测试1: 4K + BLURAY + H265 + 中文字幕
测试2: 4K + H265 + 中文字幕
测试3: 4K + 中文字幕
测试4: 4K

找出最合适的平衡点。

总结

MoviePilot 的过滤流程设计为两层漏斗：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


搜索结果（大量）
 ↓
附加参数过滤（硬性要求：分辨率、编码等）
 ↓
通过资源（较多）
 ↓
优先级规则组过滤（核心）
├─ 【第一步】前置过滤（全部类型）
│ ├─ 应用全局排除规则（!REMUX、!3D等）
│ └─ 调用 filterGlobal、filerGroup 等自定义规则
├─ 【第二步】匹配媒体类型规则组
│ └─ 根据媒体类型选择对应规则组
├─ 【第三步】遍历优先级规则
├─ 【第四步】在优先级中调用自定义规则
│ ├─ 检查包含/排除关键词
│ ├─ 检查体积范围
│ └─ 其他自定义条件
└─ 【第五步】计算优先级分数
 ↓
最佳资源（分数最高的1个）
 ↓
下载

关键点:

附加参数是硬性要求，在订阅设置中配置，不匹配直接过滤
自定义规则只是定义，不会自动生效，必须在优先级规则中引用
前置过滤最先执行，对所有类型生效，用于全局排除（如 !REMUX、!3D）
优先级规则组是核心，决定最终下载哪个资源
优先级通过 & 连接多个条件，包括引用自定义规则
优先级分数越高越优先，分数为0会被过滤

配置原则:

不要过于严格，留有余地（如不要所有优先级都要求字幕）
用优先级梯度表达倾向，而不是硬性要求
为常见场景配置多个优先级（有字幕/无字幕、BluRay/WEB-DL 等）
前置过滤用于全局排除，避免过于严格导致误杀想要的资源
自定义规则定义后，记得在优先级规则中引用才会生效
定期检查日志，根据实际情况调整优先级规则

写在最后

通过本文的详细讲解，相信你已经掌握了 MoviePilot 订阅识别的核心机制。记住这几个关键点：

自定义规则是定义，不是执行 - 定义后必须在优先级规则中引用才生效
前置过滤最先执行 - 用于全局排除，对所有类型生效
优先级规则是核心 - 决定最终下载哪个资源
配置要留余地 - 不要过于严格，用优先级梯度表达倾向

如果在配置过程中遇到问题，建议：

查看详细日志，了解资源被过滤的原因
逐步放宽规则，找到合适的平衡点
参考本文的优化建议，调整优先级配置

祝你追剧愉快！如果本文对你有帮助，欢迎分享给更多需要的朋友。

Hetzner独立服务器部署安装系统以及设置RAID

Sat, 22 Nov 2025 00:00:00 +0000

写在前面

购买独立服务器后，第一件事就是安装操作系统。与VPS不同，独立服务器通常有多块硬盘，这就涉及到RAID配置的问题。配置得当可以提升性能和数据安全性，配置不当可能导致数据丢失。

Hetzner提供了非常方便的Rescue系统和installimage工具，让服务器安装变得简单。本文将详细介绍从零开始安装系统并配置RAID的完整流程，包括：

Rescue模式的激活和使用
installimage配置文件详解
RAID 0/1/5/6/10 的选择建议
分区方案的设计
常见问题的解决方法

系统安装

激活rescue模式

首先登录到 Hetzner Robot 管理面板，在服务器列表中找到你的服务器，点击进入详情页面。

在左侧菜单栏找到 Rescue 选项，进入Rescue系统配置页面。这里有几个重要选项：

Operating system: 选择 Linux（默认）
Architecture: 根据你的服务器选择 64位或 32位（通常是64位）
Public key: 如果你之前上传过SSH公钥，可以在这里选择，这样就能直接用私钥登录，无需密码

配置完成后，点击页面底部的 Activate rescue system 按钮：

激活成功后，页面会显示一个绿色的成功提示框，包含重要的登录信息：

Login: 登录用户名（通常是 root）
Password: 自动生成的临时密码（如果没有使用SSH公钥）
SSH host keys: Rescue系统的主机密钥指纹，用于验证连接安全性

重要提示：

这个密码只在本次Rescue会话中有效
记得保存或复制这个密码，后面登录要用
Rescue模式激活后，需要重启服务器才能进入

接下来，在服务器详情页面点击 Reset 标签页，选择 Execute an automatic hardware reset，让服务器重启进入Rescue模式。重启大约需要1-2分钟。

登录 Rescue 系统

服务器重启完成后，就可以通过SSH连接到Rescue系统了。打开你的终端（Linux/Mac）或SSH客户端（Windows推荐使用PuTTY或Windows Terminal），使用以下命令连接：

1

ssh root@your-server-ip

将 your-server-ip 替换为你服务器的实际IP地址（可以在Robot管理面板的服务器详情页面找到）。

如果你使用的是SSH公钥认证，会直接登录成功。如果使用密码登录，系统会提示你输入密码，复制粘贴之前Rescue激活时显示的临时密码即可。

首次连接时的安全提示：

SSH客户端会显示一个警告信息，提示无法确认主机的真实性，这是正常的。信息类似：

1
2
3


The authenticity of host 'xxx.xxx.xxx.xxx' can't be established.
ECDSA key fingerprint is SHA256:xxxxxx...
Are you sure you want to continue connecting (yes/no)?

输入 yes 并按回车继续。系统会将服务器的指纹添加到已知主机列表中。

登录成功后，你会看到Rescue系统的欢迎界面，显示系统信息、可用的工具等：

从图中可以看到，Rescue系统已经成功启动，显示了系统版本信息和一些有用的提示。命令提示符显示为 root@rescue ~ #，说明你已经以root用户身份登录。

运行 installimage

现在可以开始安装系统了。在Rescue系统中，Hetzner提供了一个非常方便的工具叫 installimage，它会引导你完成整个安装过程。

在命令行中输入以下命令：

1

installimage

按回车后，会显示一个文本界面的菜单，列出所有可用的Linux发行版：

这是一个基于文本的交互式菜单，使用方向键上下移动，空格键选择，回车键确认。界面中列出了各种Linux发行版：

Arch Linux: 滚动更新的发行版，适合喜欢最新软件的用户
CentOS: 企业级Linux，稳定性好（注意CentOS已停止维护，建议选择AlmaLinux或Rocky Linux）
Debian: 以稳定著称，软件包丰富，社区支持好
Ubuntu: 基于Debian，使用广泛，新手友好，软件更新较快
Rocky Linux / AlmaLinux: CentOS的替代品，兼容RHEL
其他发行版…

选择建议：

新手推荐：Ubuntu LTS（长期支持版本）
追求稳定：Debian
企业应用：Rocky Linux / AlmaLinux
对于大多数应用场景，Ubuntu 22.04 LTS 或 Debian 11/12 都是不错的选择

这里我们以 Debian 为例，使用方向键选中 Debian，按回车进入版本选择界面：

这里显示了 Debian 的所有可用版本，从图中可以看到包括：

Debian 13 Trixie: 测试版（Testing），包含较新的软件包
Debian 12 Bookworm: 当前稳定版（Stable），2023年6月发布，推荐使用
Debian 11 Bullseye: 旧稳定版（Oldstable），2021年8月发布，仍然受支持
以及其他可用版本

版本选择建议：

生产环境推荐：Debian 12 Bookworm（稳定版，经过充分测试）
保守选择：Debian 11 Bullseye（更成熟，已被广泛使用）
尝鲜用户：Debian 13 Trixie（测试版，软件较新但可能不够稳定）
对于服务器，强烈建议选择 Stable 稳定版（Debian 12）

选择好版本后按回车，系统会显示一个重要提示：

这个提示非常重要！

installimage 会在这里显示：

即将执行的操作提示
需要你确认才能继续的说明

在继续之前请注意：

仔细查看检测到的硬盘信息是否正确
⚠️ 警告：安装过程会清空所有硬盘数据，如有重要数据请先备份
确认无误后，按任意键继续进入配置文件编辑界面

按下任意键后，会打开一个文本编辑器（通常是nano或vim），显示系统安装的配置文件：

这就是系统安装的核心配置文件！截图显示的是一个文本编辑界面，包含了所有的安装参数。这个配置文件看起来有点复杂，但其实结构很清晰。

配置文件结构预览：

从图中可以看到配置文件包含多个部分：

顶部注释区域：说明文件用途和基本语法
主机名配置：HOSTNAME
网络配置：IP地址、网关等（通常自动配置好）
RAID配置：SWRAID、SWRAIDLEVEL 等关键参数
分区配置：PART 和 LV 开头的行，定义如何分区

这个配置文件已经有一个默认配置，但你可以根据需要修改。特别是RAID和分区部分，建议仔细检查和调整。

配置文件详解

下面详细说明配置文件中的关键配置项，帮助你根据实际需求进行调整：

主机名和网络配置

1

HOSTNAME your-hostname

设置服务器的主机名，建议使用有意义的名称，比如 web-server-01。

RAID 配置

这是配置文件中最关键的部分：

1
2


SWRAID 1
SWRAIDLEVEL 1

SWRAID 1：启用软件RAID（1表示启用，0表示禁用）
SWRAIDLEVEL：RAID级别，可选值：0、1、5、6、10

RAID级别选择建议：

RAID 0：性能最高，无冗余，任何一块盘损坏都会导致数据丢失（不推荐）
RAID 1：镜像模式，2块盘互为备份，最常用，适合2盘服务器
RAID 5：至少3块盘，允许1块盘损坏，兼顾性能和安全
RAID 6：至少4块盘，允许2块盘同时损坏，安全性最高
RAID 10：至少4块盘，RAID 1+0 组合，性能和安全性都很好

分区方案

1
2
3
4
5
6


PART /boot ext4 1G
PART lvm vg0 all

LV vg0 root / ext4 50G
LV vg0 swap swap swap 8G
LV vg0 home /home ext4 all

这是一个使用LVM的分区方案：

第一块物理分区：/boot 分区，1GB，用于存放启动文件
第二块物理分区：全部剩余空间分配给LVM（vg0卷组）
LVM逻辑卷：
- root：根分区，50GB，存放系统文件
- swap：交换分区，8GB（通常设置为内存的1-2倍）
- home：home分区，剩余全部空间，存放用户数据

为什么推荐使用LVM：

可以动态调整分区大小
方便后期扩展
支持快照功能

配置完成后按 F10 保存退出。

开始安装

保存配置文件后，installimage 会自动开始安装系统。整个过程包括：

创建分区表
配置RAID阵列
格式化分区
下载并解压系统镜像
安装GRUB引导程序
配置网络

安装过程会显示详细的进度信息：

安装时间取决于网络速度和硬盘性能，通常需要5-15分钟。安装完成后会提示成功信息。

重启进入新系统

安装完成后，输入以下命令重启服务器：

1

reboot

重启后，服务器会从硬盘启动进入刚安装好的系统。使用安装时配置的SSH密钥或root密码即可登录。

首次登录后建议：

修改root密码（如果使用的是自动生成的密码）
更新系统：apt update && apt upgrade -y（Debian/Ubuntu）
配置防火墙
创建普通用户账号
配置SSH安全设置

RAID配置和管理

系统安装完成后，RAID已经自动配置好了。但了解如何查看和管理RAID状态非常重要。

查看RAID状态

查看RAID阵列信息

1

cat /proc/mdstat

输出示例：

1
2
3
4
5
6
7
8


Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
 1023936 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
 488281024 blocks super 1.2 [2/2] [UU]

unused devices: <none>

关键信息解读：

md0、md1：RAID设备名称
raid1：RAID级别
sda1[0] sdb1[1]：成员磁盘
[2/2] [UU]：2块盘都正常（U表示正常，_表示故障）

查看详细RAID信息

1

mdadm --detail /dev/md0

这会显示更详细的信息，包括：

RAID级别和状态
成员磁盘及其状态
同步进度（如果正在同步）
UUID等标识信息

查看磁盘健康状态

1
2


smartctl -a /dev/sda
smartctl -a /dev/sdb

定期检查磁盘的SMART信息可以提前发现问题。

RAID故障处理

硬盘故障模拟

假设 /dev/sdb 出现故障，RAID 1会自动切换到健康的盘继续工作。

标记故障盘并移除

1
2
3
4
5


# 标记为故障
mdadm --manage /dev/md0 --fail /dev/sdb1

# 从阵列中移除
mdadm --manage /dev/md0 --remove /dev/sdb1

添加新硬盘到RAID

更换新硬盘后，需要手动添加到RAID阵列：

1
2
3
4
5
6


# 复制分区表（假设新盘是 /dev/sdc）
sfdisk -d /dev/sda | sfdisk /dev/sdc

# 添加到RAID阵列
mdadm --manage /dev/md0 --add /dev/sdc1
mdadm --manage /dev/md1 --add /dev/sdc2

RAID会自动开始同步数据，可以通过 cat /proc/mdstat 查看同步进度。

RAID性能优化

调整同步速度

1
2
3
4
5
6
7


# 查看当前同步速度限制
cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_max

# 临时调整（重启后失效）
echo 50000 > /proc/sys/dev/raid/speed_limit_min
echo 200000 > /proc/sys/dev/raid/speed_limit_max

单位是KB/s。速度太快会影响系统性能，太慢则同步时间过长。

永久设置

编辑 /etc/sysctl.conf：

1
2


dev.raid.speed_limit_min = 50000
dev.raid.speed_limit_max = 200000

然后执行 sysctl -p 使配置生效。

常见问题与解决方案

问题1：安装时找不到硬盘

现象：installimage 提示没有可用的硬盘

原因：

硬盘没有正确连接
硬盘型号不兼容
RAID控制器驱动问题

解决方案：

在Rescue系统中执行 lsblk 查看是否能识别硬盘
如果能识别但installimage看不到，尝试手动指定硬盘
联系Hetzner支持检查硬件问题

问题2：RAID同步速度太慢

现象：RAID重建需要数十小时

解决方案：

调整同步速度限制（见上文RAID性能优化）
检查硬盘性能（使用 hdparm -t /dev/sda 测试）
确保没有其他高IO操作在进行

问题3：系统重启后RAID降级

现象：/proc/mdstat 显示 [2/1] [U_]，有一块盘掉线

可能原因：

硬盘连接松动
硬盘固件问题
主板SATA控制器问题

解决方案：

检查 dmesg 和 /var/log/syslog 查找错误信息
如果是临时问题，可以重新添加硬盘到阵列
如果频繁发生，需要更换硬盘或联系Hetzner

问题4：想修改分区大小

场景：安装时root分区设置太小，想扩容

解决方案（使用LVM的情况）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 缩小home分区（假设要缩小10G）
umount /home
e2fsck -f /dev/vg0/home
resize2fs /dev/vg0/home 90G # 假设原来100G
lvreduce -L 90G /dev/vg0/home

# 扩大root分区
lvextend -L +10G /dev/vg0/root
resize2fs /dev/vg0/root

# 重新挂载home
mount /home

这就是LVM的优势，可以灵活调整分区大小。

问题5：系统安装失败

现象：installimage 运行过程中报错

常见原因和解决方案：

网络问题：检查网络连接，重试安装
镜像源问题：更换镜像源或使用其他版本
配置文件错误：仔细检查配置文件语法，特别是RAID和分区配置
硬盘问题：运行 badblocks 检查硬盘是否有坏块

总结

Hetzner的服务器安装流程总体来说比较简单，关键点在于：

RAID配置选择：根据硬盘数量和需求选择合适的RAID级别
- 2块盘：RAID 1
- 3-4块盘：RAID 5 或 RAID 10
- 更多盘：RAID 6 或 RAID 10
分区方案设计：推荐使用LVM，方便后期调整
- /boot：1GB，独立分区
- 其余空间：使用LVM，分为root、swap、home

定期监控：安装后要定期检查RAID状态和硬盘健康度

1
2
3


# 建议加入crontab定期检查
cat /proc/mdstat
smartctl -a /dev/sda

备份策略：即使有RAID，也不能完全依赖，重要数据务必异地备份

完成安装后，你就拥有了一个高可用的独立服务器环境。接下来可以进行系统初始化配置、安全加固、应用部署等工作。

写在最后

独立服务器相比VPS有更强的性能和灵活性，但也需要更多的维护工作。建议：

监控告警：配置监控系统，硬盘故障时能及时收到通知
定期检查：每月检查一次RAID和硬盘状态
文档记录：记录服务器的配置信息，包括RAID配置、分区方案等
应急预案：提前了解硬盘更换流程，避免故障时手忙脚乱

祝你的服务器运行稳定！

nextnewep - 我做的智能追剧聚合平台

Sat, 11 Oct 2025 00:00:00 +0000

为什么做这个项目

作为一个追剧爱好者，我发现追剧这件事其实挺折腾的：

资源分散：想看的剧集资源散落在互联网各处，需要到处搜索
信息不全：很多时候只有资源链接，但缺少剧集详细信息，季数集数容易混淆
更新不及时：不知道追的剧是否已经更新，需要反复去各个地方查看
管理混乱：看了很多剧，但没有统一的地方来管理和记录

作为一个技术人，我决定自己动手解决这些问题，于是开发了 nextnewep —— 一个智能剧集聚合平台。

核心功能

智能搜索

平台集成了 TMDB（The Movie Database）专业剧集数据库，提供：

中英文搜索：无论是中文剧名还是英文原名都能准确搜索
精准匹配：自动识别剧集、季数、集数信息
即时响应：搜索结果实时展示，无需等待

资源聚合

这是平台的核心功能之一：

自动采集：系统自动从互联网多个渠道聚合资源链接
智能去重：相同的资源自动合并，避免重复
实时更新：每天自动同步最新资源，追剧不漏集
多版本支持：同一集可能有多个来源和清晰度版本

详细的剧集信息

不只是提供资源链接，更提供完整的剧集信息：

剧情简介：了解剧集的故事背景和主题
演员阵容：查看主要演员和角色信息
评分数据：参考 TMDB 的专业评分和用户评价
季集列表：清晰展示所有季和集的完整列表
海报和剧照：高清的官方宣传图片

现代化的使用体验

响应式设计：无论是在 PC 还是手机浏览器，都能流畅访问
快速加载：优化的性能，搜索和页面加载都很迅速
简洁界面：去繁就简的设计，专注于核心功能

使用场景

场景一：想追某部热门新剧

假设你想追最近很火的某部美剧：

在搜索框输入剧名（中文或英文都可以）
点击搜索结果进入剧集详情页
查看剧情简介和评分，确认是自己想看的
在季集列表中找到最新一集
点击资源链接开始观看

整个过程不到 30 秒，比到处找资源方便多了。

场景二：发现新剧

不知道看什么的时候：

浏览首页的热门剧集
通过评分和简介快速了解剧集内容
找到感兴趣的剧集查看详情
发现新的追剧目标

场景三：查找特定集数

已经在追某部剧，想找特定的某一集：

搜索剧名进入详情页
在清晰的季集列表中快速定位
点击对应集数的资源链接
继续追剧之旅

项目现状

目前平台已经稳定运行，数据规模：

收录剧集：1000+ 部热门剧集
资源链接：1000+ 条资源
剧集类型：覆盖欧美、日韩、国产等多类剧集
更新频率：每天自动同步最新资源

系统采用自动化流程，持续不断地：

采集最新的剧集资源
更新剧集的详细信息
优化搜索和匹配算法

技术特点

虽然不想讲太多技术细节，但还是简单介绍一下：

后端：使用 Go 语言开发，保证高性能和稳定性
前端：基于 Vue 3 + Nuxt 3，提供流畅的用户体验
数据库：PostgreSQL + Redis 组合，兼顾数据可靠性和访问速度
自动化：Python 爬虫系统，24/7 自动采集更新

所有服务都运行在我自己的服务器上，数据自主可控。

后续计划

平台还在持续优化和迭代中，计划中的功能：

🔔 剧集更新通知：订阅喜欢的剧集，有更新时及时收到通知
📝 个人追剧清单：记录想看和正在看的剧集，管理追剧进度
🎯 智能推荐：基于观看历史，推荐可能感兴趣的剧集
📊 数据统计：查看自己的追剧数据和观看习惯

体验地址

平台已经上线，欢迎访问体验：

网站地址：https://www.nextnewep.com

如果你也是追剧爱好者，或者对这个项目有任何建议和想法，欢迎通过以下方式联系我：

博客评论
邮件：contact@nextnewep.com

希望这个平台能让追剧变得更简单、更愉快！

本文介绍的 nextnewep 项目完全由个人开发和运营，所有资源链接均来源于互联网公开内容。

搭建quark-auto-save自动追更以及自动生成strm

Sat, 13 Sep 2025 16:00:00 +0800

在上篇文章中介绍了使用cloud saver搭配smartstrm进行转存网盘分享以及自动生成strm文件，这种方式适合对电影内容的处理，想看哪个就直接转存，但是对于剧集，通常情况下持续更新的，每天或者每周更新n集，那有没有一种方式可以对这种要追更的剧集在有更新的时候自动进行保存呢？答案是有的，接下来就要介绍我们今天的主角：quark-auto-save。他可以对长期分享的url进行定时检测，对比差异进行增量同步，然后再生成strm文件，满足我们追剧的需求。

网络准备(非必须)

这里使用的是飞牛Nas进行的安装，飞牛所有安装的容器我都是使用的自建的桥接网络，当然也可以使用默认的桥接网络。如果你对docker比较熟悉可以跳过准备阶段。先建自己专用的docker桥接网络。

飞牛

在飞牛Nas中，打开docker就可以看到左侧菜单的网络，可以看到当前已有四个网络，其中mynet就是新建的网络，默认只有三个网络。

点击右上角的新增网络进行新建，mynet的具体配置如下：

网络名称自己定义，子网我这里定义为111段，这个111可以自己进行修改，不要和自己家里的路由器网段重复就行了。

安装

这里还是直接提供我的docker-compose.yaml文件，如果没有新建自己的桥接网络，需要去掉网络部分(两个networks部分)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


networks:
 mynet:
 external: true
services:
 quark-auto-save:
 image: cp0204/quark-auto-save:latest
 container_name: quark-auto-save
 ports:
 - 5005:5005
 restart: unless-stopped
 environment:
 - WEBUI_USERNAME=admin
 - WEBUI_PASSWORD=admin123
 volumes:
 - ./data/config:/app/config
 - ./data/media:/media
 networks:
 - mynet
 logging:
 options:
 max-size: "10m"
 max-file: "2"

挂载了两个目录出来，同时放出我的目录结构：

接下来就可以创建容器了，在compose菜单下点击右上角的新增项目进行添加。项目名称就命名为quark-auto-save

配置

cookie配置

登录quark-auto-save项目，来到系统配置这里，最主要的就是cookie的配置，配置好cookies后，项目就可以直接访问quark网盘里的内容了。

定时规则

定时规则是指什么时候去执行任务列表中的任务，可以根据自己的需要来定制这个时间，一般腾讯和bilibili动漫都是上午10点或者晚上19点后进行更新的，所以我这里在上午10点和11点，下午7点和8点每10分钟进行一次执行，保准能够较快的抓取到内容进行转存。

通知

通知需要在启动的时候配置环境变量，我这里暂时没有进行配置。后续根据需求再进行配置。具体的参数配置可以参考官方wiki给的参数。

插件

插件也支持了不少，这里先只使用smartstrm。我们的需求就是在自动保存后需要生成strm文件，那么就需要在转存成功后通过webhook来通知smartstrm。

在文章：cloud-saver搭配smartStrm转存分享并生成strm文件中，已经初步介绍了如何配置webhook来通知smartstrm,这里的配置基本是一样的：

Webhook:就是smartstrm的webhook地址

自定义字段strmtask: 这个字段是指通知smartstrm中配置的哪个任务去执行，名称为smarstrm中配置的任务名称，根据自己的实际配置来修改值。

其他字段应该quark-auto-save内部都进行默认值封装，所以不需要进行配置。

资源搜索

资源搜索可以配置cloud saver和pansou,上篇文章中已经配置了cloud saver，所以这里我只填写cloud saver. 这个的功能是在等下配置任务的时候不需要我们自己去找资源url，可以直接输入名字，他会自己去通过cloud saver或pansou去获取所有的分享资源，可以点选进行使用，这个等下再细说。

任务列表

任务配置

比如我在追更凡人修仙传，那么我可以在任务名称中输入凡人修仙传，默认会自动进行搜索，如果没有自动搜索也可以点击后边的搜索按钮进行强制搜索，这里的搜索就是到我们在上边字段搜索配置中配置的cloud saver中去进行搜索进行返回。

除了让他自动搜索，你也可以自己去找分享url填入。完整的信息如下：

保存路径：这个是指保存在quark网盘中的路径。

保存规则：我这里默认选择TV_MAGIC, 后边的忽略后缀按官方的介绍适用于你同时对凡人修仙传配置了多个不同的分享链接，那么哪个快就转存哪个，当另一个分享链接更新后，因为已经存储过一个了，就不会进行再次保存。

更新目录：这个是指在子目录有更新的情况下使用，可以参考官方介绍。

截止日期：有明确更完日期的，可以设置一下，到那个日期后这个任务就不会再执行了。

运行星期：这个非常有用，比如我追的动漫都是周更，那么只需要在某天进行抓取就行了，不用每天进行抓取，浪费资源。

其他默认就行了。点击下边的保存，对任务进行报错。

任务执行

默认情况下，会优先按定时规则处的配置，去运行来检测是否有任务满足执行条件，比如我配置的是每天10点开始每10分钟执行一次，那么当周一的时候，10点执行凡人修仙传的时候发现它只需要每周六执行，那就不会真的执行任务，而是跳过。当到周六10点的时候，才会真的去检测分享url是否有更新，有更新进行转存。

遇到的坑

目录问题

在我实际操作中有一个目录的坑需要注意一下，正常情况下按我的配置所有的文件应该保存到/video/tv/凡人修仙传这个目录下。但对于https://pan.quark.cn/s/9a441ae30462#/list/share这个分享，默认还有一层目录F跑路我第一：

那么在实际保存后，文件是保存在/video/tv/凡人修仙传/F跑路我第一下的,多了一级目录所以需要点后边的文件按钮来进如下级目录：

所以你们看到的分享连接实际上是：https://pan.quark.cn/s/9a441ae30462#/list/share/ddc87495b1624b22bea9682ff6f95d75。

cloud-saver搭配smartStrm转存分享并生成strm文件

Sat, 13 Sep 2025 10:00:00 +0800

今天我们开启一个新的旅程，讲一下纯网盘的情况下，如何进行转存分享视频并生成strm文件进行愉快的观影。本文主要使用到cloud-saver和smartStrm两个项目，大家也可以去两个项目的仓库进行查看和配置。接下来就进入主题。

网络准备(非必须)

飞牛

在飞牛Nas中，打开docker就可以看到左侧菜单的网络，可以看到当前已有四个网络，其中mynet就是新建的网络，默认只有三个网络。

点击右上角的新增网络进行新建，mynet的具体配置如下：

网络名称自己定义，子网我这里定义为111段，这个111可以自己进行修改，不要和自己家里的路由器网段重复就行了。

smartStrm安装配置

安装

飞牛里可以直接使用docker compose,所以这里直接放出docker-compose.yaml文件，这里定义了登录的账号和密码，登录的时候要使用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


networks:
 mynet:
 external: true
services:
 smartstrm:
 image: cp0204/smartstrm:latest
 container_name: smartstrm
 restart: unless-stopped
 volumes:
 - ./config:/app/config # 挂载配置目录
 - ./logs:/app/logs # 挂载日志目录，可选
 - /vol1/1000/cloudNAS/strm:/strm # 挂载 STRM 生成目录
 ports:
 - 8024:8024
 environment:
 - PORT=8024 # 管理端口，可选
 - ADMIN_USERNAME=admin # 管理用户名
 - ADMIN_PASSWORD=admin123 # 管理用户密码
 - LICENSE= # 许可证字符串（如有）
 networks:
 - mynet
 logging:
 options:
 max-size: "10m"
 max-file: "2"

在smartstrm内部，默认strm文件保存的目录是/strm,这里默认就使用这个目录，后续在网页端也不会进行修改。使用本机的/vol1/1000/cloudNAS/strm目录和容器内的/strm目录进行关联。这里的cloudNAS目录其实就是下图中的cloudNAS。

需要创建config和logs以及strm目录，这里我放出我的目录示意图：

接下来就可以创建容器了，在compose菜单下点击右上角的新增项目进行添加。项目名称就命名为smartstrm

路径选择上边目录图中的smartstrm目录，会提示已包含docker-compose配置文件，点确定下一步就可以了。

经过上边步骤就创建好了容器，在compose菜单中进行启动就行了。然后通过浏览器访问nas的ip+在docker-compose文件中定义的端口(这里定义的是8024)就可以访问smartstrm了

存储配置

登录后先添加存储，这里只添加一个夸克，填如cookies就可以了。

添加后如下图

任务配置

添加了存储后，我们要配置对网盘下的哪些目录进行strm文件生成，这时就需要对任务进行配置。

任务名称自定义，生成的strm文件是放在/strm/任务名称下的。

使用存储就选择刚添加的夸克网盘

扫描路径填的是夸克网盘的文件名称,我的夸克网盘目录如下，我所有的电影都放在video下，所以我这里填的是video.

执行时间默认就行了，正常情况下我们也不会等他到固定的时间才生成strm,等下我们会配置cloud saver在保存的时候，就通知smartstrm立即进行strm文件生成。

系统设置

strm设置

strm设置默认是不用修改的，smartstrm地址是会写进生成的strm文件的，如果你想要在公网进行看剧，这里需要改成公网访问你smartstrm的地址。我只会在本地内网观看，所以这里我不需要进行修改。

webhook设置

webhook设置其实我们什么也不用动，只需要记住这个webhook地址就行了。等下在cloud saver那边会进行配置，在cloud saver转存文件后通过通知这个webhook,让smartstrm立即生成strm文件。

smartstrm的配置大概就讲这么多，核心步骤就是：

添加存储
创建生成strm任务，多个目录就创建多个任务

Cloud saver安装配置

安装

飞牛里可以直接使用docker compose,所以这里直接放出docker-compose.yaml文件，如果没有新建自己的桥接网络，需要去掉网络部分(两个networks部分)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


networks:
 mynet:
 external: true
services:
 cloudsaver:
 image: jiangrui1994/cloudsaver:latest
 container_name: cloud-saver
 restart: unless-stopped
 ports:
 - 8008:8008
 volumes:
 - ./data:/app/data
 - ./config:/app/config
 networks:
 - mynet
 logging:
 options:
 max-size: "10m"
 max-file: "2"

需要创建data和config目录，和docker-compose.yaml文件同级别，参考下边的目录图：

接下来就可以创建容器了，在compose菜单下点击右上角的新增项目进行添加。项目名称就命名为cloud-saver

路径选择上边目录图中的cloud-saver目录，会提示已包含docker-compose配置文件，点确定下一步就可以了。

经过上边步骤就创建好了容器，在compose菜单中进行启动就行了。然后通过浏览器访问nas的ip+在docker-compose文件中定义的端口(这里定义的是8008)就可以访问cloud-saver了。这里有两个注意事项：

资源搜索需要配置代理环境，接下来会讲到。
默认注册码，首次打开是需要注册的，记住这个。
- 管理员：230713
- 普通用户：9527

项目配置

打开登录页面(nas的ip:8008)，首次需要先注册，注册码就使用上边的230713,因为是管理员，注册完后进行登录。

如果这个地址是放在公网的，登录后对注册码进行修改，防止别人进行注册使用。

可以看到这里还有一个代理设置，如果项目我们部署在自己本地的电脑，那么正常情况下是无法访问telegram的，就需要我们配置代理来进行访问了，这个代理如果有软路由，软路由里可以开启，或者电脑开着v2rayN也会有代理开启，可以使用这两个方案里的任何一个。

如果服务我们是部署在海外的服务器的，那么这个代理就可以不用配置了，默认海外的服务器是肯定可以访问telegram的。

网盘配置

在用户配置页面，可以配置115,夸克,123以及天翼云盘的信息，配置完这个就可以在资源搜索页面对某个资源直接保存进网盘中。根据自己的需要进行配置。

搜索频道配置

在搜索频道配置中配置我们需要搜索的TG频道id，官方有一个完整的配置文件,密码:me16，在第12章，可以直接复制并导入，也可以自己手动添加想要的。

只后就可以在资源进行搜索或者在豆瓣榜单中找到自己想看的电影然后点击搜索来找到资源。

转存配置

这里就需要配置cloud saver转存后，要通知smartstrm进行生成strm文件，这里新建一个自定义推送，名字叫cloud saver,内容配置如下：

接口地址就是上边smartstrm的webhook地址

请求类型和请求格式照图片来就行了。

触发延迟时间顾名思义就是转存后多久再来触发这个webhook请求，我这里设置3s。

自定义字段event: 这个固定cs_strm

自定义字段strmtask: 这个字段是指通知smartstrm中配置的哪个任务去执行，名称为smarstrm中配置的任务名称，根据自己的实际配置来修改值。

自定义字段savepath: 保存的路径，方便smartstrm进行精准刷新。

其他的信息也可以参考官方进行配置。

转存

接下来就可以去转存了，在搜索界面搜索到想要的电影，点击转存，然后点击下一步

先选择要在夸克网盘中保存的位置，然后鼠标移动到保存后执行推送按钮上，选择cloud saver，这时候就会执行转存动作，转存成功后隔3s(上边配置的时间)通知smartstrm进行strm文件生成。

经过上边的配置就可以快速的保存电影进自己的网盘，然后再通知smartstrm进行生成strm文件。剩下的就是使用strm进行观影了。咱们后边再讲。今天的教程就先到这里。祝大家都能配置成功。

iKuai配置公网IPv6并为特定设备开启IPv6地址

Sun, 03 Aug 2025 00:00:00 +0000

IPv6是什么

IPv6是下一代互联网协议，用于替代当前广泛使用的IPv4，主要目的是解决IPv4地址枯竭问题，并提供更高效、更安全的网络通信。相比IPv4它的可用地址更多，几乎可以满足未来所有设备的需求（包括物联网IoT设备）。

现在申请的家庭宽带IPv4基本已经很难要到，但是IPv6还是可以拿到的，但是拿到IPv6后如何使用就是一个大问题了，这篇文章就来介绍一下我是如何使用家庭宽带的IPv6地址来访问家庭网络以及一些其他的用途。我不会给所有的设备开启IPv6，而是给特定的设备开启，基于此，来折腾在ikuai上配置IPv6地址。

有状态OR无状态

什么是有状态和无状态呢？主要区别在于是否依赖服务器分配地址及相关信息（如DNS），下边介绍一下两者的区别：

IPv6的无状态（stateless）地址自动配置（SLAAC）和有状态（stateful）地址配置（通常通过DHCPv6实现）是两种不同的IPv6地址分配机制。下面是这两种配置之间的一些主要区别：

无状态地址自动配置（Stateless）：在这种配置下，设备通过监听网络上的路由器广播来自动获取IPv6地址。路由器会广播网络的前缀信息，然后设备使用这个前缀和它的MAC地址（或其他唯一标识符）来生成一个唯一的IPv6地址。这个过程不需要一个中心化的地址分配服务器，所以被称为无状态。
有状态地址配置（Stateful）：在这种配置下，设备从一个中心化的DHCP服务器获取IPv6地址。DHCP服务器保持一个地址池，并跟踪哪些地址已经分配给了哪些设备。这允许网络管理员更精细地控制地址分配，并可以提供更多的配置选项，比如DNS服务器的地址等。

这两种配置可以独立使用，也可以混合使用。例如，一个设备可以使用SLAAC来获取IPv6地址，然后使用DHCPv6来获取其他的配置信息。这种模式被称为”无状态DHCPv6”。

如果DHCPv6模式被设置为”无状态+有状态“（iKuai的默认IPV6的默认设置），这意味着你的网络同时支持SLAAC和DHCPv6。设备可以选择使用SLAAC自动生成一个IPv6地址，也可以从DHCP服务器获取一个IPv6地址。

因为我是采用DHCPv6白名单的方式给设备分配IPv6，所以我这里只能采用有状态地址配置(即主动分配模式),在配置了DHCPv6白名单后，SLAAC自动失效。

IPv6配置

外网IPv6配置

首先开启外网IPv6地址分配，如下图，在网络设置-IPv6-IPv6设置的外网配置中进行添加：

点击添加，进行IPv6配置

配置保存后就可以看到获取到实际的ipv6地址了。

经过上边步骤已配置好公网IPv6地址获取，可以看到也获取到了240开头的地址。

内网IPv6配置

然后进行内网设置，绑定线路为宽带的端口，一般为wan1，DHCPv6模式配置为有状态。

这时候看看DHCPv6终端就可以看到有不少设备已经获取到了IPv6地址了

白名单分配IPv6

根据我的使用场景，我不想所有设备都获取IPv6，只想特殊的设备获取，这时候就开启IPv6白名单

通过添加按钮，指定设备的mac地址就可以了。我这里对NAS进行白名单添加，然后在nas中就可以看到分配的公网IPv6地址了。

这样子就可以给特定的设备开启IPv6。因为我是给特定设备开启而且这个设备也需要从公网来访问，所以也不用太担心内网设备暴露，因此也不用再配置ACL规则来进行防护。如果你只想让想让设备使用IPv6出，而不希望有人可以使用IPv6访问进来，那就可以通过ACL规则来进行阻断。

ACL配置

需要对IPv6进入的流量进行阻断，放行IPv6出栈的流量，调整好进接口和出接口，按我这里添加就可以了。我这里把进接口的流量控制暂停了，允许外界通过IPv6进行访问。你也可以允许特定的设备进行入栈，需要根据ACL规则来进行配置，这里就不在展开了。

经过上边步骤，就完成了iKuai的IPv6配置，以及给特定的设备来分配IPv6.

Hugo文章引用完整指南

Sat, 05 Jul 2025 00:00:00 +0000

Hugo文章引用完整指南

在Hugo中，文章之间的相互引用是提高用户体验和SEO的重要功能。本文将详细介绍各种文章引用方法。

1. 基础引用方法

1.1 使用 `ref` shortcode（推荐）

ref shortcode 是Hugo内置的引用功能，会生成绝对链接：

1

{{< ref "/post/path/to/article.md" >}}

优点：

自动生成正确的链接
构建时会检查链接有效性
支持多语言
支持锚点引用

示例：

1

查看这篇文章：[WordPress使用git-it-write插件](/post/wordpress/wordpress使用git-it-write插件配合github自动发布markdown/)

1.2 使用 `relref` shortcode

relref 生成相对链接，适合站点迁移：

1

{{< relref "/post/path/to/article.md" >}}

1.3 直接使用 Markdown 链接

1

[文章标题](/post/article-slug/)

2. 高级引用技巧

2.1 引用特定章节

可以引用文章中的特定章节：

1

{{< ref "/post/article.md#section-title" >}}

2.2 引用文章并显示链接文本

1

[显示的文本]({{< ref "/post/article.md" >}})

2.3 在链接中使用变量

1

{{< ref "/post/article.md" >}}

2.4 直接 URL、`ref` 与 `post-ref` 怎么选

本仓库当前三种写法都存在，但适用场景并不一样：

直接写 URL

1

[AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比](/ai/ai-cli-tools-comparison/)

适合场景：

系列总览页、导航页
已经显式设置 url，且路径长期稳定的文章
希望源码一眼就能看懂最终跳转地址的场景

特点：

优点是直观、简洁
缺点是目标文章如果改了 url，这里不会自动跟着改

使用 `ref`

1

[相关文章]({{< ref "/post/nas/video/视频资源术语完全指南.md" >}})

适合场景：

正文里的自然文本互链
希望链接跟随目标文章 url 或 slug 自动变化
需要 Hugo 在构建阶段帮助检查链接有效性的场景

特点：

优点是绑定内容文件，不直接绑定发布 URL
缺点是源码可读性不如直接 URL，目标文件移动后要同步改路径

使用 `post-ref`

1

{{< post-ref "post/nas/video/视频资源术语完全指南.md" >}}

适合场景：

某段正文后面插入“扩展阅读”
希望展示标题、摘要、日期、分类的引用卡片
一篇文章里少量、重点地推荐相关文章

特点：

本质上也是先按内容路径找到页面，再输出当前真实链接
更适合重点推荐，不适合在正文中高频重复插入

当前仓库的建议

如果只是正文里顺手提一句相关文章，优先用 ref。

如果是想在段落后面显式推荐一篇扩展阅读，优先用 post-ref。

如果是系列总览、专题导航，且目标文章 URL 结构已经稳定，直接写 URL 也完全可以。

3. 自定义引用卡片

我们还可以创建自定义的引用卡片来美化文章引用：

3.1 创建 shortcode

创建 layouts/shortcodes/post-ref.html：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{{- $ref := .Get 0 -}}
{{- $page := .Site.GetPage $ref -}}
{{- if $page -}}
<div class="post-reference-card">
 <a href="{{ $page.RelPermalink }}" class="post-ref-link">
 <div class="post-ref-content">
 <h3 class="post-ref-title">{{ $page.Title }}</h3>
 <p class="post-ref-summary">{{ $page.Summary | truncate 150 }}</p>
 <div class="post-ref-meta">
 <span class="post-ref-date">{{ $page.Date.Format "2006-01-02" }}</span>
 {{- if $page.Params.categories -}}
 <span class="post-ref-category">{{ delimit $page.Params.categories ", " }}</span>
 {{- end -}}
 </div>
 </div>
 </a>
</div>
{{- end -}}

3.2 使用自定义引用卡片

1

{{< post-ref "post/wordpress/WordPress使用git-it-write插件配合github自动发布markdown.md" >}}

4. 相关文章功能

Hugo Stack 主题已经内置了相关文章功能，会自动在文章末尾显示相关文章：

4.1 配置相关文章

在 hugo.yaml 中配置：

1
2
3
4
5
6
7
8
9


related:
 includeNewer: true
 threshold: 60
 toLower: false
 indices:
 - name: tags
 weight: 100
 - name: categories
 weight: 200

4.2 在文章中手动指定相关文章

在Front Matter中添加：

1
2
3


related:
 - "/post/article-1.md"
 - "/post/article-2.md"

5. 最佳实践

5.1 文件组织

建议按分类组织文章：

1
2
3
4
5
6
7
8


content/post/
├── hugo/
│ ├── hugo基础教程.md
│ └── hugo高级技巧.md
├── wordpress/
│ └── wordpress插件推荐.md
└── tools/
 └── 开发工具推荐.md

5.2 引用规范

使用内容路径：post-ref 传入相对于 content/ 的文章路径，例如 post/nas/video/视频资源术语完全指南.md
检查链接有效性：构建时会自动检查 ref 和 relref 的有效性
统一命名规范：使用一致的文件命名规范
添加描述性文本：不要直接暴露链接，添加有意义的描述

5.3 性能优化

使用缓存：Hugo会缓存引用结果
避免循环引用：不要创建文章间的循环引用
批量引用：在一篇文章中引用多个相关文章

6. 常见问题

6.1 引用失败

错误信息：

1

ERROR REF_NOT_FOUND: Ref "article.md": page not found

解决方法：

检查文件路径是否正确
确认文件是否存在
post-ref 使用 post/... 这种内容路径，确认目标文件真实存在

6.2 中文文件名问题

对于中文文件名，Hugo会自动处理，但建议在链接中使用英文slug：

1
2
3


# Front Matter
title: "中文标题"
slug: "english-slug"

6.3 多语言支持

如果使用多语言，引用时需要指定语言：

1

{{< ref "/post/article.zh-cn.md" >}}

总结

Hugo提供了多种文章引用方式，选择合适的方法可以提高用户体验和维护效率：

日常引用：使用 ref shortcode
美观展示：使用自定义引用卡片
自动推荐：配置相关文章功能
性能优化：遵循最佳实践

通过合理使用这些引用功能，可以构建一个互联互通的知识体系，提高读者的阅读体验。

WordPress使用git-it-write插件配合github自动发布markdown

WordPress安装git-it-write插件连接GitHub仓库，实现Markdown文件自动同步发布，打造基于Git的WordPress内容管理工作流，程序员友好的博客发布方案。

2025-04-06wordpress

Typora使用picgo-core配置上传图片到easyimage图床

Typora编辑器集成PicGo-Core自动上传图片到EasyImage图床，配置图床API和上传规则，实现Markdown写作图片自动上传和管理的高效方案。

2025-04-05tools

Hugo文章SEO配置完整指南

Fri, 04 Jul 2025 00:00:00 +0000

Hugo文章SEO配置完整指南

在Hugo中，正确配置SEO元数据对提高搜索引擎收录和排名至关重要。本文将详细介绍如何配置文章的各种SEO字段。

📋 Front Matter中的SEO字段

1. description 字段（重要）

description 字段是SEO中最重要的元数据之一：

1
2
3
4


---
title: "文章标题"
description: "这是一段精心编写的文章描述，长度控制在150-160字符内，准确概括文章内容，包含关键词。"
---

最佳实践：

长度：150-160字符（中文约75-80字）
包含主要关键词
准确描述文章内容
吸引用户点击

2. excerpt 字段

excerpt 用于文章摘要显示：

1

excerpt: "文章摘要内容，用于在文章列表中显示。"

3. keywords 字段

1

keywords: ["关键词1", "关键词2", "关键词3"]

🔍 Hugo的Description生成逻辑

Hugo按以下优先级生成meta description：

Front Matter中的 description（最高优先级）
自动生成的 .Summary（从文章内容提取）
站点默认描述

查看生成逻辑的模板代码：

1
2
3
4
5
6
7
8


<!-- themes/hugo-theme-stack/layouts/partials/data/description.html -->
{{ if .Description }}
 <!-- 使用Front Matter中的description -->
 {{ $description = .Description }}
{{ else if .IsPage }}
 <!-- 使用文章摘要 -->
 {{ $description = .Summary }}
{{ end }}

🎯 SEO优化的正确配置

示例1：使用自定义description

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


---
title: "Docker安装WordPress完整教程"
description: "详细介绍使用Docker快速安装WordPress的步骤，包括环境配置、容器部署、数据库设置等实用技巧。"
keywords: ["Docker", "WordPress", "安装教程", "容器部署"]
categories:
 - 教程
tags:
 - docker
 - wordpress
 - 部署
---

示例2：依赖自动摘要

1
2
3
4
5
6
7
8


---
title: "Hugo主题开发指南"
# 没有description字段，Hugo会自动提取文章开头作为摘要
categories:
 - 开发
---

Hugo是一个强大的静态网站生成器，支持多种主题定制。本文将详细介绍如何开发自定义Hugo主题，包括模板结构、样式配置等内容。

📊 验证SEO效果

1. 查看生成的HTML

1
2
3
4
5


# 构建站点
hugo --cleanDestinationDir

# 查看meta标签
grep -E "(meta.*description|og:description)" public/path/to/article/index.html

2. 使用SEO工具

Google Search Console
百度站长工具
SEO检测工具

🚀 高级SEO配置

1. 结构化数据

1
2
3
4
5
6
7


---
schema:
 type: "Article"
 author: "作者名称"
 datePublished: "2025-01-07"
 dateModified: "2025-01-07"
---

2. Open Graph配置

1
2
3
4
5
6


---
og:
 title: "自定义OG标题"
 description: "自定义OG描述"
 image: "featured-image.jpg"
---

3. Twitter Cards

1
2
3
4
5
6
7


---
twitter:
 card: "summary_large_image"
 title: "Twitter卡片标题"
 description: "Twitter卡片描述"
 image: "twitter-image.jpg"
---

📝 最佳实践总结

1. Description写作技巧

关键词前置：重要关键词放在前面
动作导向：使用动词，如"了解"、“学习”、“掌握”
解决问题：明确说明文章能解决什么问题
避免重复：不要与title完全重复

2. 常见错误

❌ 错误示例：

1
2
3


description: "这篇文章很好，大家快来看看。" # 太模糊
description: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" # 太长
description: "" # 空描述

✅ 正确示例：

1

description: "详细介绍Hugo静态网站生成器的安装配置方法，包括主题选择、内容管理、部署流程等实用技巧。"

3. 工具推荐

字符计数器：确保描述长度合适
关键词工具：Google Keyword Planner
SEO检测：Screaming Frog SEO Spider

🔧 实际应用示例

让我们看看一个完整的文章配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


---
title: "Linux服务器安全配置指南"
description: "Linux服务器安全配置的完整教程，包括防火墙设置、SSH加固、用户权限管理等安全防护措施，保护服务器免受攻击。"
excerpt: "系统化介绍Linux服务器的安全配置方法和最佳实践。"
keywords: ["Linux", "服务器安全", "防火墙", "SSH配置", "安全防护"]
date: 2025-01-07
lastmod: 2025-01-07
categories:
 - 运维
 - 安全
tags:
 - linux
 - 安全
 - 服务器
 - 运维
author: "技术博主"
---

📈 SEO效果监控

1. 搜索表现

点击率（CTR）
展现次数
平均排名
关键词覆盖

2. 优化建议

定期更新description
分析搜索查询
优化关键词
监控竞争对手

通过正确配置这些SEO字段，您的Hugo博客将在搜索引擎中获得更好的表现！

WordPress使用git-it-write插件配合github自动发布markdown

Sun, 06 Apr 2025 09:20:36 +0000

以前发布文章都是直接在wordpress后台手动编辑，手动上传文件，确认无误后再发布，整个过程比较耗时，并且有点麻烦。最近这两天忽然有一个想法：我直接写markdown然后，然后在wordpress中找支持markdown的编辑器插件，把我的内容直接粘贴进去，这样子不就方便很多了吗？于是就找到了WP-Githuber-MD这个插件，再探索的过程中无意又发现了git-it-write这个可以自动化的插件，于是就开始了折腾之旅行。

插件安装和配置

Git-it-write插件在Wordpress的插件库是可以找到的，直接搜索安装就可以了。安装后可以在设置中找到对这个插件的配置。

仓库配置

想要配合github进行自动发布，首先要解决的就是从仓库里拉去到.md的文件，所以需要去配置一个git仓库，我们可以先创建好这个git仓库，然后再来进行配置。

点击左上的add a new repository to publish posts form按钮来添加一个新的仓库：

有几个地方需要设置一下：

配置项	说明
Github username/owner	这个自己的github用户名
Repository name	仓库名称，新建或者已存在的一个仓库名称
Branch to publish from	仓库的分支，根据自己的仓库来设置，master, main等
Folder to publish from	我整个仓库都是需要发布的，而不是只发布其中一个目录，所以这里留空。
Post type to publish to	我要发布的是文章，自己根据自己的需求来选择。

其他的选项就默认了。

因为我这里建的是一个私有的仓库，想要拉取到仓库里的内容，我这里需要配置一下github access token,填在General settings的位置。如果是public类型的仓库，可以尝试一下不配置或者也配置一下，因为我不是这种情况，所以没有进行详细的研究。下边就来看一下如何获取github access token.

获取github access token

来到github的settings页面：登录github后，点击右上角的头像，就会看到有settings选项。进入settings后，拉到最下边找到developer settings选项，如下图：

点击在personal access tokens中进行添加和删除等操作：

点击右上角的Generate new token来新建一个token，设置页面如下：

发布

在我们写完markdown文件后，push到上边配置的git仓库中，下边就可以来进行发布操作了。

在wordpress插件git it write插件中添加仓库后，可以看到如上图所示的内容，我们可以点击pull posts中git仓库中拉取markdown文件进行发布。点击后有两个选项，一个是只pull更新，另一个是pull所有文件。如果是第一次拉取仓库内容，就使用pull all the files拉取左右的内容，后续就可以使用pull only changes只拉取变更的内容。

如果拉取有问题，也可以点击上边图片中的Logs来查看插件的日志来方便排查问题。截止到上边就已经差不多完成插件配置了。那么此时就需要我们每写完一篇文章就需要到wordpress的后台来进行手动pull一下，是不是也有点麻烦呢？接下来就讲一下如果来自动化发布。

Webbook 配置

在git it write的配置页面可以看到webhook secret的配置选项，没错，这个就是和github的webhook进行联动的，需要我们在github中进行相关的配置。

在github仓库的设置页面，我们可以进行webbook的配置，可以添加一个webhook,具体的webhook地址可以看git it write插件页面给的提示，那里会详细说明完整的webhook地址是什么。如下图是我的完整webhook地址，当时只有地址还是不行的，我们需要配置一个密钥，这个就自己根据自己的情况来进行配置，防止被别人猜到。

github中添加webhook如下，需要填写url，content type以及secret，这里的secret和git it write中的是同一个。另外需要什么时候来触发这个webhook,我这里选择Just the push event.其他的大家根据需求来进行填写。

经过上边的配置，我们在写好markdown文件后，只需要push到git仓库中，那么github就会触发webhook通知到wordpress中的git it write插件，插件就会来仓库中拉取markdown文件，然后进行发布。做到自动化处理发布动作。

Markdown 文件

经过上边的步骤基本已经可以正常的发布文章了，但是这里还有一个重要的问题就是发布后的文章的分类、url以及标签这些信息是怎么处理的？我们要怎么给指定呢？下边就来给大家介绍。

在markdown文件中，每个文件的顶部可以使用yaml来设置一些属性信息，这些属性信息就可以来设置我们发布文章的一些属性信息。设置的格式如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


---
title: "Wordpress使用git-it-write插件配合github自动发布markdown"
date: 2025-04-06
post_excerpt: 以前发布文章都是直接在wordpress后台手动编辑，手动上传文件，确认无误后再发布，整个过程比较耗时，并且有点麻烦。最近这两天忽然有一个想法：我直接写markdown然后，然后在wordpress中找支持markdown的编辑器插件，把我的内容直接粘贴进去，这样子不就方便很多了吗？于是就找到了WP-Githuber-MD这个插件，再探索的过程中无意又发现了git-it-write这个可以自动化的插件，于是就开始了折腾之旅行。
post_status: publish
comment_status: open
taxonomy:
 category:
 - wordpress
 post_tag:
 - wordpress
 - github
 - git-it-write
 - markdown
slug: "wordpress-use-git-it-write-and-github-publish-markdown-file"
---

是以---开始，然后设置一些特殊的属性。我这里介绍一下我上边使用到的一些信息。

属性	说明
Titile	发布文章的标题
date	发布文章的日志
post_excerpt	帖子摘录
Post_status	发布文章的状态，可以选择：publish, draft, pending, future.
Comment_status	评论的状态，这个默认值是closed.所以如果想要打开文章的评论功能，这个值要给open
Taxonmy	这里设置文章的一些属性
Category	Taxonmy 的下级，文章的分类，这个是实际发布文章后的分类
post_tag	Taxonmy 的下级，文章的标签，也是实际发布后文章的标签
slug	暂时也没发现有什么用处，本来以为是文章的自定义url，实际上不是。

我所使用到的就是上边这些属性，其他的属性暂时还没有使用到，如果有兴趣的小伙伴可以自己去看一下官方的文章，自行研究使用方法：Getting started.

另外文章的自定义url是读取的md文件的文件名。

另外，如果github仓库中的文章是有目录的，那么他会发布一个以文件夹命名的文章，暂时没有很好的解决这个问题，他只会发布一次，发布后改后私有的解决问题。

以上就是Wordpress使用git-it-write插件配合github自动发布markdown文章的折腾过程，希望可以帮助到大家。

Typora使用picgo-core配置上传图片到easyimage图床

Sat, 05 Apr 2025 02:38:24 +0000

typora是一个非常方便的markdown编辑器，如果我们不做配置，图片仅仅只是存储在本地磁盘，如果本地磁盘出现问题，那么图片就全没了，所以今天就研究一下搭配picgo-core来把插入的图片上传到图床，我这里使用的是easyimage图床。

picgo可以直接安装官方app，也可以使用node命令去进行配置，我这里为了简单直接使用node的方式去配置，在此之前请确定在本机已正确安装了node的环境。我使用的是mac，且也已配置好brew环境，可以直接使用brew来进行安装。

安装node

搜索可使用的node版本并安装，这里安装18版本。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# aaa @ Mac-mini-m4 in ~ [10:35:56] 
$ brew search nodejs
==> Formulae
node nodenv node@22 node@20 node@18 node@16 node@14

==> Casks
nodeclipse

# aaa @ Mac-mini-m4 in ~ [10:36:04] 
$ brew install node@18
==> node@18
node@18 is keg-only, which means it was not symlinked into /opt/homebrew,
because this is an alternate version of another formula.

If you need to have node@18 first in your PATH, run:
 echo 'export PATH="/opt/homebrew/opt/node@18/bin:$PATH"' >> ~/.zshrc

For compilers to find node@18 you may need to set:
 export LDFLAGS="-L/opt/homebrew/opt/node@18/lib"
 export CPPFLAGS="-I/opt/homebrew/opt/node@18/include"

安装后还需要添加环境变量，通过上面给的命令来执行echo 'export PATH="/opt/homebrew/opt/node@18/bin:$PATH"' >> ~/.zshrc，最后再刷新环境变量

1
2
3
4
5
6


# aaa @ Mac-mini-m4 in ~ [10:38:36] 
$ source .zshrc

# aaa @ Mac-mini-m4 in ~ [10:38:43] 
$ node -v
v18.20.8

最后通过npm来安装picgo:

1
2


# aaa @ Mac-mini-m4 in ~ [10:38:48] 
$ npm install picgo -g

安装情况后可以使用picgo set uploader来设置上传配置，但是默认情况下不支持自定义图床，只能选定他给的几种：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# aaa @ Mac-mini-m4 in ~ [10:39:06] 
$ picgo set uploader
? Choose a(n) uploader
 aliyun
 tcyun
 smms
 github
 qiniu
 imgur
❯ upyun

安装web-uploader

通过easyimage官方的文档来看，应该是有一个插件可以安装来支持自定义图床上传的：使用PicGo上传.md, 插件的名称是web-uploader，那怎么安装呢？通过picgo的命令来查看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# aaa @ Mac-mini-m4 in ~ [10:54:19] 
$ picgo -h
Usage: picgo [options] [command]

Options:
 -v, --version output the version number
 -d, --debug debug mode
 -h, --help display help for command

Commands:
 install|add [options] <plugins...> install picgo plugin
 uninstall|rm <plugins...> uninstall picgo plugin

可以看到可以使用install或add命令来安装。

1
2
3
4
5
6
7


# aaa @ Mac-mini-m4 in ~ [11:10:45] 
$ picgo install web-uploader

added 1 package, and audited 2 packages in 2s

found 0 vulnerabilities
[PicGo SUCCESS]: 插件安装成功

picgo的配置文件所在位置如下：

Linux / macOS → ~/.picgo/config.json.

Windows → C:\Users\[your user name]\.picgo\config.json.

查看里边的目录情况：

1
2
3
4
5
6
7
8
9


# aaa @ Mac-mini-m4 in ~ [11:17:34] 
$ tree .picgo
.picgo
├── config.json
├── i18n-cli
├── node_modules
├── package-lock.json
├── package.json
└── picgo.log

在package里记录了所有的插件信息：

1
2
3


# aaa @ Mac-mini-m4 in ~ [11:11:14] C:1
$ cat .picgo/package.json
{"name":"picgo-plugins","description":"picgo-plugins","repository":"https://github.com/PicGo/PicGo-Core","license":"MIT","dependencies":{"picgo-plugin-web-uploader":"^1.1.1"}}%

配置自定义图床

安装web-uploader后，再次执行set uploader命令查看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# aaa @ Mac-mini-m4 in ~ [11:21:32] 
$ picgo set uploader
? Choose a(n) uploader
 smms
 github
 qiniu
❯ imgur
 upyun
 web-uploader
 aliyun
(Move up and down to reveal more choices)

可以看到多了一个web-uploader选项，下边进行来设置：

1
2
3
4
5
6
7
8


# aaa @ Mac-mini-m4 in ~ [11:21:32] 
$ picgo set uploader
? Choose a(n) uploader web-uploader
? API地址 https://images.xxx.com/api/index.php
? POST参数名 image
? 图片URL JSON路径(eg: data.url) url
? 自定义请求头 标准JSON(eg: {"key":"value"})
? 自定义Body 标准JSON(eg: {"key":"value"}) {"token":"aaaaaa"}

每个参数是什么意义可以参考使用PicGo上传.md,其中api地址是自己网站的地址，post参数和图片URL JSON路径是固定，自定义请求头标准JSON可以置空，自定义body标准JSON则是在easyimage后台获取到的token替换我上边的aaaaaa;

另外需要自己开启支持API上传：

Typora配置

在typora的设置中，选择插入图片时的动作，这里选择上传图片。

主要是上传服务设置，因为我这里没有安装picgo的客户段，而是使用的picgo-core来搭配node使用，所以上传服务选择自定义命令，命令的内容是：

{node位置} {picgo位置} u.

node的位置在安装node的时候就已经知道了，我们还把bin添加进了PATH中，具体位置：/opt/homebrew/opt/node@18/bin/node,那么安装的picgo在什么位置呢？通过以下命令来查看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# aaa @ Mac-mini-m4 in ~/.npm [12:01:34] 
$ npm list --depath=0
/Users/hangkong/.npm
└── (empty)


# aaa @ Mac-mini-m4 in ~/.npm [12:02:54] 
$ npm list --depath=0 --global
/opt/homebrew/lib
└── picgo@1.5.8

可以看到位置在/opt/homebrew/lib目录下，完整的路径为：/opt/homebrew/lib/node_modules/picgo/bin/picgo。

那么设置的完整命令就是：/opt/homebrew/opt/node@18/bin/node /opt/homebrew/lib/node_modules/picgo/bin/picgo u。

经过上边的配置，就可以在使用typora插入图片的时候直接上传的easyimage图床了。

Proxmox VE(PVE)8.0安装飞牛私有云fnOS – NAS

Sun, 09 Feb 2025 03:15:47 +0000

飞牛nas系统出来也有段时间了，一个很不错的nas系统，在以前的文章中也介绍过群晖nas系统的安装，今天就来一次尝鲜，安装一下fnOS，看一下群晖的系统和飞牛的系统有什么区别。接下来就开始安装折腾之路 - 飞牛私有云fnOS nas安装。

PVE配置

首先要先去飞牛官网把官方镜像ISO文件给下载下来，上传到pve中，这个还有不清楚的可以参考Proxmox VE(PVE)8.0安装爱快ikuai虚拟机并直通网卡中对爱快ISO文件上传的步骤。

常规

修改为自己想要的vmid 以及名称，我这里名称填了103，可以修改自己喜欢的，比如飞牛NAS等。其他默认。

[][5]

操作系统

操作系统选择在飞牛官网下载的iso文件。其他的默认

[][6]

系统

机型这里选择q35，其他不变。

[][7]

磁盘

这里没有截图到，实际是和安装群群一样，把磁盘删除了，什么都不留。如果只是想体验则可以根据实际情况来分配硬盘大小。

我这里是要把一个硬盘直通给飞牛的，所以我这里就把硬盘都给删除了。

如果只是用来体验，则可以给一个30G的磁盘。

cpu

cpu核心根据自己的情况来，我的J4125只有4个核心，所以全给了。类别选host。

[][8]

内存配置

内存根据自己的需求来给，建议2G以上，我这里给4G.

[][9]

网络

网络我这里直接默认，使用pve的网桥vmbr0就可以了。

[][10]

确认

都设置完成后对已设置的信息进行确认，基本不会有什么问题，完成。

[][11]

硬盘直通

经过上边设置后，需要再给nas系统一个磁盘，可以参考我在Proxmox VE(PVE)8.0安装黑群晖NAS并直通硬盘时的直通操作，基本是一样的。

硬盘直通后，要看一下启动顺序，需要先从我们上传的iso镜像启动，如果没有问题就可以启动了。

FnOS安装

经过上边的步骤，已经创建好了一个虚拟机。接下来就是对系统进行配置启动了。点击控制台查看启动。默认图形安装。

选择安装位置，本文这里是选择直通的硬盘：

下一步选择系统分区大小,官方默认给的是64G，这里直接按官方建议来：

接下来就是安装了，等待安装成功就可以了。

下一步就会出现重启了，重启后控制台会显示一下内容：

会告诉登录的ip和端口，这里是http://192.168.1.47:5666,等下来浏览器直接输入这个地址来进行访问。

初始化FnOS

系统设置

接下来对fnos进行初始化，访问上边的地址：

初次进入后需要设置设备名称以及管理员信息。

存储空间创建

设置后会进入系统，因为是第一次进入系统，系统会提示创建存储空间：

点击立即创建，选择磁盘以及数据保护默认，我这里直接使用默认basic方式。

下一步设置存储空间可以使用的用户以及可以使用的大小，我这里只有自己使用，容量不限制：

下一步创建确认：

对磁盘进行格式化：

格式化完就创建成功了：

查看创建的存储空间：

FnOS文件系统

上边就已经完全安装好了飞牛NSA，飞牛的磁盘存储位置和群晖还是有一点不一样的，我们可以通过ssh登录进系统进行查看他的磁盘信息。

ssh登录信息为访问网页版的用户名和密码。使用访问网页的ip和22端口+用户名和密码来进行登录。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


aa@FnOS:/$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 394M 7.7M 386M 2% /run
/dev/sda2 63G 9.1G 51G 16% /
tmpfs 2.0G 1.4M 2.0G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
trimafs 1.8T 1.7T 58G 97% /fs
/dev/mapper/trim_f9cc7969_89e3_4c0b_9857_bcec3a1144d7-0 1.8T 1.7T 58G 97% /vol1
tmpfs 394M 0 394M 0% /run/user/1000

可以看到飞牛的系统是放在/目录下的，63G, 而我直通的硬盘有两个目录/fs和/vol1。

```bash aa@FnOS:/fs/1000/ftp$ ls docker download ```

直接使用应用商店安装的qb下载目录可以在qb的设置里看到，实际是在/vol1下。

aa@FnOS:/var/apps/qBittorrent/shares$ ls -alh total 8.0K drwxr-xr-x 2 root root 4.0K Jan 7 23:05 . drwxr-xr-x 6 root root 4.0K Jan 7 23:05 .. lrwxrwxrwx 1 root root 27 Jan 7 23:05 qBittorrent -> /vol1/@appshare/qBittorrent 其他的目录信息大家根据情况再去研究。

qb下载

默认qb只能访问安装后设置里配置的目录，如果想要改变qb下载的目录，则需要去系统设置-应用找到qb，添加一下允许它访问的文件目录。

下边是完整后的桌面预览图

![fnos complete](https://images.iminling.com/i/2025/01/08/3b89be1091025e546acd4224064abb0a.webp)

Hugo评论插件完整配置指南

Tue, 07 Jan 2025 00:00:00 +0000

Hugo评论插件完整配置指南

选择合适的评论系统对博客的互动性至关重要。本文将详细介绍Hugo中常用的评论插件，帮您找到最佳方案。

🔍 支持的评论系统概览

您的hugo-theme-stack主题支持以下12种评论系统：

评论系统	类型	特点	适用场景
Waline	自托管	现代化、功能丰富	🔥 最推荐
Giscus	GitHub	基于Discussions	开发者友好
Utterances	GitHub	基于Issues	轻量、简洁
Cusdis	自托管	隐私友好	注重隐私
Disqus	第三方	功能全面	国际站点
Twikoo	云函数	中文友好	国内博客
Beaudar	GitHub	Utterances中文版	中文用户
Gitalk	GitHub	功能丰富	GitHub用户
Remark42	自托管	无追踪	隐私至上
Vssue	多平台	支持多种Git托管	多平台需求
DisqusJS	第三方	Disqus代理	国内访问
Cactus	Matrix	去中心化	技术极客

🌟 推荐评论系统详解

1. Waline（🔥 强烈推荐）

优势：

✅ 现代化界面，支持暗黑模式
✅ 支持Markdown、LaTeX公式
✅ 丰富的表情包和图片上传
✅ 邮件/微信通知
✅ 访客统计和管理后台
✅ 支持多种部署方式

部署步骤：

一键部署到Vercel：
- 访问 Waline快速开始
- 点击Deploy按钮，使用GitHub账号登录
- 配置数据库（推荐LeanCloud国际版）
配置hugo.yaml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


params:
 comments:
 enabled: true
 provider: waline
 waline:
 serverURL: https://your-waline-server.vercel.app
 lang: zh-CN
 pageview: true
 emoji:
 - https://unpkg.com/@waline/emojis@1.0.1/weibo
 - https://unpkg.com/@waline/emojis@1.0.1/bilibili
 requiredMeta:
 - nick
 - mail
 locale:
 admin: 博主
 placeholder: 欢迎留言交流，支持Markdown语法 😊

2. Giscus（GitHub用户首选）

优势：

✅ 基于GitHub Discussions
✅ 支持反应表情和回复
✅ 完全免费，无广告
✅ 支持多种主题

配置步骤：

设置GitHub仓库：
- 仓库必须是公开的
- 安装 giscus app
- 在仓库中启用Discussions功能
配置hugo.yaml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


params:
 comments:
 enabled: true
 provider: giscus
 giscus:
 repo: username/repo-name
 repoID: R_kgDOxxxxxx
 category: General
 categoryID: DIC_kwDOxxxxxx
 mapping: pathname
 lightTheme: light
 darkTheme: dark
 reactionsEnabled: 1
 emitMetadata: 0

获取配置信息：
- 访问 giscus.app
- 输入仓库信息，获取配置代码

3. Utterances（轻量选择）

优势：

✅ 基于GitHub Issues
✅ 极其轻量，加载快速
✅ 开源，无追踪
✅ 支持GitHub登录

配置示例：

1
2
3
4
5
6
7
8


params:
 comments:
 enabled: true
 provider: utterances
 utterances:
 repo: username/repo-name
 issueTerm: pathname
 label: 💬评论

4. Cusdis（隐私友好）

优势：

✅ 注重隐私保护
✅ 轻量级，无追踪
✅ 支持邮件通知
✅ 简洁的管理界面

配置示例：

1
2
3
4
5
6
7


params:
 comments:
 enabled: true
 provider: cusdis
 cusdis:
 host: https://cusdis.com
 id: your-app-id

🇨🇳 国内特色方案

1. Twikoo（腾讯云函数）

适合国内用户，部署在腾讯云：

1
2
3
4
5
6
7
8
9


params:
 comments:
 enabled: true
 provider: twikoo
 twikoo:
 envId: your-env-id
 region: ap-shanghai
 path: window.location.pathname
 lang: zh-CN

2. Beaudar（中文版Utterances）

1
2
3
4
5
6
7
8
9


params:
 comments:
 enabled: true
 provider: beaudar
 beaudar:
 repo: username/repo-name
 issueTerm: pathname
 label: 💬评论
 theme: github-light

⚡ 快速切换评论系统

您只需要修改hugo.yaml中的provider字段：

1
2
3
4


params:
 comments:
 enabled: true
 provider: waline # 改为: giscus, utterances, cusdis等

🔧 高级配置技巧

1. 条件启用评论

在文章Front Matter中控制：

1
2
3
4


---
title: "文章标题"
comments: false # 禁用评论
---

2. 自定义样式

创建assets/scss/custom.scss：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 自定义评论区样式
.waline-container {
 border-radius: 12px;
 box-shadow: 0 4px 20px rgba(0,0,0,0.1);
}

// 暗黑模式适配
[data-scheme="dark"] .waline-container {
 background: var(--card-background-dark);
}

3. 多语言配置

1
2
3
4
5
6
7
8


params:
 comments:
 waline:
 locale:
 zh-CN:
 placeholder: 欢迎留言交流 😊
 en:
 placeholder: Welcome to comment 😊

📊 性能对比

评论系统	加载速度	功能丰富度	维护成本	隐私性
Waline	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
Giscus	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Utterances	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Cusdis	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Disqus	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐

🚀 部署建议

新手推荐

GitHub用户: Giscus或Utterances
追求功能: Waline
注重隐私: Cusdis
国内博客: Twikoo或Beaudar

高级用户

自托管Waline + Cloudflare CDN
配置邮件/微信通知
开启反垃圾评论
配置图片压缩和CDN

⚠️ 常见问题

1. 评论不显示？

检查comments.enabled是否为true
确认provider配置正确
查看浏览器控制台错误信息

2. GitHub评论系统配置？

仓库必须是公开的
需要安装对应的GitHub App
确认仓库ID和分类ID正确

3. 样式问题？

检查CSS是否被缓存
确认主题版本兼容性
使用浏览器开发者工具调试

🎯 最佳实践

选择标准：
- 技术栈匹配
- 用户群体考虑
- 维护成本评估
配置优化：
- 启用图片压缩
- 配置CDN加速
- 设置反垃圾机制
用户体验：
- 合理的字数限制
- 友好的提示信息
- 适配移动端

通过合理选择和配置评论系统，您的Hugo博客将获得更好的互动体验！

📝 下一步

根据需求选择评论系统
按照配置指南进行部署
测试功能和样式效果
优化用户体验设置

有任何问题欢迎在评论区交流！🎉

私人影院之emby安装配置以及通过embyExternalUrl实现302播放

Sat, 04 Jan 2025 09:48:58 +0000

前两篇文章先讲了如何安装alist并添加常见网盘，以及如何把alist通过rclone挂载在本地硬盘实现像本地文件一样进行浏览，本篇文章咱们继续，介绍如何安装emby并对媒体进行添加进emby.

emby安装

要安装emby首先要面临的就是emby版本选择问题，emby本身是一个收费软件，但是也有大佬们的破解版本，我这里选择amilys/embyserver 这个版本，可以去docker hub官方地址查看。确认镜像后，下边给出我的docker-compose.yaml配置文件:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


networks:
 mynet:
 external: true
services:
 emby:
 image: amilys/embyserver
 container_name: emby
 restart: unless-stopped
 volumes:
 - ./config:/config
 - /data/movies:/data/movies:rslave
 ports:
 - 8096:8096
 extra_hosts:
 - host.docker.internal:host-gateway
 networks:
 - mynet

network不再多说了，自己创建的一个桥接网络。

端口暴露8096出去，

emby的配置文件在/config目录，把它挂载到本地方便后续进行修改。

另外一个挂载路径就是本地的/data/movies挂载到容器的/data/movies目录。本地的/data/movies其实就是上篇文章通过rclone处理的alist中所有的文件。这里建议设置为一样的路径，方便后续在302播放的时候替换，不会遇到那么多麻烦。

整体目录如下：

1
2
3
4


root@docker:~/emby# tree -L 2
.
├── config
└── docker-compose.yaml

然后就是启动容器docker compose up -d进行emby的配置了。

emby初始化

启动容器后，可以通过ip:8096来访问刚启动的容器。下边来进行emby的一些初始化配置，首先是进行语言配置，选择chinese simplified(简体中文)，下一步

设置完语言后就会提示创建用户,根据自己的需求创建用户以及设置用户名和密码。然后继续下一步

之后就会让添加一个媒体库，这里可以先不添加，直接下一步，等完全配置好了之后再去配置媒体库相关的东西

接下来是设置媒体库的偏好语言和地区，根据自己需求英文或者中文

下边是配置远程访问，开启就好了

下边是使用条例，接收继续下一步

终于完成了,点击finish跳转。

经过上边设置，emby就算是初始化好了，接下来就可以进行媒体库添加了。

媒体库

进入到emby后台，找到媒体库菜单，就可以在这里进行添加媒体库了。

添加媒体库时需要整理好分类,是电影、电视节目还是其他，方便emby正确刮削。

根据情况配置上边的选项，配置好后emby就会开始进行刮削，完整后就可以在emby首页看到添加的目录下的所有电影了。

截止到现在emby已经可以正确的播放视频了，但是此时播放网盘的内容是会经过搭建alist那台机器，等于是那台机器把媒体内容下载下来，然后送给我们的播放器进行播放，如果alist部署在本地播放倒是什么没什么，反正都要下载下来。如果alist部署在其他vps上，流量消耗是一个比较大的问题。如果是部署在家里但是需要在家庭以外的地方播放，这时候流量也会经过家里然后才到你在外边的设备，播放速度就取决于你的家庭宽带的上行了，一般上行所以都不会太大，所以我们需要配置302重定向，让播放设备直接和网盘进行交互，而alist服务器只是负责给你列出目录树，供我们浏览使用。下边就来讲一下如何进行302播放。

embyExternalUrl实现302播放

本文主要介绍使用embyExternalUrl工具进行302播放。有大佬做了整合，弄了一个docker镜像：MediaLinker，降低了操作的复杂度，并且支持ssl证书，可以根据需求进行配置。docker compose文件内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


services:
 medialinker:
 container_name: medialinker
 image: thsrite/medialinker:latest
 restart: unless-stopped
 volumes:
 - ./data/:/opt/
 environment:
 - AUTO_UPDATE=true
 - SERVER=emby
 - NGINX_PORT=8091
 network_mode: host

具体环境信息可以看大佬的介绍，我这里使用emby且也不需要SSL，如上是最简单的配置了。启动后，在data目录下会有一个constant.js文件，我们需要改变其中emby、alist的一些配置，需要配置的地方如下图：

根据上图可以看到有7项信息需要填写，主要分为两个大项，一个是emby的配置，一个是alist的配置。下边来详细说一下每个参数的配置。

emby配置

emby需要三个参数，embyhost这个简单，就是我们打开emby的地址，安装的机器ip和docker-compose文件中的端口就可以了。

embyApiKey需要在emby的后台去获取，路径如下，新建一个api密钥，然后填进去就可以了。

mediaMountPath文件中介绍的也比较清楚：

// 挂载工具 rclone/CD2 多出来的挂载目录, 例如将 od,gd 挂载到 /mnt 目录下: /mnt/onedrive /mnt/gd ,那么这里就填写 /mnt // 通常配置一个远程挂载根路径就够了,默认非此路径开头文件将转给原始 emby 处理 // 如果没有挂载,全部使用 strm 文件,此项填[""],必须要是数组

我们在上边安装alis和emby的时候，两个内部路径都是/data/movies，那么这个数组中就填/data/movies.

emby的配置就完成了。

alist配置

host也比较简单，我们怎么访问alist的就怎么写，一般是ip:5244.

alist-token的获取路径如下：

然后是否启用了sign，这个在往alist配置每个网盘的时候，我这边都是有开启的，所以这个参数我需要设置为true.

签名有效期，按照他提供的路径也很容易找到，默认是0，我这里也把他改成12，两边同步。

然后保存constant.js文件，此时需要再对medialinker容器进行一次重启，如果不重启，mediaMountPath不生效。

如何判断是否成功了呢？可以查看medialinker的日志，docker compose logs -tf 来查看。如下我在第一次没有重启的情况去播放视频，看到有以下日志，找的还是默认的/mnt路径，并且可以看到我的服务器流量在疯狂的跑下行流量，说明是通过服务器下载后转给我的。

经过对容器进行重启后，再次去播放视频，可以看到以下日志，读取到了我配置的/data/movies.

经过以上就可以愉快的302直接播放云盘中的视频了。希望可以帮到大家。

Linux管理磁盘分区-挂载新的磁盘到系统

Wed, 04 Dec 2024 15:04:19 +0000

最近购买了两个服务器，其中一个带了一个1T的磁盘，另一个带了一个3T的磁盘，默认这两个磁盘都是没有挂载状态的，需要自己手动进行挂载，于是就开始了研究如何在linux中进行磁盘分区以及磁盘挂载，接下来记录一下折腾过程。

3T盘挂载

磁盘查看

先使用fdisk查看磁盘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


root@host:~# fdisk -l
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0DA7595A-DE2A-1042-8C4F-3C883C4D7BA6

Device Start End Sectors Size Type
/dev/sda1 262144 41943006 41680863 19.9G Linux filesystem
/dev/sda14 2048 8191 6144 3M BIOS boot
/dev/sda15 8192 262143 253952 124M EFI System

Partition table entries are not in disk order.

Disk /dev/sdb: 2.93 TiB, 3221225472000 bytes, 6291456000 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

可以看到/dev/sdb有一个2.93TB的硬盘，下边来对这个磁盘进行分区并添加。

磁盘分区

传统的MBR（主引导记录）分区表只能支持最多2TB的磁盘，而我这个盘是3T的，需要使用GPT，这个格式支持超过2TB的磁盘，Linux支持GPT（GUID分区表）格式。对于大于2T的硬盘使用parted命令来进行处理。

首先要确认是否已安装parted,如果没有安装使用一下命令进行安装：

1
2
3
4


root@host:~# apt install parted
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

然后执行parted /dev/sdb对/dev/sdb这个盘进行处理，输入命令后会进入命令模式，需要经过几个步骤

mklabel gpt ，创建GPT分区表
mkpart primary ext4 0% 100% ，创建一个新分区，使用100%的磁盘空间
print ，显示设置的分区(可选操作)
quit ，退出

完整的操作命令如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


root@host:~# parted /dev/sdb
GNU Parted 3.5
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart primary ext4 0% 100%
(parted) print
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdb: 3221GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 1049kB 3221GB 3221GB ext4 primary

(parted) quit
Information: You may need to update /etc/fstab.

分区完成。

磁盘格式化

创建分区后，需要格式化为文件系统。我这里使用ext4格式，因为我只分了一个盘，所以这里是sdb1,如果有多个盘，需要分别对每个进行格式化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


root@host:~# mkfs.ext4 /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 786431488 4k blocks and 196608000 inodes
Filesystem UUID: f2275364-6fa6-4ae0-a214-5bd98552f5b1
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
 102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

经过上边就已经对刚分的那个盘进行了格式化。

磁盘挂载

接下来就是对这个盘进行挂载，我这里挂载到/data目录下，需要先创建/data这个目录，然后通过mount /dev/sdb1 /data命令，把/dev/sdb1挂载到/data目录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


root@host:~# mkdir /data
root@host:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 979M 0 979M 0% /dev
tmpfs 198M 732K 198M 1% /run
/dev/sda1 20G 2.1G 17G 12% /
tmpfs 990M 0 990M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda15 124M 12M 113M 10% /boot/efi
tmpfs 198M 0 198M 0% /run/user/0
root@host:~# mount /dev/sdb1 /data
root@host:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 979M 0 979M 0% /dev
tmpfs 198M 732K 198M 1% /run
/dev/sda1 20G 2.1G 17G 12% /
tmpfs 990M 0 990M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda15 124M 12M 113M 10% /boot/efi
tmpfs 198M 0 198M 0% /run/user/0
/dev/sdb1 2.9T 28K 2.8T 1% /data

可以通过命令df -h查看磁盘挂载情况，如上是已经成功挂载了。

磁盘开机自动挂载

经过上面的挂载后，如果系统重启，那么挂载就会失效，所以如果你希望磁盘在系统重启时自动挂载，可以编辑/etc/fstab文件：

1
2


root@host-c:~# vim /etc/fstab
/dev/sdb1 /data ext4 defaults 0 2

如上添加一行/dev/sdb1 /data ext4 defaults 0 2就可以重启后自动实现挂载。

1T盘挂载

在3t盘挂载的教程中可以看出整个挂载过程分为：磁盘查看-磁盘分区-磁盘格式化-磁盘挂载-磁盘开机自动挂载共5个步骤，处理1T盘过程基本一致，只是在磁盘分区的时候有两种选择，第一种就还是使用到parted命令，另一种是使用fdisk命令。

先来查看磁盘的分布

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


root@host:~# fdisk -l
Disk /dev/sdb: 1000 GiB, 1073741824000 bytes, 2097152000 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0DA7595A-DE2A-1042-8C4F-3C883C4D7BA6

Device Start End Sectors Size Type
/dev/sda1 262144 41943006 41680863 19.9G Linux filesystem
/dev/sda14 2048 8191 6144 3M BIOS boot
/dev/sda15 8192 262143 253952 124M EFI System

Partition table entries are not in disk order.

可以看到有一个/dev/sdb: 1000 GiB的磁盘。

fdisk命令

先来介绍一下fdisk命令，输入/dev/sdb开始进行分区，默认是创建MBR分区，下边每个Command (m for help)都是需要进行输入的地方。首先是输入o,创建一个MBR分区，然后是输入n来创建分区，partition type选择主分区p，分区号码我这里只需要一个分区，所以输入1，然后就是first sector和last sector默认直接回车就是整个盘。最后输入w来写入修改，就完成了分区。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


root@host:~# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS (MBR) disklabel with disk identifier 0x17afed0e.

Command (m for help): o
Created a new DOS (MBR) disklabel with disk identifier 0xa7272020.

Command (m for help): n
Partition type
 p primary (0 primary, 0 extended, 4 free)
 e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-2097151999, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-2097151999, default 2097151999):

Created a new partition 1 of type 'Linux' and of size 1000 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

然后就是对新建的分区进行格式化和挂载了。和3T盘操作一样。

parted命令

parted不仅可以处理大于2T的，小于2T的也是可以处理的，下边就来看看具体怎么处理。

1
2
3
4
5
6
7
8


root@host:~# parted /dev/sdb
GNU Parted 3.5
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel msdos
(parted) mkpart primary ext4 0% 100%
(parted) quit
Information: You may need to update /etc/fstab.

唯一的区别就是mklable命令，原来是gpt（GPT分区），现在改成msdos（MBR分区），其他命令都一样。分区完成后进行格式化，挂载等一系列操作。

以上就是针对小于2T以及大于2T的盘的挂载教程，希望可以帮到大家。

私人影院之rclone安装以及通过WebDav配置alist

Sun, 13 Oct 2024 02:04:10 +0000

上一篇文章介绍了对alist的安装，本篇文章则来介绍一下rclone把alist里挂载的网盘再套娃挂载到本地磁盘，为后续emby直接读取本地的挂载文件做准备。那么接下来就开始折腾rclone.

配置文件

本文使用docker compose来进行安装，可以docker-hub找到rclone的官方镜像地址，安装可以参考rclone的官方安装教程。

先要把rclone的配置文件给配置好，我这里只配置alist，所以直接给出配置文件内容方便大家快速使用:

1
2
3
4
5
6


[alist]
type = webdav
url = http://alist:5244/dav
vendor = other
user = admin
pass = x9WN7skj6o7_fqjd4F

如上配置，

[]中的名称自己定义一个，

type固定为webdav，

url为alist的webdav的url，url地址在alist的文档中也有说明，就是自己alist的ip+端口然后拼上/dav就可以了。

vendor值为other

user为自己的alist的用户名

pass为自己的alist的用户名密码，但是密码需要进行加密才行，所以可以使用下边的命令来生成自己密码的密文，

生成加密密码：

1
2
3


docker run --rm -it \
 rclone/rclone \
 obscure [替换为具体的密码]

执行命令后就会生成一个你密码的密文，然后替换在配置文件中就可以了。

经过上边处理配置文件就处理好了，可以命名为rclone.conf，rclone的默认配置文件名就是这个，如果名字改动了，则需要在下边docker-compose配置文件的挂载时特殊配置。方便下边docker-compose文件使用。

docker compose

老规矩，所有的应用程序都使用docker compose安装，下边是docker-compose.yaml的完整配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


networks:
 mynet:
 external: true
services:
 rclone:
 image: rclone/rclone:latest
 container_name: rclone
 restart: always
 cap_add:
 - SYS_ADMIN
 devices:
 - /dev/fuse
 security_opt:
 - apparmor:unconfined
 volumes:
 - ./config:/config/rclone
 - /data/movies:/data:shared
 - /tmp:/tmp
 command: [
 "mount alist:/ /data --cache-dir /tmp --allow-other --vfs-cache-mode writes --allow-non-empty"
 ]
 networks:
 - mynet

network网络配置我这里就不讲了，是我自己创建的一个桥接网络。

这里主要说一下volumes和command, 其中cap_add，devices和security_opt有兴趣的同学可以自己去研究他的含义，这里直接按照我给的配置文件就行了。

volumes中/tmp，临时文件存放在目录，在command中指出了cache-dir的位置，然后挂载到宿住机的/tmp.

rclone的配置在容器的/config/rclone目录下，我挂载到本地的config目录，把上边咱们生成的配置文件放在里边。

/data/movies:/data则是目录的配置，先是在command中把咱们的远程alist中的/目录(alist:/)和rclone容器中的/data目录关联在一起，然后再通过volumes把容器中的/data挂载在宿主机的/data/movies下。通过这个目录挂载，咱们就可以在宿主机下/data/movies中浏览alist中所有挂载的文件信息，为后边emby添加影视库做准备。

容器启动

上边的配置信息完成后，文件放到对应的目录下，我这边的目录结构如下：

1
2
3
4
5


root@docker:~/rclone# tree
.
├── config
│ └── rclone.conf
└── docker-compose.yaml

然后在rclone目录下执行docker compose up -d启动容器就可以了。

如果配置没问题应该就可以在宿主机/data/movies目录下看到alist中的网盘和所有文件了。

以上就是折腾rclone和alist的过程，把alist挂载到本地，想本地目录文件一样来进行浏览，方便后续emby进行影视库的添加。

私人影院之搭建自己的alist服务端并添加常见网盘

Sat, 21 Sep 2024 09:56:03 +0000

前段时间写了一篇如何搭建小雅alist的文章，使用小雅的媒体库来进行观影，但是这种有一个问题就是小雅的库更新的不是很快，而且如果我想在电视上观看比较麻烦，就算搭配emby,也无法避免资源更新慢的问题。所以就想着使用自己的网盘配合自己搭建的alist服务端，来进行资源快速入库，方便自己快速观看。那么接下来就详细说明一下自己的搭建过程。

alist服务端

我这里使用docker compose来搭建alist server,alist提供了两个版本的镜像，一个是普通的版本，一个是带aria2下载的版本，根据自己的需求进行安装，安装文档参考官方文档。

我的docker-compose.yaml如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


networks:
 mynet:
 external: true
services:
 alist:
 image: xhofe/alist-aria2:latest
 container_name: alist
 restart: unless-stopped
 volumes:
 - ./data:/opt/alist/data
 networks:
 - mynet
 ports:
 - 15244:5244
 extra_hosts:
 - host.docker.internal:host-gateway
 environment:
 - PUID=0
 - PGID=0
 - UMASK=022
 - TZ=Asia/Shanghai

我的目录分配如下：

1
2
3


.
├── data
└── docker-compose.yaml

整体配置是比较简单的，我使用了自己的网络mynet，而不是让docker自建一个网络，方便后续容器之间的项目访问。

按照上边配置好后直接docker compose up -d运行起来容器。之后通过访问ip:15244(我这里映射到主机的15244端口了)，默认admin用户和密码，进行登录并修改密码。容器启动成功，alist的服务端搭建就算完成了。

网盘添加

我这里主要添加三种类型，天翼云盘，115网盘，本地smb，下边就看一下每种网盘是需要怎么来添加。

天翼云盘

我家里使用的是电信的宽带，送了天翼网盘的会员，个人和家庭分别是4TB，整体也不算少。

进入到alist的管理界面

点击存储-添加,然后选择天翼云盘客户端(官方建议的类型)。然后就可以看到很多选项需要填写，具体的填写操作步骤参考官方文档。

挂载路径是最终显示在alist主页的名称，需要唯一。

缓存过期时间根据自己的需求来定义，比如我添加了一个文件想要快一点能刷新出来，那么我就定义短一点(比如1分钟)，这个根据自己需求来定。

WebDAV策略建议都使用302重定向，这样子在通过WebDAV访问alist服务端的内容的时候，实际上会重定向到网盘内真实的路径，等于直接访问网盘。

启用签名选项如果后续是需要配合emby实现302播放，一定要打开，一定要打开，一定要打开。

用户名就是天翼云盘登录的手机号。

密码是天翼云盘登录的密码。

根文件的id根据自己需求，如果只是想把网盘内的某一个目录添加到alist中，那就按照官方文档里的方法找到对应的文件夹id。

类型有家庭云和个人云，family id在是选择家庭云的时候需要填写，官网里都有介绍。我这里就是家庭云。

基本上述搞定就可以添加成功了。

115网盘

基本和天翼云盘添加流程差不多，驱动类型选择115网盘,挂载路径、缓存过期时间、WebDAV策略、启用签名四个选项和天翼云盘意向逻辑，进行处理就行了。有不明白的可以参考官方文档。

cookie和Qrcode二选一，官方文档也有详细的介绍，包括根文件夹ID，都有详细的介绍，参考文档就可以了。感觉Qrcode会简单一点。我是直接使用的抓包软件抓的应用的cookie。这里有一个事项需要注意一下，如果使用了手机端软件，后续在网页登录的时候最好选择用手机扫码登录，要不然可能会把手机应用端挤掉导致cookie失效。

SMB添加

有些文件没有放在网盘，而是放在自己本地或者放在本地nas中，比如我上篇文档也介绍了Proxmox VE(PVE)8.0安装黑群晖NAS并直通硬盘，这样子想要在alist中把nas中的资源添加进去，就需要使用到SMB一些了，nas中是有开启这个功能的。

添加驱动类型选择SMB

smb是本地文件，启用签名就可以不用开了。地址、用户名、密码和分享名称(smb中的目录)根据自己的需求填写就可以了。

总结

我这里介绍了三种网盘的添加方式，其他的网盘也都大同小异，比如添加阿里云盘等。那么搭建alist服务端并添加网盘，就介绍到这里。希望可以帮到大家。

接下来还会介绍利用rclone挂载alist，然后让emby来使用并实现302播放。

American express checking账户申请

Sat, 21 Sep 2024 08:02:37 +0000

申请ae信用卡有段时间了，中间也想过要去申请ae的checking账户，网上搜到原来是有开户奖励的，但是我想申请的时候是没有开户奖励的，所以就一直拖着。最近收到了ae checking账户的开户奖励邀请，是发邮件过来邀请说开户后3个月内存1000刀或更多，就可以拿到200刀奖励，于是就开启了申请之路。

收到的邮件信息如下：

还没有申请ae信用卡的同学可以参考我的另一个文章：使用ITIN申请American Express(美国运通)信用卡进行申请。

申请

按上边邮件里的提示，直接点击Explore Now进行跳转浏览器进行申请，点击后跳转到介绍页：

可以看到Apply Now下边有一行小字介绍:现在接受至少35天的会员申请。直接点击申请跳转下一步：

如上，其中邮箱，手机号和家庭住址是已经默认填入且不可更改，我们只需要选择职业和填写SSN或者ITIN就可以了，下边还有一个W-9税收预扣状态证明，问美国国税局是否已通知您需要缴纳备用预扣税,选择NO，选则NO后会有下边的一些选项让确认，大概内容如下：

IRS 税收预扣证明通过选择此选项，我根据伪证处罚规定证明：

随此申请提交的纳税人识别号 (TIN) 是我的正确 TIN，并且

我无需缴纳备用预扣税，因为：(a) 我免于缴纳备用预扣税，或 (b) 我尚未收到美国国税局 (IRS) 的通知，告知我由于未报告所有利息或股息而需要缴纳备用预扣税，或 (c) IRS 已通知我，我不再需要缴纳备用预扣税，并且

我是美国公民或其他美国人，并且

此表格中输入的表明我免于缴纳 FATCA（海外账户税收合规法案）代码（如果有）是正确的。

继续往下填写，Electronic Delivery电子交付，同意，后续银行会使用电子方式(邮件)来通知一些账户等信息。

申请过程要填写的内容不是很多，经过上边的填写，需要我们处理的内容已经结束了。接下来就是Agree & Submit.

申请结果

当我们提交后，基本上会立马得到结果，

此时邮件也会收到一封通过的邮件：

可以看到5-7个工作日会收到debit card,并且如果60个日历日没有往里边存款，这个账户就会被关闭。至此申请基本就完成了。接下来就是等待房东通知收到邮件了。

收到邮件

说的是5-7个工作日，实际上速度很快，第二天就发邮件通知说已经发出。

又等待了一天房东通知收到了邮件,然后就是让房东进行转寄，目前已经转寄出了，按DHL的速度，应该很快就可以收到邮件了。等到收到邮件后再看后续如何进行存款操作。

Proxmox VE(PVE)8.0安装黑群晖NAS并直通硬盘

Mon, 16 Sep 2024 10:00:29 +0000

前段时间通过pve安装ikuai,openwrt以及使用lxc安装了docker,之后就一直稳定使用，J4125上有一个2T的硬盘，于是就想着折腾一下在上边安装一下黑群晖，体验一下nas系统。于是就又开始了折腾之路，又学习了很多知识。下边就记录一下我折腾的过程。

准备

其实在开始装nas之前我看了很多教程，里边只是提供安装过程，并提供对应的安装包。说实在的，虽然很贴心，但是每个人的主机不尽相同，适合他的nas包不一定适合我，那么自己应该选择什么nas包呢？他们基本都没有说明，但是基本都是安装DS918+。于是在b站找到了一个版本选择教程，腾讯文档地址：RR型号列表。然后又看了rr安装，使用rr安装很方便：RR地址。

直接下载一个最新RR的镜像就可以了。至于nas的版本，两个选择，DS918+和SA6400，两个版本都是视频中推荐的版本，如果cpu是10代以后选择SA6400，如果10代以前则两个都可以。

安装

新建虚拟机

下载好镜像后就需要在pve中进行新建虚拟机了。步骤和openwrt差不多。

常规选项：只需要填写一个名称就可以了。

操作系统：选择不使用任何介质。

系统：只需要将机型设置为q35，其他默认。

磁盘：直接把磁盘删除。

CPU：核心数根据自己的cpu设置，我这里给4.另外类别下拉到最后，选择host模式。

内存：内存给2-4GB都可以，我这里给4G.

网络：默认。模型为:VirtIo(半虚拟化)。

然后就是确认刚才填的信息，确认就可以了。

经过上边已经创建好了一个虚拟机，下边还需要上传刚才下载的rr镜像。

镜像上传

如图的位置进行上传。

接下来在shell中使用命令将黑群晖的引导文件rr导入到创建好的DSM虚拟机，进入到pve系统的shell中执行。

命令如下：qm importdisk 编号 /var/lib/vz/template/iso/rr.img local-lvm , 其中编号为刚创建的虚拟机编号，rr.img的镜像上传路径基本不会有不同，基本都是在/var/lib/vz/template/iso目录下再加上镜像名称，我这里就是rr.img。

我的完整命令如下：qm importdisk 104 /var/lib/vz/template/iso/rr.img local-lvm。执行成功后可以在nas虚拟机的硬件里看到一个未使用的磁盘，双击可添加磁盘：

总线设备选sata，磁盘映像默认就是刚看到的那个未使用的磁盘。其他的默认就可以了。

硬盘直通

经过上边的设置基本就可以了，此时还需要给nas添加一个磁盘。在pve的shell中通过命令找到我的固态盘ls -l /dev/disk/by-id/：

可以看到ata开头的ZHITAI就是我的固态盘了。复制完整的名称：ata-ZHITAI_SC001_XT_2000GB_ZTB502TAB2404507RX。

然后通过命令直通给nas，set后边就是虚拟机的编号，我这里是103，后边–satax 根据自己的定义，刚添加的引导盘占了sata0,所以我这里就使用sata1 后边就是完整的磁盘路径 /dev/disk/by-id/拼上的判断完整名。

1
2


root@pve:~# qm set 103 --sata1 /dev/disk/by-id/ata-ZHITAI_SC001_XT_2000GB_ZTB502TAB2404507RX
update VM 103: -sata1 /dev/disk/by-id/ata-ZHITAI_SC001_XT_2000GB_ZTB502TAB2404507RX

执行完成后就可以看到新添加的磁盘了：

然后修改启动顺序后就可以启动了。

把sata0设置为第一位：

启动成功后，在控制台中可以看到提示，会让访问一个ip:7681的网址去进行初次设置。

引导编译

访问7681端口的那个网址

先进行语言设置，选择Choose a language，找到zh-CN,切换语言为中文。

型号选择：我这里选择SA6400

版本选择：我这里选择DSM7.2

弹出的版本页面，点击URL会自动下载当前引导的系统文件（建议使用此方式下载，避免在群晖官网下载错系统），下载好的系统文件后缀为pat，然后点击确认。下边初始化会用到。

然后选择编译引导。

只需要等待。

编译好引导后会自动跳转到主菜单的启动选项，直接点击启动即可。

正常开机后，可以再次在控制台看到让访问ip:5000的端口，此时说明安装已经ok了。

NAS初始化

接下来就是访问ip:5000来进行NAS的初始化,我这里的ip是192.1681.42:5000

安装。

选择引导编译阶段下载的pat文件。

提示会删除硬盘数据，继续进行确认。

等待安装。安装后就是重启，提示大概需要10分钟，实际上我等了3分钟就可以了。

重启完成后就会提示安装组件：

套件安装完成后进入安装引导：

进入用户名和密码设置：

接下来的更新就不需要了自动安装了：

账号创建跳过：

用户体验不勾选，提交：

经过上边的一系列设置，终于来到了nas的桌面中。

桌面设置

群晖套件：不用了，谢谢。

双重2FA不开启：

下一步账户保护不开启。

终于都设置完了。。。

磁盘设置

经过上边的设置，终于提示要设置磁盘了。

点击开始进行设置：

raid类别根据自己的需要选择，我这里就一个硬盘，直接选择basic类型。继续下一步,选择硬盘，我这里需要一个硬盘：

继续下一步，跳过硬盘检查：

继续下一步配置磁盘容量：

直接最大化，整个都分配给nas，继续下一步文件系统：

这里我就选择他推荐的，继续下一步配置加密：

我这里不加密，默认，继续下一步，对刚才的配置在进行概览：

配置无问题应用就可以了。终于整个nas都配置后了。

最后再上一个桌面显示的图片：

以上就是pve安装黑群晖的折腾记录。

WSL2 Ubuntu开启SSH并配置远程登录

Sat, 17 Aug 2024 07:12:52 +0000

在公司有两台电脑，其中一台正常使用的工作电脑(A)，另一台(B)想要部署一些服务，当做一台服务器来使用，于是就是在B机器上启用了WSL服务，并安装了Ubuntu 22。但是这里遇到一个问题，我总不能一直远程桌面从A中来通过SSH操作B电脑，于是就开始折腾在B电脑开启Ubuntu的远程访问，下边记录一下折腾过程。

准备

A电脑需要有SSH远程访问工具，使用自带的powershell或者其他第三方的工具都是可以的。

B电脑需要开启WSL并安装好Ubuntu子程序。

开启远程访问

首先需要在B电脑安装ssh-server服务:

1
2
3
4


ai@DESKTOP-KKMQ55S:/etc/apt$ sudo apt install openssh-server -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

等待安装成功后就可以对ssh服务进行启用：

1
2
3
4


ai@DESKTOP-KKMQ55S:~$ sudo service ssh restart
 * Restarting OpenBSD Secure Shell server sshd [ OK ]
ai@DESKTOP-KKMQ55S:~$ service ssh status
 * sshd is running

SSH服务启动后还需要获取当前ubuntu的ip才能进行访问，WSL安装的ubuntu默认无法使用ifconfig命令，需要安装net-tools才可以使用，下边进行安装net-tools以及查看ip地址：

1
2
3
4
5
6
7


ai@DESKTOP-KKMQ55S:~$ sudo apt install net-tools
Reading package lists... Done
Setting up net-tools (1.60+git20181103.0eebece-1ubuntu5) ...
Processing triggers for man-db (2.10.2-1) ...
ai@DESKTOP-KKMQ55S:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
 inet 172.17.33.211 netmask 255.255.240.0 broadcast 172.17.47.255

如上，通过ifconfig命令查看到ubuntu机器的ip是172.17.33.211，那么可以在B机器中进行远程ubuntu机器，看一下是否可以正常远程：

1
2
3
4
5
6


C:\Users\ai001>ssh ai@172.17.33.211
ai@172.17.33.211's password:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64)

Last login: Fri Aug 16 16:15:43 2024 from 127.0.0.1
ai@DESKTOP-KKMQ55S:~$

可以看到才已经正常开启了ssh并可以连接。

其他机器访问

上边已经对WSL的Ubuntu开启了SSH访问，接下来还需要通过其他的机器来连接这个机器，连接示意图如下：

需要从电脑A访问电脑B，然后电脑B再访问WSL子系统的ubuntu.使用电脑B的ip是无法直接访问到Ubuntu系统的，

这时候就需要在电脑B中进行代理设置，需要以管理员运行Powershell工具，然后执行以下命令，listenport和listenaddress是指电脑B监听的地址和端口，connectport和connectaddress是指需要代理到的地址和端口，我这里是从电脑B的22端口到Ubuntu的22端口，所以端口都是22，ubuntu的ip这里写成了localhost，在上边咱们获取到的ip是172.17.33.211，写成这localhost和172开头的ip应该都是可以的，我这里只是测试了localhost,是可以正常联通的，有兴趣的同学可以自行测试一下。

添加protproxy的语法可以参考微软官方文档：Netsh interface portproxy commands

1
2
3
4
5
6
7
8
9


PS C:\Users\ai001> netsh interface portproxy add v4tov4 listenport=22 listenaddress=0.0.0.0 connectport=22 connectaddress=localhost

PS C:\Users\ai001> netsh interface portproxy show v4tov4

侦听 ipv4: 连接到 ipv4:

地址 端口 地址 端口
--------------- ---------- --------------- ----------
0.0.0.0 22 localhost 22

经过上边的步骤后，我们还需要对电脑B进行防火墙放行22端口的入站流量，命令如下，name可以自定义，我这里是对ssh放行的，所以取名字就叫ssh，官方文档

1

PS C:\Users\ai001> netsh advfirewall firewall add rule name=ssh dir=in action=allow protocol=TCP localport=22

然后就可以在电脑A通过电脑B的22端口访问到电脑B的WSL Ubuntu子系统了。

1
2
3
4


k@admin:~$ ssh ai@192.168.6.39
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64)
Last login: Sat Aug 17 14:36:06 2024 from 172.17.32.1
ai@DESKTOP-KKMQ55S:~$

以上就可以完成直接从A电脑访问B电脑的linux服务器，可以直接在上边愉快的部署服务了。

其他服务访问

在WSL的Ubuntu中部署其他的服务，然后根据服务占用的端口，需要再去配置电脑B的端口转发，转发到Ubuntu的对应端口去，这里我尝试了部署一个Java的tomcat服务，占用了18080端口，我通过上边的配置代理命令，connectaddress还是localhost,此时是无法访问的，然后对代理进行删除，改成了具体的172.17.33.211后，再通过192.168.6.39:18080就可以正常访问了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


PS C:\Users\ai001> netsh interface portproxy add v4tov4 listenport=18080 listenaddress=0.0.0.0 connectport=18080 connectaddress=172.17.33.211

PS C:\Users\ai001> netsh interface portproxy show all

侦听 ipv4: 连接到 ipv4:

地址 端口 地址 端口
--------------- ---------- --------------- ----------
0.0.0.0 22 localhost 22
0.0.0.0 18080 172.17.33.211 18080

如果对代理规则或者防火墙配置错误可以通过以下命令来进行删除，代理规则根据监听的端口和ip来进行删除，防火墙则通过name来进行删除。

1
2
3
4
5


PS C:\Users\ai001> netsh interface portproxy delete v4tov4 listenport=18080 listenaddress=0.0.0.0
PS C:\Users\ai001> netsh advfirewall firewall delete rule name=tomcat

已删除 1 规则。
确定。

以上就是WSL配置SSH远程访问的过程，并对特定服务的特定端口进行代理转发，实现访问。

docker搭建aliyunpan-sync时实增量同步阿里云盘文件

Sat, 06 Jul 2024 03:11:29 +0000

在前边的文章中介绍了如何快速的搭建小雅alist来满足大家的观影需求，但是有一些剧小雅更新没那么及时，这时候就需要大家八仙过海了。如何及时找到自己要观看的剧，并成功观看呢？下边就带着大家一起使用aliyunpan-sync工具来同步阿里云盘的数据。

网盘选择

这里为什么要选择阿里云盘呢？因为阿里网盘资源比较多，更新也比较快，然后网上也找了同步阿里云盘的同步工具：aliyunpan-sync，理论上115，百度云，夸克这些网盘也都是ok的，主要是把文件同步到本地，具体的网盘的同步工具就需要大家自己去找了。我这里只带着大家实现阿里云盘的同步。另外推荐给大家一个电报的阿里云盘的资源通知群，资源更新还是挺及时的：https://t.me/yunpanpan。

安装aliyunpan-sync

我这里使用的是docker compose进行的安装，如果还没有安装docker的同学可以参考的我的文章把docker 给安装一下：docker安装。

获取阿里云盘token

要想从阿里云盘里下载文件，肯定是需要先登录阿里云盘才能进行数据同步，如何登录阿里云盘aliyunpan-sync工具里也有具体的说明：登录阿里云盘，需要先在release页面下载一个对应系统的release，我的操作系统是mac m1芯片我就下载arm那个

然后对文件进行解压，使用终端进入到对应的目录里，看到有一个aliyunpan的文件，执行这个文件获取登录链接，然后在网页端进行扫码登录就可以了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# k @ Mac-mini in ~/Downloads/aliyunpan-v0.3.2-darwin-macos-arm64 [10:03:26]
$ ls
README.md manual.md sync.sh webdav.sh
aliyunpan plugin sync_drive
aliyunpan_config.json sync.bat webdav.bat

# k @ Mac-mini in ~/Downloads/aliyunpan-v0.3.2-darwin-macos-arm64 [10:03:28]
$ aliyunpan login
zsh: command not found: aliyunpan

# k @ Mac-mini in ~/Downloads/aliyunpan-v0.3.2-darwin-macos-arm64 [10:03:42] C:127
$ ./aliyunpan login
请在浏览器打开以下链接进行登录，链接有效时间为5分钟。
注意：你需要进行一次授权一次扫码的两次登录。
https://openapi.alipan.com/oauth/authorize?client_id=cf9f70e8fc6143031375&redirect_uri=https%3A%2F%2Fapi.tickstep.com%2Fauth%2Ftickstep%2Faliyunpan%2Ftoken%2Fopenapi%2F0bd327267c41f7b2fcadf927%2Fauth2&scope=user:base,file:all:read,file:all:write

请在浏览器里面完成扫码登录，然后再按Enter键继续...

打开url就需要使用手机端的阿里云盘进行扫码登录，提示进行授权：

根据需要选择授权范围，我这里把备份盘和资源库都进行授权，其实就是整个阿里云盘这个工具都可以访问。然后就是回到终端看到具体的token。保存好这个token.

docker镜像启动

我这里使用的是docker compose来进行安装的，我的文件目录如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$ tree
.
├── config
├── docker-compose.yaml
├── js
│ ├── download_handler.js.sample
│ ├── sync_handler.js
│ ├── sync_handler.js.sample
│ ├── token_handler.js
│ ├── token_handler.js.sample
│ └── upload_handler.js.sample
└── sync_drive

config目录是用来挂在配置文件的，等下token是要填在这个目录下的aliyunpan_config.json文件里的。

js目录是用来做一些脚本处理，用来控制什么文件可以上传，什么文件可以下载，以及进行一些通知操作的。

sync_drive是保存数据库的信息，用来记录同步的一些信息，即使容器销毁，同步数据库还可以用于以后使用。

具体的docker-compose.yaml文件内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


version: '3'
services:
 sync:
 image: tickstep/aliyunpan-sync:v0.3.2
 container_name: aliyunpan-sync
 restart: unless-stopped
 volumes:
 # （必须）映射的本地目录
 - /data/webdav/data:/home/app/data:rw
 # （可选）可以指定JS插件sync_handler.js用于过滤文件，详见插件说明
 #- ./config/sync_handler.js:/home/app/config/plugin/js/sync_handler.js
 - ./js:/home/app/config/plugin/js/
 # （推荐）挂载sync_drive同步数据库到本地，这样即使容器销毁，同步数据库还可以用于以后使用
 - ./sync_drive:/home/app/config/sync_drive
 # （必须）映射token凭据文件
 - ./config/aliyunpan_config.json:/home/app/config/aliyunpan_config.json
 extra_hosts:
 - host.docker.internal:host-gateway
 environment:
 # 时区，东8区
 - TZ=Asia/Shanghai
 # 下载文件并发数
 - ALIYUNPAN_DOWNLOAD_PARALLEL=2
 # 上传文件并发数
 - ALIYUNPAN_UPLOAD_PARALLEL=2
 # 下载数据块大小，单位为KB，默认为10240KB，建议范围1024KB~10240KB
 - ALIYUNPAN_DOWNLOAD_BLOCK_SIZE=1024
 # 上传数据块大小，单位为KB，默认为10240KB，建议范围1024KB~10240KB
 - ALIYUNPAN_UPLOAD_BLOCK_SIZE=10240
 # 指定网盘文件夹作为备份目标目录，不要指定根目录
 - ALIYUNPAN_PAN_DIR=/来自分享
 # 备份模式：upload(备份本地文件到云盘), download(备份云盘文件到本地)
 - ALIYUNPAN_SYNC_MODE=download
 # 备份策略: exclusive(排他备份文件，目标目录多余的文件会被删除),increment(增量备份文件，目标目录多余的文件不会被删除)
 #- ALIYUNPAN_SYNC_POLICY=increment
 # 备份周期, 支持两种: infinity(永久循环备份),onetime(只运行一次备份)
 #- ALIYUNPAN_SYNC_CYCLE=infinity
 # 网盘：backup(备份盘), resource(资源盘)
 - ALIYUNPAN_SYNC_DRIVE=resource
 # 是否显示文件备份过程日志，true-显示，false-不显示
 - ALIYUNPAN_SYNC_LOG=true
 # 本地文件修改检测延迟间隔，单位秒。如果本地文件会被频繁修改，例如录制视频文件，配置好该时间可以避免上传未录制好的文件
 - ALIYUNPAN_LOCAL_DELAY_TIME=60

重点说一下上边的四个配置：

第一个是挂载配置下的映射的本地目录，这个是把阿里云盘的数据下载下来的目录，需要把他挂载在一个比较大的存储路径。

第二个是备份模式：ALIYUNPAN_SYNC_MOD，我这里是把云盘文件下载到本地，所以模式是download。

第三个是网盘：ALIYUNPAN_SYNC_DRIVE，阿里云盘分为备份盘和资源盘，我这里大部分转存的文件都是放在资源盘，所以这里配置resource。

第四个是备份目标目录：ALIYUNPAN_PAN_DIR，这个配置就是当前容器需要下载的目录，上边指定了需要下载资源盘的文件，但是肯定不能整个资源盘都下载，只需要指定特定的目录下载就行了，比如我转存的文件都是放在来自分享目录下，我这里就配置来自分享。

js的通知后边在讲，这个目录里边暂时可以先不放任何js文件。

然后就可以启动docker compose文件了。

1

docker compose up -d

此时虽然启动了容器，但是因为没有配置token，容器会一直重启，但是此时目录config目录下就会多出一个aliyun_config.json的文件，编辑文件找到accessToken属性，把第一步生成好的token替换进去就可以了。保存文件后等待容器下一次重启或者手动重启容器就可以了。此时就可以了。

验证

接下来就是找一个文件保存到云盘的指定要下载的目录，我是来自分享，然后去看一下目录有没有进行下载。也可以通过查看容器的日志：

1
2
3
4
5
6
7
8
9


root@docker:~/images/aliyunpancli# docker compose logs -tf --tail 10
WARN[0000] /root/images/aliyunpancli/docker-compose.yaml: `version` is obsolete
aliyunpan-sync | 2024-07-06T02:52:51.522742265Z 扫描到云盘文件：/来自分享/Cover the sky.S01E61.2023.2160p.WEB.DL.H265.DDP2.0-BestWEB.mkv
aliyunpan-sync | 2024-07-06T02:52:56.282356345Z 完成全部文件的同步下载，等待下一次扫描
aliyunpan-sync | 2024-07-06T02:53:51.550419129Z 开始进行文件扫描...
aliyunpan-sync | 2024-07-06T02:53:51.756156867Z 扫描到云盘文件：/来自分享/Jade Dynasty.S02E43.2022.2160p.WEB-DL.H265.DDP2.0-BestWEB.mkv
aliyunpan-sync | 2024-07-06T02:53:51.756982180Z 扫描到云盘文件：/来自分享/Cover the sky.S01E61.2023.2160p.WEB.DL.H265.DDP2.0-BestWEB.mkv
aliyunpan-sync | 2024-07-06T02:53:56.554962070Z 下载文件：/来自分享/Jade Dynasty.S02E43.2022.2160p.WEB-DL.H265.DDP2.0-BestWEB.mkv
下载到本地:/home/app/data/Jade Dynasty.S02E43.2022.2160p.WEB-DL.H265.DDP2.0-BestWEB.mkv ↓ 773.00MB/779.46MB(99.17%) 9.64MB/s............下载完毕：/home/app/data/Jade Dynasty.S02E43.2022.2160p.WEB-DL.H265.DDP2.0-BestWEB.mkv

通过日志可以看出它在不停的扫描，检测到新文件就开始进行下载。

JS通知

在docker compose文件中，指定了js文件的目录，那么要怎么使用呢？官方也有一些具体的例子：JavaScript插件，我这里需要提供一个下载完成通知的功能，保存文件后什么时候下载完成是大家比较关心的，总不能总是查看日志。

这里要使用到的js文件是sync_handler.js文件。文件具体的内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


// ------------------------------------------------------------------------------------------
// 函数说明：同步备份-同步文件后的回调函数
//
// 参数说明
// context - 当前调用的上下文信息
// {
// "appName": "aliyunpan",
// "version": "v0.1.3",
// "userId": "11001d48564f43b3bc5662874f04bb11",
// "nickname": "tickstep",
// "fileDriveId": "19519111",
// "albumDriveId": "29519122"
// }
// appName - 应用名称，当前固定为aliyunpan
// version - 版本号
// userId - 当前登录用户的ID
// nickname - 用户昵称
// fileDriveId - 用户文件网盘ID
// albumDriveId - 用户相册网盘ID
//
// params - 同步文件后的参数
// {
// "action": "upload",
// "actionResult": "success",
// "driveId": "19519221",
// "fileName": "1.txt",
// "filePath": "D:/goprojects/dev/upload/1.txt",
// "fileSha1": "294C8F24C56042710813E95C55A0B018299BA9A7",
// "fileSize": "28077",
// "fileType": "file",
// "fileUpdatedAt": "2022-03-04 15:19:47"
// }
// action - 同步动作，
// download-下载文件，
// upload-上传文件，
// delete_local-删除本地文件，
// delete_pan-删除云盘文件，
// create_local_folder-创建本地文件夹，
// create_pan_folder-创建云盘文件夹
// actionResult - 同步结果，success-成功，fail-失败
// driveId - 网盘ID
// fileName - 文件名称
// filePath - 文件完整路径
// fileSha1 - 文件SHA1
// fileSize - 文件大小，单位B
// fileType - 文件类型，file-文件，folder-文件夹
// fileUpdatedAt - 文件修改时间
//
// 返回值说明
// （无）
// ------------------------------------------------------------------------------------------
function syncFileFinishCallback(context, params) {
 console.log(params)
 var header = {
 "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36",
 "Content-Type": "application/json",
 "Accept": "application/json"
 };
 try {
 var text = "文件名：" + params["fileName"] + " 同步完成, 同步结果: " + params["actionResult"];
 if (params["actionResult"] === "fail") {
 var reqData = {
 "chat_id": "这里是自己的id",
 "text": text
 };
 var r = PluginUtil.Http.post(header, "https://api.telegram.org/{这里替换具体的电报机器人token}/sendMessage", JSON.stringify(reqData));
 }
 } catch (e) {
 if (e !== "Error") {
 throw e;
 }
 }
}

怎么创建电报机器人以及获取自己的id这里就不再说了，大家可以网上搜索一下，如果后续时间充裕，我也会详细教大家如何创建机器人和查看自己的id。

text就是通知的内容，来看一下最终的通知效果：

PHP实现AES-128-ECB并以PKCS5Padding填充方式加解密

Sat, 29 Jun 2024 03:36:33 +0000

工作中提供给外部调用的api需要进行请求的内容进行加密，加密使用的AES/ECB/PKCS5Padding这种加密方式，公司开发使用的是Java，但是对接企业有使用Java，Go或者php进行开发的，客户会要求提供一下demo，Java语言还好搞，本身就是Java开发的，直接提供就好了，但是php和Go由于公司没有使用者，在客户来询问的时候就没有demo可以提供到，于是自己就研究了一下PHP的AES加密，并提供了一个demo。下边介绍一下具体的实现。

本文主要讲由Java转到PHP的实现，具体AES算法是怎么实现的不在本文的讨论范围，如果还不知道AES是什么自行搜索。

Java实现

在这里有必要先说明一下Java的实现，因为只有知道Java是怎么实现的，才能在其他语言里去实现。先上代码吧：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


public class AesUtils {
 private static final String TRANSFORMATION = "AES/ECB/PKCS5Padding";
 private static final String ALGORITHM = "AES";
 public static String encrypt(String content, String key){
 try {
 Key secretKeySpec = secretKeySpec(key);
 Cipher cipher = Cipher.getInstance(TRANSFORMATION);// 创建密码器
 cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec);// 初始化
 byte[] result = cipher.doFinal(content.getBytes(StandardCharsets.UTF_8));
 return Base64.getEncoder().encodeToString(result);
 } catch (Exception e) {
 }
 }
 public static String decrypt(String content, String key) {
 try {
 Key keySpec = secretKeySpec(key);
 Cipher cipher = Cipher.getInstance(TRANSFORMATION);
 cipher.init(Cipher.DECRYPT_MODE, keySpec);
 byte[] result = cipher.doFinal(Base64.getDecoder().decode(content));
 return new String(result, StandardCharsets.UTF_8);
 } catch (Exception e) {
 }
 }
 private static Key secretKeySpec(String key) throws EncryptException {
 KeyGenerator generator = KeyGenerator.getInstance(ALGORITHM);
 SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");
 secureRandom.setSeed(key.getBytes(StandardCharsets.UTF_8));
 generator.init(128, secureRandom);
 SecretKey secretKey = generator.generateKey();
 byte[] enCodeFormat = secretKey.getEncoded();
 return new SecretKeySpec(enCodeFormat, ALGORITHM);
 }
}

完整代码如上，整个代码也比较清晰，获取key然后对内容进行加解密。

但是问题就出现在key获取上，根据用户提供的key再使用RNG(Random Number Generator)算法：SHA1PRNG获取128位的key：generator.init(128, secureRandom);，由次可知完整的AES加密算法应该是AES-128-ECB并使用PKCS5Padding方式进行填充。

PHP实现

通过阅读Java的代码发现完整算法是AES-128-ECB并使用PKCS5Padding方式进行填充，获取key的时候使用SHA1PRNG，但是PHP并没有这种方式，于是就去询问GPT，查看网上各种资料，最终找到了解决办法，PHP的完整代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


<?php
$plainText = isset($_GET['text']) ? $_GET['text'] : 'Hello, World!';
$key = isset($_GET['key']) ? $_GET['key'] : 'this_is_a_very_long_key_that_needs_to_be_shortened_or_hashed';

function encrypt($plainText, $key) {
 $key = substr(openssl_digest(openssl_digest($key, 'sha1', true), 'sha1', true), 0, 16);
 // openssl_encrypt 加密不同Mcrypt，对秘钥长度要求，超出16加密结果不变
 $data = openssl_encrypt($plainText, 'AES-128-ECB', $key, OPENSSL_RAW_DATA);
 //$data = strtolower(bin2hex($data));
 return base64_encode($data);
}

function decrypt($cipherText, $key) {
 $key = substr(openssl_digest(openssl_digest($key, 'sha1', true), 'sha1', true), 0, 16);
 $decrypted = openssl_decrypt(base64_decode($cipherText), 'AES-128-ECB', $key, OPENSSL_RAW_DATA);
 return $decrypted;
}

// 示例用法
$encrypted = encrypt($plainText, $key);
echo "加密结果: " . $encrypted . "\n";

$decrypted = decrypt($encrypted, $key);
echo "解密结果: " . $decrypted . "\n";
?>

如上，在php中是对Key进行两次sha1并对结果进行截取16位。

在PHP中，openssl_encrypt和openssl_decrypt函数会自动处理PKCS#5/PKCS#7填充（padding），不需要手动实现填充。参数中指明OPENSSL_RAW_DATA就可以了。

以上就是在PHP中实现Java中SHA1PRNG生成key并以AES-128-ECB加密且以PKCS#5方式进行填充的实现。记录一下。

Google Adsense地址验证流程

Tue, 18 Jun 2024 13:10:26 +0000

网站从成功部署后，就入了google adsense，算下来也有一年多的时间了，这一年多自己发布文章的频率也比较低，所以流量不高，广告收入非常少，没想到这么快就收到了adsense的地址验证要求。今天就介绍一下我验证地址的详细过程。

验证邮件

在6月初，我收到了google的邮件，提示验证我的身份，只有这样子才能接收到来自google adsense的付款，并且邮件中直接给出了地址可以直接点击按钮跳转验证地址进行验证。

资料上传

点击链接会跳转到验证界面，最开始是需要上传一份身份证明：身份ID或者护照(passport)。我这边因为个人信息写的美国，所以这里就上传了护照上去，并填写了自己在anyboxmail上申请的美国地址，在输入完地址点击下一步的时候，又弹出需要验证地址。

地址验证这里对我倒是没有什么难处，我申请了美国运通信用卡(申请教程：使用ITIN申请American Express(美国运通)信用卡)的月度账单，上边有我的地址信息，以此来作为我的地址证明进行了上传。如果地址写的是国内的小伙伴，直接申请国内信用卡的电子账单，进行上传应该也是可以的。

整体上其实就是上传了两份文件，一份护照，一份地址证明文件，提交后就是等待处理，google那边需要点时间对上传的资料进行审查。

身份验证通过

过了有3天，收到了google的邮件通知，提示身份验证通过。

同一天google又给我发了一份邮件，提示验证地址的pin码已经发出，等具体收到信件后再进行pin码验证。

验证pin码

这中间又是一段时间的等待，因为邮件是发到我租的美国地址的，中间刚好又遇到双休，处理的没那么快，等待几天后收到了pin码邮件

然后让房东进行了扫描，扫描后的内容如下

此时登录google adsense的后台，直接看到有一个卡片就是提示要验证pin码

点击验证就跳转到了pin码验证页面

正确输入后就ok了，最终身份验证和地址验证都显示已通过，至此完成google adsense的全部验证

以上就是整个验证流程。

使用gradle kts脚本发布个人项目的jar包文件到maven中央仓库

Sun, 19 May 2024 02:02:03 +0000

上篇文章记录了如何使用maven来发布自己的个人项目到中央仓库，后边项目改使用gradle来管理依赖了，为了能及时的把jar发布到maven仓库，所以就又折腾了一遍如何使用gradle来发布自己的jar到中央仓库，在这里记录一下折腾和踩坑经历，并分享给大家。

前提准备

如果你是第一次发布jar到仓库，则需要参考我的另一篇文章：发布个人项目的jar包文件到maven中央仓库来创建好sonatype账号并生成gpg key。这些就不在另外说明了。

本篇文章就是在我已经使用了maven发布过jar到中央仓库，然后在此基础上把项目迁移到gradle，然后使用gradle来继续发布项目到中央仓库。

gradle配置

设置发布plugins

想要把jar发布的maven仓库需要先将项目的代码打包成jar，然后对jar进行签名，最后发布到maven仓库，三步对应三个插件：

1
2
3
4
5


plugins {
 `java-library`
 `maven-publish`
 signing
}

上边就添加了三个插件，将用于后续的发布使用。

配置jar打包

下边设置对项目进行打包成jar的设置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


tasks.jar {
 dependsOn(tasks.withType(GenerateMavenPom::class))
 manifest {
 attributes("Created-By" to "Gradle ${project.ext["gradleVersion"]}")
 }
 into("META-INF") {
 from("$buildDir/publications/mavenJava")
 exclude("*.asc")
 rename { it.replace("pom-default.xml", "pom.xml") }
 }
}

tasks.withType<JavaCompile> {
 options.encoding = "UTF-8"
}

java {
 sourceCompatibility = JavaVersion.VERSION_17
 targetCompatibility = JavaVersion.VERSION_17
 withJavadocJar()
 withSourcesJar()
}

上边指定了jdk的版本，并且生成javadoc和java source文件，指定打包的编码以及对manifest文件属性添加等一系列的操作。

配置发布

主要是配置仓库，pom文件以及签名等信息，先贴一下整个配置，下面单独讲。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


publishing {
 publications {
 create<MavenPublication>("mavenJava") {
 artifactId = project.name
 from(components["java"])
 /*versionMapping {
 usage("java-api") {
 fromResolutionOf("runtimeClasspath")
 }
 usage("java-runtime") {
 fromResolutionResult()
 }
 }*/
 pom {
 name.set(project.name)
 description.set("A concise description of my library")
 url.set("https://www.example.com/library")
 /*properties.set(mapOf(
 "myProp" to "value",
 "prop.with.dots" to "anotherValue"
 ))*/
 licenses {
 license {
 name.set("The Apache License, Version 2.0")
 url.set("https://www.apache.org/licenses/LICENSE-2.0.txt")
 }
 }
 developers {
 developer {
 id.set("yslao")
 name.set("yslao")
 email.set("yslao@outlook.com")
 }
 }
 scm {
 connection.set("scm:git:git://github.com/konghanghang/base-iminling-core.git")
 developerConnection.set("scm:git:ssh://github.com/konghanghang/base-iminling-core.git")
 url.set("https://github.com/konghanghang/base-iminling-core")
 }
 }
 }
 }

 repositories {
 maven {
 name = "mavenCentral"
 // change URLs to point to your repos, e.g. http://my.org/repo
 // val releasesRepoUrl = uri(layout.buildDirectory.dir("repos/releases"))
 val releasesRepoUrl = uri("https://oss.sonatype.org/service/local/staging/deploy/maven2/")
 val snapshotsRepoUrl = uri("https://oss.sonatype.org/content/repositories/snapshots")
 url = if (version.toString().endsWith("SNAPSHOT")) snapshotsRepoUrl else releasesRepoUrl
 credentials {
 // System.getenv放在.bash_profile中
 // System.getProperty可以放在命令行也可以放在gradle.properties中
 username = System.getProperty("SONATYPE_NEXUS_USERNAME")
 password = System.getProperty("SONATYPE_NEXUS_PASSWORD")
 }
 }
 }

 signing {
 sign(publishing.publications["mavenJava"])
 }

 tasks.javadoc {
 if (JavaVersion.current().isJava9Compatible) {
 (options as StandardJavadocDocletOptions).addBooleanOption("html5", true)
 }
 (options as StandardJavadocDocletOptions).encoding("UTF-8")
 }
}

整个publishing共分为四部分：

publications

指定jar的version，groupId和artifactId。另外还有pom的信息，这个在使用maven发布的时候也设置过

repositories

指定仓库地址，以及配置sonetype的账号和密码，可以放在用户目录的gradle.properties中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# k @ MacBook-Pro in ~/.gradle [9:30:05]
$ pwd
/Users/k/.gradle

# k @ MacBook-Pro in ~/.gradle [9:30:06]
$ ls
caches gradle.properties kotlin-profile notifications wrapper
daemon jdks native workers
# k @ MacBook-Pro in ~/.gradle [9:30:09]
$ cat gradle.properties
systemProp.SONATYPE_NEXUS_USERNAME=aaa
systemProp.SONATYPE_NEXUS_PASSWORD=aaa

如上在gradle.properties中以key-value的形式进行配置。另外同时配置了快照版本的发布地址和release版本的发布地址，通过项目的版本好结尾是不是SNAPSHOT来确定到底是发布到哪里。

signing

指定签名哪个publications，名字要和上边publications中配置的名称一致。另外有一点还需要特别进行配置，我maven发布的时候使用gpg生成了key，在使用gradle的时候还需要导出私钥，同样是导出到用户家目录下的.gnupg目录下，进入到此目录执行gpg --export-secret-keys -o secring.gpg ：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# k @ MacBook-Pro in ~ [9:39:08] C:1
$ cd .gnupg

# k @ MacBook-Pro in ~/.gnupg [9:39:13]
$ ls
common.conf openpgp-revocs.d public-keys.d trustdb.gpg
crls.d private-keys-v1.d secring.gpg

# k @ MacBook-Pro in ~/.gnupg [9:39:14]
$ gpg --export-secret-keys -o secring.gpg

会生成一个secring.gpg的文件，这时候需要在/Users/k/.gradle/gradle.properties进行配置

1
2
3
4
5
6
7


# k @ MacBook-Pro in ~/.gradle [9:41:37]
$ cat gradle.properties
signing.keyId=44405DA7
signing.password=12345
signing.secretKeyRingFile=/Users/k/.gnupg/secring.gpg
systemProp.SONATYPE_NEXUS_USERNAME=aa
systemProp.SONATYPE_NEXUS_PASSWORD=aa

上边有三个参数，keyId使用gpg –list-keys中展示出来的pub下C87B0403E54CD05D431E5C1A7204BFB944405DA7 中的后8位。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$ gpg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2023-02-20
/c/Users/aaa/.gnupg/pubring.kbx
---------------------------------
pub rsa2048 2021-02-20 [SC] [expires: 2023-02-20]
 C87B0403E54CD05D431E5C1A7204BFB944405DA7
uid [ultimate] ysl <ysl@test.com>
sub rsa2048 2021-02-20 [E] [expires: 2023-02-20]

password则是生成gpg key的时候输入的密码，这个在maven发布的那篇文章中讲过，有不清楚的可以再去看一下那篇文章。

secretKeyRingFile则是刚才使用gpg导出的文件。

签名相关的配置就已经配置完成了。

javadoc

这个配置相对简单，指定编码。

经过上边的配置基本就已经完成了，可以去发布了。

发布

publishing下有几个选项，主要用的还是publishToMavenLocal，这个是发布到本地的maven仓库，可以在本地测试使用。另外就是publish直接往maven仓库中发布。

双击上边的任务进行运行，或者直接在终端使用gradle + 具体的参数来运行，比如：gradle publishToMavenLocal 。

遇到的问题

在经过上边配置后发现发布到maven仓库里的只有.moudle的文件，并没有我们的jar和doc相关的文件，经过网上查询添加以下配置就可以了：

1
2
3
4


// 解决打包后生成.module文件，导致发布到中央仓库时只上传了.module文件没有上传jar文件
tasks.withType<GenerateModuleMetadata> {
 enabled = false
}

以上就是使用gradle发布jar到中央仓库的折腾过程。

参考：

Publishing a project as module

发布个人项目的jar包文件到maven中央仓库

Wed, 08 May 2024 14:33:57 +0000

自己有一个项目想要在任何机器上都能引用到，最简单的办法就是在所要使用的机器上把项目下载下来，然后install到本地仓库，但是如何直接通过引用坐标就能引用到呢？答案就是发布到maven的中央仓库，这样子无论你在什么机器上，只要能上网输入gav三个坐标就可以引入了。这篇文章就介绍一下自己项目打成jar包并发布到maven中央仓库的完整过程。mac安装maven可以参考我的另一篇文章：Mac使用Homebrew安装maven环境。

账号注册

首先我们要先注册sonatype账号，访问地址sonatype输入必须的内容就可以成功注册一个账号,不过对密码就有一些特殊的安全要求，正确注册就可以了。

sonatype工单

新建工单

点击新建按钮，项目选择open的那个，问题类型选择new project，概要，描述随便写就ok了

摘要根据自己需要填写，我这里填写的是项目的名称。

group id就是maven坐标的名称，一般是域名反转过来。例如我的域名是iminling.com,则这里填写com.imining.

project URL则是github的仓库地址，或者其他代码仓库的地址。

SCM url就是在project URL后边加上.git

其他的默认就可以了，创建。新建完成后如下图：

添加TXT记录

如上边的图所示，它为了验证你是域名的所有者，会让你去解析一条txt记录。两种方案选一种就可以了，我这里选择的是添加一条txt的记录，如下图所示，我这里是不清楚规则，提交了两个工单，所以添加了两条记录，最后其中一个工单被认为是重复提交，已关闭。其中记录值填写你的工单地址，下图中框住的部分，主机记录就是jira tiket.

这里txt解析的值来源就是你的问题url，如下：

解析完后就可以再等待审核了，我的大概是凌晨3点进行的审核，通过以后会有邮件通知，工单下边也有评论,此时我们就可以准备发布我们的jar包了。

1
2
3
4
5
6
7
8


com.iminling has been prepared, now user(s) yslaoo can:
Publish snapshot and release artifacts to https://oss.sonatype.org
Have a look at this section of our official guide for deployment instructions:
https://central.sonatype.org/pages/ossrh-guide.html#deployment

Please comment on this ticket when you've released your first component(s), so we can activate the sync to Maven Central.
Depending on your build configuration, this might happen automatically. If not, you can follow the steps in this section of our guide:
https://central.sonatype.org/pages/releasing-the-deployment.html

发布准备

gpg安装

mac可以使用用brew进行安装 brew install gpg就可以了。

windows安装了git客户端就自带了这个功能。

检查自己的gpg的版本，有些是gpg，有些则需要输入gpg2.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 或者使用gpg2 --version 就看自己的电脑上哪个命令可以运行
$ gpg --version
gpg (GnuPG) 2.2.13-unknown
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /c/Users
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
 CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

生成key

不论是mac还是windows都是使用命令gpg --gen-key来生成。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


$ gpg --gen-key
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

注意：使用 “gpg --full-generate-key” 以获得一个功能完整的密钥产生对话框。

GnuPG 需要构建用户标识以辨认您的密钥。

真实姓名： yslaoo
电子邮件地址： ysl@test.com
您选定了此用户标识：
 “ysl <ysl@test.com>”

更改姓名（N）、注释（C）、电子邮件地址（E）或确定（O）/退出（Q）？ O
我们需要生成大量的随机字节。在质数生成期间做些其他操作（敲打键盘
、移动鼠标、读写硬盘之类的）将会是一个不错的主意；这会让随机数
发生器有更好的机会获得足够的熵。
我们需要生成大量的随机字节。在质数生成期间做些其他操作（敲打键盘
、移动鼠标、读写硬盘之类的）将会是一个不错的主意；这会让随机数
发生器有更好的机会获得足够的熵。
gpg: /Users/aaa/.gnupg/trustdb.gpg：建立了信任度数据库
gpg: 密钥 84040E735F931A32 被标记为绝对信任
gpg: 目录‘/Users/aaa/.gnupg/openpgp-revocs.d’已创建
gpg: 吊销证书已被存储为‘/Users/aaa/.gnupg/openpgp-revocs.d/DD1E1B8213D07DA46FC3F2B684040E735F931A32.rev’
公钥和私钥已经生成并被签名。

pub rsa3072 2021-02-20 [SC] [有效至：2023-02-20]
 DD1E1B8213A07DA46FC3F2B684040E735F931A32
uid yslao <yslao@outlook.com>
sub rsa3072 2021-02-20 [E] [有效至：2023-02-20]

期间会让输入密码，牢记密码，后边会使用。

key操作

生成key后需要发布key到公有服务器。

先查看key：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$ gpg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2023-02-20
/c/Users/aaa/.gnupg/pubring.kbx
---------------------------------
pub rsa2048 2021-02-20 [SC] [expires: 2023-02-20]
 C87B0403E54CD05D431E5C1A7204BFB944405DA7
uid [ultimate] ysl <ysl@test.com>
sub rsa2048 2021-02-20 [E] [expires: 2023-02-20]

然后发布：

1
2
3


# 命令格式：gpg --keyserver [key的服务器](这个有很多，随便找一个就行了) --send-keys [key] key就是查看key操作中pub对应的那串字符串
$ gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys C87B0403E54CD05D431E5C1A7204BFB944405DA7
gpg: sending key 7204BFB944405DA7 to hkp://keyserver.ubuntu.com:11371

Distribution 管理

修改pom.xml, 添加以下代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


<!--父级是project-->
<distributionManagement>
 <snapshotRepository>
 <id>ossrh</id>
 <url>https://oss.sonatype.org/content/repositories/snapshots</url>
 </snapshotRepository>
 <repository>
 <id>ossrh</id>
 <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
 </repository>
</distributionManagement>

<build>
 <plugins>
 <plugin>
 <groupId>org.sonatype.plugins</groupId>
 <artifactId>nexus-staging-maven-plugin</artifactId>
 <version>1.6.7</version>
 <extensions>true</extensions>
 <configuration>
 <serverId>ossrh</serverId>
 <nexusUrl>https://oss.sonatype.org/</nexusUrl>
 <autoReleaseAfterClose>true</autoReleaseAfterClose>
 </configuration>
 </plugin>
 </plugins>
</build>

认证配置

在setting.xml中添加认证信息,此处的id要和pom文件中的distributionManagement下snapshotRepository和repository的id保持一致.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<settings>
 <servers>
 <server>
 <id>ossrh</id>
 <!-- username就是注册sonatype时的username -->
 <username>your-jira-id</username>
 <!-- password就是注册sonatype时的password -->
 <password>your-jira-pwd</password>
 </server>
 </servers>
</settings>

javadoc和源代码配置

在pom.xml中添加配置如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


<build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-source-plugin</artifactId>
 <version>2.2.1</version>
 <executions>
 <execution>
 <id>attach-sources</id>
 <goals>
 <goal>jar-no-fork</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-javadoc-plugin</artifactId>
 <version>2.9.1</version>
 <executions>
 <execution>
 <id>attach-javadocs</id>
 <goals>
 <goal>jar</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 </plugins>
</build>

gpg签名配置

在pom中添加gpg插件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-gpg-plugin</artifactId>
 <version>1.5</version>
 <executions>
 <execution>
 <id>sign-artifacts</id>
 <phase>verify</phase>
 <goals>
 <goal>sign</goal>
 </goals>
 </execution>
 </executions>
</plugin>

在setting.xml中添加gpg profile配置,gpg.executable属性要根据自己的电脑环境进行添加.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


<settings>
 <profiles>
 <profile>
 <id>ossrh</id>
 <activation>
 <activeByDefault>true</activeByDefault>
 </activation>
 <properties>
 <!--这里根据实际情况填写gpg或gpg2,看自己的环境能使用哪个命令-->
 <gpg.executable>gpg2</gpg.executable>
 <!--passphrase就是我们在gpg安装生成key的时候设置的-->
 <gpg.passphrase>the_pass_phrase</gpg.passphrase>
 </properties>
 </profile>
 </profiles>
</settings>

Nexus Staging Maven插件，用于部署和发布

在pom.xml中添加以下内容

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<plugin>
 <groupId>org.sonatype.plugins</groupId>
 <artifactId>nexus-staging-maven-plugin</artifactId>
 <version>1.6.7</version>
 <extensions>true</extensions>
 <configuration>
 <serverId>ossrh</serverId>
 <nexusUrl>https://oss.sonatype.org/</nexusUrl>
 <autoReleaseAfterClose>true</autoReleaseAfterClose>
 </configuration>
</plugin>

经过上边操作，准备工作已完毕，下边就可以开始发布jar包了。

发布

所有的发布操作确保gpg命令是可以用的,在windows下进行发布一定要注意是在git bash客户端中进行,以确保gpg可以使用.以及发布过程中可能会让你再次输入gpg的密码，这里需要注意一下。

快照版本

项目的版本如果是以-SNAPSHOT结尾的,就会发布到快照仓库,如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


D:\project\idea\base-iminling-parent>mvn clean deploy
INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.iminling:base-iminling-parent:pom:1.0.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.sonatype.plugins:nexus-staging-
maven-plugin @ line 326, column 25
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] -----------------< com.iminling:base-iminling-parent >------------------
[INFO] Building base-iminling-parent 1.0.0-SNAPSHOT
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ base-iminling-parent ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ base-iminling-parent ---
[INFO] Installing D:\project\idea\base-iminling-parent\pom.xml to D:\maven-repository\com\iminling\base-iminling-parent\1.0.0-SNAPSHOT\base-iminling-parent-1.0.0-S
NAPSHOT.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ base-iminling-parent ---
Downloading from ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/1.0.0-SNAPSHOT/maven-metadata.xml
Uploading to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/1.0.0-SNAPSHOT/base-iminling-parent-1.0.0-20210220.03
4207-1.pom
Uploaded to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/1.0.0-SNAPSHOT/base-iminling-parent-1.0.0-20210220.034
207-1.pom (14 kB at 4.8 kB/s)
Downloading from ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/maven-metadata.xml
Uploading to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/1.0.0-SNAPSHOT/maven-metadata.xml
Uploaded to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/1.0.0-SNAPSHOT/maven-metadata.xml (609 B at 263 B/s)
Uploading to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/maven-metadata.xml
Uploaded to ossrh: https://oss.sonatype.org/content/repositories/snapshots/com/iminling/base-iminling-parent/maven-metadata.xml (292 B at 54 B/s)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.105 s
[INFO] Finished at: 2021-05-20T11:42:18+08:00
[INFO] ------------------------------------------------------------------------

release版本

项目的版本不是以-SNAPSHOT结尾的,就会发布到release仓库,如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


D:\project\idea\base-iminling-parent>mvn clean deploy
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.iminling:base-iminling-parent:pom:1.0.0
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.sonatype.plugins:nexus-staging-
maven-plugin @ line 326, column 25
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] -----------------< com.iminling:base-iminling-parent >------------------
[INFO] Building base-iminling-parent 1.0.0
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ base-iminling-parent ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ base-iminling-parent ---
[INFO] Installing D:\project\idea\base-iminling-parent\pom.xml to D:\maven-repository\com\iminling\base-iminling-parent\1.0.0\base-iminling-parent-1.0.0.pom
[INFO]
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ base-iminling-parent ---
Uploading to ossrh: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/iminling/base-iminling-parent/1.0.0/base-iminling-parent-1.0.0.pom
Uploaded to ossrh: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/iminling/base-iminling-parent/1.0.0/base-iminling-parent-1.0.0.pom (14 kB at 59
7 B/s)
Downloading from ossrh: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/iminling/base-iminling-parent/maven-metadata.xml
Uploading to ossrh: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/iminling/base-iminling-parent/maven-metadata.xml
Uploaded to ossrh: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/iminling/base-iminling-parent/maven-metadata.xml (312 B at 51 B/s)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 32.049 s
[INFO] Finished at: 2021-02-20T14:11:23+08:00
[INFO] ------------------------------------------------------------------------

遇到的问题

在mac上进行发布的时候遇到下边问题：

1
2
3
4
5
6
7
8
9


[INFO] --- maven-gpg-plugin:1.5:sign (sign-artifacts) @ base-iminling-parent ---
gpg: 签名时失败： Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.069 s
[INFO] Finished at: 2021-02-21T09:36:03+08:00
[INFO] ------------------------------------------------------------------------

上网查询后，原因是 gpg 在当前终端无法弹出密码输入页面。

解决办法很简单在终端执行export GPG_TTY=$(tty) 。重新执行，发现会弹出一个密码输入界面。

同步中央仓库

发布后我们还需要在sonatype中问题下方进行评论,来激活同步到maven中心仓库.

后续的release就可以同步到maven仓库了。

版本引用

release

正常使用gav三个坐标来引入就可以了。可能刚发布的并没有同步到所有的仓库，需要等待同步，例如可以去阿里仓库里搜索几遍，让它去同步。

快照版本

快照版本需要引入仓库地址：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


<!--定义snapshots库的地址-->
<repositories>
 <repository>
 <id>sonatype-snapshots</id>
 <name>sonatype-snapshots</name>
 <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
 <snapshots>
 <enabled>true</enabled>
 </snapshots>
 </repository>
</repositories>
<!--经测试,不要下边的应该也是可以的,留着做不时之需-->
<pluginRepositories>
 <pluginRepository>
 <id>sonatype-snapshots</id>
 <name>sonatype-snapshots</name>
 <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
 <snapshots>
 <enabled>true</enabled>
 </snapshots>
 </pluginRepository>
</pluginRepositories>

上边就是通过maven发布jar包到maven中央仓库的的过程，希望可以帮助到大家。

服务器带宽测速iperf3工具使用

Fri, 03 May 2024 05:52:37 +0000

网络测速相信很多人都使用过，想要看看自己家里的宽带网速怎么样，最简单的方式就是搜索测速网，然后等结果出来就可以了，比较简单。今天要介绍的主角是：iperf3,由于经常要和vps打交到，想要测试本地到服务器的速度，使用iperf3会更准确一点，接下来就介绍一下iperf3，以及如何使用iperf3来进行测试速度。

iperf3是什么

iPerf3 是一种主动测量 IP 网络上可实现的最大带宽的工具。它支持调整与计时、缓冲区和协议（TCP、UDP、SCTP 与 IPv4 和 IPv6）相关的各种参数。对于每次测试，它都会报告带宽、损耗和其他参数。它是一个 C/S 类型的测速工具，在服务器上开放某个端口，然后在客户机上连接该服务器对应的端口，就可以开始进行 tcp 或 udp 的下载速度了

iperf3安装

iperf3的官网也详细介绍了几种操作平台的安装，具体的地址：安装iperf3。下边说明一下几种操作系统的安装。

Windows

直接去官方下载地址：budman.pw或者github去下载安装文件,下载最新的就可以了。

Mac OS

mac可以使用homebrew来进行安装，如果还没有安装homebrew可以参考我的另一篇文章来进行安装：Mac更换源更快速的安装Homebrew.然后通过命令brew install iperf3。

Ubuntu/Debian

使用命令：sudo apt-get install iperf3进行安装。如果当前用户是root用户，则可以省略sudo.

Centos/Red hat

使用命令：yum install iperf3进行安装。

iperf3使用

iperf3分为客户端和服务端，服务端开放端口，客户端则连上对应的端口进行发包，达到测速。下边来使用命令来快速的进行一轮测速：

服务端

服务端执行命令iperf3 -s -p 1111就启动了：

1
2
3
4


root@docker:~# iperf3 -s -p 1111
-----------------------------------------------------------
Server listening on 1111 (test #1)
-----------------------------------------------------------

服务端开启1111端口后就等待客户端连上来。

客户端

客户端执行命令iperf3 -c 192.168.1.222 -p 1111 -i 1 -t 10 ,其中192.168.1.222是你服务端所在服务器的ip，执行后客户端输出如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


$ iperf3 -c 192.168.1.222 -p 1111 -i 1 -t 10

Connecting to host 192.168.1.222, port 1111
Reverse mode, remote host 192.168.1.222 is sending
[ 5] local 192.168.1.10 port 56431 connected to 192.168.1.222 port 1111
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 52.1 MBytes 435 Mbits/sec
[ 5] 1.00-2.00 sec 67.4 MBytes 567 Mbits/sec
[ 5] 2.00-3.00 sec 58.6 MBytes 492 Mbits/sec
[ 5] 3.00-4.00 sec 71.4 MBytes 600 Mbits/sec
[ 5] 4.00-5.00 sec 69.2 MBytes 579 Mbits/sec
[ 5] 5.00-6.00 sec 69.8 MBytes 586 Mbits/sec
[ 5] 6.00-7.00 sec 67.5 MBytes 568 Mbits/sec
[ 5] 7.00-8.00 sec 70.9 MBytes 593 Mbits/sec
[ 5] 8.00-9.00 sec 73.1 MBytes 613 Mbits/sec
[ 5] 9.00-10.00 sec 73.1 MBytes 613 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 676 MBytes 565 Mbits/sec 2 sender
[ 5] 0.00-10.00 sec 673 MBytes 564 Mbits/sec receiver

iperf Done.

一次测速就完成了。服务端也会有同样的日志输出。可见速度大概是500Mb/s。

参数详解

具体的参数详细解释可以参考官网的文档;这里我也简单的介绍一下。

通用参数

通用参数就是客户端和服务端都可以使用的参数。

命令行选项	说明
-p, –port n	服务器侦听和客户端连接的服务器端口。这在客户端和服务器中应该是相同的。默认值为 5201。
–cport n	指定客户端端端口的选项。(iPerf 3.13 新特性)
-f, –format [kmKM]	指定打印带宽数字的格式的命令字。支持的格式有 ‘k’ = Kbits/sec ‘K’ = KBytes/sec ’m’ = Mbits/sec ‘M’ = MBytes/sec 自适应格式根据需要在千级和兆级之间进行选择。
-i, –interval n	设置周期性带宽、抖动和丢失报告之间的间隔时间（以秒为单位）。如果非零，则自上次报告以来每隔 n 秒带宽参数会生成一份报告。如果为零，则只打印定期报告。默认认为零。
-F, –file name	客户端：从文件中读取并写入网络，而不是使用随机数据；服务器端：从网络读取并写入文件，而不是丢弃数据。
-A, –affinity n/n,m/m-f	如果可能的话，设置 CPU 关联性（仅限 Linux 和 FreeBSD）。在客户端和服务器上，您可以使用此参数以 n 的形式（其中 n 是 CPU 编号）来设置本地关联性。在客户端，您可以使用 n,m 形式的参数覆盖服务器的关联性，仅用于测试。请注意，使用此功能时，进程将仅绑定到单个 CPU（而不是包含潜在多个 CPU 的集合）。
-B, –bind host	绑定到特定网卡，即该计算机的地址之一。对于客户端，这设置输出的网卡接口。对于服务器端，这设置传入网卡接口。这仅在具有多个网卡接口的多宿主主机上有用。
-V, –verbose	给出更详细的输出
-J, –json	以 JSON 格式输出
–logfile file	将输出发送到日志文件。(iPerf 3.13 新特性)
-d, –debug	发出调试输出。主要供开发人员使用。
-v, –version	显示版本信息并退出。
-h, –help	显示帮助概要并退出。

以上是通用的参数说明，可以根据需求在执行命令的时候添加。

服务端参数

下边对服务端特有参数进行说明：

命令行选项	说明
-s, –server	在服务器模式下运行 iPerf。（这一次只允许一个 iperf 连接）
-D, –daemon	服务器作为守护进程在后台运行。
-I, –pidfile file	写入一个包含进程 ID 的文件，这在作为守护进程运行时最有用。（iPerf 3.1 新特性）

服务端的命令选项相对来说少一些。

客户端参数

下边对客户端特有参数进行说明：

命令行选项	说明
-c, –client host	在客户端模式下运行 iPerf，连接到主机上运行的 iPerf 服务器。
–sctp	使用 SCTP 而不是 TCP（Linux、FreeBSD 和 Solaris）。 (iPerf 3.1新特性)
-u, –udp	使用 UDP 而不是 TCP。另请参阅 -b 选项。
-b, –bandwidth n[KM]	将目标带宽设置为 n 位/秒（UDP 默认为 1 Mbit/秒，TCP 无限制）。如有多个流（-P 标志），带宽限制单独应用于每个流。可向带宽说明符添加“/”和数字，称为“突发模式”，将发送给定数量的数据包而不暂停，即使暂时超出指定带宽限制。
-t, –time n	传输时间（以秒为单位）。iPerf 通常通过在 time 秒内重复发送 len 个字节的数组来工作。默认值为 10 秒。另请参见 -l、-k 和 -n 选项。
-n, –num n[KM]	要传输的缓冲区数量。通常 iPerf 发送 10 秒。-n 选项会覆盖此设置并发送 len 个字节的数组 num 次，无论需要多长时间。另请参见 -l、-k 和 -t 选项。
-k, –blockcount n[KM]	要传输的块（数据包）数量。（而不是 -t 或 -n）另请参阅 -t、-l 和 -n 选项。
-l, –length n[KM]	要读取或写入的缓冲区的长度。iPerf 的工作原理是多次写入 len 个字节的数组。TCP 默认为 128 KB，UDP 默认为 8 KB。另请参见 -n、-k 和 -t 选项。
-P, –parallel n	与服务器建立的同时连接数。默认值为 1。
-R, –reverse	以反向模式运行（服务器发送，客户端接收）。
-w, –window n[KM]	将套接字缓冲区大小设置为指定值。对于 TCP，这设置 TCP 窗口大小。（这会被发送到服务器并在该端使用）
-M, –set-mss n	尝试设置 TCP 最大分段大小 (MSS)。MSS 通常为 MTU - 40 字节。例如以太网，MSS 为 1460 字节（1500 字节 MTU）。
-N, –no-delay	设置 TCP 无延迟选项，禁用 Nagle 算法。通常仅交互式应用（如 telnet）禁用此功能。
-4, –version4	仅使用 IPv4。
-6, –version6	仅使用 IPv6。
-S, –tos n	传出数据包的服务类型。可用“0x”前缀的十六进制、0 前缀的八进制或十进制。常用值： IPTOS_LOWDELAY 0x10 IPTOS_THROUGHPUT 0x08 IPTOS_RELIABILITY 0x04 IPTOS_LOWCOST 0x02
-L, –flowlabel n	设置 IPv6 流标签（目前仅在 Linux 上支持）。
-Z, –zerocopy	使用“零复制”方法发送数据（如 sendfile(2)），而非通常的 write(2)。减少 CPU 使用率。
-O, –omit n	省略测试的前 n 秒，以跳过 TCP 慢启动期。
-T, –title str	使用此字符串作为每个输出行的前缀。
-C, –linux-congestion algo	设置拥塞控制算法（仅 iPerf 3.0 Linux，iPerf 3.1 支持 Linux 和 FreeBSD）。

以上就是服务端和客户端的所有参数说明。

搭建属于自己的影视小站：小雅Alist安装及使用

Sat, 20 Apr 2024 06:39:56 +0000

之前一直在使用其他的影视站去看一些电影，这些影视站基本网速都比较慢，画质也都一般，观看体验也不怎么好，这里顺便也分享一下我一直使用的影视站：影视森林，该站整理了一些比较不错的影视站。偶然的机会下了解到了小雅(xiaoya)Alist，搭配阿里云盘简直不要太爽，作者也在一直更新资源，非常推荐自己搭建，下边就简单介绍一下我的搭建过程以及一些使用。

准备工作

在进行安装前需要先获取三个东西：token,open token以及folder id,下边介绍一下如何获取这几个信息。另外需要在机器上安装docker，因为小雅Alist是使用docker镜像来安装的，如果本机还没有安装docker,可以参考我的文章：docker安装来安装docker。

token

打开网站：https://aliyuntoken.vercel.app/，会出现二维码，使用手机端的阿里云盘扫描就可以获取到token。先记录下。

open token

打开网站：Get Aliyundrive Refresh Token，首先点击Scan QrCode获取二维码，然后使用手机端阿里云盘扫描，扫描完成后再点击I have scan 来获取refresh token。同时记录下这个token。

folder id

打开小雅的分享地址：https://www.alipan.com/s/rP9gP3h9asE，将里边的内容转存到自己的网盘下，选择资源库。

然后进入到自己的阿里云盘，打开刚才转存的目录，看地址栏，最后那一串字符串就是需要的folder id.记录改folder id.

经过上边几步，已经准备好了所需要的三个必须信息，下边就开始安装小雅Alist。

小雅Alist安装

安装有几种方式，小雅也有提供一键安装脚本，比较方便，下边我介绍一下几种安装方式。

一键脚本

这种方式最简单，在获取了上边的信息后，就可以直接在vps或者自己的电脑上进行安装，打开命令窗口(终端)执行一键安装脚本：bash -c “$(curl http://docker.xiaoya.pro/update_new.sh)"，执行后会提示输入token（32位）、open Token也就是刚才的refresh Token(335位)以及folder id(40位)，输入完成后就开始了安装，等待结束就可以了。通过docker 命令docker ps来查看安装情况,看是否有一个容器名称为xiaoya,存在就说明安装成功。

一键脚本安装的小雅默认配置文件是在/etc/xiaoya目录下，后续的配置文件都需要往这个文件下配置。

docker命令

上边介绍了一键脚本，本质上也是使用docker命令来安装的，如果我们想要自己控制配置放在什么地址，可以把脚本下载下来自行修改，或者来进行docker的配置安装。

比如我想把配置文件放在/data/xiaoya下，那么我需要在data/xiaoya目录下先新建三个文件:

mytoken.txt：把信息准备中的token字符串放在这个文件里。
myopentoken.txt：把信息准备中的refresh Token字符串放在这个文件里
temp_transfer_folder_id.txt：把folder id字符串放在这个文件里。

此时准备工作就完成了，可以来使用命令来安装小雅了： docker run -d --network=host -v /data/xiaoya:/data --restart=always --name=xiaoya xiaoyaliu/alist:hostmode,等待安装完成，同样通过docker ps来查看是否启动成功，后续所有的配置文件都放在/data/xiaoya目录下。

docker compose安装

这种是我最常用的方式，容器的配置都放在compose文件中，方便管理。和docker安装差不多，也是先需要将三个文件创建出来，目录结构如下：

1
2
3
4
5
6
7
8


root@docker:~/xiaoya# tree -l
.
├── data
│ ├── docker_address.txt
│ ├── myopentoken.txt
│ ├── mytoken.txt
│ └── temp_transfer_folder_id.txt
└── docker-compose.yaml

docker-compose.yaml文件内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


root@docker:~/xiaoya# cat docker-compose.yaml
version: '3.9'
services:
 xiaoya:
 image: xiaoyaliu/alist:latest
 container_name: xiaoya
 env_file:
 - .env
 restart: unless-stopped
 ports:
 - 5678:80
 - 2345:2345
 - 2346:2346
 volumes:
 - ./data:/data
 environment:
 - TZ=Asia/Shanghai

然后在~/xiaoya目录下执行 docker compose up -d启动就可以了。

经过上边的安装已经可以通过你的机器ip:5678来访问了。

播放

经过上边安装默认情况下已经可以正常使用了，在网页端找到自己想观看的电影，直接在网页端观看，或者在视频播放器下边的按钮里选择自己本地已安装的程序打开进行播放,例如下边有iina,VLC等播放器，自己在本地安装就可以了。

也可以在小雅Alist中找到对应的安装包，也提供了很多播放器的安装包：

安卓手机

想要在安卓手机上使用alist,我是使用tvbox来观看的，在小雅Alist提供的安装包里也是有tvbox的，需要在配置文件目录新建一个docker_address.txt文件，里边填写http://xxxxx:5678，网址最后不需要/, xxx替换为自己的vps的ip，或者搭建机器的内网ip。

安卓手机正常安装后进行配置：http://xxxxx:5678/tvbox/my.json。

如果同时有内网以及外网地址，那么想要在公网访问，则需要再多建一个docker_address_ext.txt,里边需要填写公网的ip:端口,然后在tvbox中进行配置:http://xxxxx:5678/tvbox/my_ext.json就可以了。

电视端

其实和安卓端是一样的，安装tvbox(安装包也是在小雅Alist中获取)，按照安卓的配置方式，进行配置后就可以观看了。

配置

登录配置

如果你搭建的机器是公网的，又不想别人随便使用，可以通过配置，需要使用账号和密码来登录，需要在配置文件目录添加两个文件:guestlogin.txt,和guestpass.txt两个文件，guestlogin.txt控制Alist网页端需要登录，只是一个空文件就可以了，guestpass.txt里边内容是登录密码，这样子访问你的Alist就需要账号和密码了，账号是：dav，密码是guestpass.txt中的内容。

其他配置暂时也没有使用到，后续有使用到再进行更新，祝大家都能顺利安装成功。

Proxmox VE(PVE)8.0使用CT模板创建LXC版docker服务

Wed, 27 Mar 2024 15:28:11 +0000

前边已经分享了PVE的安装，pve下安装爱快(ikuai)以及pve下安装openwrt实现旁路由，还想要弄一个docker来跑一些其他的服务，docker的安装有两种方式，一种是装一个linux的虚拟机，然后在里边来跑docker,另一种就是今天要介绍的使用CT模板来创建LXC容器跑docker。

CT模板下载

我这里使用的是debain12来当作模板，可以在pve里下载该模板。

创建CT

常规

点击创建CT,这里的主机名随便给一个，因为我这里是要专门来运行docker,所以我这里填：docker, 密码是这个容器的登录密码，一定要牢记。另外要把无特权的容器取消勾选。

模板

模板选择下载的debian模板

磁盘

磁盘大小根据自己的实际需要给

CPU

cpu把j4125的4核都给过去

内存

我这里先给2GB，后续根据需求再添加

网络

我这里手动指定了ip，可以使用dhcp自动分配ip

DNS

dns默认

确认

刚才设置的一些信息的预览

创建完成后先不要开机，还需要一些其他的一些配置。

功能

在功能里勾选NFS等选项

LXC配置文件

还需要进入pve的shell,对刚创建的LXC容器的配置文件进行修改，位置：/etc/pve/lxc,此时里边应该只有1个配置文件，文件名对应创建的lxc容器在pve里的id。我的是102.conf

需要在后边再添加几行：

1
2
3
4
5
6


lxc.apparmor.profile: unconfined # 表示容器内的进程将不受任何 AppArmor 限制
lxc.mount.auto: cgroup:rw
lxc.mount.auto: proc:rw
lxc.mount.auto: sys:rw
lxc.cap.drop: # 用于指定容器内进程的能力限制，允许进程执行一些特定的操作，例如修改系统时间、挂载文件系统等
lxc.cgroup.devices.allow: a

完整的配置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


root@pve:/etc/pve/lxc# cat 102.conf
arch: amd64
cores: 4
features: fuse=1,mount=nfs;cifs,nesting=1
hostname: docker
memory: 4096
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.253,hwaddr=BA:64:EF:29:04:A6,ip=192.168.1.22/24,type=veth
ostype: debian
rootfs: local-lvm:vm-102-disk-0,size=30G
swap: 512
lxc.apparmor.profile: unconfined
lxc.mount.auto: cgroup:rw
lxc.mount.auto: proc:rw
lxc.mount.auto: sys:rw
lxc.cap.drop:
lxc.cgroup.devices.allow: a

配置完成后就可以正常启动该容器了。

更换源

源文件路径：/etc/apt/sources.list,替换为下边的内容。

1
2
3
4


root@docker:/etc/apt# cat sources.list
deb https://mirrors.ustc.edu.cn/debian bookworm main contrib
deb https://mirrors.ustc.edu.cn/debian bookworm-updates main contrib
deb https://mirrors.ustc.edu.cn/debian-security bookworm-security main contrib

查看是否替换成功，执行命令apt update:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


root@docker:/etc/apt# apt update
Hit:1 https://mirrors.ustc.edu.cn/debian bookworm InRelease
Get:2 https://mirrors.ustc.edu.cn/debian bookworm-updates InRelease [55.4 kB]
Get:3 https://mirrors.ustc.edu.cn/debian-security bookworm-security InRelease [48.0 kB]
Get:4 https://mirrors.ustc.edu.cn/debian-security bookworm-security/main amd64 Packages [148 kB]
Hit:5 https://download.docker.com/linux/debian bookworm InRelease
Fetched 251 kB in 1s (228 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
51 packages can be upgraded. Run 'apt list --upgradable' to see them.

可见已经替换成功。

SSH登录

默认情况下只能通过pve的控制台进行登录，无法在其他地方进行登录。

修改sshd的配置文件，文件路径：/etc/ssh/sshd_config,添加下边的内容：允许root登录，开启key登录：

1
2
3


PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

如果只想使用key登录，禁止密码登录可以再添加一行：PasswordAuthentication no 。根据自己需求添加。

时区设置

默认情况下是0时区：

1
2
3
4


root@docker:~# date
Sun Mar 24 07:04:09 UTC 2024
root@docker:~# date -R
Sun, 24 Mar 2024 07:04:11 +0000

修改为北京时间：

1
2
3
4
5
6
7
8
9


root@docker:~# timedatectl set-timezone Asia/Shanghai
root@docker:~# timedatectl
 Local time: Sun 2024-03-24 15:06:22 CST
 Universal time: Sun 2024-03-24 07:06:22 UTC
 RTC time: n/a
 Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
 NTP service: inactive
 RTC in local TZ: no

可以看到已成功设置为北京时间了。

整个LXC容器已设置完成。

Proxmox VE(PVE)8.0换中科大源

Tue, 26 Mar 2024 23:45:43 +0000

前边介绍了PVE的安装，Proxmox VE(PVE)8.0的底层使用的是debian12，默认的源在国外下载速度非常慢，甚至可能连接失败，所以需要更换一下默认源为中科大的源来加快下载以及更新软件的速度。

APT源

需要修改三个文件

sources.list

位置在/etc/apt/sources.list,这个文件里默认有三行：

1
2
3
4
5
6
7


root@pve:~# cat /etc/apt/sources.list
deb http://ftp.debian.org/debian bookworm main contrib

deb http://ftp.debian.org/debian bookworm-updates main contrib

# security updates
deb http://security.debian.org bookworm-security main contrib

替换为一下三条：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


root@pve:~# cat /etc/apt/sources.list
#deb http://ftp.debian.org/debian bookworm main contrib
deb https://mirrors.ustc.edu.cn/debian bookworm main contrib

#deb http://ftp.debian.org/debian bookworm-updates main contrib
deb https://mirrors.ustc.edu.cn/debian bookworm-updates main contrib

# security updates
#deb http://security.debian.org bookworm-security main contrib
deb https://mirrors.ustc.edu.cn/debian-security bookworm-security main contrib

或使用一键命令进行替换：

1
2


sed -i 's|^deb http://ftp.debian.org|deb https://mirrors.ustc.edu.cn|g' /etc/apt/sources.list
sed -i 's|^deb http://security.debian.org|deb https://mirrors.ustc.edu.cn/debian-security|g' /etc/apt/sources.list

最主要的就是 http://ftp.debain.org 替换为 https://mirrors.ustc.edu.cn , http://security.debian.org 替换为 https://mirrors.ustc.edu.cn/debian-security 。

ceph.list

位置：/etc/apt/sources.list.d/ceph.list,原始内容如下：

1
2


root@pve:~# cat /etc/apt/sources.list.d/ceph.list
deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise

替换为：

1
2
3


root@pve:~# cat /etc/apt/sources.list.d/ceph.list
#deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise
deb https://mirrors.ustc.edu.cn/proxmox/debian/ceph-quincy bookworm no-subscription

替换完成。

pve-enterprise.list

位置是：/etc/apt/sources.list.d/pve-enterprise.list,这个是pve企业的源，没有订阅pve也就没什么用，直接把这个文件里的内容注释了。

1
2


root@pve:~# cat /etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

到这里apt的源就替换完成了，可以执行apt udpate来看一下是否更换成功。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


root@pve:~# apt update
Hit:1 https://mirrors.ustc.edu.cn/debian bookworm InRelease
Get:2 https://mirrors.ustc.edu.cn/debian bookworm-updates InRelease [55.4 kB]
Get:3 https://mirrors.ustc.edu.cn/debian-security bookworm-security InRelease [48.0 kB]
Hit:4 https://mirrors.ustc.edu.cn/proxmox/debian/ceph-quincy bookworm InRelease
Get:5 https://mirrors.ustc.edu.cn/debian-security bookworm-security/main amd64 Packages [148 kB]
Fetched 251 kB in 1s (300 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
94 packages can be upgraded. Run 'apt list --upgradable' to see them.

已经使用了中科大的源了，替换成功。

CT模板源

文件位置：/usr/share/perl5/PVE/APLInfo.pm，需要替换 http://download.proxmox.com 为 https://mirrors.ustc.edu.cn/proxmox,可以执行命令：

1

sed -i 's|http://download.proxmox.com|https://mirrors.ustc.edu.cn/proxmox|g' /usr/share/perl5/PVE/APLInfo.pm

或者通过直接修改APLInfo.pm的内容进行修改，替换后的内容如下：

1
2
3
4
5
6


my $sources = [
 {
 host => "download.proxmox.com",
 url => "https://mirrors.ustc.edu.cn/proxmox/images",
 file => 'aplinfo-pve-8.dat',
 }

保存后进行重启pvedaemon：systemctl restart pvedaemon.service 。

整个pve的源就替换完成了。

Proxmox VE(PVE)8.0无法访问网络排查

Tue, 26 Mar 2024 05:34:09 +0000

前边介绍了roxmox VE(PVE)的安装，一直也没有在pve中进行过联网动作，直到今天想要在pve中运行LXC容器，需要下载CT模板的时候才发现原来pve是无法联网的，于是又开始了折腾pve的网络了。

情况说明

在我下载CT模板的时候模板列表是能出来的，但是当点击下载后，等待一段时间后就提示无法下载，但是那个地址我直接在浏览器中访问是可以的。在pve的shell中ping一些地址提示：Destination Host Unreachable，如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


root@pve:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 192.168.1.251 icmp_seq=1 Destination Host Unreachable
From 192.168.1.251 icmp_seq=2 Destination Host Unreachable
From 192.168.1.251 icmp_seq=3 Destination Host Unreachable
From 192.168.1.251 icmp_seq=4 Destination Host Unreachable
^C
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4065ms
pipe 4

但是ping内网的网段是完全ok的，可见是内网通，只是无法连接到互联网。

问题分析

在遇到上边问题后，我也上网找了一些解决办法，大部分都是说DNS服务器设置的不对，第一个为lan，第二个为阿里的dns服务器，第三个为爱快(ikuai)的地址，这样子设置后发现还是同样的问题。

后来在网络配置中发现了问题，这里的网关我配置的是192.168.1.1。

当时安装pve的时候在规划网络时填的是192.168.1.1，但是当安装完pve，进行ikuai配置的时候我改变了注意，把ikuai的地址分配为192.168.1.253，所以导致192.168.1.1其实并没有设备使用，导致pve无法访问网络。

问题解决

既然找到了问题，那就修改一下试一试，于是对pve的网关配置进行修改，把网关地址设置为爱快(ikuai)的地址：

再去pve中进行ping检测，发现已经可以通了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


root@pve:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=152 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=164 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=54 time=166 ms
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 151.887/160.656/165.863/6.236 ms
root@pve:~#

成功的解决了pve无法联网的问题。

使用ITIN注册美区stripe进行收款

Mon, 25 Mar 2024 05:35:52 +0000

很久以前就拿到了ITIN，在这期间使用ITIN也成功的申请到了Capital One(C1)的信用卡和 American Express(AE)的信用卡，今天就来分享一下使用ITIN申请美区的Stripe的经历。

注册

stripe的注册很简单，只需要邮箱就可以注册成功，地址：stripe官网。

验证完毕登录到stripe后就被要求需要激活支付账户。

账户激活

如下图，要求激活账户。

点击激活支付功能

商家类型

地区美国，类型个人。

个人详情

法定名称就是自己的姓名，第一行名，第二行姓。

家庭地址我这里填写的申请ITIN时的地址。

电话号码填写的是GV号

社会保障码后四位：填写ITIN后四位

商家详情

纳税人识别码：填ITIN

商家地址：和上边个人详情的一样

网站：自己的网站

产品描述：介绍一下为何收款，我这里填的是英文的。

公开详情

添加一些描述以及客服地址等信息

银行详情

我这里使用的是revolut的美元账户。

路径号码：ACH号码

账户：银行账号

两步验证

出于安全，添加2FA

税款计算

默认

捐款

拒绝白嫖

摘要

摘要信息

提交等代审核就可以了。

设置账户

进入stripe的首页，提示账户已激活。

但是当我们去创建收款的时候，发现还是不能使用。

点击添加信息，发现还需要再次输入ITIN，提交。

手机号验证

账户详情处进行手机号验证

经过这些处理后基本已经可以正常使用了。

可以在账户状态看是否还需要补充什么信息，如下图就说明完全不需要补充资料了。

账号注册完毕，可以开心收款了。

Proxmox VE(PVE)8.0安装Openwrt实现旁路由模式

Sun, 24 Mar 2024 05:43:31 +0000

在前两篇文章中分别介绍了pve的安装以及pve安装ikuai做为主路由来拨号上网，此时的网络环境基本已经稳定，但出于特殊需求，我需要使用Openwrt来进行科学上网，所以今天就来折腾一下pve安装Openwrt并实现旁路由模式。

openwrt镜像

我使用的是骷髅头的openwrt镜像，下载的是beggar版本，可根据自己的需求找不同的openwrt版本。下载完成后需要对文件进行解压，下载下来的是.gz结尾的文件，需要解压成.img结尾的文件，解压后上传到pve中

创建

常规

vm ID默认自增到101(ikuai是100)，名称自己填，我这里填openwrt

操作系统

选择不使用任何介质

系统

全部默认就可以了

磁盘

这里保持默认，后边会进行删除。

CPU

同样把j4125的四个核心都给到它

内存

运行openwrt,1GB的RAM就够用了。

网络

全部默认

确认

确认所有选项是否正确。

没有问题就点完成。

硬件配置

创建过程中选择的硬盘是需要删除的，所以需要对硬件进行一些配置。

移除CD

在硬件配置中将已存在的CD/DVD驱动器移除

分离并移除硬盘

选中硬盘，先进行分离，然后进行移除。

移除

添加磁盘

需要通过进入pve的shell执行命令来导入磁盘,执行命令qm importdisk 虚拟主机编号 /var/lib/vz/template/iso/openwrt镜像名 local-lvm ，虚拟主机编号是在经过上边创建虚拟机后pve生成的一个编号，例如我的是101，openwrt镜像名是在刚开始的时候上传到pve中的名称，我的名称是：openwrt.img. 替换后的命令如下：qm importdisk 101 /var/lib/vz/template/iso/openwrt.img local-lvm。

执行成功后会在硬件中看到一个未使用的磁盘，进行添加。

引导顺序

磁盘添加后需要修改引导为当前的磁盘

经过上边的设置就已经完全ok了，可以来启动openwrt了。

openwrt设置

启动openwrt虚拟机，如下会卡住，敲回车就可以进行下去

回车后如下图，表示启动成功

设置ip

一般固件都有自己的管理ip，可能和我们自己的网络不是在同一个网段，比如我下载这个默认的管理网段是192.168.6.1，我需要改成和我的网络在同一个网段，192.168.1.xxx。

编辑 /etc/config/network，修改如下：

我这里改成192.168.1.254，修改保存后重启openwrt,重启后就可以通过访问192.168.1.254在浏览器中进行相关配置了。

LAN口设置

进入openwrt系统后，首先是对网络接口LAN口进行设置，设置网关为爱快(ikuai)的管理地址，并关闭LAN口的DHCP功能

修改网关

这里需要注意一点，我在刚开始设置的时候并没有设置使用自定义DNS服务器，后边发现openwrt无法上网，最终是填写了一个DNS服务器后才解决的，这里可以使用223.5.5.5或者其他的DNS服务器。

关闭防火墙

接下来关闭openwrt的防火墙

UPNP

开启UPNP

经过上边的设置，openwrt基本已设置完毕，可以开始使用了。

旁路由模式

openwrt做为旁路由，该怎么工作呢，在ikuai设置的时候我设置了31-250的一个DHCP网络段，他们只会经过ikuai来处理流量，那什么设备可以经过这个openwrt旁路由呢？这里就需要在ikuai中进行一些设置了，同样是DHCP服务,我设置了10-30这个ip段的ip的网关为192.168.1.254也就是openwrt的ip，那么这个ip段里的设置的网络就会经过openwrt来处理，满足特定需求了。

因为我是先设置的31-250这个ip段，所以连接上来的设置被优先往这个ip段分配，自己的其他设置如果想要使用openwrt来处理流量，则对特定设置固定ip就可以了，设置他们的ip在10-30之间。

大功告成，使用pve安装ikuai并使用openwrt做为旁路由。

Proxmox VE(PVE)8.0安装爱快ikuai虚拟机并直通网卡

Sun, 24 Mar 2024 04:02:02 +0000

上一篇介绍了在J4125机器上安装pve环境，安装好pve后整个机器还是无法上网的状态，所以接下来就来介绍一下在pve中安装爱快，使用爱快(ikuai)来进行拨号上网，当然也可以直接安装openwrt,出于综合考虑我这里还是安装爱快(ikuai)，会稳定一些，后续再折腾其他的也不影响家人上网。

爱快(ikuai)固件

爱快(ikuai)的固件也不大，直接官网下载就可以了，下载ISO 64位的镜像。把下载的镜像上传到pve中

创建ikuai虚拟机

鼠标右键点击pve选择创建虚拟机：

常规

名称命名为ikuai，其他默认

操作系统

ISO镜像选择上传的爱快镜像：

系统

保持默认继续下一步

磁盘

ikuai我不做其他用处，所以这里给5GB硬盘

CPU

cpu把j4125的四个核心都给它

内存

我这里给2GB的内存

网络

默认

确认

显示ikuai虚拟机的一些信息，确认和我们选择的是否一致

一些基本信息就已经完成了。

添加直通网口

在畅网J4125安装pve 8.0一篇中已经规划了ETH3归为pve的管理口，那么剩下的三个网口都直通给ikuai,让ikuai来管理,选择硬件，然后点击添加，PCI设备，就会弹出下图：

可以看到总共有4个I226-V的网口，04已经被pve管理口使用了，那么可以把01，02，03分别添加到硬件中。

设置引导项

默认优先是从添加的硬盘启动，因为是第一次启动硬盘里还没有数据，所以需要先从上传的ISO文件引导启动，修改启动项为ISO文件

安装

经过上边的设置，下边就可以来真正的安装，点击启动

选择1安装到硬盘，安装成功后就会自动重启。重启后先关闭虚拟机，因为启动项问题还是从镜像启动的，所以先关机然后去调整启动项为硬盘

调整完成后就可以再次启动ikuai虚拟机了。

设置LAN

看到下图说明ikuai已经安装并启动成功了

可以看到上图里有四个网口，eth0-eth3,其中eth0是pve一个虚拟网口，是ikuai的管理网口，其他三个网口是直通的三个PIC网口设备，后边进入ikuai设置界面后会把eth1设置为wan口，用来连接光猫拨号使用。

选择2设置LAN,我规划的ikuai的管理地址是192.168.1.253

设置成功后就可以不用再理pve了，此时可以通过网页进入ikuai的管理页面，浏览器直接访问192.168.1.253(这个根据自己设置的lan地址来进入)，密码都是admin/admin。初次登录会让改密码，修改为自己常用的密码。

配置WAN

进入管理页面后会看到WAN口有异常，先配置WAN口

绑定wan并设置pppoe拨号上网：

设置好WAN后，此时还没有把WAN口和光猫连在一起，网络还是不行，我们先完成一些其他的配置项。

配置LAN

将直通给爱快的其他两个口分配给lan

DHCP配置

对连接上来的设备进行ip地址自动分配

添加一条新的dhcp配置,我这里预留一些ip给自己使用，所以分配的ip是从31到250。

网关：设置为ikuai自己的ip

DNS：设置了一个阿里的和一个114的。

其他默认就好。

然后重启dhcp服务。

UPNP

开启ikuai的UPNP服务

ikuai的设置基本已经设置完毕了。剩下的就是要接入互联网了。

把光猫连在j4125机器的eth1上，路由器接到机器的eth3上来开启wifi，整个家庭的网络就已经通了。

畅网J4125安装Proxmox VE(PVE)8.0

Sat, 23 Mar 2024 09:15:47 +0000

年前综合考虑买了一台畅网的J4125，低功耗，也能满足一些搞机需求。由于一直忙于工作，一直没有时间研究它，最近终于抽空给机器装上了PVE8.0系统，记录一下折腾的过程。

机器配置

畅网J4125

英特尔®第十代Gemini Lake低功耗四核处理器
4个Intel i226-V 2.5G网卡
2条SO-DIMM DDR4 2400MHz（兼容2666/3200MHz）
1个mSATA接口、1个SATA3.0硬盘接口
1个HDMI 1.4接口支持4K（4096x2160@30Hz）
1个DP 1.2接口支持4K（4096x2160@60Hz）
4个USB 3.0
全长miniPCle插槽支持USB信号的4G/WiFi通讯模块
直流DC-12V 55*25输入或凤凰端子供电
支持看门狗、GPIO、PXE无盘启动、网络唤醒

我这边是买了一个梵想的256G mSATA硬盘，另外买了两个三星8GB,3200HZ的内存条，整机的硬件算是完成。

准备工作

U盘

安装PVE需要从U盘进行启动，这里使用ventory来制作启动盘。电脑上插上需要制作启动盘的U盘，然后下载ventory解压后运行ventory2Disk.exe，设备选择自己的U盘，安装就可以了。

PVE下载

直接PVE官网进行下载，根据自己的情况下载，我这里下载的是8.0的版本。

把下载好的pve镜像放到上边制作好的U盘中。

准备工作已完成。

安装PVE

安装的所有截图都来源于网络，因为安装的过程没办法截图，具体的ip地址请以文字中说明的为准。

网段是：192.168.1.xxx

网关：192.168.1.253

pve管理ip：192.168.1.251

网口规划

机器有4个网口，ETH0、ETH1，ETH2，ETH3，我打算是让ETH3来作为管理端口，所以在后边安装的时候选择最后一个网口。

安装

下边就可以开始安装pve了，机器通过HDMI连接到显示器，并连接键盘和鼠标。然后进行开机，我这台机器是按delete键进入bios设置,在Boot选项中选择Boot option #1中选择上边制作的启动盘，然后F10保存重启。

模式选择

开机后就进入了安装，选择第一个模式进行安装：

协议

接下来就是同意协议：

硬盘选择

选择硬盘，选择自己的J4125机器中安装的硬盘，不要选择成了U盘。

地区设置

地区和时区以及键盘设置：

密码设置

管理密码和邮箱设置,密码在后边登录pve的时候要用到，请牢记。

网络设置

接下来的就是重点了，需要指定pve的管理网口以及ip的一些信息

假如我想让我家的所有设置的ip是192.168.1.xxx开头,其中第三位的1可以替换为自己想要的网段，比如：192.168.31.xxx(小米路由器就是用这个网段)

详细说明一下这5个选项：

管理接口：这里在上边也说了，我打算把管理接口放在ETH3，所以我这里选了最后一个：enp4s0.

主机名称：这里可以不用处理，默认就行了。

ip地址：这里的ip是等下在网页登录的地址，根据自己需求来指定，我自己的设置为192.168.1.251,

网关：这里是主路由的地址，比如我在安装pve后想要再装ikuai来拨号上网，并且ikuai的管理ip为：192.168.1.253，那么我这里的网关地址就填这个了。如果你后边的ikuai是其他的ip，替换为自己的。

DNS服务器：填写和网关一样的地址就可以了。

这里的网关如果填错了也没关系，后边在pve里也可以进行修改，如果填错最直接的表现就是pve没办法上网。这个我在折腾的过程中也遇到了。

剩下的就是核对信息，然后进行安装了。等安装完成后会提示让重启。进行重启就可以了，在重启的时候拔掉U盘，防止又从启动盘中进行了启动。

PVE设置

上边安装pve后会进行重启，重启后会进入一个命令界面，需要输入账号和密码才能进入

这时候可以把机器连接到电脑，使用电脑通过网页端来设置pve了。正确的连接方式是：在安装过程中的管理端口连上网线，网线的另一端插入到电脑的网线口，并设置电脑端和pve在同一个网段（这个在上边安装的时候已经说明过），比如我的安装网段是192.168.1.xxx，pve管理ip是：192.168.1.251，那么设置电脑的网络为192.168.1.200就可以了。

设置好后就可以通过网页端访问ip：192.168.1.251:8006来访问了,如果提示不安全则点击高级继续访问：

然后输入用户名和密码进行登录，用户名：root，密码是在安装的时候输入的密码。就进入了pve的管理界面：

网口直通

进入后首先需要设置的就是网口直通，进入pve的shell界面，修改/etc/default/grub文件，修改GRUB_CMDLINE_LINUX_DEFAULT=“quiet"为GRUB_CMDLINE_LINUX_DEFAULT=“quiet intel_iommu=on”

然后执行update-grub更新并重启：

1
2
3
4
5
6
7
8
9


root@pve:~# vim /etc/default/grub
root@pve:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.2.16-3-pve
Found initrd image: /boot/initrd.img-6.2.16-3-pve
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
root@pve:~# reboot

进行到这里pve安装基本已经完成了，截止到现在pve还不可以上网，这个需要在进行爱快(ikuai)安装后，进行拨号上网让整个环境都有网络。后续在进行介绍。

使用fiddler抓包旧版本iTunes并下载ios历史版本软件

Tue, 20 Feb 2024 15:17:33 +0000

最近上车的office365到期了，搜索后发现在苹果土耳其商店使用onedrive可以以23.99里拉每个月的价格来开通office365，算下来一个月6块都不到(土耳其钱包FUPS注册可以参考另一篇文章：土耳其虚拟银行FUPS注册教程)，非常划算，所以就开始折腾。手上的iphone se2的版本是15.5，在商店下载onedrive的时候提示当前版本只支持ios16以及更新的ios版本，我又不想升级手上这个手机的版本，于是就想着通过fiddler抓包来获取ios15支持的版本来进行安装。

旧版本iTunes安装

我这里下载的是12.6.5.3的版本，iTunes的历史版本可以去到wiki百科进行下载：iTunes。这里边包含所有的版本的下载链接，如果打不开wiki百科，可以使用下边这个url进行下载，也是直链苹果官网：iTunes 12.6.5.3。下载正常安装，成功后登录自己的土耳其apple id就可以了。

fiddler安装配置

fiddler直接去官网下载就可以，官网地址：fiddler。安装成功后首先要开启解密https流量，位置：Tools -> Options -> decrypt https traffic，勾选后就会让添加证书到当前电脑，根据弹窗提示进行安装。

添加成功后，把ignore server certificate errors(unsafe)也勾选一下。到这里fiddler就设置好了。

获取oneDrive版本

直接在iTunes中进行搜索，找到oneDrive：

点击查看详情，可以看到一个show all versions的链接，点击查看所有的版本说明：

版本说明如下，可以看到官方的说明，14.21.7是最后一个支持ios15的版本，后续的版本只支持16和17.这个版本就是我需要的版本了。

现在只是知道了版本是哪个，在下载历史版本的时候需要获取一个9位数的id才能正确的下载到对应的版本。所以需要先获取历史版本的id。

获取历史版本id

此时需要使用到fiddler来进行抓包，如果已经启动了fiddler可以先清理一下已经抓取的历史记录,如下图，remove all或者使用快捷键：ctrl+x清除：

清除后在iTunes里进行一次onedrive的下载，此时在fiddler里会有一个pxx-buy开头的url，这个url就是我们需要找的url，在这里边可以获取到onedrive所有的历史版本id，先双击这个url，在右侧就会有信息展示出来，如下：

上图我框起来的有一处是说响应体被加密，需要点击来解密(Response body is encoded. Click to decode)，鼠标点击一下，在textView下就可以找到对应的id了,这个id从上到下一次递增，越新的版本越靠后：

通过上边查看onedrive的版本说明看出是倒数第7个版本，从这个版本列表里倒序去找第7个再下载一下看看是不是需要的版本，我在尝试后发现并不是倒数第7个id，具体的规则也不清楚，但是大概位置不会错，下载后看版本：如果大了就继续倒序往上找，如果小了就正序再往下找。最终我是找到了id：861576168，下边说一下怎么去下载历史版本。

下载历史版本

通过上一步拿到了很多的版本id，倒序从后边先随便找一个id来下载一下看看版本具体是什么。因为在获取版本的时候已经下载过了一次，所以需要在iTunes中把原来的给删除了：

通过文件->资料库->打开Genius来打开已下载的程序,如下选择应用，然后把已经下载的给删除了。

删除成功了后，需要在fiddler程序里输出一下命令: bpu MZBuy.woa。，然后fiddler就可以拦截请求，给咱们机会去修改请求的id，从而达到下载历史版本的需求，输入完需要敲回车，使之生效：

然后就是继续清除fiddler里已经抓取的url方便下边去找url，清除后再去itunes里点击一次下载：

点击下载后，在fiddler里可以看到图标是一个T字的url，它此时已经被拦截了，需要等待我们手动的处理是中断(Break on Response)还是继续运行完成(Run to Completion),此时需要我们在TextView下去修改string包裹的那一串id，替换成需要的历史id，替换完成后，点击Run to Completion就会按照我们替换后的id来继续下载了。下载完成后在文件夹里查看当前下载的文件，就会显示是什么版本：

如上下载到了最终的14.21.7版本。

安装

下载了之后就需要安装到手机上，这里也非常简单，电脑下载爱思助手，选择手动安装软件，选择上边下载好的ipa文件就可以了。

记录如上。愉快的使用oneDrive来购买office365

docker配置fail2ban拦截nginx非法请求ip

Mon, 05 Feb 2024 13:12:33 +0000

前边写过一篇通过fail2ban来拦截ssh暴力破解：docker安装fail2ban并配置防止ssh登录爆破，fail2ban能做到的远不止这些，如果你有一个属于自己的网站，那么一定会遇到有无数不知明ip来访问你网站的敏感路径，总是想着要来获取你网站的一些有用信息。今天我们就来使用fail2ban去拦截那些非法访问的ip地址。

环境与目录情况

fail2ban如上篇：中的安装方式，是使用docker来安装的 nginx也是使用docker来安装的，并使用的是桥接网络。然后再来看一下配置的目录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ tree
.
├── data
│   ├── filter.d
│   │   └── nginx-cc.conf
│   └── jail.d
│   ├── nginx-cc.conf
│   ├── sshd.conf
├── docker-compose.yaml
├── .env
└── logs

如上，需要创建两个文件，一个是针对非法访问的日志的过滤规则，另一个是针对非法访问的ip的监狱规则。我这里暂定这个监狱的名称就叫做：nginx-cc,filter.d和jail.d中的配置文件名称一致。

过滤配置

先来看一下过滤规则的配置：

1
2
3


[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD).*HTTP.*" (404|503) .*$
ignoreregex =.*(robots.txt|favicon.ico|jpg|png)

failregex配置的就是针对错误访问日志进行过滤的正则表达试，以ip开头，并把ip使用<HOST>代替。这里是针对访问状态是404和503的请求。 ignoreregex配置了针对什么样的路径日志进行忽略。

以上是nginx默认日志的访问日志匹配的正则，如果你修改了自己的nginx的访问日志输出格式，则需要按自己的日志输出格式来编写失败请求的正则表达式。

监狱配置

直接先看一下监狱的具体配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[nginx-cc]
enabled = true
filter = nginx-cc
chain = DOCKER-USER
#action = iptables-multiport[name=nginx-cc, port="http,https", protocol=tcp]
port = http,https
logpath = /var/logs/nginx/access.log
maxretry = 3
bantime = 86400
findtime = 3600
ignoreip = 192.168.0.1/24

下边详细说明一下各参数： filter对应的就是上边的过滤规则中的名称 chain为DOCKER-USER,因为nginx是使用docker安装的，所以需要把iptables的规则添加到DOCKER-USER中，DOCKER-USER中的规则在Docker自动创建的任何规则之前加载，拥有更高的优先级。 port满足添加是禁止的端口 logpath读取的日志路径 findtime日志文件中分析错误连接数的时间。以秒计算

启动配置

因为以前已经配置过sshd的监狱，并且fail2ban也是正常运行的，此时只需要对配置进行重新加载就可以了，可以使用以下命令：

1
2


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ docker exec fail2ban fail2ban-client reload
OK

再来查看当前生效的监狱有哪些：

1
2
3
4


ubuntu@VM-20-3-ubuntu:~/images/fail2ban# docker exec fail2ban fail2ban-client status
Status
|- Number of jail: 2
`- Jail list: nginx-cc, sshd

可以看到nginx-cc监狱已经生效了，再来看一下这个监狱的详细情况：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ubuntu@VM-20-3-ubuntu:~/images/fail2ban# docker exec fail2ban fail2ban-client status nginx-cc
Status for the jail: nginx-cc
|- Filter
| |- Currently failed: 0
| |- Total failed: 134
| `- File list: /var/logs/nginx/access.log
`- Actions
 |- Currently banned: 0
 |- Total banned: 21
 `- Banned IP list:

可以看到鉴于的详细信息，此时不出意外就可以拦截到那些异常情况了。

遇到的问题

不出意外，肯定会出意外。我在debian11的机器上安装，请求404的url会被记录到Total failed里，并且请求失败的ip也会出现在Banned Ip list里，但是被ban后竟然还可以访问，此时通过查看fail2ban容器发现竟然添加iptables规则的时候出现了异常。

如上图，出现iptables: No chain/target/match by that name 错误，导致iptables规则添加失败，通过iptables -nvL的确也看不添加的被禁的ip。在网上找了好久不知道是什么原因，后来发现官方的github仓库的说明里就有关于这个的说明crazy-max/docker-fail2ban：

If your system’s iptables tooling uses the nftables backend, this will throw the error stderr: 'iptables: No chain/target/match by that name.'. You need to switch the iptables tooling to ’legacy’ mode to avoid these problems. This is the case on at least Debian 10 (Buster), Ubuntu 19.04, Fedora 29 and newer releases of these distributions by default. RHEL 8 does not support switching to legacy mode, and is therefore currently incompatible with this image.

原来是因为iptable的模式问题，默认debian11使用的nf_tables模式,按照官方的提示需要切换为legacy模式，如何查看自己的iptables是哪种模式呢？可以使用iptables --version来查看，如下就使用的是nf_tables模式。

1
2


ubuntu@VM-20-3-ubuntu:~# iptables --version
iptables v1.8.7 (nf_tables)

那如何修改成legacy模式呢？官方也给了解决方案：

On Ubuntu or Debian：

1
2
3
4


$ update-alternatives --set iptables /usr/sbin/iptables-legacy
$ update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
$ update-alternatives --set arptables /usr/sbin/arptables-legacy
$ update-alternatives --set ebtables /usr/sbin/ebtables-legacy

On Fedora:

1

$ update-alternatives --set iptables /usr/sbin/iptables-legacy

我的系统是debian，所以按照上边的四条来执行，后边两条并没有执行成功，提示没有开启，那就不管了。执行完后可以再使用上边的version命令查看模式是否已经改过来了:

1
2
3


ubuntu@VM-20-3-ubuntu:~/images/fail2ban# iptables --version
iptables v1.8.7 (legacy)
ubuntu@VM-20-3-ubuntu:service networking restart

可以看到，已经切换成功了，并且重启了networking服务。此时再去看禁止ip发现还是不行，仍然可以访问，官方建议重启，我以为重启networking就可以了，但是并不行，最后只好对服务器进行了重启，最终终于生效，成功的对异常访问ip进行了禁止。

以上就是折腾过程，希望可以帮助到大家。

docker安装fail2ban并配置防止ssh登录爆破

Sat, 03 Feb 2024 14:52:53 +0000

平时也没有怎么关注过ssh的日志，而且服务器的ssh登录端口也是默认的22，只是密码设置的相对来说复杂了点，后边听说有人会进行密码爆破，于是就查看了一下ssh的日志，日志路径是/var/log/auth.log，一看整个人都呆了，登录错误的日志不停的刷，都不带停的。如果密码设置的简单点，估计早就被人给试出来了。在网上查询到可以使用fail2ban来进行防御，把经常访问出错的ip加入到iptables中，禁止掉它的访问，于是就开干了，开始摸索fail2ban如何安装使用。

1
2
3
4
5
6


Feb 3 15:04:36 localhost sshd[3030796]: pam_unix(sshd:auth): check pass; user unknown
Feb 3 15:04:36 localhost sshd[3030796]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=170.64.155.113
Feb 3 15:04:37 localhost sshd[3030785]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=104.250.50.16 user=root
Feb 3 15:04:38 localhost sshd[3030796]: Failed password for invalid user es from 170.64.155.113 port 56728 ssh2
Feb 3 15:04:39 localhost sshd[3030796]: Connection closed by invalid user es 170.64.155.113 port 56728 [preauth]
Feb 3 15:04:39 localhost sshd[3030785]: Failed password for root from 104.250.50.16 port 57284 ssh2

安装fail2ban

我这里使用docker进行安装fail2ban,使用的docker镜像地址：crazy-max/docker-fail2ban,目录如下所示：

1
2
3
4
5
6
7
8


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ tree
.
├── data
│   └── jail.d
│   └── sshd.conf
├── docker-compose.yaml
├── .env
└── logs

docker-compose.yaml文件

先看一下docker-compose.yaml的内容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


version: "3"
services:
 fail2ban:
 image: crazymax/fail2ban:latest
 container_name: fail2ban
 restart: unless-stopped
 network_mode: "host"
 cap_add:
 - NET_ADMIN
 - NET_RAW
 env_file:
 - .env
 volumes:
 - ./data:/data
 - ./logs/:/var/log/
 # sshd 日志映射
 - /var/log:/var/logs/sshd:ro
 logging:
 driver: "json-file"
 options:
 max-size: "5m"
 max-file: "10"

这里说明两点，首先是网络模式使用的是host模式，第二，因为我们是要检测暴力破解sshd登录的，所以我们需要读取ssh登录的日志，日志文件路径是/var/log/auth.log,所以在卷挂载那里就把ssh日志的目录进行挂载。

配置监狱拦截

fail2ban中是需要定义监狱(jail)来对访问者进行过滤，每个监狱(jail)可以对应我们的一个服务或者服务的某一个维度，比如我们要对ssh的登录这个场景进行监控，那我们就可以定义一个名称为sshd.conf的监狱配置，这里也是参考github上的示例：sshd.conf,内容如下：

1
2
3
4
5
6
7
8
9


[sshd]
enabled = true
chain = INPUT
# port = ssh
port = 22
filter = sshd[mode=aggressive]
logpath = /var/logs/sshd/auth.log
maxretry = 3
bantime = 86400 # 禁止一天，单位秒

logpath的配置，因为在docker-compose.yaml中对ssh日志的目录进行了挂载配置，这里根据自己的需要进行修改maxretry也修改为3次，严格一点

启动拦截

首先启动容器：

1
2
3
4
5
6
7
8


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ docker compose up -d
[+] Running 4/4
 ⠿ fail2ban Pulled 36.8s
 ⠿ 7264a8db6415 Pull complete 8.6s
 ⠿ 81330df9fd42 Pull complete 9.4s
 ⠿ 39280c79d189 Pull complete 9.5s
[+] Running 1/1
 ⠿ Container fail2ban Started 0.6s

查看当前fail2ban的状态，如下，可以看到有一个监狱：sshd正在生效中:

1
2
3
4


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ docker exec fail2ban fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd

然后再来查看一下sshd监狱的状态，可以看到总共出现了53次错误登录，当前已经拦截了6个ip，信息很详细：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ docker exec fail2ban fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 6
| |- Total failed: 53
| `- File list: /var/logs/sshd/auth.log
`- Actions
 |- Currently banned: 6
 |- Total banned: 6
 `- Banned IP list: 112.213.110.8 196.189.21.247 104.250.50.16 175.144.208.9 183.56.193.178 141.98.11.90

被ban的ip会添加到iptables中，并且fail2ban会主动为每个监狱创建一个Chain,Chain的名称为f2b-监狱名，可以通过命令来查看iptables中添加的规则:

1
2
3
4
5
6
7
8
9


ubuntu@VM-20-3-ubuntu:~/images/fail2ban$ sudo iptables -nvL f2b-sshd
Chain f2b-sshd (1 references)
 pkts bytes target prot opt in out source destination
 0 0 REJECT all -- * * 183.56.193.178 0.0.0.0/0 reject-with icmp-port-unreachable
 3 156 REJECT all -- * * 175.144.208.9 0.0.0.0/0 reject-with icmp-port-unreachable
 1 60 REJECT all -- * * 104.250.50.16 0.0.0.0/0 reject-with icmp-port-unreachable
 3 180 REJECT all -- * * 196.189.21.247 0.0.0.0/0 reject-with icmp-port-unreachable
 0 0 REJECT all -- * * 112.213.110.8 0.0.0.0/0 reject-with icmp-port-unreachable
 354 24037 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

可以看到很多ip已经被ban了，这是我才刚启动1分钟不到，就这么多ip被ban了，可见坏人真多，老是想着爆破我的服务器。

fail2ban的使用

使用docker exec <容器名称> fail2ban-client命令来操作fail2ban。

查看状态

一个是查看当前总状态：启用了什么监狱，另一个是查看某个监狱的状态，上边已经展示过了，这里就不再详细说了：

1
2
3
4
5


# 查看状态
docker exec fail2ban fail2ban-client status

# 查看指定监狱状态
docker exec fail2ban fail2ban-client status sshd

主动屏蔽ip

我们也可以主动的屏蔽某个ip的访问，通过下边命令：

1
2
3
4
5


# 指定监狱屏蔽IP（<JAIL>为监狱名）
docker exec fail2ban fail2ban-client set <JAIL> banip <IP>
# 示例：docker exec fail2ban fail2ban-client set sshd banip 1.1.1.1
ubuntu@VM-20-3-ubuntu:~$ docker exec fail2ban fail2ban-client set sshd banip 183.56.193.179
1

然后再通过查看监狱状态命令查看Banned Ip List中是否已经有了这个ip来判断是否成功。

主动解除已屏蔽ip

有主动的去屏蔽某个ip，如果设置错误就需要主动把设置错误的取消掉，可以通过下边的命令来进行取消：

1
2
3
4
5


# 指定监狱解封IP（<JAIL>为监狱名）
docker exec fail2ban fail2ban-client set <JAIL> upbanip <IP>
# 示例：docker exec fail2ban fail2ban-client set sshd upbanip 1.1.1.1
ubuntu@VM-20-3-ubuntu:~$ docker exec fail2ban fail2ban-client set sshd unbanip 183.56.193.179
1

然后再通过查看监狱状态的命令查看ip是否已经被取消掉。

以上就是通过安装fail2ban来对暴力破解ssh密码进行拦截，另外也可以通过修改ssh的端口来进行简单的拦截，通常默认的ssh端口是22，如果换了端口他们想要找到这个ssh端口也是要花费一些时间的，再就是可以通过禁用密码只使用key来登录，会更安全一些，这个可以参考我的另一篇文章：修改SSH端口使用公钥登录并禁用root密码登录修改SSH端口使用公钥登录并禁用root密码登录。希望可以帮到大家。

使用火币给土耳其虚拟银行FUPS进行快速入金

Wed, 31 Jan 2024 14:07:04 +0000

上篇文章介绍了如何快速的注册土耳其虚拟银行FUPS：土耳其虚拟银行FUPS注册教程，注册后可以申请三张土耳其的visa虚拟银行卡，申请后想要使用面临的第一个问题就是如何给这张虚拟银行卡来进行入金，没法入金基本就代表这张卡是一张废卡。这篇文章就来介绍一下如何使用火币来给这张土耳其的虚拟银行卡进行入金，满足购买需求。

火币注册

我在注册火币前是先注册了币安的，刚开始什么都不清楚，直接就在币安中购买了20USDT，后来发现大陆KYC的用户只能交易RMB，然后就找到了火币，火币的KYC用四级认证，L1基础认证就可以进行交易，而且L1的认证只需要选择国家就可以认证成功，然后就可以进行交易，对币种也没有限制，很是方便。

购买USDT

USDT是一种资产支持的加密稳定币，基本和美元等价，我们需要把自己的RMB转换成USDT，然后再通过USDT换成我们想要的土耳其里拉TRY，首先我们要登录到火币官网，选择C2C交易，如下图：

然后就是购买，使用RMB进行购买，然后对商家进行筛选，首先是选择可交易的，有些商家对交易有限制，需要实名或者有交易过等条件，所以需要先筛选出我们可以立马进行交易的；其次是选择可以使用微信、支付宝或银行卡的商家，用这些付款最方便；另外有些商家对购买额度有限制，比如下图中的第一个需要1.5w起购买，我可能只需要购买几十元，所以这类商家就适合我们，需要找一些起步金额较低的商家：

然后就购买了，我当时购买的一个是需要进行添加微信，然后在微信直接转账给他，他在HTX平台进行放行，然后我们就可以收到购买的币了，整个过程还是比较丝滑的，5分钟搞定。

购买后的usdt好像是在法币中，具体也不记得了，火币好像不需要在法币和现货里进行转换就可以直接进行交易卖出，如果不行，就需要从法币转移到现货，这个根据具体操作的时候的情况进行调整。资产-我的资产-划转三步搞定。

卖出换TRY

购买到USDT后，需要进行卖出换TRY到我们的FUPS账户中，还是在C2C交易中进行，在此之前需要先在火币平台绑定一种收款方式，具体路径如下图，可以随便添加一种方式，实际的付款方式还是在下单后的聊天窗口进行沟通，只要确保可以最后可以收到钱就行了。

添加了收款方式后我们就可以进行卖出了，选择TRY进行交易：

同样也有交易限额，选择我们可以接受的限额商家进行交易，然后在聊天窗口询问是否支持FUPS，或者有些商家描述里也是有写的，根据实际需求来选择具体的商家。

使用FUPS收款我们可以提供二维码或者一个付款链接，具体的生成是在FUPS的应用程序的首页点击top up，然后跳转到下面页面，选择request from others，然后就通过生成二维码或付款链接让对方来付款。

生成的时候需要输入对方付款的金额，输入完成就可以生成，然后发送给对方，对方付款后立马就可以到。

我选择的商家使用FUPS需要收取4%的手续费，所以在生成付款链接的时候自己算后扣出手续费后的金额并生成，发送给对方。

愉快购物

在出U成功后，我收到1080的里拉，然后就去spotify进行Premium的购买，在购买的时候发现需要先对虚拟卡进行交易金额限制，否则spotify无法进行扣款，具体的限额设置是在FUPS的app下方菜单中的Cards中进行设置，可以看到Your Virtual Card Limit选项，有一个new limit和Automatic Card Limit选项，这里一定要设置New Limit,否则还是无法购买。我这里设置100里拉。

最后祝大家都可以成功的入金进行购买自己想要买的东西。

土耳其虚拟银行FUPS注册教程

Mon, 29 Jan 2024 15:10:25 +0000

以前注册过Oldubil，后来Oldubil限制交易后，一直没有去研究新的代替方案，最近在论坛看到有人成功使用FUPS来购买的Telegram的会员，想着自己的termius会员也快要过期了，所以就研究一下如何注册FUPS来代替Oldubil，下面分享一下注册流程。

注册条件

注册FUPS算是比较简单的了，需要两个重要的信息：

土耳其手机号
土耳其身份信息

以上两个信息看似很难，但是对于我们云土耳其用户来说没有什么困难是不能解决的。下边我们就看一下两种信息如何快速的获取到。

土耳其手机号

对于经常撸土耳其相关服务的人来说，肯定都知道可以找接码平台，但是并不是随便哪个接码平台就可以接FUPS的码，比如我经常使用的sms-activate就没有可以接FUPS的服务，不过功夫不负有心人，在另一个接码平台sms-man还是找到了:

上边就是在sms-man平台通过先选择国家，然后再选择服务后锁定的FUPS的可用接码服务。成功解决了手机号问题。

土耳其身份信息

看网上说土耳其有泄漏过一次信息，导致他们国家很多人的信息都被泄漏出去了，如果有能力可以找到那个泄漏的数据就很容易解决这个问题。但是我信息大部分人和我一样，只需要快速的拿到信息就行了，无需了解过多，那么我在网上也搜到一个发卡站，里边有出售土耳其身份信息，售价5元，可以无脑购买。网站：https://pay.catiz.cn。

~~收到的信息格式如下：“TC” “FIRST NAME” “LAST NAME” “性别” “出生日期” “地址” “区” “教区”~~

最后还真的找到了免费的土耳其用户信息：Telegram，里边有免费的用户信息，大家根据自己需要进行获取。

至次，两个难题就都解决了。

注册

满足了两上边两个条件后，注册就变的很简单了，手机下载FUPS的应用程序，首次打开默认显示的是土耳其语，我想大部分人都是看不懂的，可以点又上角的_三个点_设置语言为英文，最起码可以读懂一些：

点击第一个按钮：register，进入注册页面：

获取虚拟卡

注册成功后我们就可以去获取虚拟卡了，我们默认注册的账户是标准账户，限制最大金额是2750里拉，更高的限额需要升级账户等级，升级可能就需要更多资料了，默认2750也是够用的。

登录后，点击下方的transactions菜单进行，然后选择New Card选项来进行开卡：

点击了New Card后跳转到如下页面，选择virtual Card进行开卡:

一个账户最多有3张免费的虚拟卡，经过上边步骤就成功的开到了土耳其的虚拟visa卡，为我们快乐的购物奠定了基础。

注意

在注册成功后，我想在另一台手机上登录FUPS，发现无法登录，需要用注册时的手机号再一次接码，因为我们是用的接码平台，再一次接码是不可能的了，所以这个账户应该就只能在这一个手机上登录了，大家需要记住相关的卡信息，防止app无法登录，就无法再使用这些虚拟卡了。

上边介绍了如何注册FUPS，但是距离能购物还有一段距离，教程就先到这里，后续再更新如何入金到FUPS中来进行购物。

入金教程已更新，详细：使用火币给土耳其虚拟银行FUPS进行快速入金。

修改SSH端口使用公钥登录并禁用root密码登录

Fri, 05 Jan 2024 15:14:15 +0000

不得不说这个世界上坏人还是比较多的，以为购买一台服务器后部署自己的服务后就可以高枕无忧了吗？NO，总有刁民想还朕，默认的SSH端口是22，这个是SSH协议的规范，那么大部分人购买了服务器后也不会想着去更改这个端口，那么就会被一些不法分子利用，服务器用户名默认root，端口默认22，那么他们就会通过这个来扫你的机器，不停的尝试登录，如果我们设置的密码强度不够，那么很快就会被穷举出来，然后你的服务器就被别人控制。今天我们就来做三步操作增强我们服务器的安全性。

配置公钥

生成密钥对

我们首先要做的就是生成一对密钥，可以使用ssh-keygen来生成一对，生成语法如下：

1

ssh-keygen -t rsa -f ~/.ssh/my-ssh-key -C [USERNAME]

其中

-t 指定算法，一般使用rsa非对称加密算法

-f 指定生成的密钥对存放的路径，可以不指定。

-C 为该密钥对分配一个用户名，只是为了分组使用，可以随意命名。

当我们执行生成命令时，如果不指定文件路径，默认会放在当前用户的.ssh目录下，并会为改密钥设置密码，默认不设置，直接回车跳过，经过这个命令就生成了一对密钥，公钥名称：id_rsa.pub，私钥名称：id_rsa

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/aaa/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/aaa/.ssh/id_rsa
Your public key has been saved in /Users/aaa/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:03Gf81aw0hniwCGSylV1VbOntYOrgsw1RicsUxWwKs aaa
The key's randomart image is:
+---[RSA 3072]----+
| .oo.o ooB=o|
| o. o o B.oo|
| . o + O.*.o|
| o . = XoOo|
| S . +oOo.|
| . Eo.ooo|
| + . .o|
| o . |
| |
+----[SHA256]-----+

$ ls .ssh
config id_rsa.pub
id_rsa known_hosts

上传公钥

生成密钥后，我们需要做的是把公钥上传的需要登录的服务器上，这样子我们才能在自己本地或者其他服务器上使用私钥去登录到这台服务器。上传公钥有两种方式，一种是我们直接拷贝公钥里的内容到需要登录服务器的

1

~/.ssh/authorized_keys

文件中，如果文件不存在直接新建一个。另一种是直接使用ssh-copy-id命令来完成。

直接上传文件内容

我这里使用scp命令把文件传到服务器上，然后在服务器上把内容写入到authorized_keys中。上传命令中端口是非必填的默认是22端口，如果没有修改端口可以添加此参数，后边的.pub文件就是你要上传的文件，后边紧跟着你服务器的用户名@ip:具体服务器路径

1
2
3
4
5
6
7


# scp [-P 端口] ./my-ssh-key.pub [USERNAME]@[EXTERNAL_IP_ADDRESS]:/root/.ssh
scp ./my-ssh-key.pub root@192.168.31.1:/root/.ssh

# 上传成功后，ssh登录到服务器上，把上传的pub文件追加到.ssh目录下的authorized_keys中。
$ ssh root@192.168.31.1
$ cd .ssh
$ cat my-ssh-key.pub >> ~/.ssh/authorized_keys

经过上边步骤就上传好了pub公钥了，就可以使用key来登录了。下边介绍一下使用ssh-copy-id来上传。

ssh-copy-id上传

这个上传就很简单了，直接使用命令：

1
2


# ssh-copy-id -i ./my-ssh-key.pub [USERNAME]@[EXTERNAL_IP_ADDRESS] [-p 端口]
$ ssh-copy-id -i ./my-ssh-key.pub root@192.168.31.1

-i 指定要上传的文件路径，

-p 指定端口，默认22，如果没修改过ssh端口就直接不需要该参数

公钥登录

在登录前要先确认要登录的服务器是否开启了支持公钥登录，其实现在大部分服务器都是默认支持的，如果遇到登录不了的情况可以检查一下是否开启，具体的文件路径是/etc/ssh/sshd_conf,设置以下参数为yes：

1
2
3


PasswordAuthentication yes　　　　　　# 口令登录
RSAAuthentication yes　　　　　　　　　# RSA认证
PubkeyAuthentication yes　　　　　　　# 公钥登录

如果有修改需要重启一下服务器的sshd服务：

1

service sshd restart

然后就可以在本地或者其他服务器使用ssh并指定要使用的私钥文件目录来连接这个远程的服务器了：

1
2


# ssh -i .ssh/my-ssh-key [USERNAME]@[EXTERNAL_IP_ADDRESS] [-p 端口]
ssh -i .ssh/my-ssh-key root@192.168.31.1

经过上边步骤就可以使用公钥连接到服务器了。

修改SSH端口

默认的ssh端口是22，是在/etc/ssh/sshd_conf中配置的，在这个配置文件中我们先找到原来的配置22端口，然后复制一行出来，改成另外一个端口，比如我改成1024端口，那么此时22端口和1024端口应该都是可以通过SSH来访问的，这里一定要小心，不能一上来就把22端口干掉，万一配置错误就凉凉了。所以配置两个端口，保证22端口是肯定可以使用的，然后再添加一个新的端口，配置后重启sshd服务。然后看新配置的端口是否可以访问SSH，如果可以那说明配置没有问题，就可以干掉原来的22端口了。

1
2


Port 22
Port 1024

配置的属性就叫Port。

禁用密码登录

上边已经配置了使用公钥登录，并且也修改了SSH的端口，但是root用户的密码还在，那么一旦一些人扫到了服务器的1024端口是ssh，那么他们还是会不停的尝试密码，暴力破解密码，所以需要把密码登录关掉，只用公钥来登录。同样也是修改/etc/ssh/sshd_conf，修改PasswordAuthentication为no就可以了：

1
2
3


PasswordAuthentication no 　　　　　　# 口令登录
RSAAuthentication yes　　　　　　　　　# RSA认证
PubkeyAuthentication yes　　　　　　　# 公钥登录

经过上边的配置就可以禁用掉root用户的密码登录功能，并修改了SSH登录的端口，这样子服务器的安全性就提高了一些。

遇到的问题

在第一步上传公钥到服务器的时候，上传成功了，但是始终无法通过公钥去登录到服务器，研究了好久发现是服务器上的目录权限不正确，正确的权限应该是下边这样子的:

1
2


$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

多网卡环境下Spring Cloud微服务注册特定网卡Ip到注册中心(Nacos)

Sun, 24 Dec 2023 09:02:19 +0000

在本地开发或者在线上环境的时候，本地开发机器和线上都有可能有多张网卡：物理网卡或者虚拟网卡，如果只有一张网卡，那么 Spring Cloud微服务也不会有注册错ip的情况，一旦有多张网卡，问题就会暴露出来，不同的网卡网络段肯定是不同的，那么ip之间也不可能互通，就会出现虽然服务注册到了注册中心，但是却无法访问到这个已注册的服务。

遇到问题过程

我遇到这个问题主要是在自己的本地电脑上，我电脑上有两个网卡的地址不是同一个段上的，如下：

有一个192.168.6.6和另一个192.168.64.1的，在我启动我的本地的Cloud服务的时候，Nacos中默认注册的是192.168.6.6的地址：

经过查询后在boostrap.yaml配置文件中进行修改：

1
2
3
4
5


spring:
 cloud:
 inetutils:
 preferredNetworks:
 - 192.168.64

经过配置后，再次启动项目，再看注册中心中注册的地址如下：

已经是想要的结果了。

问题深入

在spring官方文档可以查询到，有几种方式可以配置，地址：common-abstractions。

可以使用忽略特定的网络接口：

1
2
3
4
5
6


spring:
 cloud:
 inetutils:
 ignoredInterfaces:
 - docker0
 - veth.*

如上忽略了docker的网络接口以及veth相关的网络接口。

另一种就是我上边提到的preferredNetworks

配置首选网络，偏向与使用哪个ip地址。

官网还提到可以强制只使用站点本地地址，如下例所示：

1
2
3
4


spring:
 cloud:
 inetutils:
 useOnlySiteLocalInterfaces: true

具体详见官网的文档。

升级Intellij IDEA 2023.3后找回Ant构建工具

Sat, 16 Dec 2023 03:00:20 +0000

公司有一个项目使用的是Ant来进行打包构建的，没升级IDEA前还可以在工具栏找到Ant功能来进行构建，升级2023.3版本后，Ant就找不到了，经过一番折腾，终于找回了Ant。再次提醒各位，升级还是需要谨慎呀，旧的又不是不能用，哈哈。废话不多说，下边给出具体的解决方法。

2023.3以前版本

在2023.3版本以前，如果在工具栏找不到Ant，可以在IDEA的菜单中把Ant给添加到工具栏，如下图：

view菜单 tool windows - Ant就可以找到Ant工具。

2023.3版本

升级到2023.3版本后，在view菜单 tool windows中找不到Ant选项了，但是多了一个 AI Assistant 的功能，在IDEA中找Ant相关的配置也是无果。

最后在IDEA的官方日志中找到了原因，官方地址：IntelliJ IDEA 2023.3 最新变化。其实上图里也有说明，只是升级后并没有仔细阅读，而是后来网上找到了中文的升级说明：

在新版本中Ant要去到市场下载了。

下载Ant插件

在plugin中搜索Ant，就可以看到一个jetbrains提供的Ant插件，进行下载，然后就可以在view - tool windows中找到Ant插件了。

安装后立马就可以找到，也不需要重启IDEA，经过上述过程就成功的找回了Ant插件，可以愉快的使用Ant来编译打包项目了。

IDEA如何使用开源项目申请可以参考我的另一篇文章：开源项目申请JetBrains Open Source Development License。

使用ITIN申请American Express(美国运通)信用卡

Sat, 09 Dec 2023 03:40:08 +0000

在今年三月份我成功的拿到了itin，然后使用itin申请了第一张美国信用卡：captail one的押金信用卡，具体的申请过程可以参考我的另一篇文章：使用ITIN申请capital one信用卡，经过几个月的使用，信用分也积攒的差不多了，所以就萌生了申请American Express(美国运通)信用卡的想法，于是就开始了申请之路，这里分享一下我的申请经历。

自身情况

从三月份拿到itin申请captial one信用卡后，从5月开始出账单，到现在大概也是出了半年的账单，11月6日在equifax查询信用分是731分，经过11月wise扣款失败产生逾期费用，我本以为信用分会降低，没想到12月6号在equifax查询信用分的时候还涨了1分，申请的时候信用分是732分。

申请

我们去到AE官网，找到免年费的信用卡，我申请的是：Blue Cash Everyday® Card， 可以根据需求来申请**。**

往下来找到需要申请的卡片，点击apply now 或者 view details，下面是详细信息页面：

申请页面需要填的都是一些基础信息，根据自己的实际情况进行填写，填写SSN的时候，根据提示实际上ITIN也是ok的。

填写完成就提交下一步，同意一些条款并提交申请：

之后就会出现你的追踪号码页面：

同时也会收到一封邮件，和上图的提示差不多，总之就是让打电话给他们提供更多的信息来申请这张卡。除了这个邮件外，还有一个是可以查看申请进度的邮件，后边我们会使用这个地址来查看我们的申请进度：

提交申请后的申请进度查看

电话客服

我大概是在晚上10点左右给客服电话，客服询问了我的名字，生日，SSN(我报的是ITIN)。以及还问我的军事身份，回答NO。然后说让我记下资料上传的网址，需要上传SSN或者驾驶证等一些资料信息，具体的网址是：https://www.americanexpress.com/upload，随后就挂了电话，我就在资料上传的地址上把护照和ITIN的信上传了上去，同时也收到了邮件，提示收到资料。刚上传完没多久，就收到了美国打来的一个电话，进行二次信息确认，也是简单的问了一下生日和SSN，以及提醒我上传这些信息，但是她很快就发现我已经上传了，就简单说了两句就挂了电话。

二次电话客服

在提交申请资料后的第二天，我通过查看申请进度的连接发现还需要我上传一些资料，点击查看详情，里边要让我提供SSN，我只有ITIN怎么提供呢？

view the full decision details的如下：

无奈又打电话给了客服，报了名字，追踪号码以及地址信息，然后表明没有SSN，只有ITIN，然后就让我再次上传这些资料，挂了电话后我就又去上传了ITIN信和护照的照片，这次提交资料并没有像第一次那样收到邮件提示说收到资料，然后就是继续等待。

审批通过

再二次致电客服并提交资料后，终于在第二天早上醒来收到了审批通过的邮件：

根据邮件提示，当前这个节点还没有影响到我的信用分，如果我在美国东部时间12月14日晚上11点59分之前没有接受这个卡片，那申请将会被取消。

Accept Your Card

根据邮件提示，去接受申请的那张卡片，打开链接后先是一个验证，需要输入邮编号和生日

继续下一步：

接受或者取消申请，当时就接受了。

成功接受了申请卡片，根据图片提示我的卡应该会在12月19号收到。然后就是创建AE的账户了。根据提示自行创建就可以了，也没有太多需要注意的。

卡片额度

captial one的额度是$3200，AE的额度5000，中规中矩吧

从申请到下卡也不算太曲折，中间历时三天。希望对大家有所帮助。

卡片邮寄

在12月11日收到邮件通知卡片已邮寄

追踪邮件，在12月15日显示就已经到了，但是后边两天迟迟没有收到anytimemailbox的邮件，我还以为丢件了呢，后来想想应该是周六日的缘故吧，更新延迟了一些，在12月19日收到了通知

之后就是转运回国，让房东使用的DHL邮寄回来，费用80$。从12月20号从美国寄出，到今天(12月26号)终于收到了卡片，历时6天。

卡片照片

信用分

在申请的卡片的时候，我用equifax查询的信用分是732，在运通寄来的信里边有一张纸写是FICO信用分，竟然是769分，不同的地方信用分原来还不一样。

安装node exporter监控linux主机各项指标

Sun, 26 Nov 2023 06:42:47 +0000

在上一篇文章中讲解了如何在docker环境下快速的安装prometheus：debian系统使用docker快速安装promutheus，这篇文章咱们来讲一下如何在linux主机中安装node exporter来采集linux系统的各项指标。

安装node exporter

node exporter的安装非常简单，可以去prometheus的官网下载：node exporter - prometheus，或者去github进行下载：node_exporter - github，我这里直接使用wget命令从github上下载最新的安装包wget https://github.com/prometheus/node_exporter/releases/download/v1.2.2/node_exporter-1.2.2.linux-amd64.tar.gz：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


root@admin:~# wget https://github.com/prometheus/node_exporter/releases/download/v1.2.2/node_exporter-1.2.2.linux-amd64.tar.gz
--2023-11-25 22:35:44-- https://github.com/prometheus/node_exporter/releases/download/v1.2.2/node_exporter-1.2.2.linux-amd64.tar.gz
Resolving github.com (github.com)... 20.205.243.166
Connecting to github.com (github.com)|20.205.243.166|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/9524057/28598a7c-d8ad-483d-85ba-8b2c9c08cf57?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231126%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231126T033542Z&X-Amz-Expires=300&X-Amz-Signature=cf09a0c524756802e669d7ccb2b60b9dcc5f3cfd0855cd9abad7d31947596c2f&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=9524057&response-content-disposition=attachment%3B%20filename%3Dnode_exporter-1.2.2.linux-amd64.tar.gz&response-content-type=application%2Foctet-stream [following]
--2023-11-25 22:35:45-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/9524057/28598a7c-d8ad-483d-85ba-8b2c9c08cf57?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231126%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231126T033542Z&X-Amz-Expires=300&X-Amz-Signature=cf09a0c524756802e669d7ccb2b60b9dcc5f3cfd0855cd9abad7d31947596c2f&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=9524057&response-content-disposition=attachment%3B%20filename%3Dnode_exporter-1.2.2.linux-amd64.tar.gz&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.111.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8898481 (8.5M) [application/octet-stream]
Saving to: ‘node_exporter-1.2.2.linux-amd64.tar.gz’

node_exporter-1.2.2.linux-amd64.tar.gz 100%[===============================================================================>] 8.49M 20.2MB/s in 0.4s

2023-11-25 22:35:46 (20.2 MB/s) - ‘node_exporter-1.2.2.linux-amd64.tar.gz’ saved [8898481/8898481]

下载到本地主机后解压刚下载的文件，里边有三个文件，node_exporter就是我们需要的可执行文件：

1
2
3
4
5
6


root@admin:~# tar -zxf node_exporter-1.2.2.linux-amd64.tar.gz
root@admin:~# ls
images node_exporter-1.2.2.linux-amd64 node_exporter-1.2.2.linux-amd64.tar.gz
root@admin:~# cd node_exporter-1.2.2.linux-amd64
root@admin:~/node_exporter-1.2.2.linux-amd64# ls
LICENSE node_exporter NOTICE

运行node exporter

可以进入到node_exporter-1.2.2.linux-amd64

目录，执行./node_export来执行项目，如下：

1
2
3
4
5


root@admin:~/node_exporter-1.2.2.linux-amd64# ./node_exporter
level=info ts=2023-11-26T06:17:11.718Z caller=node_exporter.go:182 msg="Starting node_exporter" version="(version=1.2.2, branch=HEAD, revision=26645363b486e12be40af7ce4fc91e731a33104e)"
.......
level=info ts=2023-11-26T06:17:11.720Z caller=node_exporter.go:199 msg="Listening on" address=:9100
level=info ts=2023-11-26T06:17:11.720Z caller=tls_config.go:191 msg="TLS is disabled." http2=false

从上边启动的日志可以看出采集的具体指标，倒数第二行日志可以看出node_exporter占用的是9100端口，如果我们想控制采集的指标或者更改占用端口，可以使用-h命令查看启动参数说明：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


root@admin:~/node_exporter-1.2.2.linux-amd64# ./node_exporter -h
 --web.listen-address=":9100" # 监听的端口，默认是9100
 --web.telemetry-path="/metrics" # metrics的路径，默认为/metrics
 --web.disable-exporter-metrics # 是否禁用go、prome默认的metrics
 --web.max-requests=40 # 最大并行请求数，默认40，设置为0时不限制
 --log.level="info" # 日志等级: [debug, info, warn, error, fatal]
 --log.format=logfmt # 置日志打印target和格式: [logfmt, json]
 --version # 版本号
 --collector.{metric-name} # 各个metric对应的参数
 ......

具体的采集参数后续在使用的时候再详细研究，这里就先全部让它采集。以上边的方式启动是以前台运行的，我们关闭窗口程序就会自动退出，下边来配置systemd管理node_exporter.

配置node_exporter.services

首先把把解压后的node_exporter移动到/usr/local/bin目录下，然后新建一个node_exporter.service，需要建到/etc/systemd/system目录下，具体内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Unit]
Description=node exporter service
Documentation=https://prometheus.io
After=network.target

[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/bin/node_exporter --web.listen-address=":9100"
Restart=on-failure

[Install]
WantedBy=multi-user.target

如上所示，启动命令指定了启动的时候占用的端口，这个根据自己的实际情况进行更改，创建完毕后需要重启systemd服务，并使用systemd启动服务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


root@admin:/usr/local/bin# systemctl daemon-reload
root@admin:/usr/local/bin# systemctl start node_exporter
root@admin:/usr/local/bin# systemctl status node_exporter
● node_exporter.service - node exporter service
 Loaded: loaded (/etc/systemd/system/node_exporter.service; disabled; vendor preset: enabled)
 Active: active (running) since Sun 2023-11-26 01:28:25 EST; 6s ago
 Docs: https://prometheus.io
 Main PID: 2794065 (node_exporter)
 Tasks: 4 (limit: 2358)
 Memory: 4.7M
 CPU: 15ms
 CGroup: /system.slice/node_exporter.service
 └─2794065 /usr/local/bin/node_exporter --web.listen-address=:9100

Nov 26 01:28:25 WIKI-HK-A1 node_exporter[2794065]: level=info ts=2023-11-26T06:28:25.705Z caller=node_exporter.go:115 collector=xfs
Nov 26 01:28:25 WIKI-HK-A1 node_exporter[2794065]: level=info ts=2023-11-26T06:28:25.705Z caller=node_exporter.go:115 collector=zfs
Nov 26 01:28:25 WIKI-HK-A1 node_exporter[2794065]: level=info ts=2023-11-26T06:28:25.706Z caller=node_exporter.go:199 msg="Listening on" address=:9100
Nov 26 01:28:25 WIKI-HK-A1 node_exporter[2794065]: level=info ts=2023-11-26T06:28:25.706Z caller=tls_config.go:191 msg="TLS is disabled." http2=false

经过上述步骤就在需要被监控的linux主机上安装好了node exporter，接下来需要在prometheus中配置对该主机的指标进行抓取。

prometheus指标获取

在文章：debian系统使用docker快速安装promutheus中只配置了对promutheus本身指标的采集，下边我们修改prometheus的配置文件，对刚才配置的linux主机进行指标采集，修改prometheus的配置文件如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


global:
 scrape_interval: 1m

scrape_configs:
 - job_name: 'prometheus'
 scrape_interval: 1m
 static_configs:
 - targets: ['localhost:9090']

 - job_name: 'linux-node'
 static_configs:
 - targets: ['127.0.0.1:9100']

如上，配置了一个任务名称为linux-node的任务，它去获取127.0.0.1机器的指标，我们可以在prometheus的后台查看到对应的targets:

到这里就配置好了prometheus采集linux主机指标的配置，可以在prometheus的后台对信息进行查询，后续也可以配置grafana的图形界面来对node exporter采集的数据进行可视化展示。

debian系统使用docker快速安装promutheus

Sun, 26 Nov 2023 00:00:00 +0000

Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。它的功能强大，被广泛使用。今天这边文章就简单介绍一下如何使用docker快速的搭建一个prometheus的服务，其他相关的知识在后续的文章里再详细分享。先把服务跑起来。

如果还没有安装docker的同学可以参考的我另一篇文章来快速的安装docker环境：docker安装。

docker-compose文件准备

我习惯直接使用docker-compose来安装所有服务，我的所有服务都使用同一个网络，实现服务的互通，下边贴出我的配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


networks:
 mynet:
 external: true
services:
 prometheus:
 image: prom/prometheus:v2.46.0
 restart: unless-stopped
 container_name: prometheus
 volumes:
 - ./config/prometheus.yml:/etc/prometheus/prometheus.yml
 - /data/prometheus/data:/prometheus
 command:
 - '--config.file=/etc/prometheus/prometheus.yml'
 - '--storage.tsdb.path=/prometheus'
 - '--web.console.libraries=/etc/prometheus/console_libraries'
 - '--web.console.templates=/etc/prometheus/consoles'
 - '--web.enable-lifecycle'
 networks:
 - mynet
 ports:
 - 9090:9090
 environment:
 - TZ=Asia/Shanghai
 user: "0"

以上是我的docker-compose文件，下边我们介绍一下个项的意义

networks

网络，我指定了一个已经创建好的桥接网络：mynet，这个大家可以指定自己的网络，或者删除这个networks，让docker为该compose创建一个网络。

services

服务，就是我们要创建的prometheus服务了，指定了镜像，重启策略，启动命令，网络，端口以及时区等信息。

目录结构

上边是docker-compose的配置信息，里边指定了prometheus启动的配置文件地址，我们准备一个最简单的配置文件，prometheus自己拉取自己的监控信息：

1
2
3
4
5
6
7
8


global:
 scrape_interval: 1m

scrape_configs:
 - job_name: 'prometheus'
 scrape_interval: 1m
 static_configs:
 - targets: ['localhost:9090']

具体的配置信息以后再讲，这里的global设置了整个拉取间隔为1分钟，并添加了一个拉取配置，任务名叫：prometheus，目标是localhost:9090，就是安装的prometheus自己。

整个的目录结构如下：

1
2
3
4
5


prometheus
├── README.md
├── config
│ └── prometheus.yml
└── docker-compose.yaml

启动服务

在根目录使用命令来启动prometheus：

1

docker compose up -d

启动后可以使用docker ps 来查看服务是否启动成功，如下启动成功：

1
2
3


root@WIKI-HK-A1:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9b24b2c868ad prom/prometheus:v2.46.0 "/bin/prometheus --c…" 3 hours ago Up 34 minutes 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp prometheus

访问服务

prometheus启动占用的是9090端口，我们可以使用自己服务器的ip:9090来访问：

访问后如上，我们可以在staus-targets中查看我们添加的那个任务：

以上就是简单的安装prometheus的过程，希望可以帮到大家。

Mac终端美化之Oh My Zsh安装配置

Fri, 27 Oct 2023 10:07:07 +0000

使用Mac的同学应该对Mac自带的终端配置都没什么好感，默认白底黑字，文件夹也没有特殊标识，还是上一张图来感受一下吧：

黑呼呼的一团，看着实在是难受，下边就让我们使用Oh My Zsh来进行美化一下。

Oh My Zsh安装

oh my zsh的安装是非常简单的，大家可以参考官网来进行安装：Oh My Zsh Install,通过curl或wget都可以安装，下边使用curl进行安装：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


k@MacBook-Pro ~ % sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
Cloning Oh My Zsh...
remote: Enumerating objects: 1370, done.
remote: Counting objects: 100% (1370/1370), done.
remote: Compressing objects: 100% (1318/1318), done.
remote: Total 1370 (delta 32), reused 1155 (delta 28), pack-reused 0
Receiving objects: 100% (1370/1370), 2.01 MiB | 2.66 MiB/s, done.
Resolving deltas: 100% (32/32), done.
From https://github.com/ohmyzsh/ohmyzsh
 * [new branch] master -> origin/master
branch 'master' set up to track 'origin/master'.
Switched to a new branch 'master'
/Users/k

Looking for an existing zsh config...
Using the Oh My Zsh template file and adding it to /Users/k/.zshrc.

 __ __
 ____ / /_ ____ ___ __ __ ____ _____/ /_
 / __ \/ __ \  / __ `__ \/ / / / /_ / / ___/ __ \
/ /_/ / / / / / / / / / / /_/ / / /_(__ ) / / /
\____/_/ /_/ /_/ /_/ /_/\__, / /___/____/_/ /_/
 /____/ ....is now installed!

Before you scream Oh My Zsh! look over the `.zshrc` file to select plugins, themes, and options.

• Follow us on Twitter: https://twitter.com/ohmyzsh
• Join our Discord community: https://discord.gg/ohmyzsh
• Get stickers, t-shirts, coffee mugs and more: https://shop.planetargon.com/collections/oh-my-zsh

上边就安装成功了oh my zsh。

切换主题

安装成功后，默认的主题(robbyrussell)如下所示：

文件夹也可以高亮了，看着还是不错的。剩下的就是修改自己喜欢的主题了。oh my zsh自带了一些主题，存放在~/.oh-my-sh/themes下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74


# k @ MacBook-Pro in ~/.oh-my-zsh/themes on git:master o [17:47:16]
$ ls
3den.zsh-theme kennethreitz.zsh-theme
Soliah.zsh-theme kiwi.zsh-theme
adben.zsh-theme kolo.zsh-theme
af-magic.zsh-theme kphoen.zsh-theme
afowler.zsh-theme lambda.zsh-theme
agnoster.zsh-theme linuxonly.zsh-theme
alanpeabody.zsh-theme lukerandall.zsh-theme
amuse.zsh-theme macovsky-ruby.zsh-theme
apple.zsh-theme macovsky.zsh-theme
arrow.zsh-theme maran.zsh-theme
aussiegeek.zsh-theme mgutz.zsh-theme
avit.zsh-theme mh.zsh-theme
awesomepanda.zsh-theme michelebologna.zsh-theme
bira.zsh-theme mikeh.zsh-theme
blinks.zsh-theme miloshadzic.zsh-theme
bureau.zsh-theme minimal.zsh-theme
candy-kingdom.zsh-theme mira.zsh-theme
candy.zsh-theme mlh.zsh-theme
clean.zsh-theme mortalscumbag.zsh-theme
cloud.zsh-theme mrtazz.zsh-theme
crcandy.zsh-theme murilasso.zsh-theme
crunch.zsh-theme muse.zsh-theme
cypher.zsh-theme nanotech.zsh-theme
dallas.zsh-theme nebirhos.zsh-theme
darkblood.zsh-theme nicoulaj.zsh-theme
daveverwer.zsh-theme norm.zsh-theme
dieter.zsh-theme obraun.zsh-theme
dogenpunk.zsh-theme oldgallois.zsh-theme
dpoggi.zsh-theme peepcode.zsh-theme
dst.zsh-theme philips.zsh-theme
dstufft.zsh-theme pmcgee.zsh-theme
duellj.zsh-theme pygmalion-virtualenv.zsh-theme
eastwood.zsh-theme pygmalion.zsh-theme
edvardm.zsh-theme random.zsh-theme
emotty.zsh-theme re5et.zsh-theme
essembeh.zsh-theme refined.zsh-theme
evan.zsh-theme rgm.zsh-theme
fino-time.zsh-theme risto.zsh-theme
fino.zsh-theme rixius.zsh-theme
fishy.zsh-theme rkj-repos.zsh-theme
flazz.zsh-theme rkj.zsh-theme
fletcherm.zsh-theme robbyrussell.zsh-theme
fox.zsh-theme sammy.zsh-theme
frisk.zsh-theme simonoff.zsh-theme
frontcube.zsh-theme simple.zsh-theme
funky.zsh-theme skaro.zsh-theme
fwalch.zsh-theme smt.zsh-theme
gallifrey.zsh-theme sonicradish.zsh-theme
gallois.zsh-theme sorin.zsh-theme
garyblessington.zsh-theme sporty_256.zsh-theme
gentoo.zsh-theme steeef.zsh-theme
geoffgarside.zsh-theme strug.zsh-theme
gianu.zsh-theme sunaku.zsh-theme
gnzh.zsh-theme sunrise.zsh-theme
gozilla.zsh-theme superjarin.zsh-theme
half-life.zsh-theme suvash.zsh-theme
humza.zsh-theme takashiyoshida.zsh-theme
imajes.zsh-theme terminalparty.zsh-theme
intheloop.zsh-theme theunraveler.zsh-theme
itchy.zsh-theme tjkirch.zsh-theme
jaischeema.zsh-theme tjkirch_mod.zsh-theme
jbergantine.zsh-theme tonotdo.zsh-theme
jispwoso.zsh-theme trapd00r.zsh-theme
jnrowe.zsh-theme wedisagree.zsh-theme
jonathan.zsh-theme wezm+.zsh-theme
josh.zsh-theme wezm.zsh-theme
jreese.zsh-theme wuffers.zsh-theme
jtriley.zsh-theme xiong-chiamiov-plus.zsh-theme
juanghurtado.zsh-theme xiong-chiamiov.zsh-theme
junkfood.zsh-theme ys.zsh-theme
kafeitu.zsh-theme zhann.zsh-theme
kardan.zsh-theme

比如默认的主题：robbyrussell.zsh-theme，根据自己的需求，在.zshrc文件中进行修改，

1
2
3
4
5
6


# Set name of the theme to load --- if set to "random", it will
# load a random theme each time oh-my-zsh is loaded, in which case,
# to know which specific one was loaded, run: echo $RANDOM_THEME
# See https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
#ZSH_THEME="robbyrussell"
ZSH_THEME="ys"

终端配色

我这里将主题修改为了ys。下边展示一下我修改后的终端配色：

加了一些透明在里边，下边把我自己使用的终端配色分享给大家，大家如果喜欢可以直接下载后进行导入：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>BackgroundAlphaInactive</key>
 <real>0.29155388779527558</real>
 <key>BackgroundBlur</key>
 <real>0.197831572862122</real>
 <key>BackgroundBlurInactive</key>
 <real>0.15034141538180704</real>
 <key>BackgroundColor</key>
 <data>
 YnBsaXN0MDDUAQIDBAUGKyxYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS
 AAGGoKcHCBMZHSQoVSRudWxs1QkKCwwNDg8QERJcTlNDb21wb25lbnRzVU5TUkdCXE5T
 Q29sb3JTcGFjZV8QEk5TQ3VzdG9tQ29sb3JTcGFjZVYkY2xhc3NPECowLjQwMjQ2MTQ0
 OTcgMC40MDExMDYzNjA2IDAuNDAzODE2NTM4OCAwLjVPECowLjMyODQwNDM2NyAwLjMy
 Njc0MDM4NDEgMC4zMjk2NjQyMzAzIDAuNQAQAYACgAbTFA0VFhcYVU5TSUNDWU5TU3Bh
 Y2VJRIADgAUQDNIaDRscV05TLmRhdGFPEQIkAAACJGFwcGwEAAAAbW50clJHQiBYWVog
 B+EABwAHAA0AFgAgYWNzcEFQUEwAAAAAQVBQTAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEA
 AAAA0y1hcHBsyhqVgiV/EE04mRPV0eoVggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAKZGVzYwAAAPwAAABlY3BydAAAAWQAAAAjd3RwdAAAAYgAAAAUclhZWgAAAZwA
 AAAUZ1hZWgAAAbAAAAAUYlhZWgAAAcQAAAAUclRSQwAAAdgAAAAgY2hhZAAAAfgAAAAs
 YlRSQwAAAdgAAAAgZ1RSQwAAAdgAAAAgZGVzYwAAAAAAAAALRGlzcGxheSBQMwAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXh0AAAAAENvcHlyaWdodCBBcHBsZSBJ
 bmMuLCAyMDE3AABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAACD3wAAPb////+7
 WFlaIAAAAAAAAEq/AACxNwAACrlYWVogAAAAAAAAKDgAABELAADIuXBhcmEAAAAAAAMA
 AAACZmYAAPKnAAANWQAAE9AAAApbc2YzMgAAAAAAAQxCAAAF3v//8yYAAAeTAAD9kP//
 +6L///2jAAAD3AAAwG6ABNIeHyAhWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxl
 RGF0YaMgIiNWTlNEYXRhWE5TT2JqZWN00h4fJSZcTlNDb2xvclNwYWNloicjXE5TQ29s
 b3JTcGFjZdIeHykqV05TQ29sb3KiKSNfEA9OU0tleWVkQXJjaGl2ZXLRLS5Ucm9vdIAB
 AAgAEQAaACMALQAyADcAPwBFAFAAXQBjAHAAhQCMALkA5gDoAOoA7ADzAPkBAwEFAQcB
 CQEOARYDPgNAA0UDUANZA2cDawNyA3sDgAONA5ADnQOiA6oDrQO/A8IDxwAAAAAAAAIB
 AAAAAAAAAC8AAAAAAAAAAAAAAAAAAAPJ
 </data>
 <key>BackgroundSettingsForInactiveWindows</key>
 <true/>
 <key>CursorColor</key>
 <data>
 YnBsaXN0MDDUAQIDBAUGKyxYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS
 AAGGoKcHCBMZHSQoVSRudWxs1QkKCwwNDg8QERJcTlNDb21wb25lbnRzVU5TUkdCXE5T
 Q29sb3JTcGFjZV8QEk5TQ3VzdG9tQ29sb3JTcGFjZVYkY2xhc3NPECswLjA5MDY1NzM4
 MzIxIDAuMDkwMzY5NTgxOTkgMC4wOTA5NDUxODQ0MyAxTxAqMC4wNzEzODQ3ODc1NiAw
 LjA3MTE0Nzg2NjU1IDAuMDcxNTY2Mzg4MDEAEAGAAoAG0xQNFRYXGFVOU0lDQ1lOU1Nw
 YWNlSUSAA4AFEAzSGg0bHFdOUy5kYXRhTxECJAAAAiRhcHBsBAAAAG1udHJSR0IgWFla
 IAfhAAcABwANABYAIGFjc3BBUFBMAAAAAEFQUEwAAAAAAAAAAAAAAAAAAAAAAAD21gAB
 AAAAANMtYXBwbMoalYIlfxBNOJkT1dHqFYIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAACmRlc2MAAAD8AAAAZWNwcnQAAAFkAAAAI3d0cHQAAAGIAAAAFHJYWVoAAAGc
 AAAAFGdYWVoAAAGwAAAAFGJYWVoAAAHEAAAAFHJUUkMAAAHYAAAAIGNoYWQAAAH4AAAA
 LGJUUkMAAAHYAAAAIGdUUkMAAAHYAAAAIGRlc2MAAAAAAAAAC0Rpc3BsYXkgUDMAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdGV4dAAAAABDb3B5cmlnaHQgQXBwbGUg
 SW5jLiwgMjAxNwAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAg98AAD2/////
 u1hZWiAAAAAAAABKvwAAsTcAAAq5WFlaIAAAAAAAACg4AAARCwAAyLlwYXJhAAAAAAAD
 AAAAAmZmAADypwAADVkAABPQAAAKW3NmMzIAAAAAAAEMQgAABd7///MmAAAHkwAA/ZD/
 //ui///9owAAA9wAAMBugATSHh8gIVokY2xhc3NuYW1lWCRjbGFzc2VzXU5TTXV0YWJs
 ZURhdGGjICIjVk5TRGF0YVhOU09iamVjdNIeHyUmXE5TQ29sb3JTcGFjZaInI1xOU0Nv
 bG9yU3BhY2XSHh8pKldOU0NvbG9yoikjXxAPTlNLZXllZEFyY2hpdmVy0S0uVHJvb3SA
 AQAIABEAGgAjAC0AMgA3AD8ARQBQAF0AYwBwAIUAjAC6AOcA6QDrAO0A9AD6AQQBBgEI
 AQoBDwEXAz8DQQNGA1EDWgNoA2wDcwN8A4EDjgORA54DowOrA64DwAPDA8gAAAAAAAAC
 AQAAAAAAAAAvAAAAAAAAAAAAAAAAAAADyg==
 </data>
 <key>Font</key>
 <data>
 YnBsaXN0MDDUAQIDBAUGGBlYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS
 AAGGoKQHCBESVSRudWxs1AkKCwwNDg8QVk5TU2l6ZVhOU2ZGbGFnc1ZOU05hbWVWJGNs
 YXNzI0AqAAAAAAAAEBCAAoADXxAcTWVzbG9MR01Gb3JQb3dlcmxpbmUtUmVndWxhctIT
 FBUWWiRjbGFzc25hbWVYJGNsYXNzZXNWTlNGb250ohUXWE5TT2JqZWN0XxAPTlNLZXll
 ZEFyY2hpdmVy0RobVHJvb3SAAQgRGiMtMjc8QktSW2JpcnR2eJecp7C3usPV2N0AAAAA
 AAABAQAAAAAAAAAcAAAAAAAAAAAAAAAAAAAA3w==
 </data>
 <key>FontAntialias</key>
 <true/>
 <key>FontWidthSpacing</key>
 <integer>1</integer>
 <key>ProfileCurrentVersion</key>
 <real>2.0499999999999998</real>
 <key>SelectionColor</key>
 <data>
 YnBsaXN0MDDUAQIDBAUGKyxYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS
 AAGGoKcHCBMZHSQoVSRudWxs1QkKCwwNDg8QERJcTlNDb21wb25lbnRzVU5TUkdCXE5T
 Q29sb3JTcGFjZV8QEk5TQ3VzdG9tQ29sb3JTcGFjZVYkY2xhc3NPECcwLjYyOTkyNTMz
 OSAwLjY2NTY2MzQyMjEgMC42MzA0MjI5NTI5IDFPECcwLjU1NDMwNjk4MzkgMC42MDU2
 NzE1ODQ2IDAuNTU5NTI2NjIyMwAQAYACgAbTFA0VFhcYVU5TSUNDWU5TU3BhY2VJRIAD
 gAUQDNIaDRscV05TLmRhdGFPEQIkAAACJGFwcGwEAAAAbW50clJHQiBYWVogB+EABwAH
 AA0AFgAgYWNzcEFQUEwAAAAAQVBQTAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1h
 cHBsyhqVgiV/EE04mRPV0eoVggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK
 ZGVzYwAAAPwAAABlY3BydAAAAWQAAAAjd3RwdAAAAYgAAAAUclhZWgAAAZwAAAAUZ1hZ
 WgAAAbAAAAAUYlhZWgAAAcQAAAAUclRSQwAAAdgAAAAgY2hhZAAAAfgAAAAsYlRSQwAA
 AdgAAAAgZ1RSQwAAAdgAAAAgZGVzYwAAAAAAAAALRGlzcGxheSBQMwAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXh0AAAAAENvcHlyaWdodCBBcHBsZSBJbmMuLCAy
 MDE3AABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAACD3wAAPb////+7WFlaIAAA
 AAAAAEq/AACxNwAACrlYWVogAAAAAAAAKDgAABELAADIuXBhcmEAAAAAAAMAAAACZmYA
 APKnAAANWQAAE9AAAApbc2YzMgAAAAAAAQxCAAAF3v//8yYAAAeTAAD9kP//+6L///2j
 AAAD3AAAwG6ABNIeHyAhWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMg
 IiNWTlNEYXRhWE5TT2JqZWN00h4fJSZcTlNDb2xvclNwYWNloicjXE5TQ29sb3JTcGFj
 ZdIeHykqV05TQ29sb3KiKSNfEA9OU0tleWVkQXJjaGl2ZXLRLS5Ucm9vdIABAAgAEQAa
 ACMALQAyADcAPwBFAFAAXQBjAHAAhQCMALYA4ADiAOQA5gDtAPMA/QD/AQEBAwEIARAD
 OAM6Az8DSgNTA2EDZQNsA3UDegOHA4oDlwOcA6QDpwO5A7wDwQAAAAAAAAIBAAAAAAAA
 AC8AAAAAAAAAAAAAAAAAAAPD
 </data>
 <key>TextColor</key>
 <data>
 YnBsaXN0MDDUAQIDBAUGKyxYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS
 AAGGoKcHCBMZHSQoVSRudWxs1QkKCwwNDg8QERJcTlNDb21wb25lbnRzVU5TUkdCXE5T
 Q29sb3JTcGFjZV8QEk5TQ3VzdG9tQ29sb3JTcGFjZVYkY2xhc3NHMSAxIDEgMU8QHDAu
 OTk5ODg2MDk1NSAxIDAuOTk5ODM5ODQyMwAQAYACgAbTFA0VFhcYVU5TSUNDWU5TU3Bh
 Y2VJRIADgAUQDNIaDRscV05TLmRhdGFPEQIkAAACJGFwcGwEAAAAbW50clJHQiBYWVog
 B+EABwAHAA0AFgAgYWNzcEFQUEwAAAAAQVBQTAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEA
 AAAA0y1hcHBsyhqVgiV/EE04mRPV0eoVggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAKZGVzYwAAAPwAAABlY3BydAAAAWQAAAAjd3RwdAAAAYgAAAAUclhZWgAAAZwA
 AAAUZ1hZWgAAAbAAAAAUYlhZWgAAAcQAAAAUclRSQwAAAdgAAAAgY2hhZAAAAfgAAAAs
 YlRSQwAAAdgAAAAgZ1RSQwAAAdgAAAAgZGVzYwAAAAAAAAALRGlzcGxheSBQMwAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXh0AAAAAENvcHlyaWdodCBBcHBsZSBJ
 bmMuLCAyMDE3AABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAACD3wAAPb////+7
 WFlaIAAAAAAAAEq/AACxNwAACrlYWVogAAAAAAAAKDgAABELAADIuXBhcmEAAAAAAAMA
 AAACZmYAAPKnAAANWQAAE9AAAApbc2YzMgAAAAAAAQxCAAAF3v//8yYAAAeTAAD9kP//
 +6L///2jAAAD3AAAwG6ABNIeHyAhWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxl
 RGF0YaMgIiNWTlNEYXRhWE5TT2JqZWN00h4fJSZcTlNDb2xvclNwYWNloicjXE5TQ29s
 b3JTcGFjZdIeHykqV05TQ29sb3KiKSNfEA9OU0tleWVkQXJjaGl2ZXLRLS5Ucm9vdIAB
 AAgAEQAaACMALQAyADcAPwBFAFAAXQBjAHAAhQCMAJQAswC1ALcAuQDAAMYA0ADSANQA
 1gDbAOMDCwMNAxIDHQMmAzQDOAM/A0gDTQNaA10DagNvA3cDegOMA48DlAAAAAAAAAIB
 AAAAAAAAAC8AAAAAAAAAAAAAAAAAAAOW
 </data>
 <key>UseBoldFonts</key>
 <false/>
 <key>columnCount</key>
 <integer>90</integer>
 <key>name</key>
 <string>me</string>
 <key>rowCount</key>
 <integer>25</integer>
 <key>type</key>
 <string>Window Settings</string>
</dict>
</plist>

新建一个文件，名字随意，文件格式为.terminal,例如ohmyzsh.terminal。然后在终端中进行导入并设置为默认：

选择import后，在上边的选项中就会有你刚才文件名称对应的一个配置文件，比如我这里叫me-old,然后设置为default就可以了，就和我图片中的终端配色一样了。

Mac使用Homebrew安装Gradle环境

Fri, 27 Oct 2023 05:24:40 +0000

首先mac机器需要先安装Homebrew,具体的安装教程参考我的另一篇文章：Mac更换源更快速的安装Homebrew，有了Homebrew后一切安装都变的很简单了。

安装

首先是来搜索一下gradle:

1
2
3
4
5
6
7


k@MacBook-Pro ~ % brew search gradle
==> Formulae
gradle gradle-profiler gradle@7 grails
gradle-completion gradle@6 grace glade

==> Casks
grads qlgradle

如上有几个版本的gradle:6,7以及没有加版本号的代表最新的。我这里安装gradle@7的版本：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


k@MacBook-Pro ~ % brew install gradle@7
==> Downloading https://ghcr.io/v2/homebrew/core/gradle/7/manifests/7.6.3
######################################################################### 100.0%
==> Fetching gradle@7
==> Downloading https://ghcr.io/v2/homebrew/core/gradle/7/blobs/sha256:cc0def9cb
######################################################################### 100.0%
==> Pouring gradle@7--7.6.3.all.bottle.tar.gz
==> Caveats
gradle@7 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have gradle@7 first in your PATH, run:
 echo 'export PATH="/usr/local/opt/gradle@7/bin:$PATH"' >> ~/.zshrc
==> Summary
🍺 /usr/local/Cellar/gradle@7/7.6.3: 11,535 files, 272.3MB
==> Running `brew cleanup gradle@7`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

经过上边就已经安装好了gradle,可以看到默认安装的是7.6.3版本的gradle,安装目录是/usr/local/Cellar/gradle@7/7.6.3,接下来我们就需要配置一下maven的环境变量。

添加环境变量

上边安装完输出的信息中有提示可以直接把上边提示的命令在终端执行就可以添加环境变量到.zshrc文件中：

1

echo 'export PATH="/usr/local/opt/gradle@7/bin:$PATH"' >> ~/.zshrc

或者直接编辑.zshrc文件，在文件末尾添加：

1

export PATH="/usr/local/opt/gradle@7/bin:$PATH"

然后就是刷新变量信息：

1

source .zshrc

然后就可以通过命令来查看gradle的版本信息：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


k@MacBook-Pro ~ % gradle -v

Welcome to Gradle 7.6.3!

Here are the highlights of this release:
 - Added support for Java 19.
 - Introduced `--rerun` flag for individual task rerun.
 - Improved dependency block for test suites to be strongly typed.
 - Added a pluggable system for Java toolchains provisioning.

For more details see https://docs.gradle.org/7.6.3/release-notes.html

------------------------------------------------------------
Gradle 7.6.3
------------------------------------------------------------

Build time: 2023-10-04 15:59:47 UTC
Revision: 1694251d59e0d4752d547e1fd5b5020b798a7e71

Kotlin: 1.7.10
Groovy: 3.0.13
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 17.0.9 (Homebrew 17.0.9+0)
OS: Mac OS X 14.1 x86_64

以上，Gradle就安装成功。也可以参考官网的安装步骤进行手工下载安装：Installing manually。

Mac使用Homebrew安装maven环境

Fri, 27 Oct 2023 04:01:20 +0000

首先mac机器需要先安装Homebrew,具体的安装教程参考我的另一篇文章：Mac更换源更快速的安装Homebrew，有了Homebrew后一切安装都变的很简单了。

安装

首先是来搜索一下maven:

1
2
3
4
5
6


k@MacBook-Pro ~ % brew search maven
==> Formulae
maven maven-completion maven-shell

==> Casks
marvel marvin mauve mavensmate

如上，第一个就是我们需要安装的maven,通过安装命令进行安装：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


k@MacBook-Pro ~ % brew install maven
==> Downloading https://formulae.brew.sh/api/formula.jws.json
##O#- #
==> Downloading https://formulae.brew.sh/api/cask.jws.json
##O#- #
==> Downloading https://ghcr.io/v2/homebrew/core/maven/manifests/3.9.5
######################################################################### 100.0%
==> Fetching dependencies for maven: openjdk
==> Downloading https://ghcr.io/v2/homebrew/core/openjdk/manifests/21.0.1
######################################################################### 100.0%
==> Fetching openjdk
==> Downloading https://ghcr.io/v2/homebrew/core/openjdk/blobs/sha256:ab5d32ae29
######################################################################### 100.0%
==> Fetching maven
==> Downloading https://ghcr.io/v2/homebrew/core/maven/blobs/sha256:3c0cb2c2df11
######################################################################### 100.0%
==> Installing dependencies for maven: openjdk
==> Installing maven dependency: openjdk
==> Downloading https://ghcr.io/v2/homebrew/core/openjdk/manifests/21.0.1
Already downloaded: /Users/k/Library/Caches/Homebrew/downloads/bb8a78296beb0d39c64166622e2df1a553bdf78572bac0ce95765a7007a46b8a--openjdk-21.0.1.bottle_manifest.json
==> Pouring openjdk--21.0.1.sonoma.bottle.tar.gz
🍺 /usr/local/Cellar/openjdk/21.0.1: 600 files, 331.4MB
==> Installing maven
==> Pouring maven--3.9.5.sonoma.bottle.tar.gz
🍺 /usr/local/Cellar/maven/3.9.5: 92 files, 10.4MB
==> Running `brew cleanup maven`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

经过上边就已经安装好了maven,可以看到默认安装的是3.9.5版本的maven,安装目录是/usr/local/Cellar/maven/3.9.5,接下来我们就需要配置一下maven的环境变量。

添加环境变量

编辑~/.zshrc文件,在文件末尾添加环境变量信息：

1
2


# maven
export PATH=/usr/local/Cellar/maven/3.9.5/bin:$PATH

添加完环境变量信息后，我们还需要让环境变量生效，可以使用source：

1

source .zshrc

然后就可以通过命令来查看maven的版本信息：

1
2
3
4
5
6


k@MacBook-Pro ~ % mvn -v
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 17.0.9, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_CN, platform encoding: UTF-8
OS name: "mac os x", version: "14.1", arch: "x86_64", family: "mac"

至此maven就安装完成了，我这里使用的是brew来进行安装，除了这个方法，还可以直接去maven官网进行下载maven的压缩包，然后进行解压，再进行环境变量的配置就可以了。maven官网的下载地址：Maven - Download，这里默认下载的是最新版本，如果想下载历史的版本可以去到历史库下载，具体地址：Maven Releases History。

自定义Nginx日志属性并设置日志以JSON输出

Wed, 04 Oct 2023 15:04:07 +0000

日志在日常开发中是非常重要的东西，在出现错误后可以快速的进行排查，对Nginx而言同样也很重要，同Nginx的日志我们可以清晰的了解什么url被访问，是什么Ip访问过来等一些重要信息，所以无论是在开发中还是线上环境，都会开启日志。下边就来了解一下Nginx的日志。

日志类型

在Nginx的配置文件中，日志相关的配置可以出现在_http,server,location_中，通常我们会设置以下格式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


server {
 listen 443 ssl http2;
 server_name _;

 index index.php index.html index.htm;
 root /var/www/html;
 server_tokens off;
 client_max_body_size 75M;

 access_log /var/log/access.log;
 error_log /var/log/error.log;

}

设置了access和error两种类型的日志，日志的设置语法是：

1
2


access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;

可以设置开启日志，也可以设置关闭日志。access_log中记录了所有的访问日志，error_log中则记录访问中的一些异常请求，方便在出现问题的时候进行错误排查。

另外也可以定义缓存区以及刷新时间等属性。

如果使用 gzip 参数，则缓冲数据将在写入文件之前被压缩。压缩级别可以设置在 1（最快，压缩程度较低）和 9（最慢，压缩效果最佳）之间。默认情况下，缓冲区大小等于64K字节，压缩级别设置为1。由于数据被压缩在原子块中，因此日志文件可以随时由“zcat”解压或读取。使用gzip有一个要求，那就是在构建Nginx必须使用 zlib 库构建。

以上只是设置了访问日志和错误日志的记录位置或者不记录日志，那么日志记录的格式是怎样的呢？

日志格式

上边的配置没有指定具体的日志格式，那么Nginx有一个默认的日志记录格式：

1
2
3


log_format combined '$remote_addr - $remote_user [$time_local] '
 '"$request" $status $body_bytes_sent '
 '"$http_referer" "$http_user_agent"';

它的名称叫combined,具体log_format的语法如下：

1

log_format name [escape=default|json|none] string ...;

每一个日志格式都有一个名称，然后在配置access_log的时候可以指定用哪种格式来进行记录日志。log_format只能定义在_http_块中。查看在Nginx配置文件中的定义：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


http {

 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';
}

server {
 access_log /var/log/nginx/access.log main;
 error_log /var/log/nginx/error.log;
}

如上在http块中定义了一个名称为main的日志格式，在server块中通过名称对该日志格式进行了引用，这样子日志的格式都会按找main中定义的一些属性来进行记录访问信息。

escape 参数（1.11.8）允许在变量中设置 json 或默认字符转义，默认情况下使用默认转义。 none 值 (1.13.10) 禁用转义。

对于默认转义，字符“"”、“\”以及其他值小于32（0.7.0）或大于126（1.1.6）的字符将被转义为“\xXX”。如果找不到变量值，将记录连字符（“-”）。

对于json转义，JSON字符串中不允许的所有字符都将被转义：字符“"”和“\”被转义为“\”和“\”，值小于32的字符被转义为“\n”， “\r”、“\t”、“\b”、“\f”或“\u00XX”。

但是这些属性究竟什么意思？Nginx有哪些属性可以使用呢？

日志属性

日志属性可以包含公共变量以及仅在日志写入时存在的变量：

$bytes_sent：发送到客户端的字节数
$connection：连接序列号
$connection_requests：当前通过连接发出的请求数 (1.1.18)
$msec：日志写入时的时间（以秒为单位，精度为毫秒）
$pipe：如果请求是通过管道传输的，则为“p”，“.”否则
$request_length：请求长度（包括请求行、请求头和请求正文）
$request_time：请求处理时间以秒为单位，精度为毫秒；从客户端读取第一个字节与将最后一个字节发送到客户端后写入日志之间经过的时间
$status：响应状态
$time_iso8601：ISO 8601 标准格式的当地时间
$time_local：通用日志格式中的本地时间

具体的参考：Module ngx_http_log_module

设置JSON格式

通过上边对日志格式和日志文件的一些了解，我们就可以非常容易的把日志的格式设置成JSON了，只需要定义一个log_format，把它的格式定义成一个json字符串，然后在打印日志的时候引用这个格式就可以实现了，下边是一个完成的定义文件:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


http {

 log_format json escape=json '{'
 '"msec": "$msec", ' # request unixtime in seconds with a milliseconds resolution
 '"connection": "$connection", ' # connection serial number
 '"connection_requests": "$connection_requests", ' # number of requests made in connection
 '"pid": "$pid", ' # process pid
 '"request_id": "$request_id", ' # the unique request id
 '"request_length": "$request_length", ' # request length (including headers and body)
 '"remote_addr": "$remote_addr", ' # client IP
 '"remote_user": "$remote_user", ' # client HTTP username
 '"remote_port": "$remote_port", ' # client port
 '"time_local": "$time_local", '
 '"time_iso8601": "$time_iso8601", ' # local time in the ISO 8601 standard format
 '"request": "$request", ' # full path no arguments if the request
 '"request_uri": "$request_uri", ' # full path and arguments if the request
 '"args": "$args", ' # args
 '"status": "$status", ' # response status code
 '"body_bytes_sent": "$body_bytes_sent", ' # the number of body bytes exclude headers sent to a client
 '"bytes_sent": "$bytes_sent", ' # the number of bytes sent to a client
 '"http_referer": "$http_referer", ' # HTTP referer
 '"http_user_agent": "$http_user_agent", ' # user agent
 '"http_x_forwarded_for": "$http_x_forwarded_for", ' # http_x_forwarded_for
 '"http_host": "$http_host", ' # the request Host: header
 '"server_name": "$server_name", ' # the name of the vhost serving the request
 '"request_time": "$request_time", ' # request processing time in seconds with msec resolution
 '"upstream": "$upstream_addr", ' # upstream backend server for proxied requests
 '"upstream_connect_time": "$upstream_connect_time", ' # upstream handshake time incl. TLS
 '"upstream_header_time": "$upstream_header_time", ' # time spent receiving upstream headers
 '"upstream_response_time": "$upstream_response_time", ' # time spend receiving upstream body
 '"upstream_response_length": "$upstream_response_length", ' # upstream response length
 '"upstream_cache_status": "$upstream_cache_status", ' # cache HIT/MISS where applicable
 '"ssl_protocol": "$ssl_protocol", ' # TLS protocol
 '"ssl_cipher": "$ssl_cipher", ' # TLS cipher
 '"scheme": "$scheme", ' # http or https
 '"request_method": "$request_method", ' # request method
 '"server_protocol": "$server_protocol", ' # request protocol, like HTTP/1.1 or HTTP/2.0
 '"pipe": "$pipe", ' # "p" if request was pipelined, "." otherwise
 '"gzip_ratio": "$gzip_ratio", '
 '"http_cf_ray": "$http_cf_ray"'
 '}';
}

server {
 listen 443 ssl http2;
 server_name _;
 access_log /var/log/nginx/access.log json;

}

如上定义了一个完成的json格式的输出形式，实际的请求输出是这样子的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


{
 "msec": "1696428300.136",
 "connection": "849615",
 "connection_requests": "1",
 "pid": "89",
 "request_id": "f17e4e5dcda30462ac83b120f05fedab",
 "request_length": "619",
 "remote_addr": "65.108.78.33",
 "remote_user": "",
 "remote_port": "",
 "time_local": "04/Oct/2023:22:05:00 +0800",
 "time_iso8601": "2023-10-04T22:05:00+08:00",
 "request": "GET /category/%E4%BF%A1%E7%94%A8%E5%8D%A1 HTTP/1.1",
 "request_uri": "/category/%E4%BF%A1%E7%94%A8%E5%8D%A1",
 "args": "",
 "status": "200",
 "body_bytes_sent": "12354",
 "bytes_sent": "12987",
 "http_referer": "",
 "http_user_agent": "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)",
 "http_x_forwarded_for": "65.108.78.33",
 "http_host": "www.iminling.com",
 "server_name": "www.iminling.com,iminling.com",
 "request_time": "0.093",
 "upstream": "192.168.0.3:9000",
 "upstream_connect_time": "0.000",
 "upstream_header_time": "0.092",
 "upstream_response_time": "0.093",
 "upstream_response_length": "49160",
 "upstream_cache_status": "",
 "ssl_protocol": "",
 "ssl_cipher": "",
 "scheme": "http",
 "request_method": "GET",
 "server_protocol": "HTTP/1.1",
 "pipe": ".",
 "gzip_ratio": "3.98",
 "http_cf_ray": "810dfa2978c4376f-HEL",
 "geoip_country_code": "FI",
 "geoip_city": "Helsinki" #这里的国家和城市需要开启新的功能，后续再详细说。
}

以上就是对日志格式的说明以及如何实现以json格式输出日志。

Mac快速安装jdk17环境

Tue, 03 Oct 2023 02:55:28 +0000

对于java开发者来说jdk是再熟悉不过的了，在java圈还流行这样一句话：你发任你发，我用java8。jdk8是2013年发布的，是一个LTS版本，而在17年发布了jdk9之后，jdk的发布周期变化的更快了，很多开发者直呼学不动了。截止目前已经发布到jdk21了，关于jdk版本的发布可以参考wikipedia的Java历史版本来了解详细。我们今天要安装的是jdk17。

这么多jdk版本我们应该选择哪个来使用呢？我们先来看看jdk的版本收费情况：

JDK8以前版本，目前免费。
JDK8，免费版本至8u202，从8u211开始商用收费。
JDK9、JDK10 未收费。
JDK11，免费版本版本至11.0.2，从11.0.3开始商用收费。
JDK12、JDK13、JDK14、JDK15、JDK16，全版本商用收费。
JDK17开始，免费到2024 年 9 月，后续是否收费不明。

作为企业，很大一部分都是不想付费的，所以这也是为什么很多企业使用jdk8的8u202版本，并且不愿意升级的原因。而且jdk8是一个LTS版本，支持到2030年。而下一个LTS版本是jdk11，而jdk11又是收费的，很大一部分企业都不愿意使用，所以直到jdk17出来后，jdk又开始不收费了，而且jdk17是一个LTS版本，所以如果企业想要升级jdk，那么jdk17是一个很好的选择，oracel会支持jdk17到2029年。

为了体验jdk17以及为以后切换jdk17做准备，所以就需要我们来安装jdk17的开发环境。

mac可以选择安装Homebrew来快速安装jdk17，关于Homebrew的安装可以参考历史文章：Mac更换源更快速的安装Homebrew，这里就不再多说了，下边我们使用Homebrew来安装jdk。

安装

先搜索jdk版本：

1
2
3
4
5


# ko @ MacMini in ~ [10:32:25]
$ brew search jdk
==> Formulae
openjdk openjdk@17 ✔ jd cdk
openjdk@11 openjdk@8 mdk

可以看到有几个jdk的版本可以安装，我们需要的是17，接下来就是安装了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# ko @ MacMini in ~ [11:28:24]
$ brew install openjdk@17
==> openjdk@17
For the system Java wrappers to find this JDK, symlink it with
 sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk

openjdk@17 is keg-only, which means it was not symlinked into /opt/homebrew,
because this is an alternate version of another formula.

If you need to have openjdk@17 first in your PATH, run:
 echo 'export PATH="/opt/homebrew/opt/openjdk@17/bin:$PATH"' >> ~/.zshrc

For compilers to find openjdk@17 you may need to set:
 export CPPFLAGS="-I/opt/homebrew/opt/openjdk@17/include"

经过上边的命令后，jdk17就已经安装好了。

环境变量设置

根据安装最后的提示我们需要先新建一个软链接：

1
2
3


# konghang @ MacMini in ~ [10:37:47]
$ sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk
Password:

接下来是添加环境变量，我使用的是.base_profile，使用vim编辑后添加以下内容：

1
2
3
4


# JDK
#export JAVA_HOME="/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home"
export JAVA_HOME="/Library/Java/JavaVirtualMachines/openjdk-17.jdk/Contents/Home"
export PATH=${JAVA_HOME}/bin:$PATH

然后刷新变量，然后查看jdk版本看是否成功：

1
2
3
4
5
6
7
8


# ko @ MacMini in ~ [10:43:55]
$ source .bash_profile

# ko @ MacMini in ~ [10:43:59]
$ java -version
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment Homebrew (build 17.0.8.1+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.8.1+0, mixed mode, sharing)

看到当前的环境下使用的是jdk17了，截止到这里jdk17就已经安装成功了。接下来就可以使用jdk来进行开发和研究了。

Mac更换源更快速的安装Homebrew

Mon, 02 Oct 2023 00:00:00 +0000

Homebrew是一款Mac OS平台下的软件包管理工具，拥有安装、卸载、更新、查看、搜索等很多实用的功能。简单的一条指令，就可以实现包管理，而不用你关心各种依赖和文件路径的情况，十分方便快捷。但是安装却是需要去github去拉仓库然后进行安装，github在国内的访问速度堪忧，所以会导致整个安装过程很长，甚至安装失败，这里我记录一下我替换源进行安装的过程，希望可以帮助大家。

安装准备

Homebrew的官网提供了一键安装的脚本，脚本的实际指向是github仓库中的install仓库，查看安装脚本install.sh,可以发现安装的过程会优先读环境变量中的git仓库地址，如果没有则使用脚本中默认的github中的仓库地址，所以我们可以把要使用的源设置好环境变量，在install.sh脚本安装的时候直接使用我们设置好的源来加快安装速度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


HOMEBREW_BREW_DEFAULT_GIT_REMOTE="https://github.com/Homebrew/brew"
HOMEBREW_CORE_DEFAULT_GIT_REMOTE="https://github.com/Homebrew/homebrew-core"

# Use remote URLs of Homebrew repositories from environment if set.
HOMEBREW_BREW_GIT_REMOTE="${HOMEBREW_BREW_GIT_REMOTE:-"${HOMEBREW_BREW_DEFAULT_GIT_REMOTE}"}"
HOMEBREW_CORE_GIT_REMOTE="${HOMEBREW_CORE_GIT_REMOTE:-"${HOMEBREW_CORE_DEFAULT_GIT_REMOTE}"}"
# The URLs with and without the '.git' suffix are the same Git remote. Do not prompt.
if [[ "${HOMEBREW_BREW_GIT_REMOTE}" == "${HOMEBREW_BREW_DEFAULT_GIT_REMOTE}.git" ]]
then
 HOMEBREW_BREW_GIT_REMOTE="${HOMEBREW_BREW_DEFAULT_GIT_REMOTE}"
fi
if [[ "${HOMEBREW_CORE_GIT_REMOTE}" == "${HOMEBREW_CORE_DEFAULT_GIT_REMOTE}.git" ]]
then
 HOMEBREW_CORE_GIT_REMOTE="${HOMEBREW_CORE_DEFAULT_GIT_REMOTE}"
fi
export HOMEBREW_{BREW,CORE}_GIT_REMOTE

所以我们需要设置两个环境变量HOMEBREW_BREW_GIT_REMOTE和HOMEBREW_CORE_GIT_REMOTE

，我这里使用的是中科大的源来进行安装，具体可以参考中科的的介绍页面：Homebrew 源使用帮助。两个变量的设置脚本如下：

1
2


export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.ustc.edu.cn/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.ustc.edu.cn/homebrew-core.git"

这样就完成了源的替换，不要关闭执行上边export命令的窗口，下一步在同一个窗口执行安装脚本。

安装

执行官网的一键安装脚本：

1

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

由于替换了中科大的源，安装上不会很慢，等待程序执行完成就可以了。

安装完成后把brew添加到环境变量，编辑.bash_profile文件，添加下边一行代码：

1

export PATH=/opt/homebrew/bin:$PATH

保存后刷新环境，使配置的变量生效：

1

source .bash_profile

然后就可以正常使用brew来安装和管理应用了。

使用

下边列举一些常用的brew的使用命令：

1
2
3
4
5
6
7


brew search ** //查找某个软件包
brew list //列出已经安装的软件的包
brew install ** //安装某个软件包,默认安装的是稳定版本
brew uninstall **//卸载某个软件的包
brew upgrade ** //更新某个软件包
brew info ** //查看指定软件包的说明
brew cache clean //清理缓存

以上就是homebrew简单快速的安装过程。

WordPress用户登录管理后台进行邮件或Telegram通知

Fri, 29 Sep 2023 08:46:00 +0000

前段遇到了一个大麻烦，我的网站主页发布了两篇非我自己写的文章，在登录了worpress后台后，发现的确是有两篇文章，随后赶紧删除了那两篇文章。经过排查发现是xmlrpc功能没有关闭导致的，所以就有了我的上篇文章：禁用xmlrpc.php防止wordpress被暴力破解，事后及时关闭了该功能，然后就想着，既然要发布文章，是不是要登录我的管理后台，那么是否可以设置在用户登录wordpress管理后台的时候进行通知我呢，然后就去搜索了一下相关功能，果然还是有办法通知到我的。下边简单的分享一下该功能。

邮件配置

邮件的配置网上有很多教程，比如使用WP Mail SMTP插件，这里就跳过了。

Telegram配置

其实使用邮件配置就可以了，当有登录的时候就会通过邮件来通知我们。我这里并不想在自己的邮箱里留存太多的邮件，而且自己用Telegram比较多，就想着把通知发送Telegram会更好，我就安装了插件：WP Telegram。功能也很强，它能在要发邮件的时候劫持邮件内容到telegram:

只需要在Telegram申请好机器人就可以了，插件中也有申请步骤。

发送配置

编辑主题文件中的functions.php文件[外观-主题文件编辑器]，在文件末尾添加以下代码就可以实现了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


/*****************************************************
 函数名称：wp_login_notify v1.0 by DH.huahua.
 函数作用：有登录wp后台就会email通知博主
******************************************************/
function wp_login_notify()
{
 date_default_timezone_set('PRC');
 $admin_email = get_bloginfo ('admin_email');
 $to = $admin_email;
 $subject = '你的博客空间登录提醒';
 $message = '<p>你好！你的博客空间(' . get_option("blogname") . ')有登录！</p>' .
 '<p>请确定是您自己的登录，以防别人攻击！登录信息如下：</p>' .
 '<p>登录名：' . $_POST['username'] . '<p>' .
 '<p>登录密码：' . $_POST['password'] . '<p>' .
 '<p>登录时间：' . date("Y-m-d H:i:s") . '<p>' .
 '<p>登录IP：' . $_SERVER['REMOTE_ADDR'] . '<p>';
 $wp_email = 'no-reply@' . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME']));
 $from = "From: \"" . get_option('blogname') . "\" <$wp_email>";
 $headers = "$from\nContent-Type: text/html; charset=" . get_option('blog_charset') . "\n";
 wp_mail( $to, $subject, $message, $headers );
}
add_action('wp_login', 'wp_login_notify');

/*****************************************************
 函数名称：wp_login_failed_notify v1.0 by DH.huahua.
 函数作用：有错误登录wp后台就会email通知博主
******************************************************/
function wp_login_failed_notify()
{
 date_default_timezone_set('PRC');
 $admin_email = get_bloginfo ('admin_email');
 $to = $admin_email;
 $subject = '你的博客空间登录错误警告';
 $message = '<p>你好！你的博客空间(' . get_option("blogname") . ')有登录错误！</p>' .
 '<p>请确定是您自己的登录失误，以防别人攻击！登录信息如下：</p>' .
 '<p>登录名：' . $_POST['username'] . '<p>' .
 '<p>登录密码：' . $_POST['password'] . '<p>' .
 '<p>登录时间：' . date("Y-m-d H:i:s") . '<p>' .
 '<p>登录IP：' . $_SERVER['REMOTE_ADDR'] . '<p>';
 $wp_email = 'no-reply@' . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME']));
 $from = "From: \"" . get_option('blogname') . "\" <$wp_email>";
 $headers = "$from\nContent-Type: text/html; charset=" . get_option('blog_charset') . "\n";
 wp_mail( $to, $subject, $message, $headers );
}
add_action('wp_login_failed', 'wp_login_failed_notify');

一个是登录成功的提醒，一个是登录失败的提醒，如果有人登录wordpress后台的时候就会在telegram的机器人中进行通知：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


🔔‌你的博客空间登录提醒🔔

你好！你的博客空间(分享)有登录！

请确定是您自己的登录，以防别人攻击！登录信息如下：

登录名：

登录密码：

登录时间：2023-09-29 16:02:40

登录IP：24:4:2::

经过上边的配置，就可以在有人登录worpress后台的时候及时的通知我们，避免出现我上次遇到的情况，相对来说避免发生一些自己预想以外的事情。

禁用xmlrpc.php防止wordpress被暴力破解

Sun, 03 Sep 2023 09:07:36 +0000

很多刚接触wordpress的朋友估计和我一样，对于xmlrpc.php的了解几乎为0，这玩意儿是干嘛的？为什么它会导致wordpress被暴力破解？下面我们就先来认识一下xmlrpc.php是个什么东西。

什么是xmlrpc.php

XML-RPC是支持WordPress与其他系统之间通信的规范。它通过使用HTTP作为传输机制和XML作为编码机制来标准化这些通信来实现此目的。例如，假设您想通过移动设备在您的网站上发帖，因为您的计算机不在附近。您可以使用 xmlrpc.php 启用的远程访问功能来做到这一点。

在WordPress的早期版本中，默认情况下已关闭XML-RPC。但是自v3.5版本开始，默认情况下又启用它。这样做的主要原因是允许WordPress移动应用程序与WordPress安装进行对话通讯。

但是由于REST API已集成到WordPress核心中，因此xmlrpc.php文件不再用于此通信。相反，REST API用于与WordPress移动应用程序，桌面客户端，其他博客平台，WordPress.com（用于Jetpack插件）以及其他系统和服务进行通信。REST API-可与之交互的系统范围比xmlrpc.php所允许的大得多。此外，拥有更强的灵活性。

经历

为什么我会知道这个玩意儿呢？因为在某一天的早上，我发现我的网站突然就多了两篇文章，并不是我写的，莫名其妙的就多了两篇，于是马上修改了管理用户的登录密码，防止别人再登录。之后便开始了此次被攻击的思考，我的密码设置的也并不简单，他们是怎么知道我的密码的呢？于是我就开始了查看请求日志，在nginx的日志中果然发现了一些端倪，有大量的请求在请求xmlrpc.php这个文件：

于是我就去搜索了xmlrpc.php这个文件，不搜索不知道，一搜索吓一跳，md，肯定是这玩意儿导致我的网站多了两篇文章出来。于是开始了探索如何禁用之路。

禁用xmlrpc.php

既然wordpress出了REST API取代XML-RPC，为了安全我们应该在站点上禁用xmlrpc.php。接下来介绍三种禁用的方案。

通过nginx过滤请求

这种是我在使用的方案，通过nginx的location来定位这个请求，然后相应403，禁止请求访问。关于location的用法，参考我的另一篇文章：nginx中location使用方法总结。在处理wordpress站点的server代码块中添加以下代码来阻止其他人访问xmlrpc.php:

1
2
3


location ~* ^/xmlrpc\.php$ {
 return 403;
}

添加以后，再有人访问xmlrpc.php文件的时候就会返回403.

通过functions.php禁用

刚开始我使用的就是这种方式来禁用的，但是在更新了主题文件后，设置丢失了，所以就换成了nginx来进行拦截，这里也顺带说一下这种方式。在后台中，找到外观-主题文件编辑器菜单，然后点击右侧的functions.php,在编辑区将以下方法添加进去保存文件就可以了。

1

add_filter('xmlrpc_enabled', '__return_false');

保存后，就没办法再访问xmlrpc.php文件了。

通过.htaccess 文件禁用

.htaccess文件在/var/www/html目录下，是一个隐藏文件，我们编辑这个文件，在文件中添加以下内容来达到屏蔽xmlrpc.php文件的目的：

1
2
3
4
5
6


# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>

可以禁用所有调用该文件的情况，但是可以设置例外，我们可以把允许的ip替换xxx.xxx.xxx.xxx来达到只允许特定的ip来访问该文件。

以上就是我因为xmlrpc.php文件遭遇到的问题以及针对这种情况进行的防御，希望可以帮到大家。

linux双栈网络设置IPv4优先

Sun, 03 Sep 2023 02:58:44 +0000

双协议栈技术就是指在一台设备上同时启用 IPv4 协议栈和 IPv6 协议栈，这样就可以同时使用 IPv4 和 IPv6 的网络。但是在默认情况下都会以IPv6网络优先，只有 IPv6 无法访问的时候才会尝试访问 IPv4，某些特定的应用和场景下，我们并不想要 IPv6 优先，这时候就需要修改一些配置文件让 IPv4 优先。

查看网络优先级

可以通过以下命令来查看当前的机器是以哪个网络优先的：

1
2


root@gc:~# curl ip.sb
2000::97e4

如上返回了IPv6的地址，所以该机器默认就是通过IPv6来访问网站的，通过配置curl强制使用IPv4协议来进行访问：

1
2


root@gc:~# curl ip.sb -4
192.168.0.235

接下来就来修改配置使IPv4成功默认的出栈协议。

修改/etc/gai.conf

在 Debian、Ubuntu 等 Linux 系统下，有一个 /etc/gai.conf 文件，用于系统的 getaddrinfo 调用，默认情况下，它会使用 IPv6 优先，编辑gai.conf文件，会看到以下配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# precedence <mask> <value>
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence ::ffff:0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96 100

里边有一行提示：For sites which prefer IPv4 connections change the last line to，想要IPv4出栈，可以设置：precedence ::ffff:0:0/96 100

，根据提示把该行前的注释去掉，如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# precedence <mask> <value>
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence ::ffff:0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96 100

修改后保存，然后再使用curl访问网站，不指定使用的IPv4还是IPv6，默认情况下就走了IPv4，如下：

1
2


root@gc:~# curl ip.sb -4
192.168.0.235

修改gai.conf后就默认走了IPv4协议了。

禁用IPv6

有一些极端情况下，我们可能需要禁止系统的 IPv6 功能，这时候就需要修改 /etc/sysctl.conf 文件，首先找到你的网卡名称，默认是 eth0 ，可以通过以下命令查看自己的网卡名：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


root@gc:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
 link/ether 00:16:3c:6b:b7:c3 brd ff:ff:ff:ff:ff:ff
 altname enp0s3
 altname ens3
 inet 192.168.0.235/24 brd 192.168.0.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 2000::97e4/112 scope global
 valid_lft forever preferred_lft forever
 inet6 fe80::216:3cff:fe6b:b7c3/64 scope link
 valid_lft forever preferred_lft forever

我的网卡名就是eth0，然后修改/etc/sysctl.conf，加入一下内容(将网卡名替换为自己的)：

1
2
3
4
5
6
7
8


net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

然后使用 sysctl -p 来重新加载配置文件，此时查看 ip a 就可以发现 IPv6 已经被禁止了。

以上就是双栈网络的机器设置IPv4网络优先的方法，自己测试了Debian和Ubuntu都是可以实现的，希望可以帮到大家。

nginx中location使用方法总结

Wed, 30 Aug 2023 14:57:18 +0000

在nignx中我们比较长使用的就是location，我们使用location来定位资源或者转发请求，使用不当经常就会遇到404错误，无法找到资源或者请求异常。下面我们来详细了解一下location的用法。

语法

location的具体语法如下：

1
2


location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

语法规则很简单，一个location关键字，后面跟着可选的修饰符，后面是要匹配的字符，花括号中是要执行的操作。

修饰符

在语法中可以看到location有四中修饰符，其实还有一种就是修饰符就是什么也没有，location后边直接跟uri，下边来详细了解一下各种修饰符的作用：

= 表示精确匹配。只有请求的url路径与后面的字符串完全相等时，才会命中。 ~ 表示该规则是使用正则定义的，区分大小写。 ~* 表示该规则是使用正则定义的，不区分大小写。 ^~ 表示如果该符号后面的字符是最佳匹配，采用该规则，不再进行后续的查找。 无修饰符 表示前缀匹配

=、~和^~是非正则匹配，~和~*是正则匹配。

location匹配还有一个特点：**非正则匹配优先！**非正则>正则

匹配过程

总共5种修饰符，如果一个url请求过来可以匹配到多种，那nginx会如何选择呢？下边来看一下完整的匹配过程：

用所有的前缀字符串去匹配URI(这里说的前缀字符串，是除和*修饰的字符串外的所有字符串，包括=、^~及无修饰符三种都算是前缀字符串)；
如果找到=号修饰的字符串与URI匹配(无论它在哪个位置)，则终止匹配过程，并进入该location内部执行具体操作；
如果不找到=号修饰的字符串，则继续匹配普通前缀字符串(即用^~修饰的或无修饰符的字符串)；
在^~修饰的或无修饰符的字符串中如果有多个规则能匹配上URI，则会查看最长的那一个是否用^~修饰；
如果最长的那个有用^~修饰，则终止匹配，这个用^~修饰的“最长”的匹配就是最终被选用的location，但是如果这个“最长”的匹配没有用^~修饰(说明它是无修饰符的)，则会暂时把它存储下来，但不会终止匹配，而是继续进行后面的正则匹配；
开始正则匹配，匹配所有用或*修饰的字符串
匹配到第一个正则表达式后终止匹配，使用对应的location；
如果没有匹配到正则表达式，则使用之前存储的前缀字符串对应的location，至此，整个匹配过程结束。

路径匹配

使用location的时候，代码块里一般会使用root或者alias或者proxy_pass下边详细说一下proxy_pass的用法。

proxy_pass

Nginx的官网将proxy_pass分为两种类型：

种是只包含IP和端口号的（连端口之后的/也没有，这里要特别注意），比如proxy_pass http://localhost:8080，这种方式称为不带URI方式；
另一种是在端口号之后有其他路径的，包含了只有单个/的，如proxy_pass http://localhost:8080/，以及其他路径，比如proxy_pass http://localhost:8080/abc。

不带URI方式(相对路径)

对于不带URI方式，Nginx将会保留location中路径部分，比如：<

1
2
3


location /api1/ {
  proxy_pass http://localhost:8080;
}

在访问http://localhost/api1/xxx时，会代理到`http://localhost:8080/api1/xxx

带URI方式(绝对路径)

对于带URI方式，nginx将使用诸如alias的替换方式对URL进行替换，并且这种替换只是字面上的替换，比如：

1
2
3


location /api2/ {
  proxy_pass http://localhost:8080/;
}

当访问http://localhost/api2/xxx时，http://localhost/api2/（注意最后的/）被替换成了http://localhost:8080/，然后再加上剩下的xxx，于是变成了http://localhost:8080/xxx。下面再给一些例子来帮助大家理解相对路径和绝对路径：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


server {
 listen 80;
 server_name localhost;

 # proxy_pass中的域名是相对路径，所以会带上location中的路径
 location /api1/ {
 proxy_pass http://localhost:8080;
 }
 # http://localhost/api1/xxx -> http://localhost:8080/api1/xxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api2/ {
 proxy_pass http://localhost:8080/;
 }
 # http://localhost/api2/xxx -> http://localhost:8080/xxx

 # proxy_pass中的域名是相对路径，所以会带上location中的路径
 location /api3 {
 proxy_pass http://localhost:8080;
 }
 # http://localhost/api3/xxx -> http://localhost:8080/api3/xxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api4 {
 proxy_pass http://localhost:8080/;
 }
 # http://localhost/api4/xxx -> http://localhost:8080//xxx，匹配到/api4/xxx,location中是/api4需去掉剩下/xxx，加上proxy_pass则是//xxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api5/ {
 proxy_pass http://localhost:8080/haha;
 }
 # http://localhost/api5/xxx -> http://localhost:8080/hahaxxx，匹配到/api5/xxx, 去掉location中的/api5/剩下xxx，加上proxy_pass则是hahaxxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api6/ {
 proxy_pass http://localhost:8080/haha/;
 }
 # http://localhost/api6/xxx -> http://localhost:8080/haha/xxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api7 {
 proxy_pass http://localhost:8080/haha;
 }
 # http://localhost/api7/xxx -> http://localhost:8080/haha/xxx

 # proxy_pass中的域名是绝对路径，所以不会带上location中的路径
 location /api8 {
 proxy_pass http://localhost:8080/haha/;
 }
 # http://localhost/api8/xxx -> http://localhost:8080/haha//xxx，匹配到/api8/xxx,去掉location中的/api8剩下/xxx,加上proxy_pass则是/haha//xxx
}

以上就是nginx中location的使用方法，匹配规则，以及代码块中proxy_pass的使用方法，希望可以帮到大家。

xray分流使用IPV6解锁netflix

Sun, 13 Aug 2023 15:13:49 +0000

netflix中文名又叫网飞或者奈飞，在中国大陆是无法直接观看的，当我们买了一个vps搭建节点代理后正常情况是可以观看的，但是奈飞因为版权原因，有些vps机器并不能完整的看奈飞的所有内容，这时就引出了另一个概念：奈飞解锁。一台vps观看奈飞可以分为三种情况：

无法观看，ip比较黑，直接连奈飞的官网都无法打开
只能观看奈飞的自制剧，因为是奈飞的自制剧，就没有所谓的严格版权，都可以看。大部分vps都是这种情况
可以观看奈飞非自制剧。可以观看奈飞购买的其他的版权剧。

上面我们了解到了奈飞的一些限制，所以网上就有很多解锁教程，通过warp，dns等来解锁。本文的前提是你的vps的ipv6是解锁奈飞的非自制剧的。

我手上的这台vps就是这种情况，ipv4只能观看自制剧，ipv6可以观看奈飞非自制剧，关于查看自己的vps是否解锁，可以通过以下脚本来验证：bash <(curl -L -s check.unlock.media)

我的机器解锁情况如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


** 正在测试IPv4解锁情况
--------------------------------
============[ Multination ]============
 Dazn: No
 HotStar: No
 Disney+: Yes (Region: GB)
 Netflix: Originals Only
 YouTube Premium: Yes
 Amazon Prime Video: Yes (Region: HK)
 TVBAnywhere+: No
 iQyi Oversea Region: HK
 Viu.com: Yes (Region: HK)
 YouTube CDN: Hong Kong
 Netflix Preferred CDN: Hong Kong
 Spotify Registration: No
 Steam Currency: HKD
 ChatGPT: Yes
=======================================

 ** 正在测试IPv6解锁情况
--------------------------------
============[ Multination ]============
 Dazn: Failed (Network Connection)
 HotStar: No
 Disney+: No
 Netflix: Yes (Region: HK)
 YouTube Premium: No (Region: CN)
 Amazon Prime Video: Unsupported
 TVBAnywhere+: Failed (Network Connection)
 iQyi Oversea Region: Failed
 Viu.com: Failed
 YouTube CDN: Hong Kong
 Netflix Preferred CDN: Hong Kong
 Spotify Registration: No
 Steam Currency: Failed (Network Connection)

 ChatGPT: Yes
=======================================
本次测试已结束，感谢使用此脚本

可以看到ipv4的结果是Originals Only就是所谓的只能观看自制剧，ipv6就是完整的解锁香港的奈飞的。

下面我们将使用xray来进行分流，使观看奈飞的时候走ipv6，观看奈飞的非自制剧。

xray安装

xray可以使用官方的安装脚本，也可以参考我的xui安装教程：x-ui安装配置使用,具体的安装这里就不再详细讲了。

配置节点

先建一个入站节点，即我们需要连接到这台vps所使用的节点，可以通过xui来配置，节点类型根据自己的情况配置(vless,vmess,ss等都可以，比较稳的还是vless)，可以参考我的教程来搭建vless节点：xray搭建reality和网站共用443端口启用网站SSL，我这里为了简单直接搭建一个ss的节点，下边直接贴出xray的具体配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


{
 "routing": {
 "domainStrategy": "IPIfNonMatch",
 "rules": [
 {
 "type": "field",
 "inboundTag": [
 "api"
 ],
 "outboundTag": "api"
 },
 {
 "type": "field",
 "outboundTag": "blocked",
 "protocol": [
 "bittorrent"
 ]
 }
 ]
 },
 "dns": null,
 "inbounds": [
 {
 "listen": null,
 "port": 24567,
 "protocol": "shadowsocks",
 "settings": {
 "method": "aes-256-gcm",
 "password": "WqOQzCxMwdfeegegOK36n",
 "network": "tcp,udp"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "none",
 "tcpSettings": {
 "header": {
 "type": "none"
 },
 "acceptProxyProtocol": false
 }
 },
 "tag": "inbound-13103",
 "sniffing": {
 "enabled": true,
 "destOverride": [
 "http",
 "tls",
 "quic"
 ]
 }
 }
 ],
 "outbounds": [
 {
 "protocol": "freedom",
 "settings": {}
 },
 {
 "tag": "blocked",
 "protocol": "blackhole",
 "settings": {}
 }
 ],
 "stats": {},
 "reverse": null,
 "fakeDns": null
}

如上就是一个ss的完整配置，直接运行xray核心就可以访问了。上边的配置所有的网络都还是使用的ipv4来进行代理访问的。

配置奈飞ipv6出站

这里我们就需要使用到xray的分流策略，需要在routing配置中进行分流配置，然后在outbounds中配置具体的策略。关于分流参考官方的教程：ruleObject,ruleObject的规则如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


{
 "domainMatcher": "hybrid",
 "type": "field",
 "domain": ["baidu.com", "qq.com", "geosite:cn"],
 "ip": ["0.0.0.0/8", "10.0.0.0/8", "fc00::/7", "fe80::/10", "geoip:cn"],
 "port": "53,443,1000-2000",
 "sourcePort": "53,443,1000-2000",
 "network": "tcp",
 "source": ["10.0.0.1"],
 "user": ["love@xray.com"],
 "inboundTag": ["tag-vmess"],
 "protocol": ["http", "tls", "bittorrent"],
 "attrs": { ":method": "GET" },
 "outboundTag": "direct",
 "balancerTag": "balancer"
}

这里边的属性，如果配置多个则是要多个同时匹配中才能生效，下边我贴出配置奈飞的配置：

1
2
3
4
5
6
7


{
 "type": "field",
 "outboundTag": "netflix-tag",
 "domain": [
 "geosite:netflix"
 ]
}

我这里使用domain来配置所有netflix的网址，然后使用outboundTag来指定如果匹配中netflix的网址，应该使用netflix-tag来进行出站访问，这个netflix-tag名称是可以自定义的，但是它需要和接下来讲的outbonds中的属性匹配，outbouds的配置可以参考xray官方文档：outboudsObject,outboudsObject的规则如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "outbounds": [
 {
 "sendThrough": "0.0.0.0",
 "protocol": "协议名称",
 "settings": {},
 "tag": "标识",
 "streamSettings": {},
 "proxySettings": {
 "tag": "another-outbound-tag"
 },
 "mux": {}
 }
 ]
}

下边我贴出具体的配置：

1
2
3
4
5
6
7


{
 "tag": "netflix-tag",
 "protocol": "freedom",
 "settings": {
 "domainStrategy": "UseIPv6"
 }
}

tag和routing下的ruleobject中的tag对应，经过上边的两个配置就可以使奈飞通过ipv6出站了。

完整配置

完整的xray配置config.json如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81


{
 "routing": {
 "domainStrategy": "IPIfNonMatch",
 "rules": [
 {
 "type": "field",
 "inboundTag": [
 "api"
 ],
 "outboundTag": "api"
 },
 {
 "type": "field",
 "outboundTag": "netflix-tag",
 "domain": [
 "geosite:netflix"
 ]
 },
 {
 "type": "field",
 "outboundTag": "blocked",
 "protocol": [
 "bittorrent"
 ]
 }
 ]
 },
 "dns": null,
 "inbounds": [
 {
 "listen": null,
 "port": 13103,
 "protocol": "shadowsocks",
 "settings": {
 "method": "aes-256-gcm",
 "password": "WqOQzCxMwdfeegegOK36n",
 "network": "tcp,udp"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "none",
 "tcpSettings": {
 "header": {
 "type": "none"
 },
 "acceptProxyProtocol": false
 }
 },
 "tag": "inbound-13103",
 "sniffing": {
 "enabled": true,
 "destOverride": [
 "http",
 "tls",
 "quic"
 ]
 }
 }
 ],
 "outbounds": [
 {
 "protocol": "freedom",
 "settings": {}
 },
 {
 "tag": "netflix-tag",
 "protocol": "freedom",
 "settings": {
 "domainStrategy": "UseIPv6"
 }
 },
 {
 "tag": "blocked",
 "protocol": "blackhole",
 "settings": {}
 }
 ],
 "stats": {},
 "reverse": null,
 "fakeDns": null
}

下边也给出在x-ui中的配置，具体配置位置是登录x-ui后左侧菜单：面板设置，然后点击到xray配置，然后把下边的配置粘贴到配置模板中就可以了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


{
 "api": {
 "services": [
 "HandlerService",
 "LoggerService",
 "StatsService"
 ],
 "tag": "api"
 },
 "inbounds": [
 {
 "listen": "127.0.0.1",
 "port": 62789,
 "protocol": "dokodemo-door",
 "settings": {
 "address": "127.0.0.1"
 },
 "tag": "api"
 }
 ],
 "outbounds": [
 {
 "protocol": "freedom",
 "settings": {}
 },
 {
 "tag": "netflix-tag",
 "protocol": "freedom",
 "settings": {
 "domainStrategy": "UseIPv6"
 }
 },
 {
 "protocol": "blackhole",
 "settings": {},
 "tag": "blocked"
 }
 ],
 "policy": {
 "levels": {
 "0": {
 "handshake": 10,
 "connIdle": 100,
 "uplinkOnly": 2,
 "downlinkOnly": 3,
 "statsUserUplink": true,
 "statsUserDownlink": true,
 "bufferSize": 10240
 }
 },
 "system": {
 "statsInboundDownlink": true,
 "statsInboundUplink": true
 }
 },
 "routing": {
 "rules": [
 {
 "inboundTag": [
 "api"
 ],
 "outboundTag": "api",
 "type": "field"
 },
 {
 "type": "field",
 "outboundTag": "netflix-tag",
 "domain": [
 "geosite:netflix"
 ]
 }
 ]
 },
 "stats": {}
}

经过上边的配置，正确的创建节点，就可以愉快的通过ipv4入站，然后通过ipv6出站去访问netflix网站了，享受解锁的快乐。当然上边的配置只是netflix才走ipv6出站，其他的网站还是通过ipv4来出站，如果想要让其他什么网站也通过ipv6出站，就需要在routing中配置ruleObject来达到目的。

xui网页配置(另一种方法)

上边介绍的是纯手工的去对配置文件进行编辑的方式，最近xui更新后，这些配置可以在网页端进行图形化的操作，大大降低了对新手的难度，下边来看一下如何在xui网页端来对netflix由IPv6处站做配置。如果对xui还不知道如何使用的同学可以参考我的文章来安装配置xui：x-ui安装配置使用.

出站配置

登录xui网站，菜单栏有一个xray设置一级菜单：

点开xray设置后看到有四个tab页：基本模板、路由规则、出站和高级模板部件。在上边纯手工配置xray的时候也提到过，需要有一个outboud和一个routing，在xui的网页上其实就对应出站(outbond)以及路由规则(routing)。所以在网页端配置这两个就可以了，先来配置出站，添加一个freedom类型的节点：

协议：freedom

标签：全局唯一(英文)，等下要在路由规则那里进行选择

strategy：选择使用IPv6

然后点击保存就创建好了一个出站规则了，此时出站规则并没有任何路由规则引用到它，所以并不会有任何作用，接下来就需要在路由规则中进行引用，使特定网站使用IPv6进行出站访问。

路由规则配置

如下图，添加一个路由规则，Outbound Tag就是刚才添加的出站配置的标签，是唯一的，因为是要设置netflix使用IPv6，所以Domain那项配置就把netflix的域名规则写进去，这里的配置是且的关系，所以如果需要更灵活的配置可以自己添加。例如我只想某个用户在访问netflix的时候使用IPv6出站，那么就可以在User里把这个用户的信息配置进去，具体用户是什么，是我们在添加节点的时候每个节点都要求填一个邮箱，邮箱即用户。

配置好后就可以重启一下xray，规则就生效了。

好了本文的教程就到这里，祝大家都可以成功的搭建成功。

docker网络模式简介

Mon, 07 Aug 2023 21:29:16 +0000

日常开发中都有使用到docker，一直对docker的网络不是很清楚，所以花了点时间了解一下docker的网络，这里对了解的知识进行一下总结。

当我们安装好docker后，docker默认给我们创建了3个网络，如下：

1
2
3
4
5


ubuntu@VM-20-3-ubuntu:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
cde83331f977 bridge bridge local
0e504852d7be host host local
cdc83d5d9388 none null local

分别是bridge,host和none。下边我们就来看一下这三种网络的区别。

bridge网络

桥接网络也是docker的默认网络，当我们安装好docker后，docker会在宿主机创建一个网卡docker0：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
 link/ether 52:54:00:ee:63:60 brd ff:ff:ff:ff:ff:ff
 inet 10.0.20.3/22 brd 10.0.23.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::5054:ff::6360/64 scope link
 valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
 link/ether 02:42:0c:be:59:f7 brd ff:ff:ff:ff:ff:ff
 inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
 valid_lft forever preferred_lft forever
 inet6 fe80::42:cff:febe:59f7/64 scope link
 valid_lft forever preferred_lft forever

如上，docker0网络就是docker默认的网络，他的网关是172.17.0.1,我们可以先查看一下这个bridge网络的情况(已去除多余属性)：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


ubuntu@VM-20-3-ubuntu:~$ docker inspect bridge
[
 {
 "Name": "bridge",
 "Id": "cde83331f977b86b4eaa67fe05ea18e493691fd0d3fc5edc51dec4e62a512d37",
 "Created": "2022-08-25T20:37:27.17350164+08:00",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": [
 {
 "Subnet": "172.17.0.0/16",
 "Gateway": "172.17.0.1"
 }
 ]
 },
 "Containers": {}
 }
]

subnet和docker0是一样的，containers那里暂时也是没有容器，当我们启动一个容器来使用默认的bridge网络的时候，这里边就会有对应的容器了。

我们来启动一个nginx容器，然后再来查看一下这个网络：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


ubuntu@VM-20-3-ubuntu:~$ docker run -d --name nginx-test nginx:1.22.0
4ee2915a41fa9ed6e2591f852789f5762343e3de5bdabe718896778305df3569
ubuntu@VM-20-3-ubuntu:~$ docker inspect bridge
[
 {
 "Name": "bridge",
 "Id": "cde83331f977b86b4eaa67fe05ea18e493691fd0d3fc5edc51dec4e62a512d37",
 "Created": "2022-08-25T20:37:27.17350164+08:00",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": [
 {
 "Subnet": "172.17.0.0/16",
 "Gateway": "172.17.0.1"
 }
 ]
 },
 "Containers": {
 "4ee2915a41fa9ed6e2591f852789f5762343e3de5bdabe718896778305df3569": {
 "Name": "nginx-test",
 "EndpointID": "f518fa3072bbabc3de35577e5dc99570e8e3604e23a19911473b83fe90a85d73",
 "MacAddress": "02:42:ac:11:00:02",
 "IPv4Address": "172.17.0.2/16",
 "IPv6Address": ""
 }
 }
 }
]

containers中已经有刚才创建的nginx的容器了。如果该容器想要和外界进行交互就需要暴露端口出来，然后外界才能和他进行网络通信，否则就只能从容器内部访问到外部，而无法从外部访问到容器内部。

1
2
3


ubuntu@VM-20-3-ubuntu:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4ee2915a41fa nginx:1.22.0 "/docker-entrypoint.…" 2 minutes ago Up 2 minutes 80/tcp nginx-test

我们刚才的容器，内部会暴露80端口，如果我们需要和外部的端口映射，需要在启动容器的时候加上-v参数来映射端口，这里就不再演示了。

在默认bridge网络下的容器是无法相互通过容器名称进行通信的，因为没有进行name的主机解析，如果需要让多个容器通过name进行访问，就需要我们创建自己的bridge网络了。创建命令如下：

1

docker network create --driver bridge --subnet 192.168.0.0/16 --gateway 192.168.0.1 mynet

上边命令创建了一个mynet的桥接网络，然后在创建容器的时候使用这个网络，不同的容器间就可以使用容器名进行网络访问，创建容器命令：

1

ubuntu@VM-20-3-ubuntu:~$ docker run -d --network mynet --name nginx-test nginx:1.22.0

通过–network指定容器工作的网络。

host网络

host顾名思义就是和宿主机共用同一个网络，容器没有和宿主机很好的隔离，容器占用的端口就是宿主机的端口，被容器占用的端口宿主机里的程序就没办法使用，容器里可以直接访问宿主机的其他应用程序服务，无需经过其他特殊的设置。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


ubuntu@VM-20-3-ubuntu:~$ docker inspect host
[
 {
 "Name": "host",
 "Id": "0e504852d7be83b42232d744a36504266c52cca3f1647eaeaa9d090117826924",
 "Created": "2022-05-20T13:41:40.594740985+08:00",
 "Scope": "local",
 "Driver": "host",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": []
 },
 "Internal": false,
 "Attachable": false,
 "Ingress": false,
 "ConfigFrom": {
 "Network": ""
 },
 "ConfigOnly": false,
 "Containers": {},
 "Options": {},
 "Labels": {}
 }
]

我们使用host模式创建的容器也不会显示在containers里边。

none网络

在这种模式下，docker容器没有任何网络设置，无法访问宿主机网络，宿主机也没办法访问容器的网络，做到了很好的隔离，开发中也很少用到。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


ubuntu@VM-20-3-ubuntu:~$ docker inspect none
[
 {
 "Name": "none",
 "Id": "cdc83d5d9388583dcee94758821adcd70f57825cbb05f2bcab726d484e9e9fdb",
 "Created": "2022-05-20T13:41:40.580477496+08:00",
 "Scope": "local",
 "Driver": "null",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": []
 },
 "Internal": false,
 "Attachable": false,
 "Ingress": false,
 "ConfigFrom": {
 "Network": ""
 },
 "ConfigOnly": false,
 "Containers": {},
 "Options": {},
 "Labels": {}
 }
]

我们正常使用的话，还是bridge网络用的多一些，因为各服务都是需要相互调用的，要做到网络互通。以上就是对docker三种模式的一些总结。

nginx配置隐藏版本号提升安全

Sat, 05 Aug 2023 19:21:16 +0000

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务，是个软件肯定都会多多少少有一些漏洞，所以我们需要隐藏nginx的版本号，让攻击者没那么容易很快的攻破我们的网站。

nginx官方提供了关闭显示版本号的方法，其实也很简单，只需要添加server_tokens off就可以了，server_tokens可以到http,server和location块中，我们找一个合适的位置添加进去就可以了。

添加前

没有添加之前请求网站信息如下：

```bash $ curl -I https://www.iminling.com HTTP/2 200 server: nginx/2.24.2 date: Sun, 06 Aug 2023 03:02:12 GMT content-type: text/html; charset=UTF-8 x-powered-by: PHP link: ; rel="https://api.w.org/" ```

如上，server中会把nginx的完整版本号信息展示出来。

添加server_token

我这里把server_token添加到server块中，如下：

server {
listen 8443 ssl http2;
server_name www.iminling.com;
index index.php index.html index.htm;
root /var/www/html;
server_tokens off; # 添加server_tokens屏蔽显示版本号
include conf.d/ssl_params.conf;
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
}

如上，在server中添加server_tokens为off，然后我们再去验证一下。

添加后

再来看一下请求网站的信息：

1
2
3
4
5
6
7


$ curl -I https://www.iminling.com
HTTP/2 200
server: nginx
date: Sun, 06 Aug 2023 03:02:31 GMT
content-type: text/html; charset=UTF-8
x-powered-by: PHP
link: <https://www.iminling.com/wp-json/>; rel="https://api.w.org/"

如上，server里只显示了nginx。

经过上边的配置就可以隐藏nginx的版本号了。

xray搭建reality和网站共用443端口启用网站SSL

Mon, 31 Jul 2023 06:30:46 +0000

当我们只有一个vps，又想部署网站同时又想搭建代理，当然两个程序可以分开占用端口，做到不冲突，但是感觉不怎么优雅，所以想要让两个程序都去共用一个443端口，这样子网站可以使用域名并开启ssl，代理也可以使用443(心理作用，感觉代理走443会更好一些，毕竟代理使用了ssl，走其他端口怪怪的)。下面就开启折腾之路。

代理协议

目前比较稳定的协议要数reality了，所以自己搭建的代理也是使用reality，reality可以使用自己的证书，也可以使用其他域名的证书：就是宣传的“偷证书”。既然我的网站要使用443开启ssl，那我当时使用自己的证书最方便，而且延迟最小。

证书申请

安装reality可以使用xui来安装，具体的xui安装可以参考我的文章：x-ui安装配置使用。xui本身可以帮助我们申请证书，如果不想使用xui的证书申请，还可以参考我的另一篇文章使用certbot来申请证书：docker部署certbot申请Let’s Encrypt证书，我这里就使用certbot来申请证书。

站点部署

这里是为了演示，所以我这里就只启动nginx，然后配置ssl，对域名启用ssl。nginx我使用的是docker来启动的，具体的目录如下,所在的路径是：/root/images/nginx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


├── README.md
├── conf
│ ├── conf.d
│ └── nginx.conf
├── docker-compose.yaml
├── html
│ └── index.html
└── logs
 ├── 1.txt
 ├── access.log
 ├── error.log</code></pre>

conf目录下是站点的配置文件，nginx.conf是默认的，它包含了conf.d目录为的所有.conf结尾的文件。

nginx.conf

nginx.conf的配置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


user nginx;
worker_processes auto;

error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;

events {
 worker_connections 1024;
}

http {
 include /etc/nginx/mime.types;
 default_type application/octet-stream;

 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 access_log /var/log/nginx/access.log main;

 sendfile on;
 #tcp_nopush on;

 keepalive_timeout 65;

 #gzip on;

 include /etc/nginx/conf.d/*.conf;
}

很简单就是默认配置。

web.conf

web.conf是在conf.d目录下的，就是我们部署的站点的配置文件，如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


# 设置 HTTP 服务器，将所有 HTTP 请求都重定向到 HTTPS
server {
 listen 80;
 server_name test.xxx.me;

 # 重定向所有 HTTP 请求到 HTTPS
 location / {
 return 301 https://$server_name$request_uri;
 }
}

# 设置 HTTPS 服务器
server {
 listen 443 ssl http2;
 server_name test.xxx.me; # ======域名，需要改成自己的=========

 # SSL 证书和密钥文件的路径
 ssl_certificate /etc/letsencrypt/ssl/xx/fullchain.pem; # ======自己的证书文件路径=========
 ssl_certificate_key /etc/letsencrypt/ssl/xx/privkey.pem;# ====自己的证书文件路径=======

 # 可选：设置 SSL 会话缓存
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 10m;

 # 可选：设置 SSL 协议和加密算法
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

 # 可选：开启 OCSP Stapling，提高 SSL 握手性能
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate /etc/letsencrypt/ssl/xx/fullchain.pem; # ======自己的证书文件路径=======

 # 可选：设置 Content Security Policy（内容安全策略）头
 # add_header Content-Security-Policy "default-src 'self';" always;

 # 可选：设置访问日志
 access_log /var/log/nginx/test.access.log;
 error_log /var/log/nginx/test.error.log;

 location / {
 root /usr/share/nginx/html;
 index index.html index.htm;
 }
}

访问80端口强制转到443端口，证书使用的是docker中的使用certbot申请的证书。证书的路径是和下边的docker-compose.yaml中挂载的目录相关的，xx只是为了在nginx容器中找到正确的目录。

docker-compose.yaml

具体内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


version: '3'
networks:
 mynet:
 external: true
services:
 nginx:
 image: nginx:1.22.0
 restart: unless-stopped
 container_name: nginx
 volumes:
 - ./conf/nginx.conf:/etc/nginx/nginx.conf
 - ./conf/conf.d:/etc/nginx/conf.d
 - ./html:/usr/share/nginx/html
 - ./logs:/var/log/nginx
 - /root/images/certbot/certs:/etc/letsencrypt
 - /root/images/certbot/certs/live/test.ml520.me:/etc/letsencrypt/ssl/xx
 networks:
 - mynet
 ports:
 - 80:80
 - 443:443

这里映射了letsencrypt的两个目录，配合nginx，找到对应的证书路径，如果不是在docker中就按找实际的证书路径处理就行了。

index.html

index.html就是一个非常简单的网页了，里边的内容很随意,就是一个欢迎语。

这时候我们把nginx启动起来，通过域名访问我们的网站看是否已经可以正常使用https。

代理配置

代理的配置这里就简单带过，通过x-ui或者直接安装xray-core来运行。也可以通过我的镜像：xray，直接使用docker安装，参考文章：xray配置使用reality

xray的配置文件如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81


{
 "log": {
 "loglevel": "warning",
 "access": "/var/log/xray/access.log",
 "error": "/var/log/xray/error.log"
 },
 "api": {
 "services": [
 "HandlerService",
 "LoggerService",
 "StatsService"
 ],
 "tag": "api"
 },
 "inbounds": [
 {
 "listen": null,
 "port": 8443,
 "protocol": "vless",
 "settings": {
 "clients": [
 {
 "id": "0c41318a-32b6-4017-9938-4033bf261234",
 "flow": "xtls-rprx-vision",
 "email": "reality@xray.com"
 }
 ],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "show": false,
 "dest": "www.microsoft.com:443",
 "xver": 1,
 "serverNames": [
 "www.microsoft.com"
 ],
 "privateKey": "uPPcl9806d81DMdlojRB_ps78jrxNpT0wcG0ueOmD69",
 "shortIds": [
 "6ba85179e30d4fc2"
 ]
 }
 },
 "sniffing": {
 "enabled": true,
 "destOverride": [
 "http",
 "tls"
 ]
 }
 }
 ],
 "outbounds": [
 {
 "tag": "common",
 "protocol": "freedom"
 }
 ],
 "routing": {
 "rules": [
 {
 "type": "field",
 "outboundTag": "common",
 "network": "udp,tcp"
 }
 ]
 },
 "policy": {
 "statsInboundUplink": true,
 "statsInboundDownlink": true,
 "statsOutboundUplink": true,
 "statsOutboundDownlink": true
 },
 "dns": null,
 "transport": null,
 "stats": null,
 "reverse": null,
 "fakeDns": null
}

这里先使用偷微软的证书进行验证。不出意外就已经ok了，此时xray用的8443，nginx使用的443，两个单独占用端口，是完全可以正常访问的。

共用端口

经过上边的准备，现在我们就可以开始来合并端口了，首先是修改nginx的配置，原来的nginx容器是暴露了80和443端口，现在我们需要把443端口让给xray，所以需要修改docker-compose.yaml文件，改变端口映射，让它的https使用18443，并且需要修改nginx的web.conf配置文件。

docker-compose.yaml

内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


version: '3'
networks:
 mynet:
 external: true
services:
 nginx:
 image: nginx:1.22.0
 restart: unless-stopped
 container_name: nginx
 volumes:
 - ./conf/nginx.conf:/etc/nginx/nginx.conf
 - ./conf/conf.d:/etc/nginx/conf.d
 - ./html:/usr/share/nginx/html
 - ./logs:/var/log/nginx
 - ./../naiveproxy/conf/cert:/ssl
 - ./../wordpress/html:/wordpress
 - /root/images/certbot/certs:/etc/letsencrypt
 - /root/images/certbot/certs/live/test.ml520.me:/etc/letsencrypt/ssl/xx
 networks:
 - mynet
 ports:
 - 80:80
 - 18443:18443 # 主要是修改这里，改变端口映射

主要是修改了端口，由原来的443改成18443，把443端口让给xray使用。

改了开放端口后，还需要修改web.conf，把监听的443变成18443以及一些其他配置。

web.conf

先放出配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# 设置 HTTP 服务器，将所有 HTTP 请求都重定向到 HTTPS
server {
 listen 80;
 server_name test.xxx.me;

 # 重定向所有 HTTP 请求到 HTTPS
 location / {
 return 301 https://$server_name$request_uri;
 }
}

# 设置 HTTPS 服务器
server {
 listen 18443 ssl http2 proxy_protocol; # =======修改了这里======
 server_name test.xxx.me;
 set_real_ip_from 127.0.0.1; # ======添加了这里=======
 real_ip_header proxy_protocol; # ======添加了这里======

 # SSL 证书和密钥文件的路径
 ssl_certificate /etc/letsencrypt/ssl/xx/fullchain.pem; # 证书文件，通常不区分扩展名，证书文件需要使用fullchain（全SSL证书链）
 ssl_certificate_key /etc/letsencrypt/ssl/xx/privkey.pem; # 私钥文件，通常不区分扩展名

 # 可选：设置 SSL 会话缓存
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 10m;

 # 可选：设置 SSL 协议和加密算法
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

 # 可选：开启 OCSP Stapling，提高 SSL 握手性能
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate /etc/letsencrypt/ssl/xx/fullchain.pem;

 # 可选：设置访问日志
 access_log /var/log/nginx/test.access.log;
 error_log /var/log/nginx/test.error.log;

 location / {
 root /usr/share/nginx/html;
 index index.html index.htm;
 }
}

主要是修改了listen的配置，添加了proxy_protocol,另外添加了set_real_ip_from和real_ip_header。

接下来就是修改xray的配置文件了。

xray配置

主要是修改config.json文件，从原来的8443换成可，以及域名配置，详细改动如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81


{
 "log": {
 "loglevel": "warning",
 "access": "/var/log/xray/access.log",
 "error": "/var/log/xray/error.log"
 },
 "api": {
 "services": [
 "HandlerService",
 "LoggerService",
 "StatsService"
 ],
 "tag": "api"
 },
 "inbounds": [
 {
 "listen": null,
 "port": 443,
 "protocol": "vless",
 "settings": {
 "clients": [
 {
 "id": "0c41234a-32b6-4017-9938-4033bf26b948",
 "flow": "xtls-rprx-vision",
 "email": "reality@xray.com"
 }
 ],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "show": false,
 "dest": "nginx:18443", # 这里目标网站要换成我们的nginx里的地址，这里使用了容器名加ssl监听端口
 "xver": 1, # 该参数我也不知道是什么意思
 "serverNames": [
 "test.xxx.me" # 域名就换成自己的域名
 ],
 "privateKey": "uPPcl3v45d81DMdlojRB_ps78jrxNpT0wcG0ueOmD12",
 "shortIds": [
 "6ba85179e30d4fc2"
 ]
 }
 },
 "sniffing": {
 "enabled": true,
 "destOverride": [
 "http",
 "tls"
 ]
 }
 }
 ],
 "outbounds": [
 {
 "tag": "common",
 "protocol": "freedom"
 }
 ],
 "routing": {
 "rules": [
 {
 "type": "field",
 "outboundTag": "common",
 "network": "udp,tcp"
 }
 ]
 },
 "policy": {
 "statsInboundUplink": true,
 "statsInboundDownlink": true,
 "statsOutboundUplink": true,
 "statsOutboundDownlink": true
 },
 "dns": null,
 "transport": null,
 "stats": null,
 "reverse": null,
 "fakeDns": null
}

如上，改动不大，主要是dest、xver和server_name。另外需要修改xray的docker-compose.yaml,把原来的8443端口改成443端口，并重新build启动。

验证

经过上边的改变后，通过域名就可以访问到项目，并且reality也同时在监听443，代理工具的配置改成443端口，域名也改成自己的就可以正常使用了。我这里就不再贴图了。完美的实现网站和xray共存，xray也成功的偷了自己的证书。

最后祝大家都能成功配置。

参考：

steal_yourself

docker部署certbot申请Let’s Encrypt证书

Sun, 30 Jul 2023 00:21:32 +0000

最近想给域名申请一个免费的证书，经过查询找到了Let’s Encrypt，并且可以使用certbot来申请，因为一直在使用docker,所以就想着看是否可以使用docker来进行证书的申请，于是就开启了此次的折腾之路：使用docker部署certbot申请Let’s Encrypt证书。

安装certbot

certbot的安装方式有很多种，官方也有一些系统的安装文档，可以根据官方的安装文档来直接安装到对应的操作系统上：installation，非常详细。官方推荐的方式是通过snap的形式来安装，另外还有docker、pip、第三放发行版本以及certbot-auto(官方已经标示为过期)。

申请形式

申请证书的形式也有很多:

apache{#id9.reference.internal}
Webroot{#id10.reference.internal}
Nginx{#id11.reference.internal}
Standalone{#id12.reference.internal}
DNS Plugins{#id13.reference.internal}
Manual{#id14.reference.internal}
Combining plugins{#id15.reference.internal}
Third-party plugins{#id16.reference.internal}

其中一些方式要配合开启80和443端口来实现，还需要进行域名解析，我这里就选择使用DNS Plugins的形式来进行申请，因为域名在cloudflare，所以就使用certbot-dns-cloudflare插件来进行申请，文档地址：Welcome to certbot-dns-cloudflare’s documentation!。

申请准备

docker文件的目录如下：

1
2
3
4
5
6


├── certs //存放证书
├── conf
│ ├── cloudflare.ini //配置文件
├── logs //日志
└── docker-compose.yml //docker-compse文件
└── .env //环境变量信息

certs

目录是映射到docker容器中的，存放证书文件。

cloudflare.ini

该要存放cloudflare的api token,这里使用的是自己创建的token，配置文件内容如下：

dns_cloudflare_api_token = your_cloudflare_api_key

具体的生成方式看下图：

选择创建令牌：

区域中选择DNS给一个编辑权限，然后就是区域字段选择自己的域名，我这里是给每个域名单独的token，所以需要选择一个域名，可以根据自己需求选择。

logs

logs中是存在certbot执行日志的地方。

docker-compose.yaml

docker-compose.yaml文件内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: "3"
services:
 certbot:
 image: certbot/dns-cloudflare:v2.4.0
 container_name: certbot
 env_file:
 - .env
 volumes:
 - ./certs:/etc/letsencrypt
 - ./logs:/var/log/letsencrypt
 - ./conf/cloudflare.ini:/secrets/cloudflare.ini
 # dry run
 # command: certonly --dns-cloudflare --agree-tos --non-interactive --dns-cloudflare-credentials /secrets/cloudflare.ini --email ${CERTBOT_EMAIL} --dns-cloudflare-propagation-seconds 20 -d ${CERTBOT_DOMAIN} --dry-run
 # issue --force-renewal
 command: certonly --dns-cloudflare --agree-tos --non-interactive --dns-cloudflare-credentials /secrets/cloudflare.ini --email ${CERTBOT_EMAIL} --dns-cloudflare-propagation-seconds 20 -d ${CERTBOT_DOMAIN}
 # renew
 # command: renew --dns-cloudflare --no-self-upgrade --agree-tos --non-interactive --dns-cloudflare-credentials /secrets/cloudflare.ini --dns-cloudflare-propagation-seconds 20

使用.env配置文件，然后把certbot中的/etc/letsencrypt目录映射到容器外部的certs目录，另外就是日志以及cloudflare的配置文件。

执行的命令有三个，dry-run是测试申请功能是否正常，如果正常则使用issue的命令进行正常申请，因为申请的证书只有三个月的有效期，所以需要进行续期，续期使用renew的命令。

–agree-tos 同意tos(term of service)

–non-interactive 非交互式的

–dns-cloudflare-credentials 指定cloudflare的token文件位置

–eamil 邮箱

–dns-cloudfalre-propagation-seconds 等待时间

-d 指定需要申请证书的域名，如果有多个域名则指定多个-d参数。如果需要申请泛域名证书，则使用*.xxx.com，生成的证书会在xxx.com目录下。

.env

env文件是一些配置信息，如上边的docker-compose.yaml文件中有两个动态的参数，一个是邮箱，另一个是申请证书的域名，我们就是在.env文件中指定的，内容如下：

CERTBOT_DOMAIN=your_domain_name
CERTBOT_EMAIL=your_email

指定邮箱和域名就可以了。

申请

经过上边的文件准备，接下来就可以开始申请了，使用docker compose up 来进行申请。申请后的证书就在certs目录下。

1
2
3
4
5
6
7


├── 1.txt
├── accounts
├── archive
├── live
├── renewal
├── renewal-hooks
└── ssl

证书文件在live下。然后我们就可以在nginx中使用我们申请的证书文件了。

续期

证书三个月的有效期，在快要过期的时候需要进行续期，续期则使用docker-compose.yaml文件中的续期命令就可以了。大家也可以做一个corn定时任务来进行定期续期。

最后祝大家申请顺利。

docker容器配置ipv6

Sat, 15 Jul 2023 21:34:56 +0000

在默认情况下，docker默认只是配置了ipv4地址，并没有ipv6地址，需要我们手动的去进行ipv6地址配置。下面就介绍一下容器支持ipv6的一种方式。

docker启用ipv6

具体的方式我们先参考docker的官方文档：Enable IPv6 support,启用docker对ipv6的支持。需要修改daemon.json文件，具体位置为/etc/docker/目录下，如果没有则自己创建daemon.json,添加以下内容：

{ “experimental”: true, “ip6tables”: true }

然后对docker进行重启。systemctl restart docker

创建网络

我安装docker后都会自己创建一个桥接网络已方便启动的各个容器之间的网络通信。创建网络的命令如下：

1

docker network create --driver bridge --subnet 192.168.0.0/16 --gateway 192.168.0.1 mynet

如上创建了一个名字为mynet的网络，可以使用docker inspect来查看这个网络：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


root@us-la:~# docker inspect mynet
[
 {
 "Name": "mynet",
 "Id": "914c2a3a0a6ae0bdc0b8d51ba4782b6d232e6c978f2b0596fc4b7938d6c72ddd",
 "Created": "2022-08-21T09:19:48.858428501Z",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": {},
 "Config": [
 {
 "Subnet": "192.168.0.0/16",
 "Gateway": "192.168.0.1"
 }
 ]
 },
 "Internal": false,
 "Attachable": false,
 "Ingress": false,
 "ConfigFrom": {
 "Network": ""
 },
 "ConfigOnly": false,
 "Containers": {
 "edfd85b3884679256388f3c13afcd1774ac282a34de2438191bdad824a68f765": {
 "Name": "nginx",
 "EndpointID": "eafe61ed19613cfd2a7f56ee1737987d907a26210f0de557499fe4e6c1171e9c",
 "MacAddress": "02:42:c0:a8:00:02",
 "IPv4Address": "192.168.0.2/16",
 "IPv6Address": ""
 }
 },
 "Options": {},
 "Labels": {}
 }
]

这个网络只支持ipv4，我们可以ping一下v6看看：

1
2
3


root@us-la:~# docker run --rm -it --net mynet busybox ping -6 -c4 ipv6-test.com
PING ipv6-test.com (2001:41d0:701:1100::29c8): 56 data bytes
ping: sendto: Cannot assign requested address

如果我们需要支持ipv6，需要创建一个ipv6网络。

创建ipv6网络

用以下命令来创建一个ipv6网络：

1
2


docker network create --ipv6 --subnet="2001:db8:1::/64" --subnet="192.168.0.0/24" mynet
9db7d457fd11f8c7c4256a1f4b2e00085d537f34e15dd0b0636bc00d4aa6d234

再次检查网络：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


root@WIKIHOST-221108EU1RTF:~/images# docker network ls
NETWORK ID NAME DRIVER SCOPE
9a75cccf2d9a bridge bridge local
5677c5bdadce host host local
9db7d457fd11 mynet bridge local
86ce569ad194 none null local
root@1RTF:~/images# docker inspect mynet
[
 {
 "Name": "mynet",
 "Id": "9db7d457fd11f8c7c4256a1f4b2e00085d537f34e15dd0b0636bc00d4aa6d234",
 "Created": "2023-07-12T09:48:08.273299482-04:00",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": true,
 "IPAM": {
 "Driver": "default",
 "Options": {},
 "Config": [
 {
 "Subnet": "192.168.0.0/24"
 },
 {
 "Subnet": "2001:db8:1::/64"
 }
 ]
 },
 "Internal": false,
 "Attachable": false,
 "Ingress": false,
 "ConfigFrom": {
 "Network": ""
 },
 "ConfigOnly": false,
 "Containers": {},
 "Options": {},
 "Labels": {}
 }
]

多了一个ipv6的子网。

容器支持ipv6

docker run

使用docker run命令运行容器的时候只需要加上–net 就可以使用我们创建的网络了：

1
2
3
4
5


root@U1RTF:~# docker run --rm -it --net mynet busybox ping -6 -c4 ipv6-test.com
PING ipv6-test.com (2001:41d0:701:1100::29c8): 56 data bytes
64 bytes from 2001:41d0:701:1100::29c8: seq=0 ttl=45 time=249.606 ms
64 bytes from 2001:41d0:701:1100::29c8: seq=1 ttl=45 time=249.622 ms
64 bytes from 2001:41d0:701:1100::29c8: seq=2 ttl=45 time=249.691 ms

通过上边命令可以发现已经支持了ipv6了。

docker compose

编写docker-compose.yaml文件，使用刚才创建的网络。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


version: '3'
networks:
 mynet:
 external: true
services:
 xray:
 image: teddysun/xray
 restart: unless-stopped
 container_name: xray
 environment:
 # 自定义host
 - XRAY_HOST=${XRAY_HOST}
 ports:
 - 13100:13100
 networks:
 - mynet
 volumes:
 - ./log:/var/log/xray
 - ./conf/config.json:/etc/xray/config.json

运行上边的xray后再执行ping v6，也是可以正常ping通的。

至次，我们已经可以给docker容器分配ipv6地址了，以上就是折腾过程，记录一下。

极光面板安装及迁移

Fri, 09 Jun 2023 22:08:05 +0000

极光面板是一个多服务器端口租用管理面板，你可以添加多台服务器及端口，并将其分配给任意注册用户，租户则可以很方便地使用被分配的端口来完成各种操作。支持IPv4以及IPv6。github地址：极光面板。

准备工作

在正式安装极光面板之前需要在要安装的机器上准备以下工作：

安装docker和docker-compose, 参考：docker安装
生成ssh密钥。如果使用密码连接就不用生成

ssh密钥生成：

1
2
3
4


# 如果面板服务器并没有已经生成好的 ssh 密钥
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
# 后面一直回车，跳过设置 passphase 即可
# 然后还需要将面板服务器 ~/.ssh/id_rsa.pub 里面的内容复制到每一台被控机的 ~/.ssh/authorized_keys 文件中去。

准备工作好了以后就可以安装了。

安装

使用官方的安装命令：

1
2
3


mkdir -p ~/aurora && cd ~/aurora && wget https://raw.githubusercontent.com/Aurora-Admin-Panel/deploy/main/docker-compose.yml -O docker-compose.yml && docker compose up -d
# 创建管理员用户（密码必须设置8位以上，否则无法登陆）
docker-compose exec backend python app/initial_data.py

首先创建aurara目录，然后把官方的docker-compose.yaml文件下载下来，直接启动就可以了。

之后可以访问 http://你的IP:8000 进入面板。

之后就是添加机器以及添加端口转发。

迁移

使用了一段时间后，想把面板迁移到另一台机器，已经配置好的端口转发不想再配置一遍，所以就需要使用到迁移功能。迁移的步骤也比较简单，首先是要把原面板中的数据导出来，执行命令要在aurora目录下进行：

1
2


# docker-compose exec -T postgres pg_dump -d aurora -U [数据库用户名，默认aurora] -c > data.sql
docker compose exec -T postgres pg_dump -d aurora -U aurora -c > data.sql

然后把导出的data.sql传到新的要安装面板的机器上，在那边用同样的方法先安装面板(把上边的安装步骤完整的走一遍)，然后根据官方的迁移指引，在新安装面板的机器上的aurora目录执行以下命令：

1
2
3
4
5
6
7
8


# 首先先把所有服务停下
docker compose down
# 只启动数据库服务
docker compose up -d postgres
# 执行数据恢复
docker compose exec -T postgres psql -d aurora -U [数据库用户名，默认aurora] < data.sql
# 然后正常启动所有服务
docker compose up -d

等到所有容器都起来的时候，可以继续访问 http://你的IP:8000 进入面板。查看相关的数据是否也迁移过来了。安照步骤来我是已经可以正常迁移的。

linux服务器快速安装docker和docker-compose

Fri, 09 Jun 2023 21:49:42 +0000

记录一下安装docker的过程，具体的安装步骤都是参考docker的官方网站进行的安装。

ubuntu安装

卸载旧版

执行下边的命令

1
2
3
4
5


ubuntu@VM-20-3-ubuntu:~$ sudo apt-get remove docker docker-engine docker.io containerd runc
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package docker-engine

执行上边的命令清除以前的安装。

设置源

执行以下命令：

1
2
3
4
5
6
7
8


ubuntu@VM-20-3-ubuntu:~$ sudo apt-get update
ubuntu@VM-20-3-ubuntu:~$ sudo apt-get install \
 ca-certificates \
 curl \
 gnupg \
 lsb-release
# 添加docker官方GPG key
ubuntu@VM-20-3-ubuntu:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

执行

1
2
3
4


ubuntu@VM-20-3-ubuntu:~$ echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

设置安装源。

安装

先更新刚才安装的源，然后就可以执行安装了：

1
2
3
4


# 更新
sudo apt-get update
# 安装
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

上边的安装是安装最新版本，如果想安装特定版本则需要先查看有哪些可以安装的版本：

1
2
3
4
5


ubuntu@VM-20-3-ubuntu:~$ apt-cache madison docker-ce
 docker-ce | 5:20.10.16~3-0~ubuntu-focal | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages
 docker-ce | 5:20.10.15~3-0~ubuntu-focal | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages
 docker-ce | 5:20.10.14~3-0~ubuntu-focal | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages
 docker-ce | 5:20.10.13~3-0~ubuntu-focal | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages

找到版本后执行以下命令来进行安装：

1
2


# 版本是上个命令输出的第个列5:20.10.16~3-0~ubuntu-focal
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

安装后就可以使用了。

不使用sudo

ubuntu的系统如果使用的不是root安装，每次运行命令都是需要使用sudo,相对来说是比较麻烦的，如果不想使用sudo，可以使用下面的命令来解决：

1
2
3
4
5
6


ubuntu@VM-20-3-ubuntu:~$ sudo groupadd docker
[sudo] password for root:
groupadd: group 'docker' already exists
ubuntu@VM-20-3-ubuntu:~$ sudo gpasswd -a ${USER} docker
Adding user ubuntu to group docker
ubuntu@VM-20-3-ubuntu:~$ newgrp - docker

这样子使用起来就方便了很多。

debain安装

前两步和ubuntu基本一样，删除旧版，然后设置源。

删除旧版以及更新apt

1
2
3
4


# 删除旧版
root@s9707 ~ # apt-get remove docker docker-engine docker.io containerd runc
# 更新apt包索引
root@s9707 ~ # apt-get update

添加gpg

执行以下命令添加gpg

1
2


root@s9707 ~ # mkdir -p /etc/apt/keyrings 
root@s9707 ~ # curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc

如果在添加gpg的时候报错：gpg: command not found

则可以先安装gpg：

1

root@s9707:~# apt-get install gnupg gnupg2

设置仓库

通过以下命令添加仓库

1
2
3
4


root@s9707:~# echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 tee /etc/apt/sources.list.d/docker.list > /dev/null

然后再次更新apt包索引：

1

root@s9707 ~ # apt-get update

安装docker

接下来就是安装：

1

apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

整个安装过程也不是很麻烦，跟着官方的步骤走就可以了，这里记录一下自己的安装过程，方便以后快速安装。

java连接ftp部署在k8s中无法读取文件

Thu, 01 Jun 2023 17:21:12 +0000

起因

最近工作中需要使用到ftp工具，就在网上找了一个java编写的ftp工具类，功能也是挺齐全的，我在本地测试的时候对文件的下载和上传都是没有问题，正常使用。等到功能开发完成后，部署到k8s就出现了无法读取ftp服务器的文件的情况，起初以为是ftp服务器的问题，就又重新搭建了新的ftp服务器还是同样的问题。中间也想过是不是工具类的功能，就在网上查询了好久，大家基本都是用的commons-net这个包，具体的maven依赖如下：

1
2
3
4
5


<dependency>
 <groupId>commons-net</groupId>
 <artifactId>commons-net</artifactId>
 <version>3.6</version>
</dependency>

以为网上找的工具有问题，后来就引用了hutool工具类中的方法，还是同样的问题，百思不得其解的时候，看到hutool工具类那里有一个标题：主动模式和被动模式。起初我也没注意这个，毕竟是一堆的理论。实在是被这个问题虐的体无完肤的时候，我看了一下这个概念，恍然大悟，不就是因为这个原因吗？下面我们来解释一下这两个模式

PORT和PASV

在解释具体的概念前，我们先来说明一下主动和被动它针对的对象是谁，其实主动和被动都是针对ftp服务器来说的。下面我们来说明一下两个模式

和

PORT（主动模式）

FTP客户端连接到FTP服务器的21端口，发送用户名和密码登录，登录成功后要list列表或者读取数据时

_客户端_随机开放一个端口（1024以上），发送 PORT命令到FTP服务器，告诉服务器客户端采用主动模式并开放端口；

FTP服务器收到PORT主动模式命令和端口号后，通过服务器的20端口和客户端开放的端口连接，发送数据。

此模式是ftp服务器主动连接客户端的一个端口，并提供文件上传和下载服务，所以客户端需要开发端口的权限出来，防火墙进行放行，这样子ftp服务器才能连接到_客户端_进行文件处理。

PASV（被动模式）

FTP客户端连接到FTP服务器的21端口，发送用户名和密码登录，登录成功后要list列表或者读取数据时，

客户端发送PASV命令到FTP服务器，服务器在本地随机开放一个端口（1024以上），然后把开放的端口告诉客户端，

客户端再连接到服务器开放的端口进行数据传输。

此模式是客户端主动去连ftp服务端的端口，然后再进行文件的上传和下载，和我们正常思维逻辑是一样的，此时就需要ftp服务端开放具体的端口出来，并在防火墙中进行放行，客户端才能连接上去进行文件处理。

问题原因

这里来说明一下我遇到的问题的原因，因为我是网上找的客户端，我起初也并不清楚它使用的是主动模式还是被动模式，就直接发布到k8s中进行使用，从遇到的情况来看，应该默认使用的是主动模式:由ftp服务器主动连接客户端的高位端口，来实现文件的上传和下载。但是因为我的服务是放在k8s中，容器的端口都是需要写命令暴露出来的，而我们系统的容器都是默认只暴露了8080端口来进行服务的访问。

所以在使用主动模式的时候，ftp服务器想通过高位端口来连接到客户端是没有办法成功的，所以在获取文件的时候就什么也拿不到。

解决办法

我们知道了具体什么问题那就好解决了，解决办法也就是指定当前ftp客户端是使用主动模式还是被动模式。

因为我们的服务都是部署在k8s中的，所以我选择使用被动模式来进行文件处理，这样子k8s中的容器就不需要做什么处理。而ftp服务器则需要对高位端口进行放行，以便客户端可以连接上来进行服务的上传和下载。

代码如下：

1
2
3
4
5
6
7
8


FTPClient ftpClient = new FTPClient();

ftpClient.connect(url, port);

ftpClient.enterLocalActiveMode(); //主动模式
// ftpClient.enterLocalPassiveMode(); 被动模式
ftpClient.setControlEncoding("UTF-8");
ftpClient.changeWorkingDirectory(path);

开源项目申请JetBrains Open Source Development License

Sat, 20 May 2023 04:18:39 +0000

开发需要使用idea，以前使用的是破解版，使用起来没什么区别，后边觉得破解实在是麻烦，就转正购买了正式版，随意升级的感觉还是很美好的，哈哈。等到第二年快要续费的时候才了解到可以使用开源项目来申请idea全家桶的License，于是就开始了折腾之路。

申请准备

想要申请免费的License还是需要准备一些事情的：

满足以下条件的开源项目：

了解开源定义。

正在积极开发，例如，在过去 3 个月内定期提交新代码。

不提供开源软件的付费版本，也不提供与开源项目相关的任何商业服务（例如付费支持、咨询等）。

未获得商业公司或组织（NGO、教育、研究或政府组织）的资助。

不为他们的核心项目开发者支付工资。

支持条款：

许可证仅提供给项目负责人和核心项目提交者。

许可证有效期为一年，之后如果您的项目仍符合支持计划要求，也可以续订。

您只能将免费许可证用于开发非商业开源项目。

您不能与任何第三方共享免费许可证。

github的邮箱要设置成公开的，keep my email addresses private去掉勾选：

然后就可以开始申请了。

申请

申请地址：Request for Open Source Development License，里边共有三大项需要填写

新用户还是老用户

如果是第一次申请，那么肯定是新用户，选择 **No, we are a new customer.**如果是后续通道到期续的话，那就是第二个选项了

项目信息

填写自己项目的一些信息：项目名称，项目网站地址(如果没有项目网站地址可以和仓库地址填写同一个地址)，仓库地址，License地址(仓库中的开源协议文件)，以及一些项目的信息，如实填写就可以了。

关于我们自己

主要就是邮箱，github个人主页，以及姓名，填写完成后再勾选一些协议信息就可以提交了。整个过程还是很快的。提交后就会收到邮件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Hello xxx,

Thank you for your OSS development license request.

We will evaluate your project, and we’ll notify you of our decision by email. Please note that it could take up to one week to have your project reviewed.

If you have any questions, please contact us atJetBrains Community Support.

Kind regards,

JetBrains Community Support Team
www.jetbrains.com
The Drive to Develop

提示已经收到了我们的申请，需要一个星期来审核我们的申请。接下来就是耐心等待了。

审核结果

大概四五天就会出审核结果，审核不通过就是下边的邮件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Hello xxx,

Thank you for contacting us.

I’ve checked if your open source project is still actively and regularly developed - it is one of the main requirements ofJetBrains Open Source Support Program. According to the project's repository, it has not been actively developed, so I’m afraid that we cannot provide free licenses for your project at this point.

Please feel free to contact us again atopensource@jetbrains.comonce you resume active work on your project.

If you have any additional questions, I will be glad to help.

Regards,
Paige Rothmaller
JetBrains Americas
Phone: 609-714-7883
Fax: 866-838-6784
https://www.jetbrains.com
The Drive to Develop

如果审核通过则是下边的邮件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


Dear xxx,

Congratulations, your request to JetBrains for Open Source development license(s) has been approved! The license certificate is attached to this message.

Main facts about your license(s):

They are valid for one year. You will receive an automatic email reminder shortly before the license expiration date.
They should be used for developing your non-commercial open source projects only.
If you’ve received more than one license, please share them only with active contributors to your project.

To redeem your license(s), please click the link below:
Take me to my license(s)

If you find that JetBrains software has been useful for your project, please consider mentioning JetBrains support on your project’s homepage. Feel free to use theJetBrains logoand a link to our website such ashttps://jb.gg/OpenSourceSupport.

If you have any questions, please get in touch with us atopensource@jetbrains.com. We’ll be glad to help.

Kind regards,

JetBrains Community Support Team
https://www.jetbrains.com
The Drive to Develop

续期

免费的license需要一年一续的，在到期前会有邮件通知我们来进行续期：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Hi xxx,

Your JetBrains All Products Pack license(s) will expire in two weeks, on June 3, 2023.

We hope that our products have been useful in the development of your open source project. If your project is still in active development, please consider applying for renewal.

Don’t hesitate to contact us if you have any questions or issues regarding our support program – we'll be glad to help. We would also appreciate any feedback on your experience with JetBrains products.

Thank you!

Kind regards,
JetBrains Community Support Team
https://www.jetbrains.com
The Drive to Develop

我们可以直接点击邮件里的applying for renewal来续期我们的license。

填写的信息和第一次申请基本一样，只是在第一项新老用户选择的时候选择老用户，然后填写第一次申请通过的license ID就可以了。

提交申请后还是会有邮件通知：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


Hello xx,

We're writing to you in regards to your OSS development license request.

We've run an automated check of your GitHub repository to see if your open source project meets the requirements of our Open Source Support Program. Unfortunately, the check failed because the project has not been actively developed recently. We need to see regular code commits submitted for the past 3 months or more. Readme.md and other non-code commits do not count.

If you continue working on your project for a few more months, you're welcome to re-apply for support.

If you believe that your application has been evaluated incorrectly, please email us back at opensource@jetbrains.com. We’ll be glad to look into your case and see how we can help you.

Thank you!

The Community Support team
JetBrains
https://www.jetbrains.com
The Drive to Develop

由于我的项目最近三个月没有提交过记录，很快就收到了拒绝的邮件，所以如果想续期，续期前的三个月最好提交一下commit：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Hello xxx,

Thank you for your OSS development license request. We will evaluate your project, and we’ll notify you of our decision by email.

Please allow up to 2 weeks for your application to be processed, as we're currently experiencing a high volume of requests. We appreciate your patience.

If you need assistance with an urgent license renewal request, please contact us at opensource@jetbrains.com.

Kind regards,
JetBrains Community Support Team
www.jetbrains.com
The Drive to Develop

后续

终于等到了3个月，2023-07-01日马上又提交了申请，这次终于过了检查，有开始了漫长的等待。07-07凌晨收到了一封邮件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Dear xx,

Thanks for your interest in our Open Source Program!

Could you please provide more details about your OS project and its functionality?
What tools are you interested in and how are you going to use them?

Thanks, I look forward to your response!

Kind Regards,
xx
Community Support Team
JetBrains
www.jetbrains.com
The Drive to Develop

早上就赶紧回复邮件，介绍了一下项目情况，以及对哪些工具感兴趣，当天晚上就收到了通过的邮件，比初次申请的时候稍微麻烦了一点：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Hi xx,

Thank you for providing such detailed information.

We’ve extended your free All Products Pack license for another year. Please check your inbox for the new license certificate.

If you have any questions, please feel free to contact me. Have a nice day!
Kind Regards,

xx
Community Support Team
JetBrains
www.jetbrains.com
The Drive to Develop

最后祝大家都可以成功的申请下来。

sing-box for ios 配置xray reality

Thu, 18 May 2023 16:52:19 +0000

在ios端虽然有很多可以用来代理的软件，但是大多知名的软件都没法完整的支持reality, 小火箭(shadowrocket)是支持最好的一个软件了，支持到了xray1.7.5的版本，可以来配置rprx-vision,截止写这篇文章的时候还没有支持reality。其他的圈X(Quantumult X)、Loon以及Stash都还没有完整的支持vision,所以在ios上使用代理软件还是有一些尴尬的。好在还有两个软件是支持reality的。而且还都是免费软件，一个是sing-box for ios(SFI)，另一个就mate for iso(MFI)。现在都还在内测的阶段，今天我们就主要介绍SFI在ios上的安装和使用。

安装

先安装TestFlight才可以安装使用。直接在苹果应用商店搜索搜索就可以了。安装完TestFlight后就可以使用官方的邀请连接加入内测了：SFI官方安装地址。

TestFlight安装后的界面：

软件：

使用

界面

下面我们先看一下软件打开后的界面：

初次打开的时候，Dashboard界面会有所不同，会提示安装一个配置文件，根据提示安装就可以了。

新建配置

配置文件是在Profiles菜单下新建的，点击New Profile就可以了，有三个参数需要填写：Name,Type和(File,Path或URL)。

Name随便起一个名字就可以了，Type可以选择local(本地),icloud以及Remote。

我们可以先在本地创建一个新的配置文件。

具体的配置文件如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105


{
 "log": {
 "level": "info",
 "timestamp": true
 },
 "dns": {
 "servers": [
 {
 "tag": "cloudflare",
 "address": "https://1.1.1.1/dns-query"
 },
 {
 "tag": "dnspod",
 "address": "https://1.12.12.12/dns-query",
 "detour": "direct"
 },
 {
 "tag": "block",
 "address": "rcode://success"
 }
 ],
 "rules": [
 {
 "geosite": "cn",
 "server": "dnspod"
 },
 {
 "geosite": "category-ads-all",
 "server": "block",
 "disable_cache": true
 }
 ]
 },
 "inbounds": [
 {
 "type": "tun",
 "tag": "tun-in",
 "interface_name": "utun",
 "inet4_address": "172.19.0.1/30",
 "auto_route": true,
 "strict_route": true,
 "stack": "gvisor",
 "sniff": true
 }
 ],
 "outbounds": [
 {
 "tag": "bwg", # tag和下边route中的要一致
 "type": "vless",
 "server": "自己的IP",
 "server_port": 自己的端口,
 "uuid": "自己的UUID",
 "flow": "xtls-rprx-vision",
 "network": "tcp",
 "packet_encoding": "xudp",
 "tls": {
 "enabled": true,
 "server_name": "www.microsoft.com", # 根据需要改成自己的
 "utls": {
 "enabled": true,
 "fingerprint": "chrome"
 },
 "reality": {
 "enabled": true,
 "public_key": "自己的Public_key",
 "short_id": "自己的short_id"
 }
 }
 },
 {
 "type": "direct",
 "tag": "direct"
 },
 {
 "type": "block",
 "tag": "block"
 },
 {
 "type": "dns",
 "tag": "dns"
 }
 ],
 "route": {
 "rules": [
 {
 "protocol": "dns",
 "outbound": "dns"
 },
 {
 "geosite": "cn",
 "geoip": [
 "cn",
 "private"
 ],
 "outbound": "direct"
 },
 {
 "geosite": "category-ads-all",
 "outbound": "block"
 }
 ],
 "auto_detect_interface": true,
 "final": "bwg"
 }
 }

将上边的相关配置改成自己的添加成功就可以了。

使用

通过上边的准备，现在已经可以开始使用了，在DashBoard界面，启动就可以了。也可以在Logs查看当前的连接情况，以及分流情况。

总结

以上就是reality的简单配置，sing-box支持多种协议，具体的可以参考：官方文档。

openwrt系统frps配置使用

Sun, 09 Apr 2023 06:23:58 +0000

宽带给了公网ip，所以想在自己家搭建一个frp的服务端，这样子就可以当做一台服务器，来进行内网穿透使用了。

frps配置

我家里是使用的r2s刷的openwrt系统，所以可以在r2s中进行frps的搭建，找到对应的菜单：

端口绑定默认7000，直接使用就可以了，我们这里主要是使用http和https服务，所以填写对应的http和https绑定端口就可以了，可以和端口绑定设置成同一个端口。

子域名设置

在高级选项中我们可以设置一个子域名，这样子我们就可以使用改域名的子域名来进行访问不同的内网穿透服务。对应的子域名下也有一行提示：

如果subdomain_host不为空，可以在frpc配置文件中设置类型为http(s)的subdomain；subdomain为test，路由将使用test.frps.com

管理面板设置

我们可以在管理面板查看到当前已经连接的客户端，以及每个客户端的流量使用情况，所以还是有必要进行一下设置。

面板绑定端口7500，那么我们就可以使用openwrt的管理ip:7500来登录到frps的管理界面。

端口转发配置

管理界面端口配置

我们在家里的时候可以使用内网ip:7500来访问，但是不在家的时候就没办法了。不慌，因为我有公网ip，那么我就可以通过端口转发，使用的域名+特定端口来访问到内网的7500端口。通过网络防火墙进行端口转发配置。

配置管理界面的端口转发，通过域名:7500访问到内网openwrt系统的7500端口。

绑定端口配置

我们的frps绑定的端口是7000，所以需要把7000端口也暴露出去客户端才能正常连接注册上来，同样需要在端口转发中进行配置。

通过域名:7000访问到内网openwrt系统的7000端口。

参考上边的管理界面的端口转发配置。

到这里我们的frps服务端就搭建好了，接下来我们来配置客户端进行连接。

客户端连接

我们主要先在需要内网穿透的机器上安装frp的客户端，我这里是一个路由器刷的openwrt系统，所以安装frpc就可以了：

服务器：其实就是我们frps服务端的ip，因为我使用的是宽带的动态ip，所以ip是会变的，我不能直接使用ip，但是我在家里的openwrt中配置了DDNS，那么我就可以使用ddns的域名来作为服务器，填入ddns中的域名。

端口：7000，和frps的绑定端口一致。

令牌：和frps中的令牌一致。

http和https穿透服务端口：7000，和服务端一致。

经过上边的配置我们就可以和服务端连上了，但是我们还没办法通过公网来访问我们其他需要穿透的服务，我们还需要建一条规则。在下方frp setting页面的下方点击添加，新建一个服务：

开启状态：开启。

frp协议类型：选择http就可以了。

域名类型：我们在frps服务端配置的时候使用的是子域名形式，所以这里也需要填子域名。

子域名：我们需要使用的访问域名。

内网主机地址：我们需要访问的是openwrt的管理界面，所以选择openwrt的地址就可以了。

内网主机端口：我们访问的是管理界面，默认80端口。

服务备注名：自定义的一个名称。

其他的默认就可以了。然后点击保存并应用。完成后如下图：

如上图我添加的子域名是gzax6,那么我还需要去添加一条解析才能使用gzax6.frps.com:7000来访问我的ax6这个路由器的管理界面。

我们添加一条CNAME的记录，因为ip地址是一直在变化的，我们唯一不变的就是ddns使用的域名，我们解析一条CNAME记录到我们ddns使用的域名，这样子就可以正确的解析到我的openwrt里的frps服务端了。

总结

经过上述步骤，我们就可以使用域名:7000端口来在外网访问我们内网的路由器管理界面了。

openwrt配置Cloudflare DDNS

Sat, 08 Apr 2023 18:12:20 +0000

想要在外边访问家里的网络，可以使用运营商分配的ip，但是ip可能会经常变动，所以需要进行ddns配置，配置DDNS的前提条件是家里的宽带需要有公网ip。下面我们开始使用cloudflare来进行DDNS的配置。

添加ddns配置

选择openwrt里的动态DNS功能，然后在里边添加一个自己的配置，名称随便，如我添加的MYDDNS`。

添加后就跳转到了配置界面，首先我们要选择ddns的提供商，这里我们选择cloudflare:

切换后如下图：

查询主机名

这个就是我们的域名，通过这个域名访问到我们的openwrt管理后台，配置一个自己的三级域名，比如购买的域名的openwrt.com`。这里则填写admin.openwrt.com`。

域名

域名这个选项其实就上将查询主机名修改为admin@openwrt.com。

用户名和密码

用户名是cloudflare的登录邮箱，密码是cloudflare的global api key。如下图，点击后边的view就可以查看自己的key了。

截止上边openwrt里的配置就已经完成了。点击保存并应用就可以了。

域名解析

我们在上边使用到了admin.openwrt.com。然后我们需要在cloudflare的后台去配置这个域名的解析。添加一条A记录，记录值为`admin`,然后我们就可以通过admin.自己的二级域名来访问我们软路由系统了。IPv4地址可以先随便填一个，等待ddns程序自动进行更新。

开放openwrt端口

在openwrt后台系统中找到网络-防火墙-端口转发`，进行端口转发配置

具体配置说明：

名称：随便填一个标识。

传输协议：选则TCP+UDP。

外部区域：选wan口

外部端口：ddns中的域名+外部端口访问到你这个机器。端口一般在1024~65535中选择。

内部区域：选lan口

内部ip地址：选openwrt的管理后台ip,例如我这里是192.168.6.1。

内部端口：openwrt的管理后台一般都是输入ip就可以访问，所以端口是80.

添加，然后保存并应用，就可以通过ddns里的配置的查询域名:外部端口访问到管理后台，本文中的就是admin.openwrt.com:8080。8080端口是我随便写的，根据自己情况选择一个可以使用的端口，1024~65535之间的都可以。

使用ITIN申请capital one信用卡

Mon, 03 Apr 2023 07:35:05 +0000

最近在研究国外信用卡，在朋友的帮助下申请了一张美国第一资本的信用卡(C1信用卡)，在次分享一下申请经历。

要申请信用卡之前，需要先获取到一个美国的地址以及获取美国的ITIN号，这两个会在后续的分享中介绍给大家如何进行申请。今天我们就主要来介绍capital one的信用卡申请过程。

准备

获取到ITIN号，我们获取到的应该是一个pdf的文件，里边记录了我们的税号，是9位的数字。

处理ITIN号之外，我们需要了解capital one信用卡的类别，首先我们进入到地址：capition one,在此页面我们会看到几张信用卡，我们要申请的是最后一张，用于重建信用(REBUILDING CREDIT)。

申请

首先是填写自己的基础信息，如下图，填写自己的姓名，生日，itin以及另外两个no，然后选自己的国籍：

然后是自己的联系信息，包括地址手机号以及财务信息：

接下来就是同意一些协议并提交了。

接下来就会看到以下界面，剩下的就是等待审批了。

审批

因为我是晚上申请的，处理速度特别的快，提交后不到10分钟就收到了邮件，让补充资料，也就是让补充ITIN信件以及护照。

然后就是上传继续等通知了。

通过

把护照和ITIN上传后，不到3分钟，就立马收到了审批通道的邮件，是真的效率高。

押金

如上图，我只需要最少交49刀就可以了，然后就是通过wise的账户来进行扣除。提交扣费请求后隔天就对费用进行了扣除。接下来就是耐心的等待了。

capital one 账号

等了几天后，我尝试了去注册capital one的账号，通过找回用户名和密码来进行操作，写的是Last Name，实际需要输入自己的名+姓的全拼，然后根据提示就可以找回账号并设置密码和手机号，再验证一下手机号就可以注册账号成功并进入系统。

在系统中就可以看到自己的卡片进度，比如我查看的时候卡在处理中：

以上就是截图到写这篇文章时信用卡的申请情况，后续如果有变更继续更新。

整个申请过程还是挺顺利的。

更新

2023-04-04

收到了卡片邮寄的通知，整个从扣款成功日期(2023-03-23)到4月4日，历时12天。

2023-04-06

租用的地址收到了信用卡的信件，速度还是很快的。

2023-04-13

申请转运，anytimemailbox申请转运，并扣款，当天DHL快递就发出了。

2023-04-18

DHL速度还是可以的，经历了5天终于拿到了实体卡。

快递查询单：

实体卡：

激活

直接下载captialone的app激活是不行的，提示无法激活需要打电话激活，然后就打了电话，这里使用的是google voice,根据提示输入卡号，itin后四位，然后在输入cvv就会提示激活成功，然后就可以正常使用了。

后续

退押金

在正常使用了几个月后，在9.15日，我收到了一封邮件，里边提示我押金已经退回，并升级了我的卡片，我登录app查看，的确押金早几天就已经退回了，具体的邮件如下：

额度提升

在收到押金退回的邮件几天后，9.19日我又收到captial one的一份邮件，额度提升了，惊喜，从200到3200，真的是太给力，继续好好使用了。

产生逾期费用

我一直使用的是wise的账户在还款，2023年10月14日wise通知账户进行了变更，我第一时间在app添加了账户，但是却漏了一个重要的操作：自动扣款替换。我以为添加了扣款账户进去就ok了。直到11月15日wise的app弹出消息说扣款失败，让我用新的账户扣款，我才大事不妙，这时候我进了app才发现需要先取消上一个设置的自动扣款，然后重新设置新的自动扣款账户。设置是设置成功了，但是怎么把这期的账单给还上呢？这时候我就手动的去操作了扣款，15日操作，18日wise通知扣款。18日晚上我登录了C1网页版，查看账单发现多了一笔逾期费用：$25，太狠了。希望大家引以为戒。

使用经验

拿到卡后，我的使用方式也比较单一，给T-Mobile的手机卡充值了一次大概$10，然后就是绑定了appleId，每个月正常付款Apple One订阅，就这样子使用了几个月后就把押金给退了回来，然后还把额度从200提升到了3200。以上就是我的使用经验，的确是很单调的，希望对大家有所帮助。

使用了几个月后，我又申请了AE的卡片，有兴趣的小伙伴可以参考：使用ITIN申请American Express(美国运通)信用卡

哪吒面板迁移

Tue, 28 Mar 2023 06:48:18 +0000

安装哪吒面板的机器是RN的一台小鸡，本来安装的是ubuntu系统，想换成debian系统，所以需要对哪吒面板的数据进行迁移，所以写此篇文章记录迁移过程。

迁移准备

参考哪吒面板官方的wiki，所有的数据都存放在/opt/nezha目录下，所以需要备份一下此目录，下载到本地。

如何进行数据迁移、备份恢复？

先运行一键脚本，选择停止面板
在旧服务器中打包/opt/nezha文件夹，复制到新环境相同位置解压
在新环境中运行一键脚本，选择启动面板

迁移

将备份数据上传到新的服务器，解压到/opt/nezha目录下。通过nezha.sh启动面板。

配置通过域名访问面板：

nginx配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


server {
 listen 80;
 server_name dashboard.baidu.com,tz.baidu.me;
 # ws配置
 location /ws {
 proxy_pass http://dashboard-dashboard-1:80;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "Upgrade";
 proxy_set_header Host $host;
 }
 # 访问配置
 location / {
 proxy_pass http://dashboard-dashboard-1:80;
 }
}

整个迁移过程还是比较简单的，通过备份数据，整体迁移启动。记录一下。

x-ui安装配置使用

Sun, 26 Mar 2023 01:39:01 +0000

今天我们主要来介绍一下x-ui的安装使用。

x-ui在原地址是：x-ui

~~但是由于原仓库太久没更新，我们今天使用的是改版的FranzKafkaYu/x-ui,支持单个端口多用户，还能分别统计流量，比原版较完善。~~

本文使用改版MHSanaei/3x-ui进行配置。

安装

使用github仓库中的一键安装脚本很容易就可以安装完成安装：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

安装完成如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


Saving to: ‘/usr/local/x-ui-linux-amd64.tar.gz’

/usr/local/x-ui-linux- 100%[=========================>] 27.95M 124MB/s in 0.2s

2023-03-26 08:10:51 (124 MB/s) - ‘/usr/local/x-ui-linux-amd64.tar.gz’ saved [29309974/29309974]

x-ui/
x-ui/x-ui.sh
x-ui/bin/
x-ui/bin/README.md
x-ui/bin/LICENSE
x-ui/bin/geosite.dat
x-ui/bin/geoip.dat
x-ui/bin/xray-linux-amd64
x-ui/x-ui
x-ui/x-ui.service
--2023-03-26 08:10:52-- https://raw.githubusercontent.com/FranzKafkaYu/x-ui/main/x-ui.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.110.133, 185.199.108.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25694 (25K) [text/plain]
Saving to: ‘/usr/bin/x-ui’

/usr/bin/x-ui 100%[=========================>] 25.09K --.-KB/s in 0.001s

2023-03-26 08:10:52 (34.8 MB/s) - ‘/usr/bin/x-ui’ saved [25694/25694]

出于安全考虑，安装/更新完成后需要强制修改端口与账户密码
确认是否继续,如选择n则跳过本次端口与账户密码设定[y/n]:y
请设置您的账户名:admin
您的账户名将设定为:admin
请设置您的账户密码:admin
您的账户密码将设定为:admin
请设置面板访问端口:8080
您的面板访问端口将设定为:8080
确认设定,设定中
set username and password success
账户密码设定完成
set port 11000 success面板端口设定完成
Created symlink /etc/systemd/system/multi-user.target.wants/x-ui.service → /etc/systemd/system/x-ui.service.
x-ui v0.3.4.1 安装完成，面板已启动

安装完成后我们就可以进行登录了，使用我们vps的ip地址加上安装的时候设置的端口就可以正常登录了。

配置域名访问

使用ip加端口的形式多少有点不怎么方便，我们可以配置nginx来进行反向代理，使用域名来访问我们的x-ui的界面。

x-ui配置

第一次需要使用ip+端口的形式进行登录，登录x-ui后我们进入面板设置-面板url根路径配置，默认是/,我们将它改为我们想要使用的路径，我这里改为/ui.

nginx配置

配置nginx的配置文件，添加以下转发配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


server {
 listen 80;
 server_name _;

 #access_log /var/log/nginx/host.access.log main;

 location /ui {
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_ignore_client_abort on;
 proxy_pass http://172.17.0.1:8080;
 }
}

如果不限制域名server_name配置为_就可以了，如果要限制域名，则配置为对应的域名。

就可以通过域名直接进行访问了。

节点添加

现在最常用的节点还是vless节点，下边就添加一个vless节点来使用：

用户就使用xui自己生成的用户信息就可以了。

flow需要改成xtls-rprx-vision,

安全选项使用Reality，然后下边的都可以自动生成，

serverNames可以使用xui自己生成的，也可以使用我们自己找的。

然后就是保存，去相关的客户端里按照我们的配置进行填写，然后就可以正常上网了。

这里演示一下openwrt中的配置：

基本就是对着xui里的进行抄就行了，地址就是自己的vps地址，端口在xui的截图里没有截取到，按自己添加的端口进行填写就行了。然后就可以愉快的上网了。

xray配置使用reality

Sat, 11 Mar 2023 18:30:56 +0000

最近xray新版本1.8发布了，备受期待的reality也随之而来，下面介绍一下我折腾reality的过程。

首先是去reality的官方仓库查看一下R佬写的模板,git地址：REALITY

模板文件

下面开始配置reality服务器端，配置模板如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


{
 "inbounds": [ // 服务端入站配置
 {
 "listen": "0.0.0.0",
 "port": 443,
 "protocol": "vless",
 "settings": {
 "clients": [
 {
 "id": "", // 必填，执行 ./xray uuid 生成，或 1-30 字节的字符串
 "flow": "xtls-rprx-vision" // 选填，若有，客户端必须启用 XTLS
 }
 ],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "show": false, // 选填，若为 true，输出调试信息
 "dest": "example.com:443", // 必填，格式同 VLESS fallbacks 的 dest
 "xver": 0, // 选填，格式同 VLESS fallbacks 的 xver
 "serverNames": [ // 必填，客户端可用的 serverName 列表，暂不支持 * 通配符
 "example.com",
 "www.example.com"
 ],
 "privateKey": "", // 必填，执行 ./xray x25519 生成
 "minClientVer": "", // 选填，客户端 Xray 最低版本，格式为 x.y.z
 "maxClientVer": "", // 选填，客户端 Xray 最高版本，格式为 x.y.z
 "maxTimeDiff": 0, // 选填，允许的最大时间差，单位为毫秒
 "shortIds": [ // 必填，客户端可用的 shortId 列表，可用于区分不同的客户端
 "" // 若有此项，客户端 shortId 可为空
 "0123456789abcdef" // 0 到 f，长度为 2 的倍数，长度上限为 16
 ]
 }
 }
 }
 ]
}

clients参数

clients的配置和以前的vless配置一样，id可以使用xray核心程序来生成：

1
2


root@r-6c5317:~/xray# ./xray uuid
94281a1a-33bc-445a-ace9-0fdd56a0c14a

stramSettings

最重要的配置是streamSettings的配置，security要配置成reality ,dest官方建议如下：

通常代理用途，目标网站最低标准：**国外网站，支持 TLSv1.3 与 H2，域名非跳转用**（主域名可能被用于跳转到 www）
加分项：IP 相近（更像，且延迟低），Server Hello 后的握手消息一起加密（如 dl.google.com），有 OCSP Stapling
配置加分项：**禁回国流量，TCP/80、UDP/443 也转发**（REALITY 对外表现即为端口转发，目标 IP 冷门或许更好）

当我们选择了一个dest 域名后，可以使用xray核心来确定serverNames如何填，我们先来看看xray核心有那些命令可以使用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


root@r-6c5317:~/xray# ./xray -h
Xray is a platform for building proxies.

Usage:

 xray <command> [arguments]

The commands are:

 run Run Xray with config, the default command
 version Show current version of Xray
 api Call an API in an Xray process
 tls TLS tools
 uuid Generate UUIDv4 or UUIDv5
 x25519 Generate key pair for x25519 key exchange

Use "xray help <command>" for more information about a command.

serverNames

有一个tls tools，可以使用它来确定serverNames，执行 xray tls ping 目标网站网址，填 “Allowed domains” 的值。我这里使用微软的域名，所以情况如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


root@r-6c5317:~/xray# ./xray tls ping www.microsoft.com
Tls ping: www.microsoft.com
Using IP: 23.3.85.234
-------------------
Pinging without SNI
Handshake succeeded
Allowed domains: [wwwqa.microsoft.com www.microsoft.com staticview.microsoft.com i.s-microsoft.com microsoft.com c.s-microsoft.com privacy.microsoft.com]
-------------------
Pinging with SNI
handshake succeeded
Allowed domains: [wwwqa.microsoft.com www.microsoft.com staticview.microsoft.com i.s-microsoft.com microsoft.com c.s-microsoft.com privacy.microsoft.com]
Tls ping finished

可以把上面的域名填写到serverNames中，客户端在使用的时候找一个域名来填写。

privateKey

下边说一下privateKey参数，也是要使用xray核心程序来生成的，在上面我们查看xray -h的时候有一个x25519的命令，生成如下：

1
2
3


root@r-6c5317:~/xray# ./xray x25519
Private key: YIHyZpW1NJLck_XTCG8IYMMqq1JG7w2Vm95HMAbB51g
Public key: Xh_hBw4E5SBFjreeAQQjnUMlvLvFPeELy2Xdvur6XwU

服务器端就使用 privateKey，客户端在使用的时候就用publicKey。

完整服务端配置

所以完整的xray服务端的配置config.json如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


{
 "log": {
 "loglevel": "warning",
 "access": "/var/log/xray/access.log",
 "error": "/var/log/xray/error.log"
 },
 "api": {
 "services": [
 "HandlerService",
 "LoggerService",
 "StatsService"
 ],
 "tag": "api"
 },
 "inbounds": [
 {
 "listen": null,
 "port": 13100,
 "protocol": "vless",
 "settings": {
 "clients": [
 {
 "id": "0c41318a-32b6-4017-9938-4033bf26b111",
 "flow": "xtls-rprx-vision"
 }
 ],
 "decryption": "none"
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "show": false,
 "dest": "www.microsoft.com:443",
 "xver": 0,
 "serverNames": [
 "www.microsoft.com"
 ],
 "privateKey": "YIHyZpW1NJLck_XTCG8IYMMqq1JG7w2Vm95HMAbB51g",
 "shortIds": [
 "6ba85179e30d4fc2"
 ]
 }
 },
 "sniffing": {
 "enabled": true,
 "destOverride": [
 "http",
 "tls"
 ]
 }
 }
 ],
 "outbounds": [
 {
 "tag":"common",
 "protocol": "freedom"
 },
 {
 "protocol": "blackhole",
 "settings": {},
 "tag": "blocked"
 }
 ],
 "routing": {
 "rules": [
 {
 "type": "field",
 "outboundTag": "common",
 "network": "udp,tcp"
 },
 {
 "type": "field",
 "outboundTag": "blocked",
 "ip": [
 "geoip:cn",
 "geoip:private"
 ]
 }
 ]
 },
 "policy": {
 "statsInboundUplink": true,
 "statsInboundDownlink": true,
 "statsOutboundUplink": true,
 "statsOutboundDownlink": true
 },
 "dns": null,
 "transport": null,
 "stats": null,
 "reverse": null,
 "fakeDns": null
 }

客户端配置

客户端我使用的是v2rayN，配置如下：

以上就是折腾的整个过程，完美上网。

记一次踩坑:springboot2.0.2配置fastjson不生效

Wed, 08 Mar 2023 06:50:58 +0000

最近在尝试搭建springboot+dubbo+shiro基于注解的一个项目,突发奇想想把消息转换器从jackson换成fastjson,于是就开始了折腾之路.

轻车熟路的去自定了一个SpringMvcConfigure去继承WebMvcConfigurerAdapter,然后就发现这个WebMvcConfigurerAdapter竟然过时了?what?点进去看源码:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


/**
 * An implementation of {@link WebMvcConfigurer} with empty methods allowing
 * subclasses to override only the methods they're interested in.
 *
 * @author Rossen Stoyanchev
 * @since 3.1
 * @deprecated as of 5.0 {@link WebMvcConfigurer} has default methods (made
 * possible by a Java 8 baseline) and can be implemented directly without the
 * need for this adapter
 */
@Deprecated
public abstract class WebMvcConfigurerAdapter implements WebMvcConfigurer {}

可以看到从spring5.0开始就被@Deprecated,原来是java8中支持接口中有默认方法,所以我们现在可以直接实现WebMvcConfigurer,然后选择性的去重写某个方法,而不用实现它的所有方法.

于是就实现了WebMvcConfigurer:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


@Configuration
public class SpringMvcConfigure implements WebMvcConfigurer {

 /**
 * 配置消息转换器
 * @param converters
 */
 @Override
 public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
 //自定义配置...
 FastJsonConfig config = new FastJsonConfig();
 config.setSerializerFeatures(SerializerFeature.QuoteFieldNames,
 SerializerFeature.WriteEnumUsingToString,
 /*SerializerFeature.WriteMapNullValue,*/
 SerializerFeature.WriteDateUseDateFormat,
 SerializerFeature.DisableCircularReferenceDetect);
 fastJsonHttpMessageConverter.setFastJsonConfig(config);
 converters.add(fastJsonHttpMessageConverter);
 }

}

本以为这样子配置就可以完事儿,但是诡异的事情发生了,我明明注释了SerializerFeature.WriteMapNullValue,可是返回的json中仍然有为null的字段,然后我就去com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter中的write和writeInternal打了断点,再次执行,竟然什么都没有发生,根本没有走这两个方法,于是在自定义的SpringMvcConfigure中configureMessageConverters方法内打了断点,想看看这个方法参数converters里边到底有什么:

看到这里就想到,肯定是我自己添加的fastjson在后边,所以没有生效,所以就加了以下代码:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 converters = converters.stream()
 .filter((converter)-> !(converter instanceof MappingJackson2HttpMessageConverter))
 .collect(Collectors.toList());
 FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
 //自定义配置...
 FastJsonConfig config = new FastJsonConfig();
 config.setSerializerFeatures(SerializerFeature.QuoteFieldNames,
 SerializerFeature.WriteEnumUsingToString,
 /*SerializerFeature.WriteMapNullValue,*/
 SerializerFeature.WriteDateUseDateFormat,
 SerializerFeature.DisableCircularReferenceDetect);
 fastJsonHttpMessageConverter.setFastJsonConfig(config);
 converters.add(fastJsonHttpMessageConverter);
}

竟然还没有生效,后来开始追踪,开始方法是从org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport类中的一个bean配置:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


@Bean
public RequestMappingHandlerAdapter requestMappingHandlerAdapter() {
 RequestMappingHandlerAdapter adapter = createRequestMappingHandlerAdapter();
 adapter.setContentNegotiationManager(mvcContentNegotiationManager());
 //就是从这里开始设置converters的,然后从这里一路追踪下去.
 adapter.setMessageConverters(getMessageConverters());
 adapter.setWebBindingInitializer(getConfigurableWebBindingInitializer());
 adapter.setCustomArgumentResolvers(getArgumentResolvers());
 adapter.setCustomReturnValueHandlers(getReturnValueHandlers());

 if (jackson2Present) {
 adapter.setRequestBodyAdvice(Collections.singletonList(new JsonViewRequestBodyAdvice()));
 adapter.setResponseBodyAdvice(Collections.singletonList(new JsonViewResponseBodyAdvice()));
 }

 AsyncSupportConfigurer configurer = new AsyncSupportConfigurer();
 configureAsyncSupport(configurer);
 if (configurer.getTaskExecutor() != null) {
 adapter.setTaskExecutor(configurer.getTaskExecutor());
 }
 if (configurer.getTimeout() != null) {
 adapter.setAsyncRequestTimeout(configurer.getTimeout());
 }
 adapter.setCallableInterceptors(configurer.getCallableInterceptors());
 adapter.setDeferredResultInterceptors(configurer.getDeferredResultInterceptors());

 return adapter;
}

getMessageConverters()方法:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


protected final List<HttpMessageConverter<?>> getMessageConverters() {
 if (this.messageConverters == null) {
 this.messageConverters = new ArrayList<>();
 configureMessageConverters(this.messageConverters);//进入这一步
 if (this.messageConverters.isEmpty()) {
 addDefaultHttpMessageConverters(this.messageConverters);
 }
 extendMessageConverters(this.messageConverters);
 }
 return this.messageConverters;
}

org.springframework.web.servlet.config.annotation.DelegatingWebMvcConfiguration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Override
protected void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 this.configurers.configureMessageConverters(converters);
}
@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 for (WebMvcConfigurer delegate : this.delegates) {
 delegate.configureMessageConverters(converters);
 }
}

this.delegates包含了springboot的一个默认配置类类:org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration里边有一个参数

1

private final HttpMessageConverters messageConverters;

for循环里的delegate.configureMessageConverters(converters)调用了WebMvcAutoConfiguration中的configureMessageConverters方法:

1
2
3
4


@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 converters.addAll(this.messageConverters.getConverters());
}

执行完这个后,就给converters中添加了10个转换器了,就是上图中的10个. this.delegates中还有一个就是我们自定义的那个,执行完后,在我们自定义的那个SpringMvcConfigure发现我添加的fastjson添加进去了,但是org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport.getMessageConverters(),发现converters并没有发现我们添加进去的FastJsonHttpMessageConverter,这时突然又想起来:java8的stream api每次都是生成一个新的对象,所以导致converters已经不是传递过来的那个converters的引用了(这里也证明了java是值传递,不是引用传递).

于是再次改变那个lambda表达式为普通的增强for循环:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 /*converters = converters.stream().
 filter((converter)-> !(converter instanceof MappingJackson2HttpMessageConverter))
 .collect(Collectors.toList());*/
 for (HttpMessageConverter<?> converter : converters) {
 if (converter instanceof MappingJackson2HttpMessageConverter){
 converters.remove(converter);
 }
 }
 FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
 //自定义配置...
 FastJsonConfig config = new FastJsonConfig();
 config.setSerializerFeatures(SerializerFeature.QuoteFieldNames,
 SerializerFeature.WriteEnumUsingToString,
 /*SerializerFeature.WriteMapNullValue,*/
 SerializerFeature.WriteDateUseDateFormat,
 SerializerFeature.DisableCircularReferenceDetect);
 fastJsonHttpMessageConverter.setFastJsonConfig(config);
 converters.add(fastJsonHttpMessageConverter);
}

再次运行,wtf?报错了:ConcurrentModificationException,原来使用for循环遍历过程中不能进行remove操作,于是换成Iterator:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
 /*converters = converters.stream()
 .filter((converter)-> !(converter instanceof MappingJackson2HttpMessageConverter))
 .collect(Collectors.toList());
 for (HttpMessageConverter<?> converter : converters) {
 if (converter instanceof MappingJackson2HttpMessageConverter){
 converters.remove(converter);
 }
 }*/
 Iterator<HttpMessageConverter<?>> iterator = converters.iterator();
 while(iterator.hasNext()){
 HttpMessageConverter<?> converter = iterator.next();
 if(converter instanceof MappingJackson2HttpMessageConverter){
 iterator.remove();
 }
 }
 FastJsonHttpMessageConverter fastJsonHttpMessageConverter = new FastJsonHttpMessageConverter();
 //自定义配置...
 FastJsonConfig config = new FastJsonConfig();
 config.setSerializerFeatures(SerializerFeature.QuoteFieldNames,
 SerializerFeature.WriteEnumUsingToString,
 /*SerializerFeature.WriteMapNullValue,*/
 SerializerFeature.WriteDateUseDateFormat,
 SerializerFeature.DisableCircularReferenceDetect);
 fastJsonHttpMessageConverter.setFastJsonConfig(config);
 converters.add(fastJsonHttpMessageConverter);
}

再次运行,我去,终于解决了,先是删除MappingJackson2HttpMessageConverter,然后添加FastJsonHttpMessageConverter,但是不是到为什么进过一系列操作后,MappingJackson2HttpMessageConverter还是添加进去了,但是由于FastJsonHttpMessageConverter在MappingJackson2HttpMessageConverter之前添加,所以对结果不影响.至此,解决了这个问题.

总结

最重要的还是解决了springboot2.0.2配置fastjson不生效的问题
更加明白stream api返回的都是全新的对象
更理解java是值传递而不是引用传递
了解到想要在迭代过程中对集合进行操作要用Iterator,而不是直接简单的for循环或者增强for循环

如有不正确的地方还请指出,谢谢.

docker搭建wordpress教程

Tue, 07 Mar 2023 06:59:39 +0000

搭建一个wordpress网站。本文主要介绍使用docker搭建一个完整的wordpress网站。

安装docker就不做多介绍了.

准备wordpress的docker-compose.yaml文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


version: '3.9'
networks:
 mynet:
 external: true
services:
 wordpress:
 # default port 9000 (FastCGI)
 image: wordpress:6.1.0-fpm
 container_name: wordpress
 env_file:
 - .env
 restart: unless-stopped
 networks:
 - mynet
 volumes:
 - ${WORDPRESS_LOCAL_HOME}:/var/www/html
 - ${WORDPRESS_UPLOADS_CONFIG}:/usr/local/etc/php/conf.d/uploads.ini
 # - /path/to/repo/myTheme/:/var/www/html/wp-content/themes/myTheme
 environment:
 - WORDPRESS_DB_HOST=${WORDPRESS_DB_HOST}
 - WORDPRESS_DB_NAME=${WORDPRESS_DB_NAME}
 - WORDPRESS_DB_USER=${WORDPRESS_DB_USER}
 - WORDPRESS_DB_PASSWORD=${WORDPRESS_DB_PASSWORD}
 nginx:
 image: nginx:1.22.0
 container_name: nginx
 env_file:
 - .env
 restart: unless-stopped
 networks:
 - mynet
 depends_on:
 - wordpress
 ports:
 - "80:80" # http
 volumes:
 - ${WORDPRESS_LOCAL_HOME}:/var/www/html
 - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
 - ./logs:/var/log/nginx

使用官方的6.1.0版本的镜像，把文件中的数据库的信息改成自己的就可以正常启动了。端口这里没有暴露出来，因为我想使用nginx来处理所有请求，所以还需要配置一下nginx的代理规则：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


server {
 listen 80;
 listen [::]:80;
 server_name ${HOST};
 index index.php index.html index.htm;
 root /var/www/html;
 server_tokens off;
 client_max_body_size 75M;
 # update ssl files as required by your deployment
 #ssl_certificate /etc/ssl/fullchain.pem;
 #ssl_certificate_key /etc/ssl/privkey.pem;

 # logging
 access_log /var/log/nginx/wordpress.access.log;
 error_log /var/log/nginx/wordpress.error.log;

 # some security headers ( optional )
 add_header X-Frame-Options "SAMEORIGIN" always;
 add_header X-XSS-Protection "1; mode=block" always;
 add_header X-Content-Type-Options "nosniff" always;
 add_header Referrer-Policy "no-referrer-when-downgrade" always;
 add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;

 location / {
 try_files $uri $uri/ /index.php$is_args$args;
 }

 location ~ \.php$ {
 try_files $uri = 404;
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 fastcgi_pass wordpress:9000;
 fastcgi_index index.php;
 include fastcgi_params;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param PATH_INFO $fastcgi_path_info;
 }

 location ~ /\.ht {
 deny all;
 }

 location = /favicon.ico {
 log_not_found off;
 access_log off;
 }

 location = /favicon.svg {
 log_not_found off;
 access_log off;
 }

 location = /robots.txt {
 log_not_found off;
 access_log off;
 allow all;
 }

 location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
 expires max;
 log_not_found off;
 }
}

完成后就可以使用域名来访问了。

也可以参考我的github仓库中的docker-compose.yaml文件：wordpress

文章归档

Tue, 28 May 2019 00:00:00 +0000

关于

Mon, 01 Jan 0001 00:00:00 +0000

呵，欢迎你来呦。

友情链接

Mon, 01 Jan 0001 00:00:00 +0000

友情链接

欢迎与本站交换友链！以下是一些优秀的网站推荐。

申请友链

如果您希望与本站交换友链，请确保您的网站：

内容健康，积极向上
有一定的更新频率
网站访问稳定

您可以通过页面底部的联系方式与我联系。

搜索

Mon, 01 Jan 0001 00:00:00 +0000

配置项	说明
Token name	自定义的一个说明名称，可以随意配置
Description	说明，可以留空
Resource owner	正常情况下，选择自己的github用户就可以了
Expiration	token的过期时间，根据自己的情况设置，我这里设置永不过期
Repository access	仓库访问权，我这里选择只给他访问特定的仓库
Permissions	这里需要注意了，Repository permission一定要点开，然后对每项进行设置，我这里每项都只给access权限。

记录点滴 - 分享

GitHub 的 Verified 提交、SSH Key 与 noreply 隐私邮箱，一次讲清楚

写在前面

先分清三个最容易混淆的概念

1. 账号邮箱验证

2. 提交显示 Verified

3. noreply 隐私邮箱

auth key 和 sign key 到底分别做什么

auth key：证明“你能操作仓库”

sign key：证明“这次提交确实是你签的”

一个比喻就够了

为什么同一把 SSH key 可以同时用于 auth 和 sign

想让每次 GitHub 新提交都显示 Verified，最推荐怎么配

第一步：确认 Git 版本

第二步：确认本机是否已有 SSH key

第三步：先添加 Signing Key，需要 SSH 传输时再补 Authentication Key

第四步：告诉 Git 以后用这把 key 给提交签名

第五步：确认提交邮箱配置正确

第六步：做一次测试提交

补充：为什么网页上直接改文件，也可能显示 Verified

同时使用 GitHub 和 GitLab，应该怎么配才不互相干扰

推荐方案：只在 GitHub 仓库开启自动签名

如果你接受所有仓库都默认签名

最后一定要会看实际生效配置

noreply 隐私邮箱到底解决什么问题

它不会替你完成签名

它在网页端和命令行端的行为不一样

这个设置建议一起打开

开启 noreply 之后，旧 commit 会不会自动变匿名

如果想把旧 commit 也改成匿名邮箱，要付出什么代价

什么情况下可以考虑重写历史

什么情况下通常不建议动

最后给三个直接可用的结论

场景一：只想让 GitHub 新提交显示 Verified

场景二：既想 Verified，又不想暴露真实邮箱

场景三：本地同时操作 GitHub 和 GitLab

参考文档

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

Codex 也能定义 Agent：和 Claude Code Agent 到底差在哪

写在前面

核心概念

先看一张总表

定义方式：Claude 更像写角色卡，Codex 更像写配置文件

Claude Code：Markdown 文件就是 agent 本体

Codex：TOML 更偏配置驱动

委派机制：这可能是两边最大的分水岭

Claude Code：可以自动委派

Codex：只有显式要求才会 spawn

继承规则：Claude 更强调边界，Codex 更强调沿父会话继承

Claude Code 的继承重点

Codex 的继承重点

能力边界：Claude Code 在 subagent 这层给的旋钮更多

Claude Code 能直接在 subagent 层定义的东西更多

Codex 的 custom agent 更像核心运行参数覆写

工程化能力：Claude 更像内建工作流，Codex 更像多线程调度器

Claude Code 的工程化味道

Codex 的工程化味道

一个很实际的判断：谁更适合什么人

常见问题与解决方案

问题一：现在还能说 Codex 不支持自定义 agent 吗

问题二：Claude Code 和 Codex 的 agent，能不能简单理解成同一种东西

问题三：如果我要给团队写一套 agent，先选哪边更省事

问题四：agent 和 skills 是一回事吗

总结

MoviePilot订阅与通知配置指南：目录、整理与Webhook一次讲清

写在前面

先说结论

目录配置：先决定文件会落到哪里

通知系统：为什么有时有通知，有时没有

自动整理与 Webhook：到底是谁在推动文件入库

手动添加种子：会不会被接管

搜索关键词和自定义识别词：什么时候值得用

MoviePilot订阅识别流程详解：从入门到精通

视频资源术语完全指南：从入门到精通

最后给一套排查顺序

第一步：先看目录

第二步：再看通知

第三步：再看整理方式

第四步：最后再看识别和规则

总结

2. 提交显示 `Verified`

3. `noreply` 隐私邮箱

`auth key` 和 `sign key` 到底分别做什么

`auth key`：证明“你能操作仓库”

`sign key`：证明“这次提交确实是你签的”

为什么同一把 SSH key 可以同时用于 `auth` 和 `sign`

想让每次 GitHub 新提交都显示 `Verified`，最推荐怎么配

第三步：先添加 `Signing Key`，需要 SSH 传输时再补 `Authentication Key`

补充：为什么网页上直接改文件，也可能显示 `Verified`

`noreply` 隐私邮箱到底解决什么问题

开启 `noreply` 之后，旧 commit 会不会自动变匿名

场景一：只想让 GitHub 新提交显示 `Verified`

场景二：既想 `Verified`，又不想暴露真实邮箱

Claude Code — `settings.json`（4 层级，固定路径，不遍历目录）

OpenCode — `opencode.json`（多层级，支持目录遍历）

5. 用户全局 `AGENTS.md`