1️⃣ 服务器性能配置未达标#

搭建 Misskey 的服务器需要有充足的运行内存以支持构建，引用他人博客中的内容，至少需要2核、1.5GB空余内存才有可能部署成功。

我正好踩到此坑。最初搭建时什么也不懂，只是按照官方文档的流程 Ctrl + C Ctrl + V，以至于我自信使用1c1g的主机运行docker构建命令，然而不出意外地因内存不足而构建失败。后来决定换到我的家里云主机（系统: Windows Server）上运行，并通过 Cloudflare Tunnels 内网穿透提供给公网访问，使用 Tunnels 的好处是 i) 无需配置 SSL 证书和 ii) 无需服务器等。

2️⃣ 大陆网络 Git 克隆缓慢#

大陆网络环境从 GitHub 仓库克隆缓慢，可使用代理。

代理配置完成后，打开 Git Bash，设置临时环境变量再尝试克隆，可享受较快的速度。

1
export http_proxy=http://127.0.0.1:7890
2
export https_proxy=http://127.0.0.1:7890
3
git clone -b master https://github.com/misskey-dev/misskey.git

因为官方文档中提到克隆后需要检出 master 分支，而官方克隆到本地的分支默认检出为 develop 分支，所以可直接使用 -b master 参数指定分支克隆。

3️⃣ 大陆网络无法构建 Docker 镜像#

构建镜像过程中应全程使用代理让 Docker 访问国际网络，否则会报错。

构建 Docker 镜像大约耗时 3000 秒，构建过程内存几乎都是占满状态，看别人只需要 500 秒，比我主机耗时少得多。影响构建时间可能的因素是代理服务端网速、主机性能等。

4️⃣ 反向代理配置不全#

如果是通过 Cloudflare Tunnels 内网穿透，则无需配置反向代理。

配置 nginx 时需要注意配置客户端上传文件大小限制和 WebSocket 支持，否则在网页使用时会出现对应的问题。

官方文档已经有关于Nginxの設定的说明，给出的配置是完整且可用的，但我在配置过程中只是一味地按照 AI 的操作指令做事，几乎没有看官方文档，AI 确实仍然不够可靠。

另外，在使用 frp 进行内网穿透时，我使用了 certbot 实现 SSL 证书自动部署。

可用的配置内容参考（来自官方文档）：

1
# For WebSocket
2
map $http_upgrade $connection_upgrade {
3
    default upgrade;
4
    ''      close;
5
}
6

7
proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=cache1:16m max_size=1g inactive=720m use_temp_path=off;
8

9
server {
10
    listen 80;
11
    listen [::]:80;
12
    server_name <替换为你的域名>;
13

14
    # For SSL domain validation
15
    root /var/www/html;
16
    location /.well-known/acme-challenge/ { allow all; }
17
    location /.well-known/pki-validation/ { allow all; }
18
    location / { return 301 https://$server_name$request_uri; }
19
}
20

21
server {
22
    listen 443 ssl;
23
    listen [::]:443 ssl;
24
    http2 on;
25
    server_name <替换为你的域名>;
26

27
    ssl_session_timeout 1d;
28
    ssl_session_cache shared:ssl_session_cache:10m;
29
    ssl_session_tickets off;
30

31
    # To use Let's Encrypt certificate
32
    ssl_certificate     /etc/letsencrypt/live/<替换为你的域名>/fullchain.pem;
33
    ssl_certificate_key /etc/letsencrypt/live/<替换为你的域名>/privkey.pem;
34

35
    # To use Debian/Ubuntu's self-signed certificate (For testing or before issuing a certificate)
36
    #ssl_certificate     /etc/ssl/certs/ssl-cert-snakeoil.pem;
37
    #ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
38

39
    # SSL protocol settings
40
    ssl_protocols TLSv1.2 TLSv1.3;
41
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
42
    ssl_prefer_server_ciphers off;
43
    ssl_stapling on;
44
    ssl_stapling_verify on;
45

46
    # Change to your upload limit
47
    client_max_body_size 80m;
48

49
    # Proxy to Node
50
    location / {
51
        proxy_pass http://127.0.0.1:3000;
52
        proxy_set_header Host $host;
53
        proxy_http_version 1.1;
54
        proxy_redirect off;
55

56
        # If it's behind another reverse proxy or CDN, remove the following.
57
        proxy_set_header X-Real-IP $remote_addr;
58
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
59
        proxy_set_header X-Forwarded-Proto https;
60

61
        # For WebSocket
62
        proxy_set_header Upgrade $http_upgrade;
63
        proxy_set_header Connection $connection_upgrade;
64

65
        # Cache settings
66
        proxy_cache cache1;
67
        proxy_cache_lock on;
68
        proxy_cache_use_stale updating;
69
        proxy_force_ranges on;
70
        add_header X-Cache $upstream_cache_status;
71
    }
72
}

5️⃣ 错误配置对象存储#

如果对象存储链接设置错误，会导致用户无法上传图片到存储桶或无法从存储桶中访问图像。

首先，应该在云服务商控制台创建存储桶，并将其访问权限设置为公开以便所有人可访问，并获取后续配置对象存储时需要的字段值。需要注意存储桶名称中的英文字符应为全小写。

接下来实现配置，需要配置的设置项有：

• Base URL
• 存储桶
• 端点
• 可用区
• Access key
• Secret key
• 使用 SSL (开)
• 使用代理 (关)
• s3ForcePathStyle (开)

以上设置项目，可用区、存储桶名称、Access key、Secret key 这 4 个配置项应该不会配置错误，需要特别注意的配置项是 Base URL 和端点，它们分别决定资源是否可成功被外部访问和能否成功上传到存储桶。

以下使用 Oracle Cloud 的服务进行举例。

对于端点(Endpoints)，可参考文档说明找到你所选地域的专用 API 端点，比如对于日本东京区域，可找到以下端点：

1
https://<object_storage_namespace>.compat.objectstorage.ap-tokyo-1.oci.customer-oci.com

注意需要将 <object_storage_namespace> 替换为存储桶的名称空间，这在控制台可看到。替换后，这就是正确的端点链接，可填写到 Misskey 对象存储配置项“端点”的输入框中。

对于 Base URL，Misskey 将使用 Base URL + /文件名 组成访问链接。它的获取方法的话，可以手动上传一个文件到存储桶，并复制其访问链接，删除最后的斜杠和文件名，即是正确的 Base URL。比如有以下文件访问链接：

1
https://objectstorage.ap-tokyo-1.oraclecloud.com/n/n14514191981/b/misskey-media/o/b43d6709-a490-46dc-9668-57f2167d7e56.png

高亮部分即是我们需要的 Base URL。另外你可以注意到链接中包含了可用区（ap-tokyo-1）、名称空间（n14514191981）和存储桶名称（misskey-media）的值。

6️⃣ 添加中继总是显示“待审核”#

添加中继总是显示“待审核”，大概是因为部署 Misskey 主机的网络问题，大陆网络无法访问这些中继的网站，可以使用代理以便访问网站，中继添加完成后可关闭代理。

如果主机处于中国大陆网络环境，关闭代理后将无法访问那些在中国大陆无法访问的实例，即便本实例用户处于国际网络环境，也无法搜索到位于那些实例的用户。

7️⃣ 文件上传到云盘很慢#

实际使用时出现了文件上传缓慢的情况，经过实测，最大影响因素是从用户上传文件到服务主机接收到文件这一过程。服务主机接收文件速度缓慢，将导致用户使用网页时出现上传进度为 100% 但迟迟等不到上传成功的情况。

接下来分析此问题。

对于以下配置：

1. 使用对象存储
2. 借助 Cloudflare Tunnel 或 frp 进行内网穿透
3. 服务主机使用代理访问外部网络

文件上传有以下大致流程：

用户主机 —①—( CF Tunnel 或 frps 主机 )—②-> 服务主机（无公网） —③—( 代理服务 )—④-> 对象存储服务

详细检视一下此流程：

① 用户上传

• 从用户设备通过内网穿透上传文件到服务主机，主要上传速度取决于用户网速。

② 服务主机接收

• 服务主机接收内网穿透主机传来的用户上传的文件。
• 服务主机的文件接收速度主要取决于服务主机从 Tunnel 或 frps 主机的文件下载速度。
• Note: 此步骤与步骤①应该是同时进行的，而不是等到用户上传完成文件到内网穿透主机后再上传到服务主机。

③ 通过代理

• 服务主机通过本机代理端口上传文件到对象存储服务。
• 如果服务主机在不使用代理时上传速度更快，应在代理软件中添加直连对象存储服务域名的规则。

④ 上传文件到对象存储服务

• 服务主机将文件上传到对象存储服务。
• 上传速度主要取决于服务主机的上传带宽或服务主机访问代理服务的上行速度（如果设置为全局代理）。

延迟发生的地方：

• 经过实测，延迟主要发生于步骤②，即服务主机接收文件速度缓慢；上传文件的话，对于 10MB 的文件，一秒左右即可上传完成。
• 如果使用 Cloudflare Tunnel 进行内网穿透的话，这主要和 Cloudflare 分配的 IP 在中国的连接速度不佳有关，导致用户上传流量在到达服务主机前可能在“环球旅行”。

解决方法：

• 要解决此问题，可搜寻 Cloudflare Tunnel 优选 IP 相关内容并配置，实现内地访问加速。这应该也可以同时解决媒体文件加载缓慢的问题。