Alice の Blog

hi

Mtoly — Sun, 25 Oct 2026 06:53:05 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/notes/3

Nezha 监控系统入侵事件应急响应实录

Mtoly — Wed, 24 Jun 2026 02:53:51 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Note/nezha

一次真实的 40 台 VPS 批量入侵事件全记录：从漏洞发现到后门清理、根因定位、复发处置、自动化加固的完整过程。

事件时间：2026-06-19 至 2026-06-20 影响范围：40 台服务器，主控 Nezha dashboard 2.2.3，34 台 agent 被植入后门 事件性质：利用 Nezha 低版本安全漏洞投放持久化后门

一、事件背景

我有 40 台 VPS 分布在多个云服务商（腾讯云、阿里云、华为云、racknerd、netcup、dmit 等），全部接入同一套 Nezha 监控面板。主控部署在腾讯云新加坡（43.156.17.202:8008），运行 dashboard v2.2.3。

2026-06-19，我注意到 Nezha 官方发布了多个安全公告（security advisories），涉及低版本的远程命令执行、路径穿越泄露密钥等严重漏洞。我需要确认：

我的 dashboard 和 40 台 agent 是否受影响？
攻击者是否已经利用漏洞入侵了我的服务器？
如果被入侵了，植入了什么后门？怎么清理？

二、漏洞分析

受影响版本

Nezha 官方安全公告显示，关键修复分界点是 2.2.0：

Dashboard/Agent < 2.2.0：受多个中危漏洞影响
更老版本叠加高危/严重漏洞

关键 CVE

GHSA	CVE	严重性	概述
GHSA-99gv-2m7h-3hh9	CVE-2026-46716	严重	低版本 RoleMember 可通过 cron 接口在 Agent 节点执行 shell 命令
GHSA-5c25-7vpj-9mqh	CVE-2026-53519	严重	低版本 Dashboard 预认证路径穿越泄露 `jwt_secret_key`

攻击链路

攻击者获取面板访问权限
  ├─ 方式1：利用 CVE-2026-53519 路径穿越泄露 jwt_secret_key → 伪造管理员 JWT
  ├─ 方式2：利用 CVE-2026-46716 cron 接口直接执行命令
  └─ 方式3：弱口令 / 泄露的面板账号
        ↓
通过面板的远程命令能力（cron / terminal / force-update）
在 Agent 节点上执行任意命令
        ↓
植入持久化后门

三、版本排查

Dashboard 版本

主控 dashboard 是 Docker 部署，版本确认：

docker exec nezha-dashboard /dashboard/app -v
# 输出：2.2.3

dashboard 2.2.3 > 2.2.0，不受 advisory 影响。

Agent 版本（40 台）

这里踩了一个大坑：公开 WebSocket 返回的 host.version 在访客视图下是 null，必须用管理员 JWT 才能看到真实版本。

最终通过以下步骤获取 40 台 agent 版本：

从主控 SQLite 数据库读取 jwt_secret_key 和未过期 session 的 key_id
用 Go + sqids-go 生成管理员 JWT（Nezha 用 idcodec 对 user_id 做 sqids 编码）
用 JWT 连接管理员 WebSocket 读取 host.version

结果：

主控 agent：2.2.2（最新）
31 台在线 agent：2.2.2（最新）
5 台在线 agent：1.9.7（受漏洞影响）
4 台离线无版本

5 台旧版 agent：狗云-MG-V6、hostyun-us、绿云-日本大版、狗云-MG-V4、racknerd-DC02。

四、第一轮清理：sysmon 后门

发现

对主控做深度只读检查时，发现 /etc/systemd/system/sysmon.service 和 sysmon-guard.timer，进一步排查发现完整的后门体系：

后门结构：

/usr/local/sysmon/              ← 伪装 Nezha agent 的假二进制 + config.yml
  └─ config.yml                 ← server: 51.254.44.35:8008（攻击者面板）
/usr/local/.sysmon-guard/       ← 守护进程
/usr/local/lib/libsysmon.so     ← preload 注入库
/etc/systemd/system/sysmon.service
/etc/systemd/system/sysmon-guard.service
/etc/systemd/system/sysmon-guard.timer   ← 30 秒触发自恢复
/etc/ld.so.preload              ← 加载 libsysmon.so

后门行为：

伪装成 sysmon 系统监控服务，实际运行类似 Nezha Agent 的二进制
配置文件 server: 指向攻击者控制的 Nezha 面板 51.254.44.35:8008
sysmon-guard.timer 每 30 秒检查一次，如果 sysmon 被杀就重新拉起
/etc/ld.so.preload 加载 libsysmon.so 做全局钩子（可能用于隐藏进程/文件）
日志显示守护进程每 30 秒执行 SELF-HEAL: Re-installing cron

环境变量泄露的后门设计：

STEALTH_NAME=sysmon
INSTALL_DIR=/usr/local/sysmon
GUARD_DIR=/usr/local/.sysmon-guard
LIB_PATH=/usr/local/lib/libsysmon.so
PRELOAD_FILE=/etc/ld.so.preload

清理

清理顺序非常重要（顺序错了守护器会重建文件）：

停止并禁用 sysmon-guard.timer、sysmon-guard.service、sysmon.service
kill -9 杀掉所有 sysmon 相关进程
删除 systemd unit 文件
清理 /etc/ld.so.preload 中的 libsysmon.so 引用
删除 /usr/local/lib/libsysmon.so
删除 /usr/local/sysmon 和 /usr/local/.sysmon-guard 目录
systemctl daemon-reload

清理后复查：主控 sysmon 后门已彻底删除，无残留进程/文件/外连。

五、批量清理 40 台

用 paramiko 线程池（10 并发）批量清理所有服务器，密码只在内存中不落盘。

清理结果

主控 + 大部分感染节点：sysmon 后门已清理
3 台 SSH 超时：raksmart-圣何塞、云曦幻境、geelinx-b，需手动处理
Agent 版本升级：通过面板 force-update API + 手动 SSH 升级，5 台 1.9.7 升级到 2.2.2

升级 Agent 的坑

force-update API 对 disable_force_update: true 的 agent 无效
主控显示旧版本不一定是二进制旧，可能是进程没重启
有些机器有多个 nezha-agent 服务，只重启了一个
hostyun-us 的 IP 从 45.155.222.112 换到了 207.57.137.18

六、复发！发现真正的根因

清理 sysmon 后做全量复查，发现 sysmon 后门 0 复发，但发现了更危险的东西。

第二份 config 后门

34 台服务器的 /opt/nezha/agent/ 目录下，除了合法的 config.yml，还存在随机命名的 config-XXXXX.yml：

字段	恶意配置 (config-XXXXX.yml)	合法配置 (config.yml)
server	207.58.173.192:8088	data.nat.tf:8008 (=43.156.17.202)
disablecommandexecute	false（远程命令开启）	true（已加固）
文件名	随机 5 位后缀	无后缀

关键证据：

data.nat.tf 解析到 43.156.17.202（我的主控），确认 config.yml 是合法配置
207.58.173.192:8088 当前无法连接，但配置和进程仍在
主控上恶意 agent 进程（PID 911，config-etp0h.yml → 207.58.173.192:8088）一直在运行
34 台的恶意配置文件名都是随机 5 位后缀，说明是自动化批量投放

为什么这比 sysmon 更危险

维度	sysmon 后门	第二份 config 后门
二进制	独立假 agent (/usr/local/sysmon)	合法 nezha-agent
配置	独立 config.yml	config-XXXXX.yml 混在合法配置目录
守护	sysmon-guard.timer 30 秒	systemd nezha-agent-XXX.service
注入	ld.so.preload	无
隐蔽性	低（独立路径明显）	高（混在合法 agent 目录里）
命令执行	通过 C2 面板	通过攻击者 nezha 面板

这是真正的复发根因：攻击者不植入独立二进制，而是利用合法 nezha-agent 二进制 + 额外配置文件。即使清理了 sysmon，攻击者仍可通过合法 nezha-agent + 恶意配置维持对 34 台服务器的远程命令执行能力。

七、第二轮清理：第二份 config 后门

清理逻辑

# 1. 找出所有 config-*.yml（带随机后缀的恶意配置）
for cfg in /opt/nezha/agent/config-*.yml; do
  # 2. 找对应 service 并停用
  for svc in $(systemctl list-units | grep nezha-agent-); do
    svc_cfg=$(systemctl cat "$svc" | grep -oE "/opt/nezha/agent/config[^ ]*\.yml")
    if [ "$svc_cfg" = "$cfg" ]; then
      systemctl stop "$svc"
      systemctl disable "$svc"
      rm -f "/etc/systemd/system/$svc"
    fi
  done
  # 3. 杀进程
  pkill -9 -f "$(basename $cfg .yml)"
  # 4. 删配置
  rm -f "$cfg"
done
systemctl daemon-reload

# 5. 加固合法 config.yml
sed -i 's/^disable_command_execute:.*/disable_command_execute: true/' /opt/nezha/agent/config.yml
systemctl restart nezha-agent.service

清理结果

37 台成功清理：删除 35 个恶意配置 + 35 个恶意服务
3 台超时：raksmart-圣何塞、云曦幻境、geelinx-b
所有成功清理的服务器：AFTER 状态只剩 config.yml + nezha-agent.service，网络检查全部 CLEAN

八、深度复查

清理后对 40 台服务器做 19 项深度 IOC 扫描：

sysmon 后门文件
ld.so.preload 注入
第二份 config 后门
合法 config 加固状态
nezha 服务列表
挖矿木马进程
sysmon 相关进程
攻击者网络连接
cron 持久化
systemd 可疑服务
SSH authorized_keys
登录记录
SUID 文件
/tmp 隐藏文件
可疑定时器
CPU 占用
异常监听端口
rc.local/profile.d
内核模块

结果

检查项	结果
sysmon 后门残留	0
第二份 config 后门	0
挖矿木马进程	0
到攻击者面板连接	0
ld.so.preload libsysmon	0
可疑 cron/systemd	2 台（腾讯云官方 stargate，已核实非恶意）
完全干净	34/36

结论：sysmon 后门和第二份 config 后门均无复发，未发现新的木马或黑客遗留。

九、自动化加固

1. 关闭远程命令能力

所有 34 台 nezha 节点的 config.yml 已设置：

disable_command_execute: true   # 关闭远程命令执行（terminal/webssh）
disable_nat: true               # 关闭 NAT 穿透

2. Dashboard 自动更新（Watchtower）

部署 Watchtower 容器实现 dashboard 自动更新：

docker run -d \
  --name watchtower \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --cleanup \
  --interval 3600 \
  nezha-dashboard

每小时检查 ghcr.io/nezhahq/nezha:latest 是否有新镜像
有新版自动拉取并重启 nezha-dashboard 容器
只监控 nezha-dashboard，不影响其他容器
GitHub 发布新版后，最多 1 小时内自动更新，无需手动介入

3. Agent 自动更新

修改 agent 配置：

disable_auto_update: false      # 开启自动更新
disable_force_update: false     # 允许主控下发强制更新
disable_command_execute: true   # 保持远程命令关闭

GitHub 发布新版 agent 后，各节点自动更新，无需手动介入。

十、复发根因分析

后门清理后再次出现，通常是以下原因之一：

★第二份 config 后门未清理（最隐蔽）：清理了 sysmon 但没检查 config-XXXXX.yml，攻击者通过合法 nezha-agent + 恶意配置维持控制。这是本次事件复发的真正根因。
残留自恢复链路：sysmon-guard.timer / cron / ld.so.preload / 隐藏脚本任一残留
攻击者仍有登录入口：root 密码、SSH key、面板账号、Agent Secret、JWT Secret 任一泄露
Nezha 远程命令未及时关闭：低版本暴露期间攻击者拿到面板 token，能继续下发命令
同机其他面板漏洞：1Panel / 宝塔 / x-ui / MCSManager / phpMyAdmin / MySQL / Redis 暴露公网
清理顺序错误：先删文件没先停守护 → 守护器重建文件
密码未轮换：清理后没换 root 密码 / SSH key

十一、经验教训

1. 不要只查一种后门

sysmon 后门特征明显（独立路径 + ld.so.preload），容易发现也容易清理。但第二份 config 后门极隐蔽（合法二进制 + 混在配置目录），清理完 sysmon 后必须复查是否有 config-XXXXX.yml。

2. 清理顺序很重要

停守护 → 杀进程 → 删文件 → 清 ld.so.preload → daemon-reload

顺序错了，守护器会重建文件，等于白清理。

3. Nezha 版本读取的坑

公开 WebSocket 的 host.version 在访客视图下是 null，必须用管理员 JWT 才能看到真实版本。这会导致误判"所有 agent 版本未知"，延迟发现旧版节点。

4. Windows SSH 中文路径

Windows 上 OpenSSH 对含中文/空格的私钥路径处理不可靠，必须复制到 ASCII 临时路径 + icacls 收紧 ACL + 用系统自带 C:\Windows\System32\OpenSSH\ssh.exe。

5. 批量操作用 paramiko

系统无 sshpass/expect 时，paramiko 是批量 SSH 的最佳选择。密码只在内存中，绝不落盘。

6. 自动更新很重要

这次事件根因是低版本漏洞被利用。部署 Watchtower + 开启 agent 自动更新后，未来 GitHub 发新版会自动更新，不再需要手动介入。

7. 安全加固清单

升级 Dashboard 到最新版（2.2.3）
升级所有 Agent 到最新版（2.2.2）
清理 sysmon 后门
清理第二份 config 后门
关闭远程命令执行（disablecommandexecute: true）
部署 Watchtower 实现 Dashboard 自动更新
开启 Agent 自动更新
轮换 root 密码
轮换 SSH key
轮换 Nezha 面板密码
轮换 Agent Secret
轮换 JWT Secret
关闭非必要公网面板入口

十二、开源工具

本次事件中开发的清理脚本已开源：

仓库：https://github.com/motao123/cleanmalwareandhardennezha
完整清理脚本：clean_malware_and_harden_nezha.sh（覆盖三类后门）
轻量版：manual_clean_second_config.sh（仅清理第二份 config 后门）

一键使用

curl -fsSL https://raw.githubusercontent.com/motao123/clean_malware_and_harden_nezha/main/clean_malware_and_harden_nezha.sh -o /root/clean.sh
bash /root/clean.sh

群发排查命令

如果你也想检查自己的服务器是否中招：

# sysmon 后门排查
ls -ld /usr/local/sysmon /usr/local/.sysmon-guard /usr/local/lib/libsysmon.so /etc/systemd/system/sysmon* /etc/ld.so.preload 2>/dev/null

# 第二份 config 后门排查
ls /opt/nezha/agent/config-*.yml 2>/dev/null && echo "WARNING: second config backdoor detected"

# 挖矿木马排查
ps auxww | grep -Ei "sysmon|kworker|kdevtmpfsi|kinsing|xmrig" | grep -v grep

# 攻击者连接排查
ss -tnp | grep -E "51.254.44.35|207.58.173.192"

十三、事件时间线

2026-06-19  攻击者利用低版本漏洞植入 sysmon 后门 + 第二份 config 后门
2026-06-20 00:30  发现 Nezha 安全公告，开始排查
2026-06-20 00:45  确认主控 dashboard 2.2.3 不受影响，5 台 agent 为 1.9.7
2026-06-20 00:51  发现主控 sysmon 后门，开始清理
2026-06-20 01:00  sysmon 后门清理完成（主控）
2026-06-20 01:15  批量清理 40 台 sysmon 后门
2026-06-20 01:30  批量升级旧版 agent 到 2.2.2
2026-06-20 02:00  hostyun-us IP 变更，手动修复
2026-06-20 10:25  第一次复发复查：sysmon 0 复发，但发现 34 台第二份 config 后门
2026-06-20 11:00  定位复发根因：第二份 config 后门（config-XXXXX.yml → 207.58.173.192:8088）
2026-06-20 11:47  批量清理第二份 config 后门（37 台成功）
2026-06-20 11:52  更新清理脚本并推送 GitHub
2026-06-20 12:00  深度复查 40 台（19 项检查全部通过）
2026-06-20 12:07  部署 Watchtower + 开启自动更新
2026-06-20 12:13  撰写本文档

总结

这次事件的核心教训：清理了一种后门不等于清理了所有后门。sysmon 后门特征明显容易被发现，但第二份 config 后门利用合法二进制 + 混在配置目录里，隐蔽性极强。如果不是做了深度复查，攻击者仍可通过 34 台服务器的合法 nezha-agent 维持远程命令执行能力。

安全是一个持续的过程，不是一次性的操作。清理后门只是第一步，还需要：升级版本、关闭远程能力、开启自动更新、轮换凭据、关闭非必要公网入口。只有全链路加固，才能避免再次被入侵。

本文档基于真实事件整理，相关清理工具已开源：https://github.com/motao123/cleanmalwareandhardennezha

原文章地址：https://github.com/motao123/cleanmalwareandhardennezha/blob/0772009f3980f8fa3410fe980cd4ab3f3cbd0681/incident-report.md

https://lenghang.com/archives/nezha-jian-kong-xi-tong-ru-qin-shi-jian-ying-ji-xiang-ying-shi-lu

览毕，何不一言？

自建 Tailscale DERP 中继服务器

Mtoly — Thu, 09 Apr 2026 01:37:14 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Network/self-hosted-tailscale-derp-relay-server

国内使用 Tailscale 官方 DERP 中继服务器时，容易遇到延迟高和连接不稳定的情况。在一台有公网 IP 的 VPS 上自建 DERP 服务器，能明显改善节点间的通信延迟和打洞成功率。下面介绍两种基于 Docker 的部署方式：域名反向代理模式和纯 IP 模式。

前置条件

一台有公网 IP 的 VPS（建议选择延迟低的地区）
已安装 Docker 和 Docker Compose
域名并配置好 DNS 解析（方案一需要，方案二不需要）
Nginx（或其他反向代理）处理 SSL（方案一需要，方案二不需要）

方案一：域名部署 DERP（反向代理模式）

Docker Compose 配置

创建 docker-compose.yml：

services:
  derper:
    container_name: derper
    image: fredliang/derper
    restart: always
    network_mode: host  # 直接使用宿主机网络，支持 IPv6
    environment:
      - DERP_DOMAIN=derp.example.com
      - DERP_ADDR=:13477
      - DERP_HTTP_PORT=13478
      - DERP_VERIFY_CLIENTS=true
    volumes:
      - /var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock

关键配置说明

配置项	说明
network_mode: host	必须。使用宿主机网络栈，支持 IPv6 和 STUN
DERP_DOMAIN	你的 DERP 服务器域名
DERP_ADDR	监听地址和端口
DERPVERIFYCLIENTS	设为 true 验证客户端身份，防止滥用
tailscaled.sock	挂载 Tailscale socket，用于客户端验证

⚠️ 注意：DERP_VERIFY_CLIENTS=true 需要服务器上运行 Tailscale 客户端，并且挂载其 socket 文件。

启动服务

docker compose up -d

Nginx 反向代理配置

DERP 使用 WebSocket 进行通信，需要正确配置反向代理。

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name derp.example.com;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    location ^~ / {
        proxy_pass http://127.0.0.1:13477;
        
        # 核心：强制发送 WebSocket 头
        # 解决 HTTP/2 下头丢失导致 426 错误的问题
        proxy_set_header Upgrade "websocket";
        proxy_set_header Connection "upgrade";
        
        # 必须：协议版本与关闭缓存
        proxy_http_version 1.1;
        proxy_buffering off;
        
        # 基础头
        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;
        proxy_set_header X-Forwarded-Port $server_port;
        
        # 超时（保持长连接）
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
        
        # 安全头
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    }
}

重要配置解释

强制 WebSocket 头：proxy_set_header Upgrade "websocket" 和 Connection "upgrade" 是必须的，否则在 HTTP/2 下会出现 426 错误
使用 HTTP/1.1：proxy_http_version 1.1 确保 WebSocket 正常工作
关闭缓冲：proxy_buffering off 避免中继数据被缓存
长超时：86400 秒（24 小时）保持连接不断开

重载 Nginx：

sudo nginx -t && sudo nginx -s reload

Tailscale ACL 配置

{
  // 自定义 DERP 服务器
  "derpMap": {
    // 只使用自定义 DERP，禁用官方 DERP
    "OmitDefaultRegions": true,
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "hk",
        "RegionName": "DMIT Cloud Hong Kong",
        "Nodes": [
          {
            "Name": "hk1",
            "RegionID": 900,
            "HostName": "derp.example.com",
            "DERPPort": 443,
            "STUNPort": 3478
          }
        ]
      }
    }
  },
  "acls": [
    {
      "action": "accept",
      "src": ["*"],
      "dst": ["*:*"]
    }
  ]
}

配置说明

配置项	说明
OmitDefaultRegions	设为 true 禁用官方 DERP，只用自建的
RegionID	自定义区域 ID，建议用 900+ 避免冲突
RegionCode	区域代码，如 hkg、sgp、tyo
HostName	DERP 服务器域名
DERPPort	DERP 端口，通过 Nginx 反代后是 443
STUNPort	STUN 端口，保持 3478

可选：指定 IP 地址

如果不想走 DNS 解析，可以直接指定 IP：

{
  "Name": "hk1",
  "RegionID": 900,
  "HostName": "derp.example.com",
  "IPv4": "[IP_ADDRESS]",
  "IPv6": "[IP_ADDRESS]",
  "DERPPort": 443,
  "STUNPort": 3478
}

方案二：无域名部署 DERP（纯 IP 模式）

如果你没有域名，或者不想折腾 DNS 和 SSL 证书，可以直接用 IP 地址部署 DERP 服务器。这种方式使用 ip_derper 镜像，会自动生成自签名证书，无需 Nginx 反向代理。

Docker Compose 配置

创建 docker-compose.yml：

services:
  derper:
    container_name: derper
    image: ghcr.io/yangchuansheng/ip_derper:latest
    restart: always
    network_mode: host  # 直接使用宿主机网络，支持 IPv6
    environment:
      - DERP_HOST=你的服务器IP
      - DERP_ADDR=:13477
      - DERP_HTTP_PORT=13478
      - DERP_CERTS=/app/certs
      - DERP_STUN=true
      - DERP_VERIFY_CLIENTS=true
    volumes:
      - /var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock:ro
      - ./certs:/app/certs

关键配置说明

配置项	说明
ip_derper 镜像	基于官方 derper 修改，支持纯 IP 运行，自动生成自签名证书
DERP_ADDR	监听端口，这里使用 13477
DERP_CERTS	自签名证书存放路径（容器内部自动生成）
DERPVERIFYCLIENTS	设为 true 验证客户端身份，防止滥用
network_mode: host	使用宿主机网络栈，支持 IPv6 和 STUN

💡 与域名版本的区别：无域名版本不需要配置 Nginx 反向代理，DERP 服务器直接暴露端口，使用自签名 TLS 证书。

启动服务

docker compose up -d

ACL 配置

{
  // 自定义 DERP 服务器
  "derpMap": {
    // 只使用自定义 DERP，禁用官方 DERP，true 是只使用自己的节点，false 是自己的节点+官方节点
    "OmitDefaultRegions": false,
    "Regions": {
      "900": {
        "RegionID":   900,
        "RegionCode": "chn",
        "RegionName": "China",
        "Nodes": [
          {
            "Name":     "server",
            "RegionID": 900,
            "IPv4":             "[IP_ADDRESS]",
            "IPv6":             "[IP_ADDRESS]",
            "InsecureForTests": true,
            "DERPPort":         13477,
            "STUNPort":         3478
          }
        ]
      }
    }
  }
}

核心配置说明

配置项	说明
OmitDefaultRegions	false 表示同时使用自建和官方 DERP；true 表示只用自建
IPv4 / IPv6	直接指定服务器 IP 地址，不走 DNS 解析
InsecureForTests	核心配置：设为 true 允许跳过 TLS 证书校验（因为使用自签名证书）
DERPPort	与 DERP_ADDR 配置的端口一致，这里是 13477
STUNPort	STUN 端口，默认 3478；设为 -1 可禁用该节点的 STUN

⚠️ 注意：InsecureForTests 虽然名称中包含 “ForTests”，但这是 Tailscale 官方提供的跳过 TLS 校验的正式配置项，在纯 IP 无域名场景下是必须的。

服务器防火墙配置

无论选择哪种部署方案，都必须在系统防火墙及云服务商安全组（如阿里云、腾讯云等）放行对应端口：

方案	端口	协议	作用
方案一 (反代)	443	TCP	Nginx 接收的 HTTPS/DERP 流量
方案二 (纯 IP)	13477	TCP	DERP Docker 原生中继监听
所有方案	3478	UDP	STUN 协议，用于 NAT 打洞穿透

# UFW 示例：方案一（反代部署放行 HTTPS）
sudo ufw allow 443/tcp
sudo ufw allow 3478/udp

# UFW 示例：方案二（纯 IP 部署直接放行）
sudo ufw allow 13477/tcp
sudo ufw allow 3478/udp

验证 DERP 服务器

检查 DERP 状态

在任意 Tailscale 客户端执行：

tailscale netcheck

输出应显示你的自定义 DERP 区域及其延迟：

Report:
    * UDP: true
    * IPv4: yes, ...
    * IPv6: yes, ...
    * DERP latency:
        - hkg: 25.3ms (Tencent Cloud Hong Kong)

检查连接方式

tailscale status

如果显示 relay "hkg" 或类似内容，说明正在使用你的 DERP 中继。

常见问题

Q: 状态显示 IPv6: No

检查以下几点：

服务器是否有 IPv6 地址
DNS 是否配置了 AAAA 记录
Docker 是否使用 network_mode: host
防火墙是否放行 IPv6

Q: 426 Upgrade Required 错误

Nginx 配置问题，确保：

设置了 proxy_set_header Upgrade "websocket"
设置了 proxy_set_header Connection "upgrade"
使用 proxy_http_version 1.1

Q: 客户端验证失败

确保：

服务器上运行了 Tailscale 客户端
正确挂载了 /var/run/tailscale/tailscaled.sock
容器有权限访问该 socket

总结

自建 Tailscale DERP 服务器的主要作用：

访问私有节点，减少异地通信延迟。
流量不走官方服务器。
可选在特定区域如国内云服务器部署节点。
支持 IPv6，提高 P2P 打洞成功概率。

配置重点：

Docker 的 network_mode 需设为 host。
域名反代模式下，Nginx 必须加上 WebSocket 头（Upgrade "websocket" 等），避免 426 错误。
纯 IP 模式下，ACL 配置中必须有 "InsecureForTests": true。
ACL 中的 OmitDefaultRegions 控制是否弃用官方的 DERP 节点。

览毕，何不一言？

古见同学有交流障碍症

Mtoly — Thu, 12 Mar 2026 16:23:50 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Anime/Komisan-komyusho

基本信息

标题：古見さんは、コミュ症です。
古见同学有交流障碍症
图片宽度：300px
原名：古見さんは、コミュ症です。
常用译名：古见同学有交流障碍症
古见同学有社交障碍
古见同学是沟通鲁蛇。（青文版译名。“鲁蛇”是台湾对loser的音译（相当于大陆网络用语的卢瑟/撸瑟）。由于译名与内容严重不符而在网络上引发大量批评）
作者：小田智仁
地区：日本
出版社：小学馆
连载杂志：《週刊少年SUNDAY》
丛书：SHONEN SUNDAY COMICS
发表期间：2016年5月18日(2016年25号) - 2025年1月29日（2025年9号）
册数：36卷（2025.1）
连载状态：已完结

《古见同学有交流障碍症》（日语：古見さんは、コミュ症です。）是小田智仁于《週刊少年Sunday》上连载的漫画，并有衍生动画、真人电视剧。

原作介绍

于漫画杂志《週刊少年Sunday》2016年第25期开始连载至2025年第9期。

剧情简介

万人迷的美少女古见同学有交流障碍症。她不擅长与人交流，所以周围的人也觉得她难以亲近？ “要怎样才能和人说上话？” “说上话后又要怎么做呢？” 古见同学总是有着这样的烦恼。于是，因为机缘巧合而成为她朋友的只野同学挺身而出，希望能帮她交到一百个朋友！

角色介绍

主要角色

古见硝子

有交流障碍症的超级美少女。私立伊旦高校1年1班。

CV：古贺葵

只野仁人

私立伊旦高校1年1班。因坐在古见硝子的隔壁而被同学们视为眼中钉。

CV：梶原岳人（TV动画）
市谷春一（2016年12月CM）

长名奈津美

私立伊旦高校1年1班，只野仁人的发小。

CV：村川梨衣

次要角色

见古见同学有交流障碍症/角色列表

出版信息

单行本由小学馆出版，繁體中文由青文出版社出版。

简体中文版由小学馆授权网站哔哩哔哩漫画自行翻译刊登。

卷	日文版	ISBN	繁体中文版	ISBN
1	2016年9月16日	ISBN 978-4091273437	2018年2月5日	EAN 471-8016028043 EAN 471-8016028050（限定版）
2	2016年12月16日	ISBN 978-4091274267	2018年5月21日	EAN 471-8016029422
3	2017年3月17日	ISBN 978-4091275097	2018年8月9日	ISBN 978-9863565314
4	2017年6月16日	ISBN 978-4091275752	2019年1月17日	ISBN 978-9863567608
5	2017年7月18日	ISBN 978-4091276643	2019年4月11日	ISBN 978-9863568643
6	2017年10月18日	ISBN 978-4091278562	2019年7月8日	ISBN 978-9863569732
7	2017年12月18日	ISBN 978-4091278852	2019年10月9日	ISBN 978-9865120771
8	2018年3月16日	ISBN 978-4091280916	2019年12月19日	ISBN 978-9865121587
9	2018年6月18日	ISBN 978-4091282545	2020年4月1日	ISBN 978-9865122911
10	2018年9月18日	ISBN 978-4091283900	2020年6月4日	ISBN 978-9865123734
11	2018年12月18日	ISBN 978-4091285904	2020年9月10日	ISBN 978-9865125066
12	2019年3月18日	ISBN 978-4091288028	2020年11月5日	ISBN 978-9865126025
13	2019年6月18日	ISBN 978-4091291660	2021年4月15日	ISBN 978-9865129323
14	2019年8月16日	ISBN 978-4091293299	2021年5月17日	ISBN 978-9865498795
15	2019年11月18日	ISBN 978-4091294418	2021年10月25日	ISBN 978-6263035072
16	2020年2月18日	ISBN 978-6263035072	2022年1月25日	ISBN 978-6263220478
17	2020年5月18日	ISBN 978-4098500727	2022年3月17日	ISBN 978-6263222632
18	2020年9月18日	ISBN 978-4098501786	2022年6月2日	ISBN 978-6263225022
19	2020年11月18日	ISBN 978-4098502776	2022年7月18日	ISBN 978-6263227828
20	2021年2月18日	ISBN 978-4098503896	2022年9月28日	ISBN 978-6263400641
21	2021年5月18日	ISBN 978-4098505296	2023年1月11日	ISBN 978-6263404366
22	2021年8月18日	ISBN 978-4098506446	2023年3月30日	ISBN 978-6263407589
23	2021年10月18日	ISBN 978-4098507207	2023年6月19日	ISBN 978-6263409408
24	2022年1月18日	ISBN 978-4098508662
25	2022年4月18日	ISBN 978-4098510580
26	2022年7月15日	ISBN 978-4098511853
27	2022年10月18日	ISBN 978-4098513499
28	2023年1月18日	ISBN 978-4098515325

人气投票

小学馆

于2019年11月27日~12月25日举行的人气投票，投票结果于2020年2月6日发售的《周刊少年Sunday》2020年13号上公布

排名共有100位角色，此处只列出前15名

古见硝子（83324pt）
只野仁人（48831pt）
尾根峰宁宁（25334pt）
万场木留美子（23534pt）
中中思春（17843pt）
长名奈津美（13963pt）
尾鸡枫（13309pt）
古见秀子（12742pt）
古见笑介（12460pt）
只野瞳（10610pt）
阿濑志吹（8989pt）
米谷忠释（7514pt）
夏木户澪（6525pt）
片居诚（6110pt）
山井恋（4925pt）

哔哩哔哩漫画

哔哩哔哩漫画于2020年3月4日~10日举行的人气投票，投票结果见此

古见硝子（5835票）
只野仁人（2930票）
只野瞳（748票）
古见笑介（591票）
长名奈津美（475票）
万场木留美子（411票）
中中思春（393票）
尾鸡枫（354票）
古见秀子（337票）
夏木户澪（324票）
尾根峰宁宁（207票）
阿濑志吹（171票）
米谷忠释（113票）
岸姬子（104票）
古见将贺（81票）
山井恋（60票）
加藤三九二（56票）
上理卑美子（55票）
佐佐木彩美（40票）
矢田野真花琉（25票）

衍生作品

电视剧

2021年7月23日宣布真人电视剧化，于2021年9月6日~11月1日在NHK综合频道的“夜剧”时段播出，全8话。

STAFF

原作：小田智仁
脚本：水橋文美江
音楽：瀬川英史
导演：瑠東東一郎（1~2、5、8话）、岡下慶仁（3~4话）、石井永二（6~7话）
演出：岡下慶仁（TV MAN UNION）、石井永二（TV MAN UNION）
総合演出：瑠東東一郎（MEDIA PULPO）
摄影：高野学
摄影协力：光英VERITAS初中・高中、JOYSOUND（第6话）
照明：坂本心
音声：池谷铁兵
影像技术：香山达也
音响效果：岩下康洋
编集：石井康裕（1、3、5、7话）、二宫心太（2、4、6、8话）
美术：小堺健司（1~4话）、平原道夫（5~8话）
服装：大平みゆき
发型：オオクボエミコ
假发：本间宽人
制作統括：樋口俊一（NHK）、高城朝子（TV MAN UNION）
制片人：大沼宏行（TV MAN UNION）（1、3、5、7话）、今山典子（2、4、6、8话）
制作、著作：NHK、TV MAN UNION

CAST

只野仁人：增田贵久
古见硝子：池田依来沙、冈本望来（童年）
万场木留美子：吉川爱
长名奈津美：优太朗、大冈周太郎（童年）
阿濑志吹：笕美和子
洁清子：大西礼芳
片居诚：沟端淳平
成濑诗守斗：城田优
班主任：永野宗典
旁白：高橋克実

动画版

基本信息

标题：古见同学有交流障碍症
原名：古見さんは、コミュ症です。
译名：Komi Can't Communicate
古见同学有交流障碍症（台译）
古见同学有社交障碍（香港&澳门译名）
作者：小田智仁
首播时间：1期：2021年10月6日~12月22日
2期：2022年4月6日~6月22日
总话数：1期：12
2期：12
制作公司：OLM TEAM KOJIMA
播放平台：日本：东京电视台、BS东视、大阪电视台、爱知电视台
全球：Netflix
中国大陆：腾讯视频
播放状态：已完结

2021年5月11日，於当天发售的《週刊少年Sunday》2021年24號上宣布動畫化決定，其后在第1期最后1话的结尾宣布第2期制作决定。

TV动画第1期于2021年10月6日~12月22日在东京电视台播出，全12话。动画第2期于2022年4月6日播出，全12话。

图集

STAFF

原作：小田智仁（小学馆《周刊少年Sunday》连载中）
总监督：渡边步
监督：川越一生
副监督：难波功
系列构成：赤尾凸
角色设计：中岛敦子
主动画师：早川麻美、野村治嘉、鸟井隼人
首席动画：并木祐一
道具设计：佐藤和巳
美术监督：佐藤胜
色彩设计：林由稀
摄影监督：并木智
剪辑：小岛俊彦
音响监督：渡边淳
音响效果：林佑树
音响制作：HALF H・P STUDIO
音乐：桥本由香利
音乐制作人：穴井健太郎、大隅启良
音乐协力：日本哥伦比亚、小学馆 Music & Digital Entertainment
企划：丸茂礼、高泽邦仁、泽边伸政、北条真、远藤哲哉（1期）、东山敦（2期）
原作协力：市原武法（1期）、大岛一范（2期）、小仓功雅、吉本有李
顾问：长谷川友纪
制作人：红谷佳和（东京电视台）、伊藤香织、近藤秀峰、谷口博康、川崎あやね（1期）、间宫孝治（2期）
联合制作人：上村真由、丰岛敬亮（2期）、仲村里步
动画制作人：儿岛宏明
动画制作：OLM TEAM KOJIMA
动画制作协力：BUG FILMS
制作：小学馆集英社Production
出品：私立伊旦高校

CAST

各话标题

话数	日文标题	中文标题	剧本	分镜	演出	作画监督	总作画监督	改编自原作
第1期
第1话	コミュ01「喋りたいんです。」	交流01「我想说话」	赤尾凸	川越一生	早川麻美近藤瑠衣小川茜	中岛敦子	第1卷
第2话	コミュ02「幼馴染です。」コミュ03「殺し屋じゃないです。」コミュ04「はじめてのおつかいです。」	交流02「发小」交流03「不是杀手」交流04「第一次帮买东西」	柴田匠	安东大瑛	泽村亨村上彩香森本浩文	广田茜
第3话	コミュ05「あがり症です。」コミュ06「携帯電話です。」コミュ07「委員会決めです。」コミュ08「間違い電話です。」コミュ09「齋藤さんです。」	交流05「对人恐怖症」交流06「手机」交流07「班委会选举」交流08「打错电话了」交流09「斋藤先生」	川越一生	田中貴大	吉田翔太森悦史吉田和香子近響子袖山麻美	中岛敦子
第4话	コミュ10「身体検査です。」コミュ11「恋です。」	交流10「体检」交流11「恋爱」	川畑荣郎	香月麻衣子小川茜	广田茜	第2卷
第5话	コミュ12「夏服です。」コミュ13「体力測定です。」コミュ14「ヤサイニンニクアブラマシマシカラメです。」コミュ15「血の契約です。」	交流12「夏装」交流13「体力测试」交流14「面要柔软的不放油少放生姜蔬菜」交流15「血之契约」	笔坂明规	内野宫晃希	野上慎也 Song Hyeonju Park Songhwa Bae Geonyeong Park Jaeseok	中岛敦子广田茜
第6话	コミュ16「ギャグです。」コミュ17「買い物です。」コミュ18「美容院です。」コミュ19「モヤモヤです。」コミュ20「テスト勉強です。」コミュ21「夏休みです。」	交流16「段子」交流17「购物」交流18「美发店」交流19「纠结」交流20「考前复习」交流21「暑假」	铃森ゆみ	渡部稳宽	村田尚树	小田真弓山下菜摘中熊太一吉田翔太古池由香里	广田茜
第7话	コミュ22「プールです。」コミュ23「かき氷です。」コミュ24「図書館です。」コミュ25「公園です。」	交流22「游泳池」交流23「刨冰」交流24「图书馆」交流25「公园」	北条史也	横手飒太	藤崎真吾金内惠美里森谷春树小园菜穗	中岛敦子	第3卷
第8话	コミュ26「お盆です。」コミュ27「お祭りです。」コミュ28「夏休みも終わりです。」	交流26「盂兰盆节」交流27「庙会」交流28「暑假即将结束」	赤尾凸	笔坂明规	石田畅	野上慎也 Song Hyeonju Jo Wonha Bae Geonyeong Kim Ranyeong	第3卷第4卷
第9话	コミュ29「田舎の子です。」コミュ30「テレビゲームです。」コミュ31「アルバイトです。」コミュ32「顔にゴミがついてます…です。」	交流29「乡下孩子」交流30「电子游戏」交流31「打工」交流32「脸上有脏东西	铃森ゆみ	川畑荣郎	徐惠真	日影工房	广田茜
第10话	コミュ33「体育祭です。」コミュ34「ちょっと苦しいような気持ちです。」コミュ35「プリントシールです。」	交流33「运动会」交流34「有点痛苦的心情」交流35「大头贴」	矢岛哲生	是本晶	早川麻美香月麻衣子近藤瑠衣金城美保	中岛敦子
第11话	コミュ36「文化祭の出し物です。」コミュ37「文化祭準備です。」コミュ38「チラシ配りです。」コミュ39「文化祭前日です。」コミュ40「メイドです。」	交流36「文化节摆摊」交流37「文化节准备」交流38「发传单」交流39「文化节前日」交流40「女仆」	博多正寿	野吕真太郎	高木淳福岛喜晴	广田茜
第12话	コミュ41「文化祭です。」コミュ42「後夜祭です。」コミュ43「打ち上げです。」	交流41「文化祭」交流42「后夜祭」交流43「庆功宴」	赤尾凸	博多正寿川越一生	川畑荣郎石丸史典川越一生	野村治嘉金城美保土方友希小川茜難波功香月麻衣子近藤瑠衣广田茜早川麻美	中岛敦子	第5卷
第2期
第13话	コミュ44「冬の訪れです。」コミュ45「不良です。」コミュ46「中々さんちで勉強です。」コミュ47「期末テストです。」	交流44「冬天来临」交流45「不良少年」交流46「在中中同学家学习」交流47「期末考试」	赤尾凸	川越一生	是本晶	小川茜近藤瑠衣石丸史典	中岛敦子
第14话	コミュ48「台風です。」コミュ49「妄想です。」コミュ50「ネコカフェです。」コミュ51「愛してるゲームです。」	交流48「台风」交流49「妄想」交流50「猫咖」交流51「"我爱你"游戏」	铃森ゆみ	顶真司	石田畅	清水博幸樱井木之实成濑蓝山村俊了	中岛敦子早川麻美广田茜
第15话	コミュ52「気持ちです。」コミュ53「妄想です。2」コミュ54「お昼のお誘いです。」コミュ55「石焼き芋です。」	交流52「想法」交流53「妄想2」交流54「约午饭」交流55「烤红薯」	小岛正士	前屋俊广	野上慎也 Bae Genon yeong Kim Ran yeong Hwang Mi jeong Han Eun mi Park Song hwa
第16话	コミュ56「メリークリスマス…です。」	交流56「圣诞快乐」	博多正寿	-	中岛骏石原彩子大久保步美关本美穗南伸一郎
第17话	コミュ57「雪だるまです。」コミュ58「雪合戦です。」コミュ59「年末です。」コミュ60「元旦です。」	交流57「堆雪人」交流58「打雪仗」交流59「年末」交流60「元旦」	高木启明	近藤瑠衣中野彰子	中岛敦子小川茜
第18话	コミュ61「それぞれのお正月です。」コミュ62「アイススケートです。」コミュ63「風邪です。」	交流61「各自的正月」交流62「溜冰」交流63「感冒」	小岛正士	前田基匡	迫江沙罗平马浩司前岛弘史金正男渡边桂太松本胜次野村治嘉玄机株式会社	中岛敦子早川麻美广田茜小川茜
第19话	コミュ64「誤解です。」コミュ65「幻覚です。」コミュ66「ナルシストです。」コミュ67「修学旅行の班決めです。」	交流64「误解」交流65「幻觉」交流66「自恋狂」交流67「决定修学旅行的小组」	菅野幸子	香月麻衣子	中岛敦子广田茜
第20话	コミュ68「修学旅行です。」	交流68「修学旅行」	小岛正士	桥本光夫	丹泽学福岛喜晴	中岛敦子早川麻美广田茜
第21话	コミュ69「修学旅行2日目です。」	交流69「修学旅行第二天」	博多正寿	前屋俊广	-	中岛敦子早川麻美广田茜小川茜
第22话	コミュ70「バレンタインです。」	交流70「情人节」	小岛正士	-	樱井木之实杜伟峰魏旭龙陈亮 Park Song-hwa Kim Ran-yeong Han Eun-mi Song Hyeon-ju Back Yeon-ju Jo Won-ha	中岛敦子
第23话	コミュ71「伝線です。」コミュ72「鬼に金棒です。」コミュ73「甘いです。」コミュ74「ケンカです。」	交流71「跳线」交流72「鬼使神差」交流73「好说话」交流74「吵架」	赤尾凸	川畑荣郎	中野彰子 Lee Jong Man Ho Sung Jin
第24话	コミュ75「ホワイトデーです。」コミュ76「1年間です。」	交流75「白色情人节」交流76「这一年间」	四之宫春小岛正士川越一生	四之宫春川越一生	近藤瑠衣香月麻衣子早川麻美小川茜广田茜野村治嘉土方友希

注释

外部链接

分类:日本漫画作品分类:小田智仁作品分类:古见同学有交流障碍症分类:日常题材分类:喜剧题材分类:校園题材分类:恋爱题材分类:周刊少年SUNDAY

览毕，何不一言？

超时空辉夜姬

Mtoly — Sat, 07 Mar 2026 06:53:27 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Anime/Cosmic-Princess-Kaguya

超かぐや姫！ / Cosmic Princess Kaguya!

项目	信息
原名	超かぐや姫！
常用译名	超时空辉夜姬！ / 超时空辉耀姬！
导演	山下清悟
剧本	夏生さえり、山下清悟
主演	夏吉优子、永濑安奈
角色设计	月夜见角色设计：へちま；现实角色设计：永江彰浩
音乐	Conisch
制作公司	Studio Colorido、STUDIO CHROMATO
片长	142分钟
产地	日本
上映信息	全世界：2026年1月22日（网络）；日本院线：2026年2月20日
官方网站	https://www.cho-kaguyahime.com/

《超时空辉夜姬！》（日语：超かぐや姫！，英语：Cosmic Princess Kaguya!）是 Studio Colorido 与 STUDIO CHROMATO 制作的原创网络动画电影，于2026年1月22日由网飞独占上映，并有小说、漫画等衍生作品。

本作介绍

2025年11月5日，释出预告PV及预告视觉图。于2026年1月22日由网飞独占上映。

2026年2月20日，于日本剧场限定上映，原定上映一周，后上映时间延长。2026年3月13日，日本全国上映。

本作由山下清悟担任导演，夏生さえり与山下清悟担任编剧。

本作故事与《竹取物语》和辉夜姬有关。

本作歌曲由多名 VOCALOID P 提供。

预告视觉图	主视觉图

视觉图	日本全国上映纪念视觉图

剧情简介

梦与希望汇聚的虚拟空间，「月夜见」^[1]。 少女们的相遇， 以及为离别而设的舞台，就此拉开序幕——

不久之后的未来。就读于东京都内升学向高中的17岁女高中生，酒寄彩叶，过着努力兼顾兼职和学业，超级忙碌的每一天。她每天的慰藉，就是看互联网上虚拟空间「月夜见」的管理员兼超人气主播，月见八千代的直播。在任何人都能创建自己的分身，自由进行创作活动的「月夜见」里，彩叶一边为八千代应援，一边在对战游戏中稍微赚点零花钱。

就在某一天回家的路上，彩叶发现了一根发着七彩闪耀光芒的电竞风电线杆。 在里面的，竟然是个无比可爱的婴儿。彩叶无法置之不理，把婴儿带回了家，而婴儿转眼之间长大，变成了和彩叶差不多年纪的女孩子。 "你，难道说是辉夜姬吗？"

长大后的辉夜姬任性无比。在辉夜的请求（任性）下，彩叶决定帮助她在月夜见的主播活动。彩叶作为制作人创作音乐，而辉夜作为主播进行演唱，两人就这样一点一点地敞开心扉。她们不知道的是，要把辉夜带回月亮的不祥阴影，已经近在眼前——

这是，一个前所未见的「辉夜姬」的故事。

主要角色

辉夜（かぐや / Kaguya）

月夜见	现实

CV：夏吉优子

来自月亮的神秘少女。为了寻找乐趣，决定试着在虚拟空间「月夜见」进行主播活动。活力十足，性格奔放。最喜欢彩叶了。

酒寄彩叶（酒寄さかより彩葉いろは / Sakayori Iroha）

月夜见	现实

CV：永濑安奈

17岁女高中生。在学校是学习和运动都很出色的优等生，但实际上是靠自己赚取生活费和学费的辛苦之人。是「月夜见」顶流主播月见八千代的粉丝。有音乐经验，会作曲，但因为某个原因放弃了。

月见八千代（月見るなみヤチヨ / Runami Yachiyo）

CV：早见沙织

虚拟空间「月夜见」的管理员兼顶流主播。能歌善舞又会分身的8000岁（设定）神秘AI。非常热爱任何人都能自由进行创作活动的「月夜见」空间，今天也在默默守望大家的活动。

绫䌷芦花（綾紬あやつむぎ芦花ろか / Ayatsumugi Roka）

月夜见	现实

CV：青山吉能

彩叶的闺蜜，「月夜见」中的美妆博主。拥有引人注目的美貌和细腻的个性。

谏山真实（諌山いさやま真実まみ / Isayama Mami）

月夜见	现实

CV：小原好美

彩叶的闺蜜，「月夜见」中的美食博主。帝明的粉丝。一个按自己节奏吃饭的稳重人。

帝明（帝みかどアキラ / Mikado Akira）

CV：入野自由

彩叶的哥哥，著名职业游戏团体「黑玛瑙」的领袖。一位有才华、有魅力的玩家，他喜欢华丽的制作，把全部精力都投入到娱乐观众上。

驹泽乃依（駒沢こまざわ乃依のい / Komazawa Noi）

CV：松冈祯丞

热门职业游戏团体「黑玛瑙」的成员。雷的弟弟。平时是个懒人，但只要有了动力就会坚定地做下去。

驹泽雷（駒沢こまざわ雷らい / Komazawa Rai）

CV：内田雄马

热门职业游戏团体「黑玛瑙」的成员。乃依的哥哥。性格冷静，话不多，但节奏感很好，唱歌很厉害。

其他角色

FUSHI	忠犬宅公	乙事照琴	犬DOGE

STAFF

监督：山下清悟
剧本：夏生さえり、山下清悟
月夜见角色设计：へちま
现实角色设计：永江彰浩
LIVE演出：中山直哉
美术监督：宍户太一
色彩设计：广濑泉
月夜见概念设计：東みずたまり、フジモトゴールド（ゴキンジョ）
现实概念设计：刈谷仁美
CG监督：町田政弥（Stimulus Image）
CG背景：草间彻也（QUUNPLANT）
剪辑：木南凉太
摄影监督：千叶大辅（Folium）
音乐：Conisch
音响监督：三好庆一郎
企画、制作：山本幸治
出品：Colorido·TWIN ENGINE PARTNERS
动画制作：Studio Colorido、STUDIO CHROMATO

CAST

角色	声优
辉夜	夏吉优子
酒寄彩叶	永濑安奈
月见八千代	早见沙织
帝明 / 酒寄朝日	入野自由
驹泽雷	内田雄马
驹泽乃依	松冈祯丞
绫䌷芦花	青山吉能
谏山真实	小原好美
FUSHI	钉宫理惠
忠犬宅公	菲鲁兹·蓝
乙事照琴	花江夏树
酒寄红叶	坂本真绫
酒寄朝久	铃村健一
班主任	小林亲弘
音乐老师	宫泽清子
犬DOGE	庄司更纱

衍生作品

漫画版

由米田タロウ负责作画，于 Comic Comp 连载。单行本由 KADOKAWA 出版，于 Kadokawa Comics A 发行。

册数	封面	出版日期	ISBN
1		2026年2月10日	978-4-04-811757-9

小说版

由桐山なると著作，うらたあさお插画。单行本由 KADOKAWA 出版，于 Fami通文库发行。

封面	发行时间	ISBN
	2026年1月30日	978-4-04-738734-8

公式指南书

标题为《超かぐや姫！公式ガイドブックハッピーエンドのその先へ！》。由 KADOKAWA 出版。

封面	发行时间	ISBN
	2026年1月30日	978-4-04-117055-7

注释与外部链接

注释：

「月夜见」名称源自日本神话传说中的月神"ツクヨミ"（Tsukuyomi）。该词有多种汉字写法，如月读、月夜见等。本作大多使用片假名写法"ツクヨミ"，在虚拟空间内的鸟居上方悬挂的文字则使用了"月夜见"的汉字写法。

外部链接：

动画官网（日文）
官方推特（X）（日文）
官方YouTube频道（日文）

分类：日本动画作品 · 动画电影 · Studio Colorido作品 · STUDIO CHROMATO作品 · 音乐题材 · 偶像题材 · 百合题材 · 奇幻题材 · 科幻题材 · 竹取物语题材

本文内容引自萌娘百科，文字内容使用《知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆（CC BY-NC-SA 3.0 CN）》许可协议。

览毕，何不一言？

MT5700M-CN

Mtoly — Mon, 10 Nov 2025 07:17:19 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Router/mt5700m-cn

介绍

MT5700M-CN 基于 3GPP Release 16 技术，支持 5G NR NSA 和 SA 双模组网，支持 5G 及行业特色功能：超级上行，SUL，uRLLC，5G LAN，高精度授时，网络切片以及行业定制等。
MT5700M-CN 支持 5G Sub-6 GHz，支持频段覆盖中国大陆，向下兼容 4G/3G。5G NR 上下行峰值速率分别可达4Gbps 和 1.5Gbps，可满足行业应用高带宽要求。
MT5700M-CN 采用 M.2 封装，采用高可靠性器件以及工业独特设计，适应工业环境的多样化，工作温度范至 -30℃~70℃。MT5700M-CN 集成了丰富的硬件接口，包括 USB/XGE/PCIe/UART/SPI/I2C/USIM/GPIO 等，充分满足工业设备接口需求。

MT5700M-CN 因其上手容易，操作简单，支持 3CC 载波聚合，全新模组的价格相较于其他同类模组有优势，深受 5G CPE DIY 玩家的喜爱，但也因其私有 AT 手册不完整，导致部分功能不可用，可玩性相较于 移远 Quectel 模组略差。

购买方式

淘宝、闲鱼等平台均有个人、物联网设备厂家售卖，市场价在￥650 ~ ￥750 之间

🔌 连接方式

MT5700M-CN 采用 M.2 Key-B 接口封装，支持 USB 3.0, PCIe, PHY 数传。

🔗 USB 3.0

作为 USB 设备 连接到主机，上报 USB 端口形态 后，与主机通讯工作。现已支持 Windows, Linux

共有以下 9 种端口形态，可以通过 AT 命令 AT^SETMODE=<端口形态 ID> 进行设置，命令发送后自动重启。

ID	解释
0	🐧 Linux ECM Normal, `ECM+DIAG+PCUI+Serial_B+Serial_C+GPS`
1	🪟 Windows NCM Normal, `DIAG+PCUI+Serial_B+Serial_C+GPS+NCM`
2	🐧 Linux ECM Debug, `ECM+DIAG+PCUI+ADB+Serial_B+Serial_C+GPS`
3	🪟 Windows NCM Debug, `DIAG+PCUI+Serial_B+Serial_C+GPS+ADB+NCM`
4	🐧 Linux NCM Normal (默认), `NCM+DIAG+PCUI+Serial_B+Serial_+GPS`
5	🐧 Linux NCM Debug, `NCM+DIAG+PCUI+ADB+Serial_B+Serial_C+GPS`
6	🪟 Windows RNDIS, `RNDIS+DIAG+PCUI+Serial_B+Serial_C+GPS`
7	🪟 Windows MBIM (尚未支持), `MBIM+DIAG+PCUI+Serial_B+Serial_C+GPS`
8	📞 PPP, `Modem+DIAG+PCUI+Serial_B+Serial_C+GPS`

几个重要的端口形态解释:

🖥️ PCUI: 用于 AT 通讯
📊 Serial_B/C: 与 DIAG 结合使用，收集日志信息
🔍 DIAG: 用于调试和日志，详见 日志获取
🛠️ ADB: ADB 端口，只在 debug 固件中可用，无论是否处于 Debug 端口形态

实践上建议使用 NCM 端口形态，该端口提供了两个端点，提高了带宽利用。

💻 PCIe 模式

作为 PCIe RC 模式运行，暂不支持其他模式。

应用指南

准备工作

安装 Windows/Linux 驱动
安装任意 串口软件（如 XCOM, SSCOM, ...），串口参数往往不需要做调整。
确保处于对应的端口形态，可以枚举出对应的端口。（Windows 可在 设备管理器 中查看， Linux 可以输入 lsusb 查看）

AT 通讯端口：

如果处于 Windows 系统，端口为 Application Interface
如果处于 Linux 系统，设备枚举往往为 /dev/ttyUSB1

拨号上网指南

默认采用双栈网络 （IPv4 + IPv6），如需修改，请参考手册。

手动拨号

输入 AT^NDISDUP=1,1，观察回显，判断拨号是否成功。

如需要取消拨号，输入 AT^NDISDUP=1,0.

自动拨号

自动拨号在每次模块启动都会自动执行，无需手动干预。

如果在此之前进行过自动拨号的配置，需要先取消设置，否则新的设置无法生效，输入 AT^SETAUTODIAL=0.

如果是 USB 3.0 连接方式，输入 AT^SETAUTODIAL=1,1，观察回显。
如果是 PHY 网口连接方式，输入 AT^SETAUTODIAL=1,2，观察回显。

对于 PCIe 连接方式，我暂无主机设备，请参考手册自行研究。

LED 网络状态

模组默认关闭了 LED 显示，需要通过 AT^LEDSWITCH=1 开启，重启后生效。

❓模块升级与降级

因为缺失部分 Linux 平台的固件包，建议采用 Windows 平台主机进行升降级。

下载安装鼎桥平台驱动.
下载对应平台的升级导向，按升级导向要求进行升级、降级即可。

手册下载

链接中包含如下指导手册：

MT5700M-CN 5G模块硬件设计指南
5G LAN功能验证指导
5G切片功能测试指导
AT命令手册
DIAG TOOL 用户指南
FOTA升级指南
Linux内核驱动集成指导
USB接口应用指南
Windows USB 驱动安装指南
休眠唤醒指导书
功能应用指南
温保方案使用指南
近端升级指导书_Linux
近端升级指导书_windows
近端日志获取与工具集成指导书_Linux
近端日志获取指导书_Windows
高精度授时功能验证指导

著作权归 鼎桥通信技术有限公司 所有，如有侵权，请电邮 i@racel.dev，我将会在第一时间删除。

对 `MT5700M-CN` 兼容的软件

QModem: 模组管理插件，同时兼容 QWRT/LEDE/Immortalwrt/Openwrt
MT5700M PHY AT ETH Control: Python 脚本实现的网口连接方式控制脚本
Web UI: 由个人开发者开发的 MT5700M-CN 控制面板，暂不开源，请自行寻找下载

Linux 兼容

详细参见 Linux内核驱动集成指导，或者可以直接使用我写好的内核补丁。

如果加载了 usbserial 驱动，并且 lsusb 有模组对应的设备，可以手动执行 sudo /bin/sh -c 'echo 3466 3301 > /sys/bus/usb-serial/drivers/generic/new_id';

执行之后应当可以看到 /dev/ttyUSB* 的枚举。

FOTA 升级教程

服务器搭建

准备工作

此处使用 HTTP 而不使用 HTTPS，因为证书配置过于繁琐。

公网 nginx 服务器
二进制模组固件包
模组处于在网状态

假设固件包放在 /tmp/fota/full 文件夹下（截止到现在，你必须将其放置在 full 文件夹下)

假设你的 nginx 运行在 http://localhost/

nginx 配置

假设我们最终的 FOTA 下载链接为 http://localhost/download/b16

那么你的站点配置应该是：

location /download/b16 {
  alias /tmp/fota;
  allow all;
  autoindex on;
}

配置 FOTA 更新包

FOTA 更新包由鼎桥提供，但个人往往无法获取，这里给出我研究得出的一种配置方式，严格按照这种方式来配置就没有问题.

前面所提到的 full 文件夹下，应该包含三个文件，且务必严格保证命名一致:

FIRMWARE1.BIN - 二进制固件包，该包同 Linux 平台下使用的更新包，对于 Windows 平台下的更新导向，需要对其进行提取。
changelog.xml - 更新日志文件，必需
filelist.xml - 记录上两个文件的 MD5 以及大小，必需

changelog.xml



    
    1031
    
        
            1.product_name="MT5700M-CN"
            2.update_mode="0"
            3.source_version="1.1.6.0(SP1C02)"
            en-us

这里只需修改版本号。

filelist.xml



    
        FIRMWARE1
        0
    
    
        
            changelog.xml
            changelog.xml
            c
            86ed31415b5a0b978dfa677fa47bd1b1
            484
        
        
            FIRMWARE1.BIN
            FIRMWARE1.BIN
            c
            06801c391284f4a12d92c5f0f6d8b830
            62770696

对于不同版本的固件包，注意更新 md5 和 大小(size)。

执行 FOTA 更新

详情请见 FOTA 升级指南

输入 AT^FOTASTATE?，当前应返回 10，代表等待下载状态
输入 AT^FOTAOEMDL="url"，其中 url 填写上面的 http://localhost/download/b16
等待下载完成，可使用 AT^FOTADQL 观察下载进度
下载完成，状态回显为 40，输入 AT^FWUP 执行更新
更新准备完毕，状态回显为 50，设备将自动重启，进入 DLOAD 模式执行更新

如果设备重启后没有执行更新，说明你的固件包校验失败（鼎桥为每个固件包添加了数字签名），这往往发生在自行从 exe 中提取固件包，请你再次检查。

如果 FOTA 下载更新过程中出现错误，说明你的 FOTA 服务器配置有问题，请检查配置部分，检查 nginx access log.

固件包的 Magic code 为 55 AA 5A A5，直接在 .exe 文件中搜索提取即可，注意尾部要严格对齐。

📡 天线定义

📋 技术参数

览毕，何不一言？

H5000M 5GCPE CNC版

Mtoly — Thu, 06 Nov 2025 13:28:41 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Router/h5000m-5gcpe-cnc-version

Hiveton 5GCPE CNC版是一款基于MT7987+MT7991开发的一款高性能5GCPE方案，高达4核A53 2。4GHZ处理器、BE5040M速率原生WIFI7(3T3R+2T2R) 以及全硬件加速HNAT+QOS,轻松应对高性能高负载应用场景。可搭载1+8G或2+32G版本（最大支持4+256G需定制）可安装3052 USB协议标准5G模块。支持多种5G模组（RM500Q、500U、502Q、520N、520F、巴龙5700、FM350等常见模块），可支持内置WEBUI功能（部分模块支持）。

极宽的使用范围，适用于如：车载上网、户外直播、户外供网、智慧工地、智慧农业、智能制造等领域。

内容

Hiveton H5000M 5GCPE系统；高达3Gbps+ 5G基带下行速率支持；WIFI7 5000M速率；MTK高性能4核；开放系统支持OpenWrt；PD供电；双2.5G网口；DDR4 1G超大内存，8G EMMC超大闪存；5Gbps高速M2接口；
高性能4核A53处理器，主频高达2.4GHZ，具有软路由相同性能的同时支持全链路硬件加速，转发速率高达5G时具有极低的CPU占用
开放式操作系统，支持OpenWrt、IMMWrt等开源系统。海量插件，适用于不同领域用户专业需求。
支持多种5G模组 M2 标准模组尺寸，支持市面常见模组（详细支持情况联系店铺）提供高达5GBPS连接速率，可提供3Gbps以上下行速率，支持5GA
联发科高性能WIFI7 5000M速率，对比同类WIFI7CPE提升150%速率；MLO双频聚合：单设备同时连接2.4Ghz+5Ghz频段提供更好性能和可靠性；WPA3新一代安全加密协议，保障用网安全；Multi-RU提升传输效率；Preamble Puncturing 技术，更强抗干扰能力；
双2.5G网口，提供高速有线网络支持
无线高达128设备、有线高达300台设备轻松应对；
同类少有，不惜成本全铝合金一体CNC加工，精工制造注意每一处细节，7天线接口设计，保障信号覆盖每一处
主动式散热，使用高性能涡轮风扇，且支持无极调速

用户场景

直播领域：高速5GA网络+高性能WIFI7+PD供电非常适合户外直播
工业供网：接入工业内网，可提供高可靠高性能互联网出口，可提供安防、网关等设备用网需求
车载上网
室内组网：不办宽带即可享受高速上网、且不使用5G网络亦可当做高性能入户/旁路由
外贸公司：实现公司内旁路由网络支持，专线专网
开发者：超强处理器，支持Docker，可以安装各种插件提供网络服务之外的其他服务功能，例:Mysql、Kafaka、WEB服务器等开发服务

参数

处理器：MT7987 4核A53 2Ghz
射频：MT7991 WIFI7 BE5020M
内存：DDR4 1G/2G
存储：NAND256/EMMC8G/EMMC32G
网口：2X2.5G
供电：TypeC PD供电支持9V/12V/15V
尺寸：自己量

览毕，何不一言？

MT-5700模组固件升级方法

Mtoly — Thu, 06 Nov 2025 13:16:31 GMT

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://io0.icu/posts/Router/mt-5700-module-firmware-upgrade-method

MT-5700 模组有网状态下执行AT命令，即可开始远程刷模块固件

AT^FOTAOEMDL="http://fota.lazyc.at/b21/"

输入

AT^FOTADLQ

查询下载状态，最后一个数字是当前下载，倒数第二个数字是目标大小

输入

AT^FOTASTATE?

查询更新状态，如果是40，代表下载完成，是30代表正在下载，如果是40，则是下载完成

注：待下载完成后在执行下一步

输入

AT^FWUP

模块自动重启执行更新

等待即可，刷好后重启一下就看到升级b21固件成功了。

5700用AT命令在线刷固件，方便快捷，免去拆装模块用转接板升级的烦恼。还可以避免模块菊花频发插拔导致的松动

览毕，何不一言？