运维

记录一些简单的运维知识

国内注册域名后要先实名认证后,使用国内的服务器时,网站还需要在工信部,网安备案

在国内域名商购买了域名,解析的主机或服务器也在国内时,则必须备案通过后才能访问

海外域名,就只能用国外或香港主机/服务器,不能解析到国内的服务器

运维相关好用工具

iperf3

iPerf是一个支持跨平台部署使用的网络性能测量工具。它可以创建数据流测量两端之间单向或双向的网络吞吐量。

安装

官网下载链接

威联通安装方式

如何在局域网测网速?手把手教会NAS、电脑、路由器、手机如何安装 iperf3

如何在局域网测网速?手把手教会NAS、电脑、路由器、手机如何安装 iperf3

网络环境新增一个 TCP 端口,主机和容器都选择 5201,一般 iperf3 默认的端口也是 5201

如何在局域网测网速?手把手教会NAS、电脑、路由器、手机如何安装 iperf3

在命令行里输入-s,这个是开启5201 监听端口的命令,这样其他设备才能通过命令访问 NAS 的 iperf3 端口

总览:

如何在局域网测网速?手把手教会NAS、电脑、路由器、手机如何安装 iperf3

使用

启动服务端: iperf3 -s

启动客户端: -perf3 -c 服务端ip地址

-P 8表示启用8线程

-R 反转数据流方向(数据从服务端发向客户端)

-t 1800 表示测试时长1800秒

--logfile 保存文件名.txt 设置导出为文件(设置后,测试结果就不会在命令行中展示了)

关于ECC

ECC(Error-Correcting Code)内存是一种能够自动检测和修正内存错误的技术。它通过添加额外的位来存储数据,从而能够识别和纠正单比特错误。这在服务器和关键任务系统中尤其重要,因为这些系统对数据的准确性和可靠性有很高的要求。 ECC内存的主要优点包括:

  1. 数据完整性:能够自动检测并修正内存中的错误,从而减少数据损坏的风险。
  2. 系统稳定性:提高系统的稳定性,减少由于内存错误导致的崩溃或数据丢失的可能性。
  3. 适用于关键应用:在需要高可靠性的环境中(如金融、医疗和科学计算等领域),ECC内存是一个理想的选择。

全世界的商用级服务器都在使用ECC内存纠错

内存条的区别主要在于ECC内存条其中一面的一个额外的内存颗粒上,这个颗粒会对内存进行校验,在内存和处理器间传递数据之前,进行奇偶校验

ECC内存通常使用汉明码(Hamming Code)或其他更高级的错误更正码来实现错误检测和纠正功能。

必要性在于bit有时候会自己反转,造成软错误.如果位反转现象没有被发现和解决的话,会导致数据损坏或崩溃

会影响内存出现软错误频率的因素主要有下面几项:

  1. 大小
  2. 速度
  3. 密度

一个来自谷歌的相关研究表明:

大概32%的服务器以及8%的内存会在每年至少遇到一次内存错误

如果使用的是ECC内存,就可以一定程度上把这些内存错误找到并更正

缺点就是: 同一个内存频率下,支持ECC的内存条比普通内存条跑分更低,性能差在0%到20%之间

ECC内存条要比普通内存条贵,原料成本最多增加12%

Windows上的运维指令盘点

powershell中查硬盘信息指令Get-PhysicalDisk | Format-Table FriendlyName, MediaType, Size, HealthStatus

获取剪贴板内容: Get-Clipboard

Windows事件查看器

Windows事件查看器(Event Viewer)是Windows操作系统内置的系统日志管理工具,用于记录系统运行状态、应用程序行为和安全事件。它通过分析事件日志,帮助用户快速定位系统故障、应用程序错误及安全隐患

核心功能与作用

日志分类

  • 应用程序日志:记录软件运行事件(如程序崩溃、安装卸载)
  • 系统日志:记录操作系统组件事件(如驱动加载失败、服务启动错误)
  • 安全日志:记录安全相关操作(如登录尝试、权限变更)
  • Setup日志:系统安装或更新事件
  • 转发事件:其他计算机转发的日志

事件级别

  • 错误(红色):严重故障(如蓝屏、服务崩溃)。
  • 警告(黄色):潜在问题(如磁盘空间不足)。
  • 信息(蓝色):正常操作记录(如系统启动)。

打开方式

  1. 快捷搜索

    Win + S 输入“事件查看器”或“Event Viewer”

  2. 运行命令

    Win + R 输入 eventvwreventvwr.msc

  3. 控制面板

    控制面板 → 管理工具 → 事件查看器

  4. 任务管理器

    Ctrl + Shift + Esc → 文件 → 运行新任务 → 输入 eventvwr

  5. 文件资源管理器

    访问路径 C:\Windows\System32\eventvwr.exe

网站快速部署方案

Linux控制面板

特性维度 Websoft9 宝塔面板 cPanel 1Panel FastPanel Urlos
核心定位 开源应用全生命周期管理 通用服务器运维 专业虚拟主机管理 现代化容器化运维 快速建站与多语言支持 轻量级、低资源占用
应用生态 ★★★★★ (300+模板,深度优化) ★★★★☆ (丰富,但需手动调优) ★★★☆☆ (通用功能为主,缺乏深度适配) ★★★☆☆ (模板较少,依赖容器化) ★★★☆☆ (支持WordPress/Joomla等一键安装) ★★☆☆☆ (支持多语言环境但应用较少)
部署效率 ★★★★★ (3-5分钟,一键自动化) ★★★☆☆ (30-60分钟,需一定基础) ★★★☆☆ (依赖主机商) ★★★★☆ (20分钟,容器化部署)
安全机制 ★★★★★ (全生命周期自动防护+漏洞修复) ★★★☆☆ (基础防火墙+依赖插件) ★★★★☆ (企业级但成本高) ★★★☆☆ (侧重容器和网络隔离) ★★★☆☆ (提供基础防火墙和SSL管理)
资源效率 ★★★★★ (轻量化,1GB内存即可运行) ★★★☆☆ (高负载时性能可能下降) ★★☆☆☆ (需要企业级硬件支持) ★★★★☆ (中等,容器化有优势) ★★★★★ (资源占用极低,占传统面板1/3)
扩展性 ★★★★★ (支持Docker/K8s,自主扩展中间件) ★★★★☆ (插件生态丰富) ★★★☆☆ (功能依赖主机商) ★★★★☆ (兼容K8s,容器编排)
学习成本 ★★☆☆☆ (基础功能简单,高级功能需学习) ★★★☆☆ (中文友好,社区活跃) ★★★★☆ (现代化UI,但需容器知识) ★★★☆☆ (中等) ★★★☆☆ (低)
适用场景 需快速部署、深度管理多种开源应用的企业、开发者、教育机构 国内用户广泛,适合通用服务器运维、单站点管理 传统虚拟主机管理、邮件服务 需要轻量级容器化管理的场景 需要搭建多语言教学平台或快速创建课程网站 资源有限的服务器、老旧设备改造

Websoft9

Websoft9 的核心是提供一个大量预配置好的、生产就绪的开源应用目录(如 WordPress、Jenkins、Nextcloud、Moodle 等)。它解决了手动部署这些应用时遇到的依赖复杂、配置繁琐、优化和安全加固困难的问题。它非常适合那些希望快速获得这些特定开源软件,并希望其稳定、安全运行,而不想深究底层基础设施细节的用户和团队

项目地址

  • Websoft9 的核心定位是一个 “Applications self-hosting and DevOps platform”“lite PaaS”

    用于运行开源、基于 Web 的 Linux Panel 或 Lite PaaS 的应用程序自托管和 DevOps 平台

    • 自托管: 数据存储在本地

    • DevOps 平台: DevOps是“Development(开发)”和“Operations(运维)”的组合词,是一种文化、实践和工具的集合,旨在缩短软件开发生命周期,实现持续集成、持续交付和高效运维,即一套“自动化流水线”工具。传统方式是开发人员写完代码,扔给运维人员去手动部署,效率低易出错。DevOps平台则自动化了这个过程:代码一提交,自动测试、自动打包、自动部署上线

    • 基于 Web 的 Linux Panel: 一个通过浏览器访问的图形化用户界面,用于管理和操作Linux服务器。隐藏了复杂的命令行操作

    • Lite PaaS (轻量级平台即服务): PaaS是云计算服务的一种模式,提供软件部署和运行的环境(如运行时、数据库、Web服务器),开发者只需关心自己的代码。“Lite”(轻量级) 指这是一个简化版,通常为单机或小规模集群设计,易于部署和使用.即给你一个“应用程序的万能运行底座”。你不需要关心服务器环境配置(比如需要哪个版本的PHP、Python,如何配置Nginx),只需要把你的代码或应用程序打包扔给它,它就能自动为你准备好一切并运行起来

    但是要注意Websoft9是针对开源项目优化才能实现到这一点,针对自己的项目并不一定可以

  • 它的主要功能是帮助用户在单台 Linux 服务器上通过 Docker Compose 以微服务的方式 部署和管理预配置好的开源应用模板(例如 WordPress, Nextcloud, MySQL, Redis, GitLab 等)

Websoft9 的核心优势在于自动化集中管理。它通过应用商店和容器技术,简化了从部署、配置到维护的全过程,非常适合管理多个应用或需要快速搭建标准业务系统的场景

部署自己的项目

  1. Dokku:极致简约的个人版 Heroku

    Dokku 的核心是极简模仿 Heroku 的 Git 推送部署体验。它非常适合个人开发者或微型项目,让你在最低成本的 VPS 上就能体验到类似 Heroku 的部署流程。其功能主要通过插件体系扩展,本身非常轻量

  2. CapRover:功能完善的小团队利器

    CapRover 在 Dokku 的理念基础上,增加了友好的 Web 管理界面丰富的开箱即用功能(如一键部署数据库)。它降低了自托管 PaaS 的使用门槛,适合小团队、初创公司或个人开发者,希望在易用性和控制权之间取得平衡

  3. Coolify:面向未来的自托管中心

    Coolify 的目标是成为一体化的自托管解决方案。它不仅支持应用部署,还强调多云/混合云管理强大的自动化(如自动备份、Webhooks)和团队协作。适合注重数据主权、需要灵活部署策略,且有一定运维能力的用户

  4. Heroku:省心省力的全托管标杆

    Heroku 提供了最完整的开箱即用体验无忧的运维管理。你完全不需要关心底层基础设施,只需专注代码。但其昂贵的成本和可能的厂商锁定风险,使得许多开发者和团队开始寻求像 Dokku、CapRover 和 Coolify 这样的替代方案

  • 共同点:它们都通过容器化技术(Docker),将开发者从配置服务器环境、安装依赖、配置 Web 服务器(如 Nginx)、设置 SSL 证书等重复性劳动中解放出来。你通常只需要简单地推送代码(git push),平台就会自动完成构建和部署。
  • 差异点
    • Dokku 最轻量,极致模仿 Heroku 的体验,但功能相对单一,适合个人项目。
    • CapRover 在 Dokku 基础上增加了友好的 Web 界面更丰富的功能(如一键部署数据库),在易用性和灵活性之间取得了很好的平衡,是小团队和独立开发者的热门选择
    • Coolify 目标更宏大,更像一个一体化的自托管解决方案,支持多云管理强大的自动化,适合对控制权和部署灵活性要求更高的用户。
特性维度 Heroku (参照基准) Dokku CapRover Coolify
核心定位 全托管云 PaaS 轻量级、极简的个人版 Heroku 功能丰富的自托管 PaaS,平衡易用性与灵活性 开源自托管平台,追求全面控制与自动化,支持多云/混合云
托管方式 完全托管 自托管 (通常单服务器) 自托管 (支持单机与集群) 自托管 (支持单服务器、多服务器、Docker Swarm集群,计划支持Kubernetes)
开源协议 闭源 开源 开源 开源
部署方式 Git Push、CLI、容器 Git Push (主要方式) Git Push、Web界面、Dockerfile、Docker Compose Git Push (支持多种Git平台)、Dockerfile、Docker Compose
数据库支持 需通过付费插件市场集成 需手动部署或通过插件扩展 支持一键部署多种数据库 (MySQL, PostgreSQL, MongoDB, Redis等) 支持一键部署多种数据库 (MySQL, PostgreSQL, MongoDB, Redis等),并支持自动备份到S3兼容存储
Web界面 功能完善的Web控制台 无官方Web界面 (主要依赖CLI) 提供直观的Web控制台 提供功能强大的Web控制台
多语言/框架支持 广泛支持 支持多种语言 (通过Buildpack) 支持多种语言和框架 支持多种语言和框架
SSL证书 自动管理 可通过Let’s Encrypt插件获取 内置Let’s Encrypt,自动申请和续期 内置Let’s Encrypt,自动申请和续期
扩展性 垂直与水平扩展(需付费) 仅限于单机性能 支持Docker Swarm集群部署,可实现水平扩展 支持多服务器、Docker Swarm集群,未来计划支持Kubernetes
成本 昂贵(免费层已取消) 极低(仅服务器成本) 低(仅服务器成本) 低(仅服务器成本)
适用场景 初创公司(快速原型验证)、企业项目(追求稳定免运维)、开发者(学习) 个人开发者、小型项目、需要极致简单和低成本的情景 小团队、初创公司、需要Web界面和一定灵活性、希望平衡易用性和控制权的场景 注重数据主权和控制权、需要多云/混合云部署、有一定运维能力或愿意学习的团队和个人
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
flowchart TD
A[开始平台选择] --> B{是否需要完全托管的服务<br>且预算充足?};

B -- 是 --> C[选择 Heroku];

B -- 否 --> D{主要用户是?};

D --> E[个人开发者];
D --> F[小型团队];
D --> G[中大型团队或<br>追求全面控制];

E --> H{追求极致简单<br>且只需基础部署?};
H -- 是 --> I[选择 Dokku];
H -- 否 --> J[考虑 CapRover 或 Coolify];

F --> K[选择 CapRover];

G --> L[选择 Coolify];

C --> M[特点:免运维、易用、昂贵];
I --> N[特点:极简、低成本、CLI操作];
K --> O[特点:功能全面、有Web界面、性价比高];
L --> P[特点:高度可控、支持多云、功能强大];

选择哪个工具取决于你的具体需求:

  1. 想快速使用成熟的、优化好的开源软件(如 WordPress, GitLab, Jenkins):Websoft9 是更直接的选择,它帮你处理好了应用本身的所有复杂问题。

  2. 想部署自己写的代码项目(如一个 Node.js 后端或 Python Web 应用):

    追求极致简单和低成本:从 Dokku 开始。

    • 希望有Web界面更好的易用性,适合小团队协作:CapRover 是很棒的选择
    • 需要更强大的功能支持多云/混合云,且不介意稍高的学习成本:关注 Coolify
  3. 预算充足,追求极致省心和开箱即用,不想维护任何服务器Heroku 仍然是体验非常好的选择。

临时公共子域名

完全免费使用: 使用 npx localtunnel --port [你的端口]命令启动服务不需要支付任何费用。它会为你生成一个随机的公共子域名(如 https://your-random-subname.loca.lt)指向你本地运行的服务。

开源项目: localtunnel 的代码在 GitHub 上公开,遵循 MIT 许可证。这意味着你可以自由地使用、修改和分发它。

官方公共服务器: 默认情况下,命令连接的是由 localtunnel 项目维护者提供的公共中继服务器loca.lt域名)。这是他们提供的免费公共服务

临时性: 免费提供的链接是临时的。当:

  • 主动停止了运行 npx localtunnel的命令行进程。

  • 你的电脑断网或者本地服务进程停止

  • 长时间没有流量通过隧道(具体超时时间可能由服务器设定)。

  • 公共服务器维护或重启。

    链接就会失效。下次启动时,你会获得一个新的随机子域名

1
2
3
# 完整部署流程(仅需两行命令):
cd project/dist && npx http-server -p 3000 &
npx localtunnel --port 3000

Coolify

自托管是完全免费的

官网 官方文档

免费云服务器盘点

参考来源

  1. Google Cloud Platform (GCP)

    • 免费资源
      • 1个非抢占式 e2-micro实例(每月750小时,可连续运行)
      • 30GB HDD存储 + 5GB快照存储
      • 5GB Cloud Storage + 1GB网络出口流量
    • 条件:仅限特定区域(如 us-west1, us-central1),超出部分按量付费。
  2. Oracle Cloud

    • 免费资源
      • 2个AMD虚拟机(1/8 OCPU + 1GB内存)
      • 4个Arm核心 + 24GB内存(可拆分或单机使用)
      • 200GB块存储 + 10GB对象存储
    • 条件:实例闲置时可能被回收,10TB免费出口流量/月。
  3. Cloudflare Workers

    • 免费资源
      • 无服务器部署(10万次请求/日)
      • Workers KV(100k读请求/日)
      • R2对象存储(10GB/月)
    • 特点:全球边缘网络,无需管理服务器。
  4. Fly.io

    • 免费资源
      • 3台共享CPU虚拟机(256MB内存/台)
      • 3GB持久存储
      • 160GB出站流量/月
    • 适合:轻量级容器化应用。
  5. Koyeb

    • 免费资源
      • 2个vCPU + 2GB内存实例
      • 无限应用部署
    • 限制:需绑定信用卡,但免费额度不扣费。

开源自托管项目盘点

git服务器

特性维度 GitLab CE (社区版) Gitea Forgejo (Gitea 分支) Gogs OneDev GitBucket
核心定位 一体化、功能全面的 DevOps 平台 轻量级、快速、功能丰富的协作平台 由社区驱动,注重自由与隐私的协作平台 极致轻量、最简单的协作平台 All-in-One、内置 CI/CD 的 DevOps 平台 类 GitHub、易上手的协作平台
开源协议 MIT (社区版) MIT MIT MIT Apache-2.0 Apache-2.0
开发语言 Ruby on Rails Go Go Go Java (?) Scala
资源占用 高 (推荐 4核 CPU, 4GB+ 内存) 🚀 低 (约 1GB 内存) ✅ 低 (与 Gitea 相近) ✅ 极低 (树莓派可运行) ✅ 中等 较低 ✅
核心功能 仓库管理、Issue、PR、Wiki、CI/CD、容器仓库、监控 仓库管理、Issue、PR、Wiki、Actions、包注册表 仓库管理、Issue、PR、Wiki、Actions、包注册表 仓库管理、Issue、PR、Wiki (专注核心功能) 仓库管理、Issue看板、内置CI/CD、代码搜索 仓库管理、Issue、PR、Wiki、插件系统
CI/CD 方式 强大且内置 (.gitlab-ci.yml) 通过 Actions (兼容 GitHub) 通过 Actions (兼容 GitHub) 需外部集成 (如 Drone, Jenkins) 强大且内置 (图形化或 YAML 配置) 🚀 需外部集成 (如 Jenkins)
特色优势 功能最全面,开箱即用,覆盖 DevOps 全生命周期 社区活跃,功能与资源占用的最佳平衡,迭代快 强调数据主权、社区治理,避免商业公司控制 安装部署最简单,资源占用极低 智能(代码搜索导航)、深度集成CI/CD API 兼容性好,操作类似 GitHub
潜在缺点 资源消耗大,安装和维护相对复杂,高级功能需要企业版 (EE) 功能广度与深度不及 GitLab 生态与市场占有率暂不如 Gitea 功能相对较少,高级协作功能有限 基于 Java,资源占用相对 Go 语言项目稍高 开发活跃度和社区规模相对较小
最适合场景 中大型团队,需要开箱即用的完整 DevOps 解决方案,不介意资源消耗 中小团队及个人项目,追求功能、资源和社区的最佳平衡 注重数据隐私、合规和社区治理的团队 微型团队、个人项目及资源极度受限的环境 需要开箱即用CI/CD的中小团队,喜欢一体化 喜欢 GitHub 风格、寻求简单易用的团队

GitLab

🛠️ GitLab:一体化 DevOps 平台

GitLab 是一个基于 Git 的一体化 DevOps 平台,覆盖了从项目规划、源代码管理到 CI/CD、监控的整个软件开发生命周期。

  • 它能做什么

    • 代码仓库管理:提供强大的 Git 仓库管理功能,支持代码审查、分支保护、合并请求(Merge Requests)。
    • 内建 CI/CD:通过 .gitlab-ci.yml 配置文件无缝集成持续集成和交付,自动化构建、测试和部署流程。
    • 项目管理:提供问题跟踪(Issue Tracking)、Wiki 文档、看板(Kanban)等功能,帮助团队协同。
    • 多种部署方式:提供 SaaS 托管服务(gitlab.com),也支持私有化部署(社区版免费,企业版付费),适合对数据安全有高要求的企业。
  • 谁适合用

    • 寻求开箱即用、高度集成的 DevOps 解决方案的团队。
    • 希望减少在工具链整合上花费精力的开发者。

gitbucket

GitBucket 是一个由 Scala 驱动的 Git 网络平台,提供以下功能:

  • 简单安装
  • 直观的用户界面
  • 插件高度可扩展
  • 与 GitHub API 兼容

Gitea

特性 Gitea GitBucket
主要语言 Go Scala (JVM)
部署方式 单文件可执行,Docker,群辉套件支持 Java WAR 包 / Docker
资源占用 很低,轻量 较高,需要 JVM
界面风格 类 GitHub / GitLab 简洁 几乎 GitHub 原版风格
功能 Issues、PR、Wiki、CI/CD (Gitea Actions)、Web IDE Issues、PR、Wiki,可通过插件扩展 CI/CD、GitLFS 等
插件/扩展 内置功能多,插件较少 插件机制灵活,可扩展功能
社区活跃度 非常活跃,更新快 不算活跃,更新慢
适合场景 NAS、小团队、个人开发、轻量部署 Java 团队、内部 GitHub 风格、需要插件扩展
长期维护性 高,社区活跃,更新频繁 中,依赖少数维护者,更新较慢
易用性 非常简单,上手快 上手容易,但依赖 JVM 配置

似乎gitea更好

docker部署Gitea

使用docker部署非常简单

  1. 打开 Docker → 注册表

    • 搜索 gitea/gitea
    • 选择 latest 镜像下载
  2. 创建容器

    • 打开 容器 → 添加 → 使用镜像

    • 选择 gitea/gitea:latest

    • 配置基本设置:

      • 容器名称:gitea

      • 启动方式:开机自启

      • 网络:桥接模式(Bridge)

      • 端口映射

        • 容器端口 - NAS端口
        • 3000 - 3000
        • 22 - 2222
      • 卷映射

        nas中的data和git文件夹要自己新建

        • \data - /volume1/docker/gitea/data
        • \git - /volume1/docker/gitea/git
        • \ssl - /volume1/docker/certbot/etc/ 用于结合certbot配置gitea自身的ssl配置,需要将符号链接文件和原本文件的路径都配置上才行

    启动容器后就可以访问 http://NAS_IP:3000 ,会显示Gitea初始化界面

    初始化界面中推荐使用 SQLite(轻量级,直接用文件即可)

使用tail -f /var/log/gitea/gitea.log查看gitea日志,也可以使用docker logs gitea更方便(gitea是容器名)

权限注意事项

gitea中,私有库即使给了协助者可写权限,也不能fetch或clone,但是如果将人员加入到组织中,全部成员设置为管理员,却可以进行正常的全部读写操作

将其他项目迁移到gitea流程

  1. 删除原始凭证(可选)
  2. 迁移流程
删除原始凭证(可选)

界面操作如下

  • Windows系统

    1. 打开“控制面板” -> “用户账户” -> “凭据管理器”。
    2. 在“Windows凭据”或“普通凭据”中,找到与Coding相关的条目并删除
  • macOS系统

    1. 打开“钥匙串访问”应用。
    2. 搜索“Coding”或旧地址,找到并删除对应的“互联网密码”条目
  • Linux:

    使用下面命令行方式

使用命令行删除原仓库凭证如下

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
### Windows
## 下面是cmd
# 列出所有保存的凭据
cmdkey /list

# 删除Coding相关凭据(将<target>替换为列表中的标识)
cmdkey /delete:<target>

## 下面是powershell
# 查找Coding凭据
Get-ChildItem ~\AppData\Local\GitCredentialManager\credentialstore\

# 删除特定文件(将<file>替换为实际文件名)
Remove-Item ~\AppData\Local\GitCredentialManager\credentialstore\<file>

### MacOS
# 查找Coding相关凭据
security find-internet-password -s "coding.net"

# 删除凭据
security delete-internet-password -s "coding.net"

### Linux
# 编辑凭据文件
vim ~/.git-credentials
# 删除包含coding.net的行
#清除缓存(如果使用cache模式)
git credential-cache exit

### 清除后测试连接
git ls-remote https://coding.net/your/repo.git
#此时应弹出新的认证窗口,证明旧凭据已移除
迁移流程
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
#在原项目目录下移除原本的远程地址
git remote remove origin

#将的新仓库地址添加为新的远程地址(命名为 origin)
git remote add origin <你的Gitea新仓库URL>
# 例如:
# git remote add origin https://gitea.example.com/yourname/yourproject.git

#查看项目的远程仓库信息是否配置上了
git remote -v

#检查是否连接上新的远程仓库了
git fetch origin

#查看远程仓库详情,会显示远程分支
git remote show origin

#执行以下命令(如果没有新凭证会弹出浏览器要求登录),将本地所有分支、所有提交历史、所有标签全部推送到新的Gitea仓库
git push -u origin --all
git push -u origin --tags

#重建原本就已经存在的本地分支与远程仓库的追踪关系
git branch --set-upstream-to="origin/远程分支名" #使当前分支追踪指定的远程分支名

#之后就可以正常使用git与之交互了

gitea配置

gitea/data/gitea/conf/app.ini中配置gitea:

1
2
3
4
5
6
7
8
9
10
11
12
13
[server]
APP_DATA_PATH = /data/gitea
DOMAIN = 192.168.8.6
SSH_DOMAIN = 192.168.8.6
HTTP_PORT = 3000
#ROOT_URL = https://xxx.xxx.xxxx:xxxx #限制只能这个域名访问,不保留这一行就可以随意访问
DISABLE_SSH = true
SSH_PORT = 22
SSH_LISTEN_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = UewPxQMOLEF7dRIxrCfUKrbm3TxAptRjtUw0cFyRMeE
OFFLINE_MODE = true
REDIRECT_OTHER_PORT = true ; 强制重定向非HTTPS端口

内外网域名统一设置

Gitea链接内外网显示一致

Gitea 的配置文件通常位于安装目录下的 custom/conf/app.ini。使用文本编辑器(如 nanovim)打开它,找到 [server]部分,修改或添加以下两个参数

1
2
3
4
5
6
7
8
9
10
[server]
; 内部监听地址和端口,保持原样即可,这不影响外部访问
HTTP_ADDR = 192.168.8.6
HTTP_PORT = 3000

; !!!最重要的配置:设置Gitea的外部访问根URL !!!
ROOT_URL = https://your-domain.com/
; 请将 your-domain.com 替换为您实际对外访问的域名

; 其他配置...

设置好后检查所有页面上的链接:特别是仓库的“克隆”地址,应该都显示为 https://your-domain.com/username/repo.git,而不是内网 IP

内外网访问一致

目标: 让所有用户(无论内外网)都访问统一的、无端口的标准URL

下面的可以跳过(试错流程),直接看标准流程

通过设置路由器来为内网用户设置DNS解析,将域名在内网解析为ip地址+端口号

1
192.168.8.6:3000    gitea.your-company.com
  • 内网用户:通过路由器 DNS 或 hosts文件将 your-domain.com解析到 192.168.8.6

    1
    192.168.8.6    your-domain.com
  • 外网用户:通过公网 DNS 解析到穿透服务的公网 IP。

  • 这样所有用户都使用 https://your-domain.com访问,无需区分环境。

看起来很美好,但实际上内网DNS解析(或hosts文件)只能解析到IP,无法附带端口号

而外网dns解析却可以解析到IP+端口

因此还需要在内网搭建一个反向代理服务器(如Nginx),让它监听标准的80/443端口,然后将请求转发给Gitea的3000端口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
server {
listen 80;
# 如果配置了SSL证书,也监听443
# listen 443 ssl;
server_name your-domain.com; # 你的域名

# 核心配置:将所有请求转发给Gitea
location / {
proxy_pass http://localhost:3000; # 或者 http://192.168.8.6:3000
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

最终效果

访问来源 用户行为 流量路径
外网用户 访问 https://your-domain.com 域名 → 公网IP → (公网反向代理) → 穿透服务 → 内网Nginx(:80) → Gitea(:3000)
内网用户 访问 http://your-domain.com 域名 → 内网IP → 内网Nginx(:80) → Gitea(:3000)

但这样依旧内外网不统一,内网是http,而外网却是https,这对于git来说会视为两个仓库,因此还是有问题,应该参照标准流程来进行

内外网域名统一设置标准流程

生产环境的标准实践,可扩展的企业级架构

架构图:

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
graph LR
subgraph Clients["客户端"]
LAN_PC["内网客户端"]
WAN_User["外网用户"]
end

subgraph CloudflareNet["Cloudflare 网络"]
CF_DNS["Cloudflare DNS\n(域名解析)"]
CF_Edge["Cloudflare Edge\n(反向代理/CDN/隧道)"]
end

subgraph NAS["群晖 NAS\n(宿主机: 192.168.8.199)"]
subgraph Macvlan["Docker Macvlan 网络\n(192.168.8.0/24 独立IP)"]
Nginx["Nginx 反向代理\n192.168.8.201\n80/443"]
Gitea["Gitea 服务\n192.168.8.202:3000"]
Cloudflared["Cloudflared 隧道\n192.168.8.203"]
Certbot["Certbot\n一次性申请"]
CertbotRenew["Certbot Renew\n自动续期脚本"]
end
end

%% 内网访问
LAN_PC -->|直接访问 http://192.168.8.202:3000| Gitea
LAN_PC -->|访问 nas.jhh1.site → 局域网 DNS 解析到 192.168.8.201| Nginx
Nginx --> Gitea

%% 外网访问
WAN_User -->|https://nas.jhh1.site| CF_Edge
CF_DNS --> CF_Edge
CF_Edge --> Cloudflared
Cloudflared --> Nginx
Nginx --> Gitea

%% Certbot
Certbot -->|使用 dns-cloudflare 插件申请证书| CF_DNS
Certbot -->|挂载证书| Nginx
CertbotRenew -->|定时 renew 证书| Certbot
CertbotRenew -->|证书更新后 reload 服务| Nginx
CertbotRenew -->|可选: docker restart Gitea| Gitea

下面流程图:

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
flowchart TB
subgraph LAN["局域网 192.168.8.0/24"]
NAS["宿主机 NAS\n192.168.8.199\n(不能直连 macvlan)"]

subgraph Macvlan["Docker macvlan 网络 (nas-macvlan)"]
Nginx["nginx\n192.168.8.201\n80/443\n反向代理 + TLS 证书"]
Gitea["gitea\n192.168.8.202:3000\nGit 服务"]
Cloudflared["cloudflared\n192.168.8.203\n外网隧道"]
Certbot["certbot\n一次性申请证书"]
CertbotRenew["certbot-renew\n自动续期脚本 (定时任务)"]
end
end

%% 内网访问
ClientLAN["内网客户端"] -->|http://192.168.8.202:3000| Gitea
ClientLAN -->|https://nas.jjh1.site → 静态DNS: 192.168.8.201| Nginx
Nginx --> Gitea

%% 外网访问
ClientWAN["外网用户"] -->|https://nas.jjh1.site| CloudflareNet["Cloudflare 节点"]
CloudflareNet --> Cloudflared
Cloudflared --> Nginx
Nginx --> Gitea

%% Certbot
Certbot -->|dns-cloudflare 验证申请证书| CloudflareNet
Certbot -->|证书挂载| Nginx
CertbotRenew -->|周期执行 certbot renew| Certbot
CertbotRenew -->|检测到续期成功后 reload 服务| Nginx
CertbotRenew -->|可选: docker restart gitea| Gitea
image-20250923094526592
为内网环境部署HTTPS证书

使用Let’s Encrypt免费证书(需公网域名)

1
2
3
4
5
# 在内网服务器安装certbot
sudo apt install certbot

# 通过DNS验证申请证书(无需开放80/443端口)
certbot certonly --manual --preferred-challenges dns -d your-domain.com

按提示在域名DNS添加TXT记录验证所有权,证书将生成在 /etc/letsencrypt/live/your-domain.com/

需要配置自动续期
1
2
# 每月自动续期
sudo certbot renew --quiet --post-hook "systemctl reload nginx"
配置内网Nginx HTTPS反向代理
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
# /etc/nginx/sites-available/gitea
server {
listen 443 ssl;
server_name your-domain.com;

# 证书路径(选择方案A或B的路径)
ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
# 或自签名证书路径
# ssl_certificate /etc/ssl/certs/your-domain.crt;
# ssl_certificate_key /etc/ssl/private/your-domain.key;

# 强化的SSL配置
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

location / {
proxy_pass http://localhost:3000; # 保持HTTP转发
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

# HTTP强制跳转HTTPS
server {
listen 80;
server_name your-domain.com;
return 301 https://$host$request_uri;
}
群晖Nginx

群晖的nginx配置方式有所不同,因为其本身有内置nginx占用了常用端口

最好不要动群晖本身的nginx

群晖本身就提供了反向代理服务器的功能,操作位置为: 登录DSM -> 进入 “控制面板” -> “登录门户” -> “高级” 选项卡 -> “反向代理服务器”的功能

由于群晖本身内部的实现就基于Nginx实现的反向代理443接口,因此,我们自建nginx来监听443端口会有冲突,可以通过macvlan分配的ip地址中监听443端口,就可以监听443端口,并与群晖本身相独立,相关指令如下:

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
#新建macvlan网络
docker network create -d macvlan \
--subnet=192.168.8.0/24 \
--gateway=192.168.8.1 \
--ip-range=192.168.8.200/29 \
--aux-address="host=192.168.8.199" \
-o parent=eth1 \
nas-macvlan
#👆🏻这个nas-macvlan网络在NAS重启后会丢失📢📢📢 解决方案,参考下面的 macvlan网络持久化

docker network inspect nas-macvlan#查看新建的nas-macvlan网络

#启动位于macvlan网络中的nginx服务
docker run -d --name nginx-macvlan \
--network nas-macvlan --ip 192.168.8.201 \
-v /volume1/docker/nginx/conf:/etc/nginx/conf.d:ro \
-v /volume1/docker/certbot/etc:/ssl:ro \
nginx:stable

#启动位于macvlan网络中的gitea服务 这个gitea服务必须可以访问到certbot的证书的live和archive目录,这样才能证书可以后自动更新
docker run -d --name gitea-macvlan --network nas-macvlan --ip 192.168.8.202 --restart unless-stopped -p 3000:3000 --memory="4g" -e USER=git -e GITEA_CUSTOM=/data/gitea -v /volume1/docker/gitea/data:/data -v /volume1/docker/gitea/git:/git -v /volume1/docker/certbot/etc:/ssl gitea/gitea:latest

#验证容器状态
# 检查IP地址
docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' gitea-macvlan
# 检查重启策略
docker inspect --format '{{.HostConfig.RestartPolicy.Name}}' gitea-macvlan

#启动位于macvlan网络中的内网穿透服务(此处必须要手动指明dns,可能是因为无法使用宿主机的dns服务器的原因,不指明无法正常连接cloudflare服务器进行内网穿透)
docker run -d --name cloudflare-tunnel-macvlan -e TUNNEL_TOKEN=eyJhIjoiYWVlNmYyZDFlMWU2YTFjZTg3NTdl... --dns 192.168.8.1 --dns 223.5.5.5 --network nas-macvlan --ip 192.168.8.203 --restart unless-stopped --memory="4g" cloudflare/cloudflared:latest tunnel --no-autoupdate run

注意一下,👆🏻的容器通过ssh创建的,在群晖nas中的自动重新启动策略是always,即即使正常退出也重启,在界面显示自动重启没有勾选是因为策略不是always,而是unless-stopped,所以实际上不影响出问题自动重启的功能

更改配置的ip流程

1
2
3
4
5
6
7
8
# 1. 停止容器
docker stop gitea-macvlan
# 2. 断开当前网络
docker network disconnect nas-macvlan gitea-macvlan
# 3. 重新连接并指定IP
docker network connect --ip 192.168.8.202 nas-macvlan gitea-macvlan
# 4. 启动容器
docker start gitea-macvlan

检查项目如下

1
2
3
4
5
6
7
8
#检查配置项目是否已加载
sudo nginx -T | grep "gitea.conf"
#检查配置是否通过语法测试
sudo nginx -t
#应用配置更改
sudo systemctl reload nginx
#检查监听状态(不需要,因为与原本配置没有区别,原本配置也会监听tcp和tcp6)
sudo netstat -tuln | grep :443

macvlan网络持久化

设置开机后执行创建nas-macvlan的指令:

控制面板 - 任务计划 - 新增 - 触发的任务 - 用户定义的脚本 - 任务设置 - 用户定义的脚本 中填入:

1
2
3
4
/bin/sh -c 'count=0; until docker info >/dev/null 2>&1; do if [ $count -ge 30 ]; then echo "Docker未在预期时间内启动"; exit 1; fi; count=$((count+1)); sleep 1; done; if ! docker network inspect nas-macvlan >/dev/null 2>&1; then docker network create -d macvlan --subnet=192.168.8.0/24 --gateway=192.168.8.1 --ip-range=192.168.8.200/29 --aux-address="host=192.168.8.199" -o parent=eth1 nas-macvlan; fi'

#待反馈信息的版本
/bin/sh -c 'count=0; until docker info >/dev/null 2>&1; do if [ $count -ge 30 ]; then echo "错误:Docker未在30秒内启动"; exit 1; fi; count=$((count+1)); sleep 1; done; if docker network inspect nas-macvlan >/dev/null 2>&1; then echo "网络nas-macvlan已存在"; else echo "正在创建macvlan网络..."; docker network create -d macvlan --subnet=192.168.8.0/24 --gateway=192.168.8.1 --ip-range=192.168.8.200/29 --aux-address="host=192.168.8.199" -o parent=eth1 nas-macvlan && echo "网络创建成功" || echo "网络创建失败"; fi'

p.s. 在大多数系统的计划任务或脚本输入框中,我们需要将命令写为一行,用空格分隔各个参数

内网DNS解析
  • 在路由器或内网DNS服务器将 your-domain.com解析到内网反向代理服务器IP(如 192.168.8.201
  • 或每台设备修改hosts:
1
192.168.8.201 your-domain.com

gitea分支保护配置

Gitea 的分支保护设置对于企业规范而言,核心在于平衡代码质量、安全管控与团队协作效率

保护规则 功能描述 适用场景 企业规范建议
禁止强制推送 防止覆盖历史提交,确保提交历史可追溯 所有重要分支 对所有保护分支开启
要求Pull Request 强制代码审查流程,合并前必须通过PR 所有重要分支 对所有保护分支开启,根据分支重要性设置不同批准人数
要求状态检查 确保CI测试通过,代码质量达标 集成测试分支 配置必要的状态检查,如构建、测试、lint检查
要求签名提交 验证提交者身份,增强安全性和责任追溯 安全敏感项目 按需开启,通常用于核心库或高风险项目
限制推送权限 指定特定用户或团队拥有推送权限 核心代码分支 通常仅授权技术负责人或核心维护者

企业中的代码库通常需要保护以下关键分支:

  1. 生产分支(如 mainmaster: 这是最严格保护的分支,通常对应生产环境。
  2. 开发分支(如 develop: 集成分支,用于合并各个功能分支,稳定性次于主分支但仍需保护。
  3. 发布分支(如 release/*: 用于测试和准备发布的分支。
  4. 热修复分支(如 hotfix/*: 用于紧急修复生产环境问题。
生产分支

这是你的“黄金标准”,保护应该最为严格。

  • 要求 Pull Request: 必须开启。所有合并必须通过代码审查。
  • 所需批准数: 建议至少 2 人。重要修改应获得多位核心成员的认可
  • 禁止强制推送: 必须开启。防止历史提交被覆盖。
  • 要求状态检查: 必须开启。必须通过所有CI流程(如编译、单元测试、集成测试、安全扫描等)才能合并。
  • 要求签名提交: 按需开启。对于安全要求极高的项目,可以要求所有提交必须经过GPG签名验证。
  • 限制推送权限: 强烈建议。通常只授权给团队负责人或少数核心成员,其他开发者通过PR协作。
开发分支

开发分支是活动最频繁的集成分支,需在质量和效率间权衡。

  • 要求 Pull Request: 必须开启。功能分支合并到develop前必须经过审查。
  • 所需批准数: 至少 1 人。通常由项目核心开发人员或团队负责人批准即可
  • 禁止强制推送: 必须开启
  • 要求状态检查: 必须开启。至少需要通过基础CI构建和测试。
  • 限制推送权限: 通常不开启,允许所有开发者创建指向develop的PR。但可根据团队成熟度调整。
分支命名规范

清晰的分支命名能极大提升管理效率。推荐以下规范:

  • 功能分支: feat/简短功能描述,例如 feat/user-authentication
  • 修复分支: fix/问题简要描述,例如 fix/login-validation
  • 文档分支: docs/更新内容描述,例如 docs/api-reference
  • 重构分支: refactor/修改模块描述,例如 refactor/database-layer
  • 发布分支: release/版本号,例如 release/v1.2.0
  • 热修复分支: hotfix/紧急问题描述,例如 hotfix/critical-security-patch
实际保护配置

certbot

比acme更好用

Certbot是一个由Electronic Frontier Foundation (EFF)赞助的开源工具,用于自动化管理和部署SSL/TLS证书。SSL/TLS证书是用于加密网站与用户之间传输的数据的一种安全协议。Certbot的主要目的是使网站管理员能够轻松获取、部署和更新这些证书,以确保网站的安全性

github链接

Let’s Encrypt 采用 ACME 协议来自动化验证你是否真正控制着要申请证书的域名。上述流程中最常见的两种验证方式是:

验证方式 是否需要公网IP 是否需要开放端口 配合内网穿透的可行性 推荐度
HTTP-01 间接需要(穿透服务器有即可) 需要开80端口 可行但麻烦,受穿透服务限制 ⭐⭐
DNS-01 完全不需要 不需要 非常可行且简单,是最佳方案 ⭐⭐⭐⭐⭐
  • **HTTP-01 挑战 (HTTP-01 Challenge)**:这是最常用的方式。Certbot 会在你的服务器上(通常是80端口)临时生成一个特定的验证文件,Let’s Encrypt 的服务器会尝试通过公网访问这个文件(例如 http://你的域名/.well-known/acme-challenge/某个令牌)。如果你的服务器没有公网IP,或者80端口被防火墙阻挡,外界就无法访问到这个文件,验证自然会失败
  • DNS-01 挑战 (DNS-01 Challenge):这种方式下,Certbot 会提供一个特定的文本(TXT)记录,你需要手动或通过API自动将其添加到你的域名DNS配置中。Let’s Encrypt 随后会通过查询DNS来验证。这种方式不要求你的服务器有公网IP或开放端口,但需要你能够操作域名的DNS记录。这对于无法开放端口的服务器或申请通配符证书(*.\你的域名.com)非常有用。
    • 无论服务器在哪里(有无公网IP),运行 certbot certonly --manual --preferred-challenges dns
    • Certbot 会给你提供一个随机生成的TXT记录值。
    • 手动(或通过API脚本自动) 到你的域名DNS管理后台(如阿里云、Cloudflare等),为你的域名添加这条TXT记录(例如 _acme-challenge.example.com. IN TXT "随机值")。
    • 确认记录添加后,回车继续。
    • Let’s Encrypt 会去查询域名的DNS记录,如果找到并匹配成功,就颁发证书。
    • 成功后,别忘了从DNS中删除那条TXT记录(虽然不删也没大问题,但保持整洁为好)

如果服务器位于网络地址转换(NAT) 后面,或者由云服务提供商托管,但提供商集成了 Let’s Encrypt(例如某些云平台的负载均衡器或托管服务),那么你可能不需要直接在你的服务器实例上配置公网IP。证书的申请和验证过程可以由云平台在其基础设施层面代为完成

为确保顺利申请证书,你的服务器和环境需满足以下条件

  • 公网IP与开放端口:服务器需具备公网IP,并确保所需验证端口(HTTP-01验证需开放80端口)未被防火墙或云服务商的安全组阻挡。
  • 域名与DNS解析:你必须拥有一个已注册的域名,并已将该域名(如 example.comwww.example.com)的DNS记录(通常是A记录或CNAME记录)正确解析到你的服务器公网IP。
  • 服务器环境:服务器需安装支持的操作系统(如Linux发行版),并具备命令行sudo权限。对于HTTP-01验证,需提前安装并运行Web服务器软件(如Nginx或Apache);对于DNS-01验证,需具备域名DNS管理权限或API访问密钥。
  • Certbot工具:在服务器上安装Certbot客户端。官方推荐通过Snap包安装,以获得最新版本和完整功能

安装流程

1
2
3
4
5
6
#Debian/Ubuntu安装certbot
apt update -y && apt install -y certbot
#CentOS安装certbot
yum -y update && yum -y install certbot
#Alpine Linux安装certbot
apk update && apk add certbot

首先确保80和443端口未被占用

1
2
3
4
curl -s ipv4.ip.sb
certbot certonly --standalone -d $yuming --email your@email.com --agree-tos --no-eff-ernewal
#证书存放目录
ls /etc/letsencrypt/live/

docker方案部署流程

docker方式参考下面

步骤 操作内容 关键信息/命令
1. 选择验证方式 采用 DNS-01 验证 无需公网IP,需域名服务商API支持。
2. 准备域名API凭证 从您的域名服务商(如Cloudflare)获取API密钥。 例如Cloudflare的 Global API KeyToken
3. 创建存储目录 在群晖上创建目录,用于持久化Certbot配置和证书。 mkdir -p /docker/certbot/{etc,lib,log}
4. 首次申请证书 运行Certbot容器,使用DNS插件和API凭证申请证书。
5. 配置自动续期 创建续期脚本,并添加群晖计划任务。

获取cloudflare api token

cloudflare获取api token链接

这个api token必须要有修改dns记录的权限

image-20250915153328475 image-20250915153455139

配置令牌权限和范围

  • 权限(Permissions):确保权限范围是 Zone - DNS - Edit。这赋予了Token修改DNS记录的权限。
  • 资源范围(Resource scope):选择 “包括” (Include) - “特定区域” (Specific zone),然后在下拉列表中选择你托管的那个域名。这样可以将Token的权限限制在仅管理该域名的DNS记录,遵循最小权限原则,更安全。

完成配置后,点击 “继续到摘要” (Continue to summary)检查设置,确认无误后点击 “创建令牌” (Create Token)

下载运行镜像申请证书

镜像名称 描述
certbot/certbot 基础镜像,只包含核心的 certbot 功能,不包含任何 DNS 插件
certbot/dns-cloudflare 专用镜像,在基础镜像上额外预装了 certbot-dns-cloudflare插件,支持 --dns-cloudflare参数。

由于没有公网ip,所以需要采用 DNS-01 验证方式申请证书,因此需要的镜像是certbot/dns-cloudflare

新建需要映射的文件夹和文件

  • 点击 添加文件夹
    • 文件夹:选择您之前创建的 /docker/certbot/etc
    • 挂载路径:输入 /etc/letsencrypt
  • 再次点击 添加文件夹
    • 文件夹:选择 /docker/certbot/lib
    • 挂载路径:输入 /var/lib/letsencrypt
  • 再次点击 添加文件夹
    • 文件夹:选择 /docker/certbot/logs
    • 挂载路径:输入 /var/log/letsencrypt
  • 点击添加文件(这是一个重要技巧!)
    • 文件:选择您创建的 cloudflare.ini凭证文件。
    • 挂载路径:输入 /etc/letsencrypt/cloudflare.ini:ro。最后的 :ro代表只读,更安全(群晖中不写:ro,而是手动选择只读)

cloudflare.ini中内容如下:

1
2
3
4
5
6
# 如果您使用的是 Global API Key(不推荐,但可用):
dns_cloudflare_email = your_login_email@example.com
dns_cloudflare_api_key = your_global_api_key

# 或者,如果您使用的是 API Token(推荐,更安全):
dns_cloudflare_api_token = your_api_token_here(这套方案采用这种方式,这里填入上一个流程获取到的cloudflare的api token)

👆🏻要么使用 dns_cloudflare_email+ dns_cloudflare_api_key组合,要么单独使用 dns_cloudflare_api_token绝不能同时出现这三行

运行镜像的配置如下:

image-20250917173621893
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#写成指令大概如下:
docker run --rm \
--name certbot-ApplyOnce \
-p 443:443/tcp \
-p 80:80/tcp \
-v /docker/certbot/etc:/etc/letsencrypt \
-v /docker/certbot/lib:/var/lib/letsencrypt \
-v /docker/certbot/logs:/var/log/letsencrypt \
-v /docker/certbot/cloudflare.ini:/etc/letsencrypt/cloudflare.ini:ro \
-e PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin... \
-e LANG=C.UTF-8 \
-e GPG_KEY=7169605F62C751356D054A26A821E680... \
-e PYTHON_VERSION=3.12.10 \
-e PYTHON_SHA256=07ab697474595e06f06647417d3c7fa97d... \
-e EMAIL=xxxxxxxxxx@qq.com \
--memory="4g" \
certbot/dns-cloudflare \
certonly --non-interactive --agree-tos --email xxxxxxxxxx@qq.com \
--dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 30 \
-d nas.jhh1.site -d *.nas.jhh1.site

运行后可以在日志/docker/certbot/logs/...中观察到如下内容表示成功,虽然docker消息会显示意外中断

1
2
3
4
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/nas.xxxx.site/fullchain.pem
Key is saved at: /etc/letsencrypt/live/nas.xxxx.site/privkey.pem
This certificate expires on 2025-12-16.

生成的证书在此处: ls -la /volume1/docker/certbot/etc/archive/nas.xxxx.site/(不需要勾选显示隐藏就能看见)

/volume1/docker/certbot/etc/live/nas.xxxx.site/里,您会找到以下几个符号链接文件(在群晖中默认被隐藏,在ssh中可以被看到),他们始终指向archive中的真实证书文件(真实证书文件名最后会带数字编号,更新后得以标识证书)

  • fullchain.pem- 证书链文件 (这是您需要在Web服务器中配置的证书文件)
  • privkey.pem- 私钥文件 (这是您需要在Web服务器中配置的密钥文件)
  • cert.pem- 证书文件
  • chain.pem- 中间证书文件

自动续期

1
2
3
4
5
6
7
8
9
flowchart TD
A[创建自动续期脚本] --> B[赋予脚本执行权限]
B --> C[登录群晖DSM后台]
C --> D[打开控制面板 → 任务计划器]
D --> E[创建新计划任务 → 用户定义的脚本]
E --> F[设置任务执行计划:<br>例如:每月1号和15号 凌晨3点]
F --> G[在任务设置中粘贴脚本路径]
G --> H[保存并运行任务测试]
H --> I[检查证书目录<br>确认续期成功]
  1. 创建自动续期脚本

    建议放在一个固定的、有权限的目录,例如 /docker/certbot/目录下,方便管理

    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
    #!/bin/bash

    # 记录当前证书的过期时间或修改时间
    CERT_FILE="/volume1/docker/certbot/etc/live/nas.jhh1.site/fullchain.pem"
    BEFORE_RENEW=$(stat -c %Y "$CERT_FILE" 2>/dev/null || echo 0)

    # 记录日志,方便排查
    echo "=============================="
    echo "$(date +"%Y-%m-%d %H:%M:%S"): 开始执行证书续期检查"

    # 运行Certbot续期命令
    # 使用 --quiet 参数让输出更简洁,只打印错误或真正续期的信息
    docker run --rm --name certbot-renew \
    -v /volume1/docker/certbot/etc:/etc/letsencrypt \
    -v /volume1/docker/certbot/lib:/var/lib/letsencrypt \
    -v /volume1/docker/certbot/logs:/var/log/letsencrypt \
    -v /volume1/docker/certbot/cloudflare.ini:/etc/letsencrypt/cloudflare.ini:ro \
    certbot/dns-cloudflare renew --non-interactive --quiet

    # 检查状态并判断是否真的续期了
    if [ $? -eq 0 ]; then #检查 Docker 容器的退出状态码 0:表示 Certbot 命令执行成功 非 0:表示执行过程中出现错误
    AFTER_RENEW=$(stat -c %Y "$CERT_FILE")
    if [ "$AFTER_RENEW" -gt "$BEFORE_RENEW" ]; then
    echo "$(date): 证书已成功续期,新证书已生效。"
    #配置续期后自动重新加载服务
    # 重启群晖的Web Station(Nginx)以使新证书生效
    #synosystemctl restart nginx

    # 或者,如果您是单独为Gitea配置的反向代理,并且证书是独立使用的,可能需要重启Gitea容器
    docker restart your_gitea_container_name #名字参考部署gitea时候的容器名
    else
    echo "$(date): 证书检查完成,无需续期(证书尚未到期)。"
    fi
    else
    echo "$(date): 证书续期过程中出现错误。"
    fi

    赋予脚本执行可读可写权限: chmod +wrx ./renew_cert.sh

    Certbot 的 renew命令有以下特点:

    • 如果证书未到期(距离过期时间超过30天),它会安静退出(状态码0),不做任何操作
    • 如果证书即将到期(30天内),它会执行续期并退出(状态码0)
    • 只有遇到错误时才会返回非零状态码
  2. 配置群晖计划任务

    • 登录 DSM,打开 控制面板 > 任务计划器
    • 点击 新增 > 计划的任务 > 用户定义的脚本
    • 常规 选项卡中:
      • 任务:填写一个描述性名称,例如 Certbot 证书自动续期
      • 用户账号:选择 root。这一点非常重要,因为普通用户可能没有足够的权限执行 Docker 命令。
    • 计划 选项卡中:
      • 设置执行频率。建议每月运行 1-2 次(例如,每月 1 号和 15 号的凌晨 3 点)。Let‘s Encrypt 证书会在到期前 30 天才允许续期,所以不需要每天检查。
    • 任务设置 选项卡中:
      • 用户定义的脚本 框中,输入/bin/bash /volume1/docker/certbot/renew_cert.sh
  3. 验证自动续期是否工作

    1. 手动测试:在“任务计划器”中,找到您创建的任务,选中它并点击 运行。然后检查脚本输出的日志或去证书目录查看时间戳。
    2. 查看日志:脚本的执行日志会输出到您指定的位置。您也可以运行 docker logs certbot-renew(在任务运行时)来查看实时输出。
    3. 检查证书:续期成功后,/etc/letsencrypt/archive/您的域名/目录下会生成新的证书文件(如 cert2.pem, privkey2.pem),而 live目录下的符号链接会更新指向这些新文件。

使用证书

特性 方案A: 群晖DSM管理证书 方案B: Gitea容器管理证书
配置位置 群晖 控制面板 -> 安全性 -> 证书 Gitea 容器内部的 app.ini 配置文件
自动续期 无法自动续期,需手动下载新证书并重新导入 简单。指向Certbot的Live目录,续期后自动生效
管理方式 图形化界面,简单直观 需修改配置文件
影响范围 影响整个DSM系统及所有相关服务 仅影响Gitea一个服务
冲突风险 。两者是完全独立的
群晖中使用证书

控制面板 - 安全性 - 证书 - 新增 - 新增新证书 - 导入证书 - 导入私钥,证书,中间证书 - 确定

控制面板 - 安全性 - 证书 - 设置 - 将域名设置到对应的证书

为Gitea本身配置SSL证书

Gitea是直接安装在群晖Docker中的,您可以跳过群晖DSM的证书设置,直接为Gitea容器配置SSL

p.s. 必须是 Gitea Docker 容器内部 能访问到的路径,这个路径的设置要参考gitea容器本身部署的时候的文件映射

1
2
3
4
[server]
ROOT_URL = https://nas.xxxx.site
CERT_FILE = /ssl/live/nas.xxxx.site/fullchain.pem
KEY_FILE = /ssl/live/nas.xxxx.site/privkey.pem

因为gitea的文件夹映射为:/ssl --> /volume1/docker/certbot/etc/

所以 /ssl/live/nas.xxxx.site/privkey.pem ---> /volume1/docker/certbot/etc/live/nas.xxxx.site/privkey.pem

重启Gitea容器。这样Gitea服务本身就直接提供了HTTPS

Jenkins

🔄 Jenkins:灵活可扩展的自动化引擎

Jenkins 是一个开源的、高度可扩展的持续集成和持续交付 (CI/CD) 工具。它的核心价值在于自动化软件的构建、测试和部署流程。

  • 它能做什么

    • 自动化流水线:通过丰富的插件生态系统(超1800个插件),支持与各种工具(如 Git、Maven、Docker、Kubernetes 等)集成,实现高度定制化的构建、测试、部署自动化。
    • 流水线即代码:使用 Jenkinsfile(基于 Groovy)定义流水线,实现复杂流程的版本化和可重复性。
    • 分布式构建:支持主从(Master-Agent)架构,可在多台机器上分布式执行构建任务,提升效率。
  • 谁适合用

    • 需要高度定制化和控制其 CI/CD 流水线的团队。
    • 技术栈多样,需要与大量第三方工具集成的场景。
    • 需要注意的是,Jenkins 通常需要更多的维护和配置工作。

私有云平台

Nextcloud

☁️ Nextcloud:开源私有云平台

Nextcloud 是一个开源的文件同步与共享平台,允许你搭建属于自己的私有云服务。

  • 它能做什么

    • 文件同步与共享:类似 Dropbox 或 Google Drive,你可以在不同设备间同步文件,并与他人安全共享。
    • 丰富的应用生态:通过安装应用,可以扩展出日历、联系人管理、在线文档编辑(Collabora Online)、视频会议(Talk)、任务管理等众多功能,成为一个完整的协作平台。
    • 数据掌控与隐私:所有数据都存储在你自己的服务器上,无需担心第三方云服务的隐私问题。
  • 谁适合用

    • 对数据隐私和安全非常重视的个人、团队或企业。
    • 希望替代公有云服务(如百度网盘、Google Drive),完全掌控自己数据的用户。

copyparty

开箱即用的文件服务器

copyparty 最大的特色就是简单粗暴。整个服务器就是一个 Python 文件,不需要安装任何依赖,双击运行就能启动。

整个安装过程不到 30 秒,服务器启动后会自动监听 3923 端口,用浏览器打开 localhost:3923 就能看到熟悉的文件管理界面。

虽然在界面美观度和插件生态方面还比不上 NextCloud,但它的轻量简单易上手特性,让更多人能上手体验。

如果你正在寻找一个 “开箱即用” 的文件服务器解决方案,不妨试试这个只有一个文件的小工具。

GitHub 项目地址

域名相关

个人域名购买

费用范围:首年 50元 - 200元人民币

  • .com.net 等国际域名:约 60-120元/年(首年常有优惠)。

  • .cn 等国内域名:约 30-100元/年(需实名认证)。

  • 其他小众后缀(如 .xyz.site):可能低至 10元/年(促销时)。

  • 备注:续费价格通常高于首年价,需留意服务商续费政策。

热门后缀: com,cn,net 利于SEO收录和排名

冷门后缀: top,vip,love,icu 不利于SEO优化,但价格便宜

无限邮域名也可以使用

域名商

域名购买商 fxmjyxgs.net fengxingmuju.cn
Namesilo 15.95美金一年
namecheap 12.98美金一年
daomain 14.99美金一年
godaddy 1.04元首年
阿里云 10年 386
腾讯云
spaceship

spaceship 的.top 很便宜

spaceship 的 10年 6位数+ xyz后缀域名50元

阿里云买这个域名↑,10年一共67

将购买的域名连接到Cloudflare

主要是为了利用cloudflare提供的CDN加速,安全防护(如DDOS防御),免费SSL证书等服务

通常有两种主要方式

  • 仅使用 Cloudflare 的 DNS 托管(更简单、可逆):只将域名的 DNS 解析服务器改为 Cloudflare 的,域名注册商仍是 GoDaddy
  • 将域名完全转移到 Cloudflare(更彻底):将域名的管理权从 GoDaddy 转移到 Cloudflare 注册商

对于大多数用户,推荐第一种方式(DNS 托管),因为它更简单快捷,且可逆

  1. 在 Cloudflare 账户主页 - 域 中添加域名
  • 输入从 GoDaddy 购买的完整域名(例如 yourdomain.com),然后点击”继续”
  • Cloudflare 会自动扫描该域名现有的 DNS 记录。请仔细核对,确保所有必要的记录(如 A 记录、CNAME 记录、MX 记录等)都已正确导入。也可以在此手动添加或修改记录
  • 选择套餐,免费计划通常足够个人使用。点击”继续”
  1. 更改 GoDaddy 的名称服务器(NameServers)
  • 这是最关键的一步。完成上一步后,Cloudflare 会提供两个(或更多)特定的名称服务器地址(通常类似于 lara.ns.cloudflare.com 和 vern.ns.cloudflare.com)。请完整准确地复制这些地址
  • 登录GoDaddy 账户,进入域名管理后台
  • 找到要管理的域名,点击”管理 DNS”或类似选项
  • 找到”名称服务器”(NameServers)设置部分
  • 选择”使用自定义名称服务器”(或类似选项),将 GoDaddy 默认的名称服务器删除,替换为 Cloudflare 提供的那两个地址
  • 保存更改
  1. 在 Cloudflare 完成并检查激活
  • 回到 Cloudflare 界面,点击”完成”或类似按钮
  • Cloudflare 会开始检查名称服务器更改是否生效。此过程最多需要 24-48 小时(DNS 传播时间),但通常几分钟到几小时内就会完成
  • 完成后,会收到 Cloudflare 的确认邮件,在 Cloudflare 仪表板上也能看到域名状态变为”有效”

关闭 DNSSEC:如果您之前在 GoDaddy 启用了 DNSSEC必须先将其关闭,否则在 Cloudflare 可能导致解析问题。您可以在 Cloudflare 添加域名成功后再重新配置 DNSSEC

SSL证书购买

免费证书(推荐个人使用):

  • Let’s Encrypt:完全免费,支持自动续期,适用于企业官网,个人博客和小型网站。

    • 证书有效期短:Let’s Encrypt证书仅90天有效(行业主流商业证书为1年),需定期续订。
    • 自动续订机制:可通过工具(如Certbot)实现自动化续期,几乎无需人工干预。
    特性 自签名证书 Let‘s Encrypt 证书
    颁发机构 自己给自己签发 Let’s Encrypt (一个受全球信任的非营利证书颁发机构CA)
    浏览器信任 不信任,会显示“不安全”警告 完全信任,显示绿色锁头或安全标识
    安全性 加密强度可以很高,但身份无法被第三方验证 加密强度高,且身份由可信的第三方(Let’s Encrypt)验证
    成本 免费 免费
    获取难度 自己一行命令生成,非常简单 需要验证您对域名的所有权(自动化的过程)
    有效期 可以任意设置,例如10年 很短(90天),强制要求自动化续期以提升安全
  • 服务商赠送:部分云平台(如阿里云、腾讯云)购买服务器时赠送免费SSL证书。

  • 付费证书:

    • DV证书(域名验证型):50-500元/年(适合个人)。
    • OV/EV证书(企业验证型):500-2000元/年(企业用途更多)。
  • 备注:个人网站建议优先选择免费证书。

  • DV证书(Domain Validation)
    ✅ ​适合:个人博客、小型网站、测试环境。
    ❌ ​不适用:涉及用户隐私、支付等敏感信息的网站。

  • OV证书(Organization Validation)
    ✅ ​适合:企业官网、电商平台、API服务。
    ❌ ​不适用:需要最高信任度的金融、政务场景。

  • EV证书(Extended Validation)
    ✅ ​适合:银行、支付平台、政府机构、大型企业官网。
    ❌ ​不适用:个人或非敏感业务(成本过高)

    EV证书的“绿色地址栏”在部分新浏览器(如Chrome 92+)中不再显示,但企业名称仍会展示在证书详情页

网站备案(ICP备案)

  • 费用免费(官方流程不收费)。

    代理服务费

    (可选):

    • 如果自行备案:0元(需自行准备材料并提交)。
    • 通过服务商代理备案:约 300-1000元(协助资料审核和流程处理)。
  • 耗时:约 10-20 个工作日(需配合管局审核)。

费用总结

  • 最低成本

    (自行操作):

    • 域名(50元) + 免费SSL(0元) + 备案(0元) ≈ 50元
  • 常规成本

    (含代理服务):

    • 域名(100元) + 免费SSL(0元) + 备案代理(500元) ≈ 600元
  • 高端配置

    (付费证书+代理服务):

    • 域名(200元) + 付费SSL(2000元) + 备案代理(500元) ≈ 2700元

公网ip申请

难度评估

  • 中国移动: ipv4很难申请,拉专线
  • 中国联通: 一般般,打电话给客服
  • 中国电信: 一个月20元,就可以申请到公网ip

话术: 今天打开监控,发现我们家的那个公网ipv4地址怎么没有了?之前装监控的时候有公网呀

结果: 广东电信实测失败…

公网ip解决方案

方案 成本 速度 难度 适用场景
IPv6 + DDNS 免费 快(直连) 中等 外部设备支持 IPv6
FRP 自建穿透 高频访问、需自定义端口
Zerotier 组网 免费 中等 多设备互联、低频率访问
花生壳商业服务 低-高 中等 临时测试、小白用户

解决ipv4访问ipv6服务器的问题解决方案

方案 成本 实现难度 适用场景
双栈部署 企业有公网 IPv4/IPv6 资源
CDN 协议转换 快速兼容,适合大多数企业
NAT64/DNS64 实验性场景,依赖运营商支持
IPv4 回退服务 对兼容性要求极高的关键业务

通过 CDN/反向代理实现协议转换

  • 原理:使用支持 IPv4/IPv6 双栈的 CDN 或反向代理服务,将 IPv4 流量自动转换为 IPv6 请求。

  • 推荐工具:Cloudflare(免费版支持):

    1. 将域名 DNS 解析托管到 Cloudflare。
    2. 在 Cloudflare 中开启 IPv6 兼容性DNS 代理
    3. Cloudflare 边缘节点会同时响应 IPv4/IPv6 请求,并将流量转发到公司的 IPv6 源站。
    • Nginx 反向代理(自建):nginx

      1
      2
      3
      4
      5
      6
      7
      8
      9
      # 在具备双栈的代理服务器上配置
      server {
      listen 80; # IPv4
      listen [::]:80; # IPv6
      server_name example.com;
      location / {
      proxy_pass http://[公司IPv6源站]:80;
      }
      }

    优点:

    • 无需公司源站支持 IPv4。
    • CDN 可缓存内容,提升访问速度。
  • 缺点:依赖第三方服务(如 Cloudflare)或自建代理服务器。

替代方案

  • 若只需临时、低速访问DSM管理Docker:可使用QuickConnect,它适合临时从外网登录DSM后台来管理容器启停和设置
  • 若有公网IP且追求最佳速度:可考虑端口转发。但务必注意网络安全风险,仅映射必要端口,并使用强密码和非标端口号
  • 若要暴露Web服务(如博客、导航页)Cloudflare Tunnel是首选。它无需公网IP,能自动提供HTTPS证书,安全性较好。
  • 若需访问所有协议的服务(如SSH、远程桌面、私有数据库)Tailscale等零信任网络方案是最佳选择。它能在所有设备间建立加密通道,像在局域网内一样安全访问所有服务,配置也不复杂

IPv6

可以用IPv6开+cloudflare cdn代理支持IPv4,待后续了解

不同ipv6地址特征

地址类型 前缀范围(十六进制) 用途 是否可全球路由
全球单播地址 (公网IPv6) 2000::/3(如 2001:, 2408:, 2409:, 240e:) 全球唯一,可直接访问互联网
唯一本地地址 (ULA, 内网IPv6) fc00::/7(通常 fd00::/8) 类似IPv4的私有地址,限本地网络使用
链路本地地址 fe80::/10 仅在同一物理链路有效(如局域网通信)

查看是否支持ipv6

  • Windows系统:打开命令提示符(CMD)或 PowerShell,输入 ipconfig,查看以 “IPv6 地址” 标识的条目。
  • Linux/macOS系统:打开终端,输入 ip -6 addr showifconfig,查看网卡信息。

在输出信息中,寻找那些不以 fe80fd开头的IPv6地址。如果你看到的IPv6地址是以 2001:2408:2409:240e:等开头的(属于 2000::/3范围),这很可能就是一个公网IPv6地址

使用在线工具测试

通过访问一些支持IPv6的测试网站,可以快速验证你的公网IPv6连通性和显示的地址。

  • 访问 test-ipv6.comipv6-test.com
  • 网站会自动检测你的IPv6连接状态。如果页面显示 “IPv6 访问优先”、给出了一个完整的IPv6地址(并且这个地址与你之前查看到的、以2xxx3xxx开头的地址一致),或者测试分数很高(如10/10),就说明你已成功连接到IPv6互联网,并且该地址是公网地址

路由器开启ipv6支持

以tplink企业路由器为例

  1. 首先需要在基本设置 - LAN设置中启用ipv6

    image-20250915114858281
  2. 然后需要在基本设置 - LAN设置 - SLAAC中启用服务

    image-20250915114935926

当开启SLAAC后,DHCPv6服务的开关变为不可操作的状态,这并非故障,而是TP-LINK路由器的一种智能设计。它强制用户采用业界推荐的 “SLAAC + 无状态DHCPv6” 的协同工作模式

功能 负责内容 当前状态
SLAAC 分配IPv6地址(解决“我是谁”) 已开启,工作正常
DHCPv6 分配DNS等信息(解决“如何找到别人”) 被SLAAC联动开启,无需单独操作

然后就可以在基本设置 - LAN设置 - IPV6客户端列表中查看ipv6的地址分配情况

群晖nas开启ipv6

控制面板 - 网络 - 网络界面 - 找到正在使用的局域网,右键 - 编辑 - IPv6 - IPv6设置改为自动 - 确定

解决动态变化的IPv6地址

IPv6地址是动态变化的

  • 虽然运营上粉皮儿的IPv6前缀通常比较固定,但设备通过SLAAC生成的地址后缀可能会变(尤其是隐私拓展地址)
  • 解决方案: 为需要访问的设备(如NAS)配置静态IPv6地址

内网穿透方案

参考内网穿透

内网穿透

服务名称 免费带宽 免费流量 免费隧道数 实名认证 支持协议 特点与注意事项
cpolar 1Mbps 不限流量 4条 TCP、HTTP、HTTPS 流量不限是显著优势,带宽适中,隧道数较多,每 24 小时会变化的公网地址(付费解决)
Sakura Frp 10Mbps 每月5GB 2条 TCP、UDP、HTTP、HTTPS 免费带宽较大,通过每日签到可获取额外免费流量
NATAPP 1Mbps 不限流量 2条 TCP、HTTP、HTTPS 不限流量,但免费版域名或端口可能不定时强制更换
花生壳 1Mbps 每月1GB 2条 TCP、HTTP、HTTPS 老牌服务,需6元认证费,免费版流量较少
飞鸽 0.5Mbps 不限流量 1条 TCP、HTTP、UDP 带宽较低,解压即用无需安装,适合临时轻量级需求

备选方案:自建内网穿透:如果你拥有一台具有公网IP的云服务器(国内或海外均可),可以考虑使用 FRPOpenVPN 等开源工具自建内网穿透服务。这种方式前期投入较高(需要服务器成本),但长期来看更灵活、可控,且无商业服务的额度限制

对于绝大多数个人用户——无论是远程访问家庭NAS、调试开发中的Web项目,还是运行一个小型博客——Cloudflare Tunnel 免费版提供的带宽和无限流量是完全足够且非常划算的

cloudflare方案

cloudflare的域名安全配置:

1️⃣进入 SSL/TLS 设置

  1. 进入域名管理,左侧菜单栏点击 SSL/TLS
  2. 默认进入 概述 页面,找到 SSL/TLS 加密模式
  3. 点击 配置 进入详细设置。

2️⃣ 选择合适的 SSL/TLS 模式

  1. 默认 SSL/TLS 模式为 “灵活”

    ,需要改成:

    • 完全(Full):适用于一般场景(安全性较高)。

      风险: 内网中可能面临中间人攻击风险,如果有这种风险,需要采用下面的完全(严格)模式

    • 完全(严格)(Full (strict)):适用于指向服务器的域名,但服务器需安装有效 SSL 证书。(可以使用Let’s Encrypt 证书,搭配90天自动续期服务)

  2. 如果域名不指向服务器,仅做跳转或解析,可选择“完全”模式

  3. 点击保存,完成 SSL/TLS 加密设置。

3️⃣ 开启边缘证书(Edge Certificates)

  1. 点击 “边缘证书” 选项
  2. Cloudflare 会自动申请并管理 托管证书
  3. 下拉找到 “始终使用 HTTPS” 选项,点击 开启(可选,但推荐)。
  4. 这样可以确保所有 HTTP 请求都自动跳转到 HTTPS,提高安全性

p.s. 可通过 SSL Labs 测试工具 验证加密强度

参考视频教程

参考博客

Zero Trust: cloud flare提供的内网穿透服务

必须现有一个托管在cloudflare的域名

Zero Trust界面中 - 网络 - Tunnels - 添加隧道 - 选择Cloudflared

按照安装要求进行相应安装cloudflare连接器,然后就可以转到隧道管理中配置内网穿透的具体服务了:

image-20250428165816614

就可以实现内网穿透了

但是要注意内网穿透没法将设备直接暴露到公网,只能暴露某个端口

群晖部署Cloudflare Tunnel

Cloudflare Tunnel能把 NAS 低频访问的内网服务,用最低成本稳定暴露到外网。关键数据全程 SSL 加密,比自建 FRP 省了服务器钱还不用操心 DDoS 防护‌

使用outlook邮箱可以无手机注册

然后再试用outlook账号注册cloudflare

要先在cloudflare新建隧道,新建后继续下面的步骤

群晖通过docker部署cloudflare隧道连接器

docker部署gitea参考

  1. 下载镜像: 打开群晖的 Container Manager,进入“镜像仓库”页面;搜索 cloudflare/cloudflared,选择并下载 latest (最新) 标签的镜像

  2. 创建容器: 在“映像”中找到下载好的 cloudflare/cloudflared镜像,点击“启动”

  3. 按照下面进行配置

image-20250912151754618

注意网络一定要设置为host模式,命令要设置为tunnel run

总结一下配置

选项卡 设置项 推荐配置
执行命令 Entrypoint cloudflared --no-autoupdate(保持不变)
命令 tunnel run
环境 变量 (新增) TUNNEL_TOKEN
值 (新增) eyJhIjoi...(您的真实Token)
网络 网络模式 建议选择“使用与 Docker Host 相同的网络”

配置完成后需要告诉cloudflare哪个公网域名对应哪个内网服务

  1. 在 Cloudflare Zero Trust 面板中,进入你刚创建的隧道的配置页面。
  2. 点击 “Public Hostnames” 选项卡,然后点击 “Add a public hostname”
  3. 配置你的服务映射:
    • Subdomain: 输入你喜欢的子域名前缀,如 nasdsm
    • Domain: 从下拉菜单中选择一个你托管在 Cloudflare 上的域名。
    • Service: 选择 HTTPHTTPS
    • URL: 填写你的群晖服务在内网的地址和端口。例如:
      • 访问 DSM 管理界面: http://localhost:5000
      • 访问 Docker 中的某个 Web 服务: http://localhost:3000
  4. 点击“Save”保存。现在,你就可以通过你配置的公网域名(例如 https://nas.yourdomain.com)安全地访问内网服务了

到此就部署成功了

自建服务器内网穿透

使用 frpngrok 将宿主机端口映射到公网

无限邮域名

参考链接

在spaceship购买无限邮域名,site后缀会特别便宜

另外免费方式: 在cloudflare上配置一个域名,然后找到电子邮件配置邮件路由就可以

技巧记录

ssh -o ProxyCommand="none" Qian0407@192.168.8.6绕开代理,连接ssh,不然会显示ssh被127.0.0.1断开连接

路由器配置

静态ip注意

路由器的客户端列表不会显示所有设备的ip地址,如果是静态设置(手动配置ip地址的设备)在客户端列表中不可见

特性 静态地址分配 (DHCP保留) 静态设置 (手动配置)
配置位置 路由器的管理界面 每台终端设备的操作系统内
管理方式 集中式管理,所有IP在一个地方分配和查看 分散式管理,需要登录每台设备修改
可靠性 非常高。IP地址由权威的DHCP服务器分配,绝对不会有冲突。 较低。容易因人为失误导致IP冲突,造成网络中断。
灵活性 。更改IP地址只需在路由器上操作,设备无感知。 。更改IP需要逐台设备操作,非常繁琐。
迁移性 。设备拿到新网络会自动获取新IP,无需重新配置。 。设备换网络后仍需手动设置,否则无法上网。
所需知识 较低。只需知道设备的MAC地址。 较高。需要正确填写IP、子网掩码、网关、DNS。
推荐场景 绝大多数情况,尤其是家庭、中小企业环境。 极特殊情况,如:无DHCP服务的纯静态网络、网络设备(交换机、路由器自身)、临时测试。

路由器防火墙

一般被称为虚拟服务器

将某个内网ip的某个端口对外开放

网络设备盘点

云管理交换机

VLAN

VLAN(Virtual Local Area Network,虚拟局域网)最核心、最根本的作用是可以实现”将一个物理交换机虚拟成多个独立的逻辑交换机”的效果

工作原理

  • 传统交换机(无VLAN): 所有端口都处于同一个广播域中。一台电脑发送的广播数据包(如ARP请求),会被交换机转发给所有其他端口上的设备。整个交换机就像一个大的、开放的房间,大家都能听到彼此的喊话。
  • 启用VLAN的交换机: 您可以将不同的端口划分到不同的VLAN中。例如:
    • 将端口1-8划分到 VLAN 10(比如给财务部使用)
    • 将端口9-16划分到 VLAN 20(比如给市场部使用)
    • 效果: 此时,VLAN 10和VLAN 20就相当于两个完全独立的虚拟交换机。
      • 广播隔离: 一台连接在VLAN 10端口上的电脑发送广播包,这个包只会被转发到其他属于VLAN 10的端口。VLAN 20的端口完全收不到任何VLAN 10的流量,反之亦然。
      • 通信隔离: 即使两台电脑都接在同一台物理交换机上,但如果它们属于不同的VLAN,它们之间默认也无法直接通信,就像接在了两台完全不同的交换机上一样。

TL-SG2024D

说明书 tplink云管理交换机用户手册

TP-LINK全新开发推出的“云交换系列”全千兆云管理交换机,提供更为高效、简单、安全、易用的远程管理方式,支持智能开局、自动配置组网、异常告警等功能,无需专业IT运维人员,小白也能轻松上手;采用新一代高性能硬件和软件平台,提供灵活、高性价比的全千兆端口,支持灵活的802.1Q VLAN、端口监控、端口汇聚、QoS、带宽控制等基础网络管理功能,易于管理维护,适用于校园、酒店及企业园区网络接入应用场景

一键切换工作模式

  • 云管理模式:交换机支持VLAN、端口汇聚、端口监控等网管功能,可以通过商云APP、商用网络云平台、本地界面进行管理和维护。
  • VLAN隔离模式:交换机不支持网管功能,并且部分端口相互隔离,详⻅安装手册相关说明。
  • 标准交换模式:交换机不支持网管功能,并且所有端口均可以自由通信

局域网扫描工具

特性维度 Angry IP Scanner Advanced IP Scanner
macOS 支持 明确支持 (Linux, Windows, Mac OS X) Windows
免费性 完全免费 (开源) 免费
主要功能特点 快速扫描IP地址和端口、支持自定义IP范围、数据导出、插件扩展、命令行界面 快速扫描局域网设备、显示设备信息(IP, MAC地址)、远程开关机(WOL)、访问共享资源
用户友好性 界面简洁,提供图形界面和命令行界面 强调易于使用,提供图形化界面
额外优势 跨平台兼容性佳、无需安装(便携版)、开源 绿色免安装、支持Radmin远程控制
官网 官网 官网

部署问题盘点

群晖默认nginx与docker nginx端口冲突

常见解决方案:

  • 释放默认端口,通过修改DSM的Nginx配置,将80/443改成其他端口,比如8080/8443. 注意 DSM 系统升级可能会恢复配置,需使用计划任务定时执行脚本 参考做法: 群晖 DSM 停用内置 Nginx

  • 使用独立 IP:给反向代理容器分配一个单独的局域网 IP(如通过 Docker macvlan),使它不与 DSM 共享 IP。这样反向代理可以在该 IP 的 80/443 上运行,而 DSM 自带服务绑定在另一 IP 上。例如 Andy 的案例中,他将 NPM 容器分配到 192.168.0.201,让它独立监听 80/443 。下图示意了这种网络布局:Docker 容器和 DSM 主机各自拥有不同 IP,反向代理可独占端口。参考做法

  • 更换端口:如果不想改系统 Nginx,可以让容器监听其他端口(如 8443、8080),并在 DSM 侧进行端口映射或转发。不过这样访问时需要指定非标准端口,或使用额外的 HTTP 到 HTTPS 转发(如 stream 模块或 DSM 自带转发)

    stream方案注意:

使用独立IP方案

  1. SSH登录到群晖NAS,查看宿主机的物理网卡名ip link,通常是 eth0 或者类似 ovs_eth0(取决于你是否用了群晖的虚拟网络层)

  2. 创建一个 Macvlan 网络

    1
    2
    3
    4
    5
    6
    7
    8
    9
    docker network create -d macvlan \
    --subnet=192.168.8.0/24 \
    --gateway=192.168.8.1 \
    -o parent=eth0 \
    macvlan_net
    # --subnet:局域网的子网
    # --gateway:局域网网关
    # parent=eth0:替换为你实际的物理网卡名
    # macvlan_net:这个是网络的名字,可以自己定义
  3. 启动容器并绑定独立 IP

    1
    2
    3
    4
    5
    6
    7
    8
    9
    docker run -d \
    --name my-nginx \
    --network macvlan_net \
    --ip 192.168.8.115 \
    -v /path/to/nginx.conf:/etc/nginx/nginx.conf \
    -p 80:80 -p 443:443 \
    nginx:latest
    # --ip 192.168.8.115:这是容器在局域网的固定 IP
    # -p 可以省略,因为容器直接在独立 IP 上监听,不需要映射到宿主机
  4. 配置域名解析

    在路由器或本地 DNS 中,把 nas.jhh1.site 解析到 192.168.8.115

注意事项

  • 宿主机访问容器问题:Macvlan 模式下,宿主机(群晖本身)默认不能直接访问这个容器 IP。如果需要 DSM 本身访问容器(例如 DSM 的备份任务访问 192.168.8.115:443),你需要再建一个 macvlan bridge 或者用 ipvlan 替代。
  • 防火墙:检查群晖和路由器的防火墙设置,确保放行 80/443 到 192.168.8.115。
  • DHCP 冲突:务必在路由器 DHCP 池之外选择 IP,或者在路由器里给容器 IP 做静态绑定。

macvlan

简单定义:macvlan 是 Docker(Linux 内核)的一种网络驱动,把容器虚拟成网络上的独立设备:每个容器拥有自己的 MAC 地址和 IP,像一台真实主机那样直接出现在 L2 网络上(交换机能识别它的 MAC)。

物理网口,即使是两个网口各自有独立的ip地址,也会在nginx层面涉及到互相之间端口占用的影响,而使用macvlan方案是真正意义上可以不互相占用的

解决的问题:当你想让容器直接在局域网中拥有独立 IP(并可以占用标准端口 80/443),而不与宿主机(群晖 DSM 自带服务)端口冲突时,macvlan 非常合适。

应用场景:反向代理(Nginx)直接对外提供 HTTPS;把容器暴露成局域网内独立服务;在多服务/多 IP 下避免端口冲突。

工作原理

  • macvlan 在宿主物理网口上创建虚拟网口(子接口),容器的网口直接挂在这个虚拟网口上,容器发出的帧带自己的 MAC,物理交换机会像对待物理主机一样转发。
  • parent:你需要指定一个物理网卡作为 parent(例如 eth0, bond0, ovs_eth0 等),macvlan 会基于它创建虚拟接口。
  • 主机与容器隔离:宿主机(host)默认不能直接访问 macvlan 上的容器 IP(因为主机和容器处于不同的 L2 接口)。这通常是优点(隔离),但也带来需要额外配置以便 host 访问的尴尬。
  • 支持 VLAN(如果你的网络需要 802.1Q 标签,可以在 parent 上用子接口如 eth0.10)。

优缺点

优点

  • 容器看起来像局域网内真实主机:直接使用标准端口 80/443,不需要宿主端口映射。
  • 几乎原生网速,延迟低(无 DNAT/SNAT)
  • 便于把容器放到已有网络策略 / 路由里(如静态 IP、路由器防火墙规则等)

缺点 / 限制

  • 宿主机默认无法访问容器 IP(需要特殊配置才能从 DSM 访问容器的 IP)。
  • 一些家用路由器 / 交换机或 ISP 提供的设备可能会限制一个物理端口上的多个 MAC,或者对 Wi-Fi 客户端行为不友好(尤其某些 ISP 网关或 Wi-Fi 中继)。
  • 容器在网络上直接可见,安全性依赖你在容器内配置的防护(而不是 Docker NAT 隔离)。
  • 需要知道宿主机物理接口名称,并具有对其操作权限(在群晖上需要 SSH)。

替代方案说明

  • host 网络模式:容器直接和宿主共享网络栈(能访问 host 的接口),但你无法分配独立 IP。
  • ipvlan:与 macvlan 类似,但在某些场景(比如需要更低开销)更合适;此外 ipvlan 在 host <-> container 通信上有不同行为。一般入门用 macvlan 更直观。

使宿主机能和macvlan容器互通(可选)

如前所述,macvlan 默认内核会阻止宿主和其 macvlan “子设备”互通(这是内核设计/安全隔离),若你需要从 NAS 上直接访问/调试容器(或容器访问 NAS,只是局域网内别的机器能访问容器就行),需要在宿主上建立一个 macvlan 虚拟接口(shim)并给它一个 IP(通常是 –aux-address 保留的那个)。这是社区推荐的解决办法

示例命令(继续用上面假设):

1
2
3
4
5
6
# 创建 macvlan 虚拟设备(仅在内存,不会重启后保留)
ip link add macvlan-shim link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.8.199/32 dev macvlan-shim # 这个 IP 同 aux-address 保持一致
ip link set macvlan-shim up
# 告诉宿主到容器网段走 macvlan-shim(ip-range)
ip route add 192.168.8.200/29 dev macvlan-shim

验证:宿主上 ping 192.168.8.200(容器 IP)应该可达(容器已运行的情况下)

持久化:上面这些命令是临时的,重启会丢失。建议用 DSM 的 控制面板 → 任务计划程序 新建一个“开机/登录时运行”的任务,以 root 身份运行一个小脚本来恢复这几个 ip link / ip addr / ip route(脚本示例我会在下面给出)