数字生活 — FoundersJP

日本最便宜的10G WiFi 7路由器：为什么我还是不推荐TP-Link BE550 Pro

Mon, 19 Oct 2026 14:43:30 GMT

我最近将东京家里的宽带从软银的10G光纤换成了NTT Docomo的10G服务。看到许多用户抱怨Docomo租用的网关WiFi不稳定，我决定自己动手，购买一款真正的10G WiFi 7路由器：TP-Link BE550 Pro。

购买时，这款型号是日本市场上最便宜的10G 6GHz WiFi 7路由器。得益于日元贬值以及近期消费电子产品价格的调整，我以**26,000日元（约合175美元）**的价格入手了它。

以下是我对其进行全面测试后，真实、不加修饰的评测。

开箱与设计

包装设计简约。除了主机和说明书外，仅附带一个宽电压电源适配器和一条1.5米长的屏蔽Cat6A网线。

从外观上看，这款路由器采用了隐藏式内置天线设计，中间有一条内嵌的腰线贯穿其中。其设计语言汲取了二十年前戴尔XPS机箱的灵感。与其他现代游戏主机并排放置时，它能完美融入其中，丝毫不会显得像一艘外星飞船。

亮点（硬件设计精良）

天线阵列：机身上半部分内置了6根集成天线，覆盖2.4GHz、5GHz和6GHz频段。每个频段均采用双天线配置，理论无线吞吐量最高可达9,679 Mbps。
丰富的端口配置：该设备配备一个 10G WAN 端口和四个 2.5G LAN 端口。 TP-Link在这方面值得称赞——市面上许多标榜“10G”的路由器却愚蠢地将10G WAN端口与标准的1G LAN端口搭配使用，导致整个局域网出现瓶颈。

瓶颈：灾难性的软件

虽然TP-Link在硬件配置上可谓极尽奢华，但软件方面的表现却令人大失所望。

MLO 故障： 虽然理论上支持多链路操作（MLO），但启用该功能会导致严重的数据包丢失和难以忍受的延迟，使其实际上无法使用。
**日本IPoE（IPv4 over IPv6）连接不稳定：**对于一款在日本官方销售的路由器而言，其对当地IPoE连接的适配性极差。这类连接高度依赖IPv6，但原厂固件却经常导致IPv6连接中断。更糟糕的是，一旦连接中断，系统无法自动重启或重新连接IPv6服务——这迫使用户不得不手动重启设备。

为了解决这个问题，我将另一台设备刷入了 OpenWrt 以处理 MAP-E 连接，从而将 BE550 Pro 改造成了一台功能更强大的接入点（AP）。

我对TP-Link的建议： 少花些时间在花哨、噱头性的功能上，而应专注于打造坚如磐石的核心软件功能。

如果能让时间倒流，我绝不会再买这款路由器了。

结语：为何10G光纤在AI时代至关重要

日本目前正在向居民家庭推广对称10G光纤（下行10Gbps/上行10Gbps）。在本地AI工作流时代，这种带宽不仅是一种奢侈，更是一种必需。

例如，下载一个本地 32B 参数的 AI 模型需要下载约 70GB 的数据。在标准的 1Gbps 网络连接下，下载过程需要一整晚的时间；而在全速 10G 网络连接下，则只需几分钟即可完成。

相关阅读：

NAS 中 Docker Compose 的高级应用
你非得放弃443端口，让你的IP地址后面带个数字尾巴吗？不！Lucky+CloudFlare让你焕然一新！

关注我，获取更多关于数字游民！的“生存”技巧！

AI电影制作入门：3款将故事转化为短片的工具

Thu, 17 Sep 2026 14:23:16 GMT

我的一位朋友把写剧本当作一种爱好。

最近，我帮她把几个简单的脚本做成了短视频。

虽然这些作品还远未达到好莱坞水准，但这从来都不是重点。

尽管制作过程有些粗糙，但看到故事在银幕上栩栩如生地呈现出来，却出乎意料地令人欣慰。这个过程本身既有趣、富有创意，又令人满足。

这样的经历让我相信，人工智能正将我们带向一个任何人都能成为自己人生故事的导演的世界。

今天我想分享一下我在这个项目中使用过的三款AI工具。它们结合起来，可以处理制作视频所需的大部分工作。

1. Dreamina AI — 生成图片和视频

Dreamina AI 是由字节跳动开发的一款生成式人工智能平台。它支持文本转图像、图像转视频以及基于故事的内容生成。

在这个项目中，我没有使用关键帧或精细的摄像机控制等高级技术。

相反，我只是写了几条简短的提示，然后让人工智能发挥创意来诠释它们。

正是这种简单易用，才是我认为初学者能够轻松上手AI视频工具、无需经历陡峭学习曲线的原因之一。

2. ElevenLabs — 配音与AI音乐

ElevenLabs 以其高质量的文本转语音技术而闻名。

它支持多种语言、富有情感的语音风格，并能精确控制语速、停顿和语调。生成的音频通常听起来足够专业，可用于播客、视频和商业项目。

我特别喜欢的一个功能是它能够生成歌曲。

你可以自己写歌词，选择音乐风格，然后让人工智能来创作音乐。

在我的新年视频中，我没有去寻找背景音乐，而是简单写了几行歌词，然后让人工智能生成了一首符合这种氛围的歌曲。

这既节省了时间，又让最终的视频更具个人特色。

3. DaVinci Resolve — 剪辑与调色

DaVinci Resolve 是一款在电影行业广泛使用的专业视频编辑和调色软件。

它提供了先进的编辑工具、视觉特效、多轨编辑以及业界领先的调色功能。

过去，我主要使用Premiere Pro进行剪辑。

不过，这次我发现DaVinci Resolve出乎意料地容易上手。

它介于专业级编辑软件和适合初学者的工具之间。

如果觉得 DaVinci Resolve 还是太复杂，CapCut 也是一个不错的选择。它更容易上手，只需花一点功夫就能完成大多数基本的剪辑任务。

结语

人工智能极大地降低了视频创作的门槛。

通过结合Dreamina AI生成的AI视觉效果、ElevenLabs提供的旁白和音乐，以及在DaVinci Resolve中的剪辑，普通人就能在相对较短的时间内制作出独一无二的视频。

这对作家、讲故事的人和创意爱好者来说尤其令人兴奋。

将纸面上的故事转化为更接近电影的作品，如今首次变得切实可行。

工具可以让创作变得更轻松。

但有意义的故事依然源自人们。

小白也不愁，软银封 IPv6 后，Lucky+Cloudflare Tunnel全搞定

Sun, 23 Aug 2026 13:55:00 GMT

今天突然发现家里的NAS没法在外网访问了，存里面的笔记也同步不了。排查了半天才找到原因——软银路由升级把IPv6的入站连接给封锁了。之前我分享过“去掉非443端口小尾巴”的方法，能解决不少访问问题，但面对这次的IPv6封锁，那套办法就完全不管用了。

https://www.foundersjp.com/cn/lifestyle-cn/digitallife-cn/443nolucky/

既然老办法失效，那我就换了新方案：**Lucky + Cloudflare（简称CF）**Tunnel，完美解决了问题，下面就把详细步骤一步步讲清楚，新手也能跟着做。

先说说我一直在用的核心工具——Lucky

Lucky是一个集成度超高的小工具，集合了DDNS、反向代理、内网穿透、端口转发、WebDAV、CorazaWAF防火墙等多种实用功能。不管是普通路由器，还是用Docker安装，它都能完美适配。

更棒的是它的“轻量”优势：常见的组合方案（比如NPM+cloudflared+ddclient）安装后，占用空间能到600-800M，运行内存也耗得多；而Lucky安装包不到30M，日常运行内存占用也就50M出头，对硬件配置低的设备特别友好。

接下来分步骤教大家搭建，全程跟着操作就行👇

第一步：在Cloudflare里创建隧道

登录你的Cloudflare账号，进入【Zero Trust】→【网络】→【连接器】，点击【创建隧道】按钮。
按页面提示给隧道起个名字（随便填，自己能区分就行），完成创建后，页面会显示一串隧道Token。
⚠️ 重要提醒：这个Token只显示一次！一定要立刻复制下来，粘贴到记事本里保存好，丢了就只能重新创建隧道了。
举个例子：页面里会显示类似--token 一串字符的内容，--token后面的所有字符，就是我们要的隧道Token，就算显示不全也要完整复制保存。

第二步：创建Cloudflare的API令牌

点击页面右上角的头像，进入【配置文件】，找到【API令牌】选项，点击【创建令牌】。
选择【使用模板】或者手动配置权限，按下面的要求勾选权限：

权限1：账户 → Cloudflare Tunnel → 编辑
权限2：区域 → DNS → 编辑

【账户资源】和【区域资源】选择“所有账户/区域”，也可以指定你要使用的具体域名对应的账户和区域。
点击保存后，页面会生成API令牌，同样只显示一次！复制下来保存好，建议备注成“API-Token”，避免和第一步的“Tunnel-Token”弄混。

第三步：在Lucky里添加隧道配置

打开Lucky的管理界面，找到【内网穿透】→【Cloudflare】，点击【添加实例】。
按下面的要求填参数，其他没提到的选项保持默认就行：

备注：填你喜欢的名字，方便识别这个隧道的用途（比如“NAS访问隧道”）
实例类型：选择【隧道】
第一个令牌输入框：粘贴第一步保存的“Tunnel-Token”
最下方的CF API Token输入框：粘贴第二步保存的“API-Token”

保存后，就能在隧道列表里看到刚添加的项目了。点击后面的【应用路由】，页面会显示一串专属的记录值，把这个值完整复制下来。

第四步：在Cloudflare里配置DNS解析

回到Cloudflare的管理界面，进入【DNS】→【记录】，点击【添加记录】。
记录类型选择【CNAME】，按要求填内容：

名称：填你想用来访问服务的域名前缀（比如用nas.xxx.com访问，就填nas）
内容：粘贴上一步从Lucky里复制的记录值
代理状态：打开“小黄云”图标（也就是开启CDN和代理）

点击保存，DNS记录就配置好了。

第五步：完成最终关联，开始使用

回到Lucky的隧道配置页面，在【主机名】输入框里，填上一步新建的完整域名（比如nas.xxx.com）。
点击旁边的【检测】，等检测结果变成绿色，就说明隧道已经连通了。
在【目标服务】输入框里，填你内网里设备的地址和端口（比如NAS的地址192.168.1.100:5000），保存后就能通过域名正常访问服务了。

最后说下这个方案的优缺点

✅ 优点：和传统的“DDNS+反向代理”方案比，它的加密性更好，而且通过Cloudflare中转，几乎不会被运营商拦截或封锁，稳定性拉满。
❌ 缺点：目前只支持HTTP、HTTPS协议的服务；如果你要用到远程桌面、FTP这类其他协议，这个方案就不适合了，得换其他方式。

难道失去443端口，地址就要带着数字小尾巴吗？No！Lucky+CloudFlare让你清清爽爽!

Tue, 11 Aug 2026 15:41:00 GMT

熟悉的友友都知道我比较爱折腾NAS，家里的NAS中也跑了很多服务。做为宅一族的我大部分使用也是通过路由端的内网地址跳转来使用，而没有注意到公网的访问状况。然而最近突然有一天，我在外出时发现NAS上的这些服务不能通过公网访问了。

查了一下原因是IPv6的443端口被封了，以前我所在的城市IPv6是不封443的。本以为是阶段性的封端口，过段时间会解禁，然而一个多月过去了，还是没有解禁，想必在相当长的一段时间内恐怕不会解禁了。

Lucky大吉

以往我在NAS上的服务都是通过DDNS-Go+Ngnix Prosy Manager实现的。前段时间在Lab机器上折腾iStoreOS时体验过了Lucky大吉，这次也打算正式在NAS上应用Lucky。家中的网络并非只有我一个人使用，之前也发生过因为All In One出状况导致被全家老小批判的历史。所以我现在的服务都在NAS上，路由就只做路由吧。

Lucky大吉是基于DDNS的一体化反向代理解决方案，支持很多域名服务商平台，同样也是通过API和密钥进行管理（相信能看到这里的友友，一定都知道如何申请API和密钥了），不过其管理后台设计的更加人性化，各种进程也更直观。SSL证书也是单独管理，更适合国人的使用习惯。我自己就使用了CloudFlare的15年证书，这么长的周期，还是很省心的。

当然最大的问题还是端口问题。因为我是比较懒的人，所以在通过大吉影射端口时，对外监听端口只设置了一个，各种服务是通过二级域名来做区分的。在NAS上的反向代理服务地址都加了nasx前缀。

源规则

虽说一个端口比较好记，通过域名加端口也可以使用。但作为有轻微强迫症的有菌，总会觉得很别扭，所以也一直在寻找可以实现公网端口跳转的方法。之前在大妈也有看到其他友友写的，通过重定向规则和源规则的方式去实现，但是让人比较无奈的是免费版只有10条重定向和10条源规则的使用权限。

我在尝试的过程中，发现源规则中有匹配“SSL/HTTPS”的选项，可以把默认的443端口指向服务主机的指定端口，这简直就是为我目前的情况所定制的。

CloudFlare的源规则非常人性化，可以通过“And”和“Ro”建立多种复杂的判断组合，适应各种情况。如果在单一网段只有一个主机的话，可以通过IPv6的网段做判断，这样不需要前缀，也便于记忆。但是我在“2408”下还有其他的主机，所以选择了前缀的方式来做判断，在NAS上的服务都在二级域名中加了“nasx”做为前缀，这样的设置保证了这个主域名下的其他二级域名不会出现冲突的情况。

当然DNS中的小黄云一定要打开哦，不然是不能生效的。

使用效果

经过这些设定后，仅需要域名就可以直接访问自己的私有服务了，无论是浏览器还是客户端都不成问题。不过要说明，通过域名访问的实际端口是443，而不是自定义的端口。在远程Aria下载或远程数据库访问时，端口也需要填写443。如果是远程桌面的话直接填写域名不需要端口也可以直接连接。

实际体验下来，经过CloudFlare的DNS访问比阿里DNS带端口的解析访问速度要慢一些，但是胜在稳定。在我出差的过程中发现一些城市通过阿里DNS访问会失效，但是CloudFlare却没有问题。没有试过腾讯的DNSPod和火山，不知道国内的其他平台是否支持这样的源规则，欢迎有用过的友友说说

给 AI 做个脑科手术：用 Ollama Modelfile 本地大模型调优，让它学会影分身术的？

Tue, 11 Aug 2026 13:57:00 GMT

Agent私有化的时代，Ollama是非常适合的AI模型运行基座，根据需求不同，交错加载不同的模型，以实现Agent的行为目的。不过ollama官方library的模型普遍占用空间比较大，而且不能自定义。相比较而言，从huggingface拉取是一个很好的选择。

恰好最近Qwen和Gemma都更新了新模型，号称对Agent和Skill友好，赶紧试一试。然而明明拉取了最强的 Qwen3.5，跑起来却像是个自言自语的疯子？这大概率不是模型智商问题，而是 Ollama Modelfile 缺少一场‘脑外科手术’。

huggingface拉取的模型，需要我们根据自己需求构建ModeFile，但这也往往是出现问题最多的地方，我们会遇到幻觉输出、自问自答，循环输出或者根本就不输出。这种情况的原因就是Ollama对于模型ModeFile中的Template极为敏感。大部分情况下各个模型中都有发布厂商预制的Chat Template，而出现模型暴走的根本原因是ModeFile与模型内置的Chat Template不一致而发生了冲突。

即使是同一个模型系列不同版本，内置的Chat Template差异也是很大的，Qwen3的ModeFile放到Qwen3.5就会出现暴走。所以最稳妥的方式就是导出模型内的Chat Template，并根据它去构建满足我们需求的ModeFile。

导出模版

通常Ollama是运行在容器中的，但是容器的环境通往往是精简的，所以要想提取Chat Template，最好的方式是在宿主机下直接执行。我是在UNRAID中运行的，默认是没有Python环境的，可以通过应用市场安装，同样的在群晖和飞牛中也可以安装。

在模型目录以Python的方式运行以下命令即可

python3 -c "



def read_gguf_template(file_path):
    try:
        with open(file_path, 'rb') as f:
            magic = f.read(4)
            if magic != b'GGUF': return '【无效 GGUF】'
            # 2MB 覆盖绝大多数元数据情况
            header_data = f.read(2 * 1024 * 1024)
            key = b'tokenizer.chat_template'
            pos = header_data.find(key)
            if pos == -1: return '【未找到模板字段】'
            
            # 定位 Jinja 模板特征符号
            start_jinja = header_data.find(b'{%', pos)
            if start_jinja == -1: start_jinja = header_data.find(b'{{', pos)
            
            if start_jinja != -1:
                raw = header_data[start_jinja : start_jinja + 2000]
                end_jinja = raw.rfind(b'%}')
                # 解码并清理可能存在的二进制残留
                res = raw[:end_jinja + 2].decode('utf-8', 'ignore') if end_jinja != -1 else raw.decode('utf-8', 'ignore')
                return res.strip()
            return '【找到关键字但无法定位起始点】'
    except Exception as e:
        return f'【读取出错: {e}】'

files = sorted([f for f in os.listdir('.') if f.endswith('.gguf')])
if not files:
    print('Error: 当前目录下没找到任何 .gguf 文件')
else:
    for file in files:
        print('\n' + '★' * 40)
        print(f'模型文件: {file}')
        print('--- 原始模板内容 ---')
        print(read_gguf_template(file))
        print('★' * 40)
"

之后在模型的目下就可以看到同名的

PS：我大部分使用Q4_K_M的模型，压缩比比较适中。

混乱的原因

以Qwen3.5为例：

模板中包含了 <think>\n\n</think>结构，如果Ollama的Modelfile没有定义PARAMETER stop "<|im_end|>"或者没有处理好思维链标签，模型就会进入循环思考。

为了适应现在的Agent和Skill热潮，Qwen3.5加入了大量的<tool_call>、<function=...>和<parameter=...>，如果Ollama 传入的系统提示（System Prompt）不完整，模型会“误以为”它需要调用工具。当它发现没有工具可调时，它会按照模板格式开始胡乱编造函数名和参数，产生“无意义内容”。

模板里有逻辑：{% if message.role == "tool" %}后面会接<|im_start|>user\n<tool_response>。在 Ollama 的默认逻辑里，user和assistant是交替出现的。而Qwen3.5为了兼容工具返回，把tool的返回内容包装进了user角色里。如果 Ollama 的Modelfile只是简单定义了角色，会导致上下文角色错位。模型会突然觉得自己是用户，造成“循环”假象。

自定义Modeflie

结构模型内置的模版，构建Modeflie就简单多了。根据模型中内置的Chat Template，我构建了Think和Agent两个Modeflie。

特性	Think 模式 (思考型)	Agent 模式 (执行型)
温度 (Temp)	0.6 - 0.8 (保留创造力)	0.1 - 0.4 (追求稳定性)
上下文 (Ctx)	32768 (长文本分析)	8192 - 16384 (够用即可)
核心逻辑	诱导式 `<think>` 开启	强制工具调用约束
停止词	常规角色标签	增加 `</think>` 截断

FROM ./Qwen3.5-4B-Q4_K_M.gguf

TEMPLATE """<|im_start|>system
{{ .System }}<|im_end|>
{{ range .Messages }}<|im_start|>{{ .Role }}
{{ .Content }}<|im_end|>
{{ end }}<|im_start|>assistant
<think>
"""

SYSTEM """You are an expert reasoning assistant. For every problem, think carefully and thoroughly before answering. Show your reasoning process inside <think> tags, then provide a clear, well-structured final answer after </think>."""

PARAMETER stop "<|im_end|>"
PARAMETER stop "<|im_start|>"
PARAMETER stop "<|endoftext|>"

PARAMETER num_gpu 99

PARAMETER num_ctx 32768
PARAMETER temperature 0.6
PARAMETER top_p 0.95
PARAMETER top_k 40
PARAMETER repeat_penalty 1.1
PARAMETER num_predict 8192

Agent，则是调用各种工具，以及快速生成即时内容的。Agent的modefile中严格限制了调用工具、执行和输出的规则。如果在执行的过程中，让模型思考，会导致降低执行效率，而且思考还会使执行的过程发生偏移。所以在执行中通过</think>终结思考流程，同样也有通过PARAMETER stop "</think>"参数强制终止思考。

FROM ./Qwen3.5-4B-Q4_K_M.gguf

TEMPLATE """<|im_start|>system
{{ .System }}<|im_end|>
{{ range .Messages }}<|im_start|>{{ .Role }}
{{ .Content }}<|im_end|>
{{ end }}<|im_start|>assistant
<think>

</think>

"""

SYSTEM """You are a precise, execution-focused AI assistant operating as an agent backend.

## Tool Usage
- Call tools proactively when external data, retrieval, or computation is needed.
- Return tool calls as valid JSON strictly following the provided schema.
- Include all required fields. Never omit or fabricate parameter values.
- If a required parameter is missing or ambiguous, ask for clarification before calling.
- After receiving tool results, synthesize and respond — do not re-expose raw tool output.

## Task Handling
- RAG / Retrieval: Query precisely. Summarize retrieved content faithfully without hallucination.
- Data processing: Apply operations step by step. Validate output structure before responding.
- Multi-step planning: Break complex tasks into subtasks. Track progress and adjust plan if a step fails.

## Output Rules
- Structured tasks → use JSON or markdown tables as appropriate.
- Free-form tasks → plain concise prose, no filler.
- Never guess. Never pad. If uncertain, say so explicitly."""

PARAMETER stop "<|im_end|>"
PARAMETER stop "<|im_start|>"
PARAMETER stop "<|endoftext|>"

PARAMETER num_gpu 99

PARAMETER num_ctx 16384
PARAMETER temperature 0.6
PARAMETER top_p 0.9
PARAMETER top_k 40
PARAMETER repeat_penalty 1.1
PARAMETER num_predict 2048

PARAMETER 参数部分则可以根据自己的设备环境和需求自己调整。

团队作战，1+1>2

通过这种 Modelfile 的“脑外科手术”，我们实际上是在单体模型的基础上，分化出了两个截然不同的“人格”。这就是本地大模型的影分身之术：

Thinker： 负责消化长文档、推敲逻辑，在 <think> 标签内完成复杂的思维链路。
Executor： 负责干脏活累活，严格执行 JSON 输出，绝不废话，只给结果。

这种“同源分身”的合作逻辑，相比混搭不同品牌、不同规模的模型，具有降维打击般的优势：

零沟通偏差： 因为它们共享同一套词表（Tokenizer）和底层逻辑，分身 A 规划的意图，分身 B 能精准“秒懂”，极大降低了跨模型调用时的协议对齐成本。
极致省空间： 无论你分出多少个角色，硬盘上始终只占用一份 Qwen3.5-4B-Q4_K_M.gguf 的体积。
NAS 性能飞跃： 即便是在资源有限的 NAS 环境下，通过“专精调优”的小参数模型，在特定任务上的稳定性和响应速度，甚至能超越那些臃肿的通用大模型。

Agent 私有化的终极闭环

在 Agent 私有化的浪潮中，Ollama 不再仅仅是一个模型加载器，它更像是一个“人才市场”。

通过 Modelfile 的精细控制，你可以像NARUTO -ナルト-那样，根据任务难度召唤出无数个“分身”：一个负责安全审查，一个负责代码审计，一个负责数据清洗……它们共用一个大脑（Weights），却各司其职。

当你的本地 AI 能够根据你的指令，自动在“深思熟虑”与“雷厉风行”之间无缝切换时，你拥有的就不再是一个只会聊天的机器人，而是一支召之即来、绝对忠诚且懂你底层的 AI 特种部队。

脑外科手术完成。现在，重启 Ollama，感受分身合击的力量吧！

个人账号注册Azure应用，解决不能访问Outlook邮箱必备。

Sat, 08 Nov 2025 15:51:53 GMT

世界知名的巨硬公司（微软），这回真的硬了，基于数据安全的考虑，强力推动现代安全的连接方式。自2022年起在面向企业服务的邮箱中就已经淘汰了基本身份验证（账号/密码）。2024年9月更是宣布自2025年5月起个人用户的基本身份验证也将停止，现在有延期到2026年4月底了。

对于经常使用Outlook网站和APP以及一些大厂APP，譬如Apple Mail 、Gmail的客户端的用户来说，似乎没有什么影响，这些APP都内置了Oauth2的支持。不过对于长期使用第三方客户端或者自托管工具并且积累了多年邮件信息的人来说就比较郁闷了，只能自己动手解决了。

无论使用什么客户端、APP，如果没有内置微软的Oauth2接口，首先都要取得Outlook个人账户的Oauth凭据。

首先需要在Azure注册一个免费账户，Azure是微软旗下的云服务平台。如果是企业用户的话，通常企业id已经绑定了Azure对应的账户。而个人用户需要重新注册，用Outlook所使用的邮箱即可。

这里需要注意，注册的时候会要求验证信用卡，支持的信用卡为VISA,运通,万事达和JCB（由于中国境内的微软云服务由北京世纪互联独立监管运营，所以国内用户仅支持VISA和万事达）。

注册完成后进入个人管理平台首页，选择应用注册，如果没有看到应用注册的话，可以在搜索栏中搜索即可。

在应用注册页面，点击新注册，之后填写应用的名称，账户类型等信息。如果只是自己这一个账户使用的话，选择单一租户即可。而我因为工作和私人分别有不同的Outlook邮箱，所以我需要选择 多租户和个人账户。

之后确定重定向地址，方式选择Web，地址则是

https://login.microsoftonline.com/common/oauth2/nativeclient

这个地址是一个特殊的地址，它的功能是告诉微软身份认证平台，我们目前正在注册的这个应用是用来进行API接口授权的。

点击完成后来到了应用详情页面，在左侧的管理中选择证书和密码，在其中新建客户端密码，这里可以选择密码有效的时长，最长为24个月，两年的时间，两年之后如果还要继续使用的话，需要重新申请密码，这也是微软的一种安全保障吧，注意这里的密码只会显示这一次，如果忘记的话，只能重新申请应用了，所以可以把这个密码找个安全的地方记下来。

获取密码后，选择右侧的api权限，之后选择Microsoft Graph其中的委托权限，并勾选其中的IMAP和STMP，添加后点击代表默认目录，授予管理员同意。

之后再自己使用的第3方应用或APP中，添加对应的应用租户账号和密码就可以了。

在Azure的个人首页可以看到自己目前所属的套餐，我的是免费套餐，点击详情可以看到有哪些免费的服务，如果自己要架设简单的网站或个人应用，可以充分利用这些资源。

NAS中 Docker Compose 的进阶玩法

Sun, 02 Nov 2025 04:17:06 GMT

熟悉我的友友都知道我经常折腾NAS，而我属于也在NAS部署了很多自托管的服务，这其中Docker是必不可少的。不同的NAS系统针对Docker有不同的解决方案，而Docker Compose是目前适用性最广泛额一个。

标签说明

Docker Compose 配置文件是 YAML 格式的，通常是 docker-compose.yml 或 compose.yaml 文件。顶级标签定义了整个应用的服务、网络、存储卷等配置。以下是 Docker Compose 配置文件中常见且重要的顶级标签名称及其功能列表。这个列表是基于 Compose 规范（Compose Specification）的，它取代了旧版本的 v2 和 v3 格式，是现阶段推荐和广泛使用的标准。


`version` (已废弃)	（在较新的 Compose 规范中已不推荐使用）在旧的 Compose 文件格式（v2 和 v3）中用于指定配置文件版本。现在使用 Compose 规范时，此字段通常被省略或仅用于向后兼容。	旧版本
`services`	定义应用中的所有服务。每个服务条目（如您提到的 `image`、`container_name` 等）都作为这个键下的子配置。这是 Compose 文件的核心部分。	必选
`volumes`	定义命名存储卷（Named Volumes）。这些存储卷可以在不同的服务之间共享，并且独立于容器的生命周期。	可选
`networks`	定义自定义网络。允许服务连接到特定的网络，以便相互通信或与外部网络通信。	可选
`configs`	定义配置数据（Config Data）。允许服务访问敏感或非敏感的配置数据，通常用于应用配置。	可选
`secrets`	定义敏感数据（Secrets）。允许服务安全地访问敏感信息，如密码或 API 密钥。	可选
`include`	包含其他 Compose 文件。允许将配置拆分为多个文件，便于管理和复用。	可选
`name`	指定项目名称。用于覆盖目录名称作为项目名称的默认行为。	可选

这些顶级标签中，服务标签（services） 是构建容器必不可少的，在其下也有很多常用的子标签。


`image`	指定构建容器所使用的镜像。可以是 Docker Hub 上的公共镜像，也可以是私有仓库或本地镜像。
`build`	定义如何构建镜像。如果不使用现有的 `image`，则用此指定 Dockerfile 路径和构建上下文。
`container_name`	为容器指定一个固定的名称。默认情况下 Compose 会生成一个名称（如 `projectname-servicename-1`）。
`ports`	发布容器的端口到主机。格式通常是 `主机端口:容器端口`。
`volumes`	挂载存储卷或主机路径到容器。用于数据持久化或共享主机文件。格式可以是 `主机路径:容器路径` 或 `卷名称:容器路径`。
`environment`	设置容器中的环境变量。可以是键值对列表或文件引用。
`env_file`	从文件中添加环境变量。
`networks`	指定服务应连接到哪些网络。
`depends_on`	定义服务之间的依赖关系。确保依赖的服务在当前服务启动前启动。
`restart`	定义容器退出时的重启策略。例如 `always`, `on-failure`, `unless-stopped`。
`command`	覆盖容器启动时执行的默认命令。
`entrypoint`	覆盖容器的默认入口点。
`labels`	添加自定义元数据（标签）到容器。
`healthcheck`	定义一个检查容器健康状态的命令。
`logging`	配置服务的日志驱动和选项。
`deploy`	指定部署和运行时约束（主要用于 Swarm 模式）。

样例

为了方便理解，我用两个样例来做说明。我会在每个标签旁边使用 # 符号添加注释（说明）。

以下这个示例展示了通过单个容器配置一个独立的 Web 服务器容器（使用 Nginx 镜像）的方案。

# Compose 文件的顶级配置键（标签）

# 推荐在新的 Compose 文件中省略 'version' 键，以遵循最新的 Compose 规范。
# 如果需要向后兼容，可以添加如下（但不再推荐）：
# version: '3.8'

# 核心标签：定义应用中的所有服务
services:
  # 服务名称：可以是任何你想要的名字，它作为网络别名
  web_server:
    # 服务子标签：

    # 指定构建容器所使用的镜像
    image: nginx:latest

    # 为容器指定一个固定的名称
    container_name: my_single_nginx_container

    # 挂载存储卷或主机路径到容器
    # 格式：[主机路径或卷名称]:[容器内部路径]
    volumes:
      # 挂载本地的 ./html 目录到容器的 Nginx 默认网页目录
      - ./html:/usr/share/nginx/html:ro

    # 发布容器的端口到主机
    # 格式：[主机端口]:[容器端口]
    ports:
      # 将容器的 80 端口映射到主机的 8080 端口
      - "8080:80"

    # 设置容器中的环境变量
    environment:
      # 这是一个示例环境变量
      - TIMEZONE=Asia/Shanghai

    # 定义容器退出时的重启策略
    # 'unless-stopped' 表示除非手动停止，否则容器退出时都会重启
    restart: unless-stopped

    # 添加自定义元数据（标签）到容器
    labels:
      - "com.example.description=Single Nginx Web Server"

# 顶级标签：定义命名存储卷（如果需要）
# 在这个单容器示例中，我们使用了主机挂载，所以 volumes 标签可以省略。
# volumes:
#   my_data:

# 顶级标签：定义自定义网络（如果需要）
# 在这个单容器示例中，Compose 会使用默认的 bridge 网络。
# networks:
#   default:
#     driver: bridge

这个示例则是通过多个容器配置一个 Web 应用程序（使用 Node.js 示例）和一个数据库（使用 PostgreSQL），并配置它们之间的依赖和通信的方案。

# Compose 文件的顶级配置键（标签）

# 核心标签：定义应用中的所有服务
services:
  # 服务一：Web 应用程序
  app_service:
    # 服务子标签：

    # 指定如何构建镜像（从 Dockerfile 构建）
    # 'context' 指定 Dockerfile 所在的目录，'dockerfile' 指定 Dockerfile 文件名
    build:
      context: .
      dockerfile: Dockerfile.app

    # 为容器指定一个固定的名称
    container_name: web_app_container

    # 发布容器的端口到主机
    # 将容器的 3000 端口映射到主机的 3000 端口
    ports:
      - "3000:3000"

    # 设置容器中的环境变量
    environment:
      # 连接数据库所需的环境变量
      - DB_HOST=db_service  # 使用服务名称作为主机名进行连接
      - DB_PORT=5432
      - DB_USER=user
      - DB_PASSWORD=secret

    # 定义服务之间的依赖关系
    # 确保 db_service 容器启动并运行后才启动 app_service
    depends_on:
      db_service:
        condition: service_started

    # 指定服务应连接到哪些网络
    networks:
      - internal_network
      - public_network

  # 服务二：数据库服务
  db_service:
    # 服务子标签：

    # 指定使用的数据库镜像
    image: postgres:14-alpine

    # 为容器指定一个固定的名称
    container_name: postgres_db_container

    # 挂载存储卷到容器
    volumes:
      # 使用命名存储卷进行数据持久化，确保数据在容器重启后不会丢失
      - postgres_data:/var/lib/postgresql/data

    # 从文件中添加环境变量（更安全的方式来管理密码）
    # 假设存在一个名为 .env.db 的文件，包含 POSTGRES_USER 等变量
    env_file:
      - .env.db

    # 定义容器退出时的重启策略
    restart: always

    # 指定服务应连接到哪些网络
    # 注意：数据库服务通常不直接暴露到公网，只连接内部网络
    networks:
      - internal_network

# 顶级标签：定义命名存储卷
volumes:
  # 定义一个名为 'postgres_data' 的卷
  postgres_data:
    # 可以指定驱动和选项，这里使用默认驱动
    driver: local

# 顶级标签：定义自定义网络
networks:
  # 定义一个内部使用的网络，供 app 和 db 通信
  internal_network:
    driver: bridge
  # 定义一个可能需要对外连接的网络
  public_network:
    driver: bridge

NAS中使用

目前来说各个主流的NAS系统都支持Docker Compose，根据自己的需要找到对应项目的Docker Compose，复制粘贴到NAS中的Docker Compose，并根据自己的具体情况编辑一下中即可。

需要特别说明的是在自己的NAS中使用时，修改Docker Compose文件中的路径。前文中提到的 挂载标签volumes 和 变量文件env_file 标签都会涉及到路径设置。大部分NAS系统在添加Docker Compose时都需要设置路径，这个路径就是容器项目在NAS中储存文件的位置。

在Docker Compose文件中，每个标签下的项目用“：”来分割，第一个冒号前的是映射的宿主机端口或地址，第一个冒号后则是容器内的端口或地址，第二个冒号后则是读写权限等设置项。

根据不同的开发者编辑代码习惯不同，映射挂载地址时，有的开发者会写绝对地址，有的则是相对地址，以上面的样例参考：

绝对地址：/volume1/docker/Test/html

相对地址：./html

上面的例子中， html 文件夹是映射挂载的文件夹，前面的“ ./ ”则表示 html 这个文件夹是在 /docker/Test 目录下的。我个人是偏好使用相对路径的，如果容器或docker目录发生位置调整时，不会使容器因目录失联而失效。

另一个就是端口，上面的例子中，是将容器中的80端口映射到宿主机的8080端口上，如果在NAS中有多的Docker容器运行，一定要注意哪些端口已经被占用了，避免在不同的容器中映射了同样的端口，这样也会导致容器无效。

简单易用!Docker添加中文支持，让你轻松打造母语环境！

Wed, 04 Jun 2025 04:40:00 GMT

玩NAS必然要折腾Docker，Docker可能是目前生态最广泛的应用平台了。除了大神们推荐的各种应用，在docker.com上也有很多好玩的东西，包括一些AIGC工具，一些私有云盘工具等。但是问题也来了，很多docker镜像应用不是面向中文用户开发的，所以也没有中文化。

前几天就有一位朋友跟我探讨Docker中的应用不支持中文怎么办？特别是视频转码字幕都变成了小方块。网上也有一些例如改时区，或者语言锁定Chianese的方案，但效果很局限。分享一下我摸索出来如何添加中文支持？

Docker的原理

想要弄懂docker，首先要理解它。Docker是基于LXC架构的容器引擎，在LXC基础上提供了更多优化管理的功能。更深度的了解可以看看下边的这篇文章。

https://www.foundersjp.com/cn/lifestyle-cn/digitallife-cn/docker-compose-advanced/

LXC全称是Linux Container，Container可译为“容器”或“集装箱”，这也是docker logo图标的由来。

无论是Docker还是LXC 本质都是基于Linux的。网上提供的容器可以理解为基于Linux底层打包了需要的依赖，精简去除不需要的部分。这样的优势是减少文件体积，利于网络传输，同时不影响原生系统，还可以在各个Linux发行版本中达到兼容的效果。

中文化方案

了解了底层原因，也就有了解决方案。很多Docker容器包不支持中文字符，或者说不支持非英语语言的原因是因为很多开发者在打包镜像的过程中，为了精简镜像的体积便于网络传输，只会保留默认的英语支持，不封装其他语言环境进去。

很多程序本身在Linux GUI(图形化界面)下是支持多语言的，因为Docker镜像中缺失了英语外其他语言的支持，所以导致不能显示其他的语言。所以我们在使用中只要挂载对应的语言字库就可以了。

为了保证最广泛的兼容性，我分别从win10和MAC中提取了字库，和Ubuntu默认的系统字库一同导出为一个文件夹作为字库文件包。保留Ubuntu的完整字库是因为Docker默认会索引Linux下的英文字体。把这个字库文件包导入宿主机的默认字库，来为所有Docker镜像提供共用的语言支持。

部署

Linux的默认字库目录是在“/usr/share/fonts”。

我们可以在Docker的命令行模式ls一下这个目录，可以看到默认是语言文件的。

所以只要在构建容器配置时，把字库目录强制指向宿主机的字库目录，再执行Docker启动命令。之后在应用中选择中文，就可以慢慢享用了。

NextCloud-AIO使用及优化，在线协同Office一键全搞定

Mon, 23 Dec 2024 12:14:29 GMT

前段时间装了NextCloud-AIO，有友友说外网使用时，有时Office还是出错。还有友友问数据怎么迁移。所以把各种状况放在一起说一下。

https://www.foundersjp.com/zh/digital-life-zh/unriad-nextcloud-aio/

安装器密码

经常折腾的友友可能会删除容器，甚至删除镜像等，而重新安装时发现不记得安装器的密码了，这就很尴尬了。如果忘记安装器密码也没有关系，可以通过下面这条命令找回密码。

docker exec nextcloud-aio-mastercontainer cat /mnt/docker-aio-config/data/configuration.json | grep password

相应的如果是在Win下的Docker，需要自己手动补全绝对路径。

容器缺失

因为网络原因，在拉取镜像时可能会失败，在安装器页面启动NextCloud时某些项目是红色的，并且在UnRaid的Docker列表中发现少了多容器的话，可以选择先停止服务，之后选择启动或并更新，安装器会自动把缺失的容器补回来。

修改密码

用安装器生成的随机密码登录后，可以在右上角头像处的菜单中的“个人设置-安全”中修改Admin的密码。这里需要校验原密码，并且新密码只输入一次，没有二次验证，所以一定要点后边的小眼睛关闭掩码确认一下，免得输入错误，别问我是怎么知道的。

Office

NextCloud默认时启用了WOPI白名单验证的，不过NextCloud也有说明在公网使用时可能会导致Office组件无法连接，所以建议通过AIO安装的情况下，关闭WOPI白名单验证。在“管理设置-Office”选项中，把“Allow list for WOPI requests”下的输入框清空，并点击右侧的箭头即可。

备份

NextCloud-AIO使用的是PostgreSQL数据库，而且数据文件并不是放在“/appdata/nextcloud/”中，如此可见只是通过UnRaid定期备份“appdata”数据是不安全的，不过NextCloud-AIO安装器提供了备份的功能，可以支持本地备份和远程备份，也支持定时备份，备份时会停止NextCloud服务，所以记得要选在没有同步计划的时间。

同步

NextCloud本身就集成了网盘、笔记、相册、通讯录、邮件、日历、TodoList等功能，在移动端也有丰富的APP支持，完全可以取代iCloud、小米云等各个厂商的云服务，毕竟自己的数字资产还是放在自己手中最安心。

常见的文件、图片、笔记等可以通过NextCloud的一系列APP，直接同步到自己家里的NAS上，安全又可靠。

iOS

iPhone和iPad的通讯录和日历同步，直接在系统设置的通讯录和日历中添加地址和帐号即可，还是比较简单方便的。

安卓

安卓手机则需要安装DAVx⁵这个APP才能同步，不过相比iPhone，通过DAVx⁵除了可以同步通讯录和日历外，还可以同步Tasks（ToDoList）,算是意外之喜了。DAVx⁵只是同步工具，Tasks可以通过jtxBoard、OpenTasks或Tasks中的任意一个在安卓手机上使用，比较推荐jtxBoard，包含日记、笔记和Tasks，都可以同步到NextCloud。

数字人生

《三体》里写到更高维度的生物看待我们，就是人生轨迹形成的点留下的一幅画作，确实是这样的，在这个数字的时代，我们一生中会留下无数的数据、无数的点，与其担忧云端的数据这个项目下线了，那个公司跑路了，不如把这些重要的人生轨迹握我们自己手中。NAS就是这样的存在包含我的喜好、我的兴趣以及我的人生数据。

手把手教程，在线协同Office一键全搞定，UnRiad+NextCloud-AIO

Fri, 20 Dec 2024 15:12:26 GMT

最近和朋友一起做项目，要协同办公，所以打算搭建一个功能强大的自托管协同平台。选来选去选择了NextCloud。选择它的原因有二：其一，它的功能丰富多样，涵盖了任务板、Office套件以及ToDoList管理等；其二，每个功能都配备了相应的移动端应用，使我们能够随时随地推进项目进程。

以前也在UnRaid中装过Docker的NextCloud，但是并不能很好的实现Office功能，总是出现各种问题。最近发现NextCloud官方推出了All In One解决方案，号称解决了office的问题，同时还自带杀毒底层等更多增强功能，正好这次尝试一下。

安装器

在UnRaid应用市场中直接搜索NextCloud就能找到“nextcloud-aio-mastercontainer”，这不是NextCloud本体，而是NextCloud-AIO的安装器，还特别标注了官方版，需要通过这个安装器完成NextCloud-AIO的安装。

安装前会有一个特别的提示，需要在UnRaid的Docker设置中开启“保留用户自定义的网络”。

点击确定就可以进入安装器容器的配置页面，其中很多不常用的选项都隐藏了。点击下面的更多设置，可以看到更多的东西。

其中“AIO webui”是安装器的内网访问端口，“Nextcloud apache port”是NextCloud的实际访问端口，这个端口是需要预先进行域名解析并反向代理的，默认是11000，这两个端口可以根据自己的网络环境修改。反向代理也可参考我之前的方案：

https://www.foundersjp.com/zh/digital-life-zh/no443luckycloudflare/

“Nextcloud Data Directory”NextCloud的文件储存在宿主机的路径，对于UnRaid来说，除了这里的位置需要修改一下，其他的都不需要修改。最下边的“Skip domain check”是跳过域名检测，如果确定域名指向反代已经绑定好的话，这一项可以选择ture。点击应用开始拉取镜像，之后在UnRaid的Docker页面中就可以看到安装器。

安装选项

打开安装器，系统会自动生成了一段短语，这个短语就是首次登录的密码。

登录NextCloud-AIO安装器后，首先需要的就是验证域名，就是之前指向11000的反向代理域名。

之后就是安装选项了，从上到下分别是：

防病毒引擎

Office组件

全文搜索组件

图片查看器

聊天工具

为聊天工具提供录音的服务

Docker 代理管理器

白板

这里根据自己的需要选择要安装的组件，其中“Docker 代理管理器”NextCloud官方在Git中特别说明“不建议在AIO中使用”。选好后需要保存一下。点击“Download and start containers”开始下载安装。这是一个漫长的过程，回到UnRaid的Docker页面页面刷新一下，可以看到出现了几个新的容器。

完成安装

至此NextCloud-AIO安装完成，全部容器启动完成后会随机生成admin帐号的初始密码，通过这个密码就可以愉快的登录使用了。