[{"content":"这个页面用于记录网站本身的结构、功能、页面与导航更新。\n规则：\n只有网站本身发生变化时才记录在这里，例如：新增搜索页、调整首页按钮、修改导航、调整页面结构、增加新的静态功能。 新增文章不记入这里。 2026-05-24 首页“关于”入口改为“网站更新日志”。 新增单独搜索页，并在首页按钮和顶部导航中加入“搜索”入口。 ","permalink":"https://hanhua.asia/about/single/","summary":"\u003cp\u003e这个页面用于记录网站本身的结构、功能、页面与导航更新。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e规则：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e只有网站本身发生变化时才记录在这里，例如：新增搜索页、调整首页按钮、修改导航、调整页面结构、增加新的静态功能。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e新增文章不记入这里。\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"2026-05-24\"\u003e2026-05-24\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e首页“关于”入口改为“网站更新日志”。\u003c/li\u003e\n\u003cli\u003e新增单独搜索页，并在首页按钮和顶部导航中加入“搜索”入口。\u003c/li\u003e\n\u003c/ul\u003e","title":"网站更新日志"},{"content":"作者：寒花（助手：GPT-5.4）\nSillyTavern 是一个面向大模型聊天与角色扮演的前端工具。它本身不是模型服务，而是一个把聊天、角色卡、世界书、预设、语音、图片生成和扩展能力集中到一起的操作界面。\n它的作用，不只是把模型回复显示出来，而是把“长期使用 AI”这件事做成一个可以积累、可以整理、可以持续调教的环境。你可以在里面管理角色、整理设定、保存对话、切换预设，也可以继续往上接 TTS、图片生成和其他扩展能力。对于想把 AI 聊天真正当成一个长期使用环境来配置的人来说，SillyTavern 会比单纯在某个网页里直接对话更灵活。\n这篇文章写的就是一套适合个人服务器使用的 SillyTavern 搭建与配置思路。重点不放在命令本身，而放在技术实现路径、模块拆分方式，以及这些功能为什么要这样接。\n一、先明确要搭成什么样 在开始之前，先把目标想清楚。对我来说，一套真正可用的 SillyTavern 环境，至少应该满足这些要求：\n能长期稳定运行 能通过浏览器正常访问 配置和聊天记录可以保留 后续接 API、世界书、预设、语音和图片功能时，不需要推倒重来 即使重建容器，主要数据也不会丢 如果只是临时体验，直接在本机跑一个实例当然更快；但如果希望它成为一套长期使用的环境，那么从一开始就要把结构想清楚，而不是只追求“先跑起来”。\n二、为什么我更推荐用 Docker 来搭 SillyTavern 这类前端，真正麻烦的通常不是第一次安装，而是后面越用越复杂。\n今天接一个 API，明天导入一批角色卡，过几天再加上世界书、预设、TTS 和图片功能，如果一开始部署方式就很随意，后期会很难维护。也正因为这样，我更推荐直接用 Docker 来跑。\n这样做的好处主要有几个：\n程序本体和数据可以分开 重建容器时不需要重做全部配置 升级和迁移更容易控制 后续要加插件、扩展或适配器时，更容易拆分层次 Docker 不会自动让一切变简单，但它能帮你把“容器本体”和“长期积累的数据”切开。对 SillyTavern 来说，这一点非常重要。\n三、搭建时先想目录，不要先想功能 很多人第一次搭 SillyTavern，会先关心页面能不能打开、模型能不能回字。这个顺序不能说错，但如果你想长期使用，那么更值得先想清楚的其实是目录结构。\n因为真正长期有价值的东西，不是容器本身，而是后面积累出来的这些内容：\n配置文件 用户数据 聊天记录 世界书 预设 扩展文件 前端改动内容 所以更合理的做法，是一开始就把这些内容按职责拆开。这样做之后，整个环境会有几个明显好处：\n重建容器不会影响历史数据 配置改动和前端改动更容易定位 备份时不需要整包乱拷 后面迁移到新机器时更省事 对长期实例来说，目录规划这一步其实比“先接几个功能”更重要。因为前面偷懒，后面大概率要花更多时间补回来。\n四、基础搭建过程，核心不是启动命令，而是顺序 SillyTavern 的基础搭建本身并不复杂。官方文档里也给了 Docker 安装方式，思路很直接：\n使用官方镜像 把配置目录和数据目录挂载出来 暴露访问端口 启动容器 但真正影响后续体验的，不是你有没有把命令敲对，而是你搭建时采用什么顺序。\n我更推荐这样的流程：\n第一步：先把本体跑起来 先只做一件事：确认 SillyTavern 容器本体能稳定启动。\n这个阶段不需要急着接所有功能，也不需要一开始就把世界书、预设、TTS、图片和扩展全部装上。重点只是确认：\n容器能正常运行 页面能正常打开 配置和数据已经落到宿主机目录里 第二步：先确认“本机访问”正常 在服务本体跑起来以后，先确认本机访问是稳定的，再去做外部访问。\n原因很简单：如果本机这一层都没有稳定，后面再叠加反向代理、内网穿透、受控访问或其他连接方式，问题会越来越难定位。\n更稳的顺序应该是：\n先让本机入口可用 再做外部访问 最后再叠加更多功能 第三步：把访问方式和服务本体分开思考 SillyTavern 是服务本体，外部访问是另一层。两者不要混在一起处理。\n如果只是个人使用，更合理的思路通常是：\n先让 SillyTavern 自己只负责提供稳定入口 再根据自己的环境决定怎么从外部进入 这样后续不管你是用内网、反代，还是其他受控访问方式，都不会把服务本体和访问层搅在一起。\n五、API 接入的关键，不是全都支持，而是先跑通主链路 SillyTavern 搭好之后，下一步通常就是接聊天模型 API。\n这一层最容易犯的错误，是一开始就同时配置很多不同的模型源、很多不同的接口类型，然后把大量时间花在切来切去上，最后反而不知道哪条链路才是稳定的。\n更稳的做法应该是：\n先选一个你真正会长期用的模型源 先把这一条 API 接通 先确认消息能正常发送和返回 再去调预设、上下文和其他高级设置 也就是说，先把主聊天链路跑通，再去做调优。\nSillyTavern 支持的 API 类型很多，但大多数时候你真正需要的不是“全都配好”，而是先把自己主用的那一类接好。因为只有主聊天链路稳定了，后面的角色卡、世界书、预设和语音功能才有实际意义。\n六、为什么图片功能更适合加一层适配器 如果想在 SillyTavern 里直接使用图片生成功能，更合理的做法通常不是让它直接去接不同图片上游，而是在中间加一层适配器。\n原因在于，SillyTavern 对图片接口有自己的预期格式，但你实际使用的图片上游未必正好和它完全兼容。直接硬接的后果通常是：\n每换一个上游都要重新调一遍 问题难以定位 前端和上游耦合得太死 所以更稳的技术实现方式是：\nSillyTavern 只面对一个固定接口 中间适配器负责做请求和返回格式转换 真正的图片上游放在后面独立处理 这样做的意义，不只是“让它能用”，而是让整条链路以后更容易维护。因为真正容易变化的往往不是 SillyTavern 本体，而是你后面接的图像服务。\n换句话说，适配器的作用不是替代图片服务，而是把“前端预期格式”和“真实上游格式”隔开。只要这层隔开了，后面怎么换图片来源，影响都会小很多。\n七、TTS 接入更适合走兼容接口路线 TTS 这一层，其实和图片适配器很像。\n真正重要的不是“有没有声音”，而是这条链路以后是不是好维护。如果一开始就把 TTS 和某个很特殊的实现方式绑死，后面想换音色、换后端、换服务，通常都会很麻烦。\n所以更稳的思路是：\n让 SillyTavern 对接一个结构稳定的兼容接口 让真正的语音服务放在后面独立处理 这样做的好处是：\n前端配置更统一 后续替换语音服务更容易 和 API、图片功能的管理方式更一致 TTS 真正合理的调试顺序，也不应该是一上来就追求最完美的朗读体验，而应该是：\n先确认能正常发声 再确认链路稳定 再去调朗读范围、音色和其他细节 先把链路做通，后面的优化才有意义。\n八、世界书不是“多塞设定”，而是“动态放背景” 世界书是 SillyTavern 里很重要的一层，但很多人刚接触时，容易把它理解成一个单纯堆设定的地方。实际上更准确的理解应该是：\n世界书是一种按条件动态插入背景信息的机制。\n它真正的作用，不是无限堆内容，而是在需要的时候，把合适的背景信息推给模型。这样模型在对应场景下会更容易保持设定一致，也更容易在长对话里维持世界观。\n世界书的来源通常有几种：\n社区分享 角色卡作者配套提供 别人整理好的 lorebook 自己手工整理 但比“从哪里来”更重要的，是导入之后怎么用。\n更合理的使用思路通常是区分范围：\n有些世界书适合全局使用 有些只适合某个角色 有些只适合某个聊天 如果不区分这一层，最后很容易变成所有背景内容都一直参与上下文，反而让整个环境越来越重、越来越乱。\n九、预设的作用，不是替代角色卡，而是控制输出方式 预设和世界书经常会一起出现，但它们负责的事情并不一样。\n世界书偏向补背景 预设偏向控制模型输出方式、格式习惯和提示词结构 很多时候，一个玩法之所以表现得稳定，不是因为某张角色卡本身写得特别好，而是因为：\n角色卡 世界书 预设 这三者之间配合得比较完整。\n所以在实际使用时，预设不要被当成一个“顺手导进去就完了”的附属品。它其实决定了模型最终是怎么理解当前聊天环境、怎么组织输出、怎么遵循你想要的写作或角色风格。\n更稳的导入思路是：\n先原样导入 先确认它原本能正常工作 再做最小改动 因为很多预设并不是“意思差不多就行”，而是对整体骨架很敏感。先验证原版，再做个性化调整，会比一上来就大改更稳。\n十、为什么这些功能最好分层管理 SillyTavern 之所以适合长期使用，一个很重要的原因，就是它允许你把不同层级的东西拆开。\n比较实用的分层方式通常是：\nAPI 连接是一层 角色卡是一层 世界书是一层 预设是一层 TTS 是一层 图片功能是一层 扩展又是一层 这样做的好处是，后面不管你换模型、换预设、换世界书，还是增加语音和图片能力，都不需要把整套环境全部推倒重来。\n从技术实现角度看，这其实就是在尽量降低耦合：\n前端只负责统一交互 各类能力分别通过不同模块接进来 数据和配置尽量独立保存 这种结构的价值，不在于它看起来多高级，而在于后面真的会省很多事。\n十一、当前这套搭建与配置思路的总结 如果只做一个简化总结，我会把这套方案概括成下面几点：\n用 Docker 部署 SillyTavern 先把服务本体跑稳，再考虑外部访问 先把配置和数据目录分清楚 先接通一个稳定的聊天 API 图片功能优先走适配器思路 TTS 优先走兼容接口思路 世界书和预设按用途分开管理 整个环境尽量按层次组织，而不是一股脑堆在一起 这样搭出来的 SillyTavern，不一定是功能最多的一套，但通常会是更适合长期使用，也更容易维护的一套。\n","permalink":"https://hanhua.asia/posts/build-a-usable-sillytavern/","summary":"\u003cp\u003e作者：寒花（助手：GPT-5.4）\u003c/p\u003e\n\u003cp\u003eSillyTavern 是一个面向大模型聊天与角色扮演的前端工具。它本身不是模型服务，而是一个把聊天、角色卡、世界书、预设、语音、图片生成和扩展能力集中到一起的操作界面。\u003c/p\u003e\n\u003cp\u003e它的作用，不只是把模型回复显示出来，而是把“长期使用 AI”这件事做成一个可以积累、可以整理、可以持续调教的环境。你可以在里面管理角色、整理设定、保存对话、切换预设，也可以继续往上接 TTS、图片生成和其他扩展能力。对于想把 AI 聊天真正当成一个长期使用环境来配置的人来说，SillyTavern 会比单纯在某个网页里直接对话更灵活。\u003c/p\u003e\n\u003cp\u003e这篇文章写的就是一套适合个人服务器使用的 SillyTavern 搭建与配置思路。重点不放在命令本身，而放在技术实现路径、模块拆分方式，以及这些功能为什么要这样接。\u003c/p\u003e\n\u003ch2 id=\"一先明确要搭成什么样\"\u003e一、先明确要搭成什么样\u003c/h2\u003e\n\u003cp\u003e在开始之前，先把目标想清楚。对我来说，一套真正可用的 SillyTavern 环境，至少应该满足这些要求：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e能长期稳定运行\u003c/li\u003e\n\u003cli\u003e能通过浏览器正常访问\u003c/li\u003e\n\u003cli\u003e配置和聊天记录可以保留\u003c/li\u003e\n\u003cli\u003e后续接 API、世界书、预设、语音和图片功能时，不需要推倒重来\u003c/li\u003e\n\u003cli\u003e即使重建容器，主要数据也不会丢\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果只是临时体验，直接在本机跑一个实例当然更快；但如果希望它成为一套长期使用的环境，那么从一开始就要把结构想清楚，而不是只追求“先跑起来”。\u003c/p\u003e\n\u003ch2 id=\"二为什么我更推荐用-docker-来搭\"\u003e二、为什么我更推荐用 Docker 来搭\u003c/h2\u003e\n\u003cp\u003eSillyTavern 这类前端，真正麻烦的通常不是第一次安装，而是后面越用越复杂。\u003c/p\u003e\n\u003cp\u003e今天接一个 API，明天导入一批角色卡，过几天再加上世界书、预设、TTS 和图片功能，如果一开始部署方式就很随意，后期会很难维护。也正因为这样，我更推荐直接用 Docker 来跑。\u003c/p\u003e\n\u003cp\u003e这样做的好处主要有几个：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e程序本体和数据可以分开\u003c/li\u003e\n\u003cli\u003e重建容器时不需要重做全部配置\u003c/li\u003e\n\u003cli\u003e升级和迁移更容易控制\u003c/li\u003e\n\u003cli\u003e后续要加插件、扩展或适配器时，更容易拆分层次\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDocker 不会自动让一切变简单，但它能帮你把“容器本体”和“长期积累的数据”切开。对 SillyTavern 来说，这一点非常重要。\u003c/p\u003e\n\u003ch2 id=\"三搭建时先想目录不要先想功能\"\u003e三、搭建时先想目录，不要先想功能\u003c/h2\u003e\n\u003cp\u003e很多人第一次搭 SillyTavern，会先关心页面能不能打开、模型能不能回字。这个顺序不能说错，但如果你想长期使用，那么更值得先想清楚的其实是目录结构。\u003c/p\u003e\n\u003cp\u003e因为真正长期有价值的东西，不是容器本身，而是后面积累出来的这些内容：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e配置文件\u003c/li\u003e\n\u003cli\u003e用户数据\u003c/li\u003e\n\u003cli\u003e聊天记录\u003c/li\u003e\n\u003cli\u003e世界书\u003c/li\u003e\n\u003cli\u003e预设\u003c/li\u003e\n\u003cli\u003e扩展文件\u003c/li\u003e\n\u003cli\u003e前端改动内容\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e所以更合理的做法，是一开始就把这些内容按职责拆开。这样做之后，整个环境会有几个明显好处：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e重建容器不会影响历史数据\u003c/li\u003e\n\u003cli\u003e配置改动和前端改动更容易定位\u003c/li\u003e\n\u003cli\u003e备份时不需要整包乱拷\u003c/li\u003e\n\u003cli\u003e后面迁移到新机器时更省事\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e对长期实例来说，目录规划这一步其实比“先接几个功能”更重要。因为前面偷懒，后面大概率要花更多时间补回来。\u003c/p\u003e\n\u003ch2 id=\"四基础搭建过程核心不是启动命令而是顺序\"\u003e四、基础搭建过程，核心不是启动命令，而是顺序\u003c/h2\u003e\n\u003cp\u003eSillyTavern 的基础搭建本身并不复杂。官方文档里也给了 Docker 安装方式，思路很直接：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e使用官方镜像\u003c/li\u003e\n\u003cli\u003e把配置目录和数据目录挂载出来\u003c/li\u003e\n\u003cli\u003e暴露访问端口\u003c/li\u003e\n\u003cli\u003e启动容器\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e但真正影响后续体验的，不是你有没有把命令敲对，而是你搭建时采用什么顺序。\u003c/p\u003e\n\u003cp\u003e我更推荐这样的流程：\u003c/p\u003e","title":"自己搭建一个可用的 SillyTavern"},{"content":"作者：寒花（助手：GPT-5.4）\n如果你想拥有一个真正属于自己的邮箱，比如 me@yourdomain.com，最直接的思路通常是：准备一台服务器，部署邮件服务，配置域名解析，然后接入邮件客户端使用。\n实际操作时，真正的关键不在于“有没有装上邮件软件”，而在于你选择的服务器是否适合承担公网邮件入口。如果服务器能够稳定接收来自互联网的 SMTP 投递，那么可以走标准邮件服务器方案；如果服务器不适合直接开放 25 端口收件，那么更适合采用“平台代收入口、本机负责邮箱本体”的方案。\n这篇文章写的就是一套适合个人使用的域名邮箱搭建思路，并且尽量按教程的方式组织，方便后续整理成给 agent 执行的操作文档。\n一、先明确要实现什么 这套方案完成后，目标应当包括：\n拥有自己的域名邮箱账号，例如 admin@yourdomain.com 能接收外部邮箱发来的邮件 能从自己的域名邮箱向外发信 能接入 Thunderbird 等邮件客户端 能继续扩展普通邮箱账号、别名和 catch-all 能通过脚本完成基础收发测试 如果只是为了自用，不需要一开始就追求企业级邮件平台。先做出一套可收、可发、可登录客户端、可长期维护的系统，比堆很多附加组件更重要。\n二、准备条件 开始之前，先准备好以下资源。\n1. 服务器 至少需要一台 Linux 服务器，建议条件如下：\n1GB 内存起步，2GB 更稳 至少 10GB 磁盘空间 能通过 SSH 登录 系统为常见 Linux 发行版 能正常安装 Docker、Python 和基础依赖 如果服务器上已经运行了很多服务，建议先确认还有足够可用内存，避免邮箱服务部署后长期处于资源紧张状态。\n2. 域名 需要一个自己的域名，例如：\nyourdomain.com 建议同时预先规划一个邮件服务地址，例如：\nmail.yourdomain.com 它可以用于 IMAP、SMTP、证书、客户端配置以及后续标准化管理。\n3. Cloudflare 账号 如果你的服务器不适合直接开放公网 25 端口，那么需要：\n一个 Cloudflare 账号 域名 DNS 托管在 Cloudflare 能使用 Cloudflare Email Routing 能部署 Cloudflare Worker 如果你的服务器可以直接收 25 端口邮件，那么 Cloudflare 不是必须条件，只要你能正常配置 DNS 即可。\n4. 核心软件 本教程中的邮箱本体推荐使用：\nStalwart Mail Server 它负责：\n邮件存储 账号管理 IMAP SMTP 管理后台 如果你走“无 25 端口”的方案，还需要一个很轻量的桥接服务，作用是把平台转来的邮件重新提交到本机邮箱系统中。\n三、先判断走哪条路线 在开始部署前，先确认你的服务器属于哪一种情况。\n情况 A：服务器可以直接通过公网 25 端口接收外部邮件 如果满足这一点，那么可以走标准方案：\n部署 Stalwart 初始化域名和邮箱账号 配置 DNS 中的 MX、SPF、DKIM、DMARC 等记录 让外部邮件服务器根据 MX 记录直接投递到你的服务器 完成收发测试和客户端接入 这种情况下，不需要 Cloudflare Email Routing，也不需要桥接服务。\n情况 B：服务器不适合直接通过公网 25 端口接收外部邮件 如果外部邮件无法稳定直接投递到你的服务器，那么不要继续强行走纯直收路线，而是改用：\nCloudflare Email Routing 作为收件入口 Cloudflare Worker 作为中转层 本机桥接服务把邮件交给 Stalwart 四、标准直收方案 如果你的服务器可以正常承接公网 25 端口邮件，那么搭建过程相对直接。\n第一步：部署 Stalwart 先在服务器上部署 Stalwart Mail Server，并准备好：\n容器运行环境 配置目录 数据目录 对外监听的邮件端口 管理后台访问入口 部署完成后，应当确认：\nStalwart 后台能够正常访问 邮箱域名可以初始化 管理员账号可以创建并登录 SMTP、IMAP 等协议端口已经正常工作 第二步：初始化邮件域名与账号 在 Stalwart 中完成这些基础配置：\n设置服务器主机名，例如 mail.yourdomain.com 设置默认邮箱域名，例如 yourdomain.com 创建管理员邮箱，例如 admin@yourdomain.com 根据需要创建普通用户邮箱、别名或 catch-all 规则 第三步：配置 DNS 在域名 DNS 中完成邮件相关记录：\nA 或 AAAA：指向 mail.yourdomain.com MX：指向你的邮件主机 TXT：配置 SPF TXT：配置 DKIM 公钥 TXT：配置 DMARC 如果没有正确配置这些记录，即使服务本身能运行，也可能导致发信可信度低、收信异常或客户端自动发现失败。\n第四步：测试收发 完成 DNS 配置后，做两类测试：\n外部邮箱发送到你的域名邮箱，确认能收到 你的域名邮箱发送到外部邮箱，确认能正常到达 如果以上都正常，再进行客户端接入即可。\n第五步：接入邮件客户端 推荐使用 Thunderbird 作为日常邮件客户端，配置以下内容：\nIMAP 服务器 SMTP 服务器 邮箱账号 密码 加密方式 到这里，标准直收方案就完成了。\n五、无 25 端口方案 如果你的服务器不能稳定承接公网 25 端口邮件，那么更适合采用“平台代收入口 + 本机邮箱系统”的方式。\n这条路线的核心思路是：\n发件人\n→ Cloudflare Email Routing\n→ Cloudflare Worker\n→ 服务器桥接服务\n→ Stalwart Mail Server\n在这个方案里，Cloudflare 负责接住外部邮件，服务器负责真正的邮箱存储和客户端服务。\n第一步：先部署 Stalwart 即使你不走公网 25 端口直收，Stalwart 仍然是邮箱本体。 所以第一步仍然是部署并初始化 Stalwart，完成这些工作：\n创建配置目录和数据目录 启动邮箱服务 初始化域名 创建管理员邮箱 开启 IMAP / SMTP 服务 确认后台能登录 第二步：在 Cloudflare 开启邮件入口 接下来在 Cloudflare 侧完成：\n开启 Email Routing 让你的域名具备邮件接收入口 配置收件规则 规划是否启用 catch-all 准备好相关 DNS 记录 这一步的作用不是替代你的邮箱系统，而是帮你接住原本应该打到 25 端口的邮件。\n第三步：部署 Worker Worker 的职责非常明确：\n接收 Email Routing 传来的邮件 提取发件人、收件人、主题、正文、HTML、头信息等内容 转换成标准化 JSON 以 HTTP 请求发送到你的服务器桥接服务 第四步：部署桥接服务 桥接服务是这条链路里的本机入口。它需要完成：\n提供一个邮件接收接口 校验请求是否来自你自己的 Worker 接收并解析邮件 JSON 把邮件重新提交进本机 Stalwart 这里建议采用认证提交方式，而不是匿名本地投递。也就是说，桥接服务应当像一个正常的发件客户端一样，把邮件通过受信通道提交到 Stalwart。这样更利于邮件进入正常收件箱，也更容易保持链路一致性。\n第五步：打通整条链路 完成 Worker 和桥接服务后，做完整收件测试：\n从外部邮箱向你的域名邮箱发送测试邮件 确认 Worker 是否正确收到并转发 确认桥接服务是否收到并提交邮件 确认 Stalwart 中是否能看到邮件 确认 IMAP 也能读到相同邮件 第六步：配置发件与客户端 虽然收件入口交给了 Cloudflare，但发件仍然由你自己的邮箱系统负责。 因此还需要继续确认：\nStalwart 的 SMTP 发件能力正常 外部邮箱能收到你的测试邮件 Thunderbird 等客户端可以正常登录并收发 到这里，无 25 端口方案就完成了。\n六、收发测试与客户端接入 无论你走哪条路线，最后都应当补上两部分内容。\n1. 收发测试脚本 建议额外准备两类测试工具：\n收件测试脚本：通过 IMAP 登录邮箱，读取最新邮件 发件测试脚本：通过 SMTP 登录邮箱，向外部邮箱发送测试邮件 如果你在 Windows 上使用，也可以额外准备一个 bat 启动入口，用于一键执行测试。\n2. 邮件客户端接入 最终日常使用时，推荐接入 Thunderbird。 配置完成后，你就可以像使用普通邮箱一样管理：\n收件箱 发件箱 已发送 草稿 未读已读状态 附件邮件 如果只是测试阶段，可以先使用管理员账号；如果准备长期使用，建议后续再创建一个普通用户邮箱作为日常主账号。\n七、结论 搭建域名邮箱时，最先要确定的不是“选哪个邮件软件”，而是“服务器适合走哪条收件路线”。\n如果服务器可以稳定承接公网 25 端口邮件，那么直接部署 Stalwart，配好 DNS，即可走标准直收方案。 如果服务器不适合直接对公网收件，那么就不要强行直收，而应改用 Cloudflare Email Routing + Worker + 桥接服务 + Stalwart 的组合。\n前者更标准，后者更适合很多现实环境。 无论选择哪一种，核心目标都应当是：做出一套真正能收、能发、能接入客户端、能长期维护的域名邮箱系统。\n","permalink":"https://hanhua.asia/posts/build-your-own-domain-mail/","summary":"\u003cp\u003e作者：寒花（助手：GPT-5.4）\u003c/p\u003e\n\u003cp\u003e如果你想拥有一个真正属于自己的邮箱，比如 \u003ccode\u003eme@yourdomain.com\u003c/code\u003e，最直接的思路通常是：准备一台服务器，部署邮件服务，配置域名解析，然后接入邮件客户端使用。\u003c/p\u003e\n\u003cp\u003e实际操作时，真正的关键不在于“有没有装上邮件软件”，而在于你选择的服务器是否适合承担公网邮件入口。如果服务器能够稳定接收来自互联网的 SMTP 投递，那么可以走标准邮件服务器方案；如果服务器不适合直接开放 25 端口收件，那么更适合采用“平台代收入口、本机负责邮箱本体”的方案。\u003c/p\u003e\n\u003cp\u003e这篇文章写的就是一套适合个人使用的域名邮箱搭建思路，并且尽量按教程的方式组织，方便后续整理成给 agent 执行的操作文档。\u003c/p\u003e\n\u003ch2 id=\"一先明确要实现什么\"\u003e一、先明确要实现什么\u003c/h2\u003e\n\u003cp\u003e这套方案完成后，目标应当包括：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e拥有自己的域名邮箱账号，例如 \u003ccode\u003eadmin@yourdomain.com\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e能接收外部邮箱发来的邮件\u003c/li\u003e\n\u003cli\u003e能从自己的域名邮箱向外发信\u003c/li\u003e\n\u003cli\u003e能接入 Thunderbird 等邮件客户端\u003c/li\u003e\n\u003cli\u003e能继续扩展普通邮箱账号、别名和 catch-all\u003c/li\u003e\n\u003cli\u003e能通过脚本完成基础收发测试\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果只是为了自用，不需要一开始就追求企业级邮件平台。先做出一套可收、可发、可登录客户端、可长期维护的系统，比堆很多附加组件更重要。\u003c/p\u003e\n\u003ch2 id=\"二准备条件\"\u003e二、准备条件\u003c/h2\u003e\n\u003cp\u003e开始之前，先准备好以下资源。\u003c/p\u003e\n\u003ch3 id=\"1-服务器\"\u003e1. 服务器\u003c/h3\u003e\n\u003cp\u003e至少需要一台 Linux 服务器，建议条件如下：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e1GB 内存起步，2GB 更稳\u003c/li\u003e\n\u003cli\u003e至少 10GB 磁盘空间\u003c/li\u003e\n\u003cli\u003e能通过 SSH 登录\u003c/li\u003e\n\u003cli\u003e系统为常见 Linux 发行版\u003c/li\u003e\n\u003cli\u003e能正常安装 Docker、Python 和基础依赖\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果服务器上已经运行了很多服务，建议先确认还有足够可用内存，避免邮箱服务部署后长期处于资源紧张状态。\u003c/p\u003e\n\u003ch3 id=\"2-域名\"\u003e2. 域名\u003c/h3\u003e\n\u003cp\u003e需要一个自己的域名，例如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eyourdomain.com\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e建议同时预先规划一个邮件服务地址，例如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003email.yourdomain.com\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e它可以用于 IMAP、SMTP、证书、客户端配置以及后续标准化管理。\u003c/p\u003e\n\u003ch3 id=\"3-cloudflare-账号\"\u003e3. Cloudflare 账号\u003c/h3\u003e\n\u003cp\u003e如果你的服务器不适合直接开放公网 25 端口，那么需要：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e一个 Cloudflare 账号\u003c/li\u003e\n\u003cli\u003e域名 DNS 托管在 Cloudflare\u003c/li\u003e\n\u003cli\u003e能使用 Cloudflare Email Routing\u003c/li\u003e\n\u003cli\u003e能部署 Cloudflare Worker\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果你的服务器可以直接收 25 端口邮件，那么 Cloudflare 不是必须条件，只要你能正常配置 DNS 即可。\u003c/p\u003e","title":"自己搭建一个可用的域名邮箱"},{"content":"这是博客的第一篇文章。\n关于这个博客 这里用来记录技术学习、日常思考和折腾的过程。\n主题 博客使用 Hugo + PaperMod 主题，部署在 GitHub Pages 上。\n","permalink":"https://hanhua.asia/posts/first-post/","summary":"\u003cp\u003e这是博客的第一篇文章。\u003c/p\u003e\n\u003ch2 id=\"关于这个博客\"\u003e关于这个博客\u003c/h2\u003e\n\u003cp\u003e这里用来记录技术学习、日常思考和折腾的过程。\u003c/p\u003e\n\u003ch2 id=\"主题\"\u003e主题\u003c/h2\u003e\n\u003cp\u003e博客使用 Hugo + PaperMod 主题，部署在 GitHub Pages 上。\u003c/p\u003e","title":"第一篇文章"}]