@sitboy #12
服务器启动后用 itdog 之类的在线服务测试一下连通性, 主要测试 21115~21117 端口 (其中 21116 需要额外允许 UDP 协议入站).
除此之外客户端也需要如图所示额外配置指向你的服务器 (API 服务器为可选).
https://i.imgur.com/EtyzSdo.png

----
前段时间官方公告屏蔽了中国大陆访问.

@kneo #3
为了所谓的安全, 不能像以前那样通过程序内部的设置批量设置文件关联 (一定要通过系统设置手动为几十种文件类型挨个关联一次).
视觉上能变得透明的地方较 Windows 7 更多, 总体而言打磨不足.

@robinchina #7 按下 Win + E 打开资源管理器的延迟目测约 0.7 ~ 1 秒不等.

https://i.imgur.com/EPLegn2.png
https://i.imgur.com/huX6coX.png 蒙的.

仅适用于 Windows 版本:
a) 对客户端容器化 (Turbo Studio 或 VMware TthinApp 之类的软件) 处理, 可执行文件和配置文件打包后作为 "单文件绿色版软件" 发出. 对方只需在拿到文件后双击即可等待连接. 缺点是有较高概率会被主流杀软 (已知 Windows 自带的 Defender) 报毒;
b) 用常规方法压缩脚本 + 可执行程序, 对方拿到并解压后从脚本开始执行. 脚本的核心功能是复制配置文件到指定路径并以便携模式启动客户端. 这种在步骤上比上面要稍微复杂一点, 并且需要确保对方不会直接双击压缩包内的文件以防客户端做出意料之外的行为.

----
配置信息置入文件名虽然是官方文档给出的方法之一, 但如果服务器生成的密钥过长或含有 Windows 文件名不允许的字符, 则这种方法在有时不可取. 至少我在看了服务器生成的公钥并试验后发现并不适合.

@AlphaTauriHonda @gogogo2000
感谢解答, 最近花了点时间重新配置 SmartDNS, 解析的 IP 已经恢复正常. 另外 Passwall 也确实使用了 Xray 作为关键的代理程序.
不过有个槽点: "流量嗅探" 功能在 Passwall 上是全局设置, 会影响到添加到 Passwall 的所有节点. 这种设计会导致这些节点无法用于 Tor 前置代理.

这段时间也发现另一个奇怪现象, 首先讲一下我的环境: 我的群晖上开着一个 Windows 虚拟机 (虚拟机的任何流量都不经过 Passwall 代理), 里面又运行了 V2RayN, 主要用途是不定期给大量节点测试可用性并手工挑选出几个对我可用的 (挑选的节点会导入到 Passwall).
在挑选期间发现某些节点仍然无法访问 matrix.org (实际 URL 为 https://matrix.org/_matrix/push/v1/notify), 我的判断标准是用 curl 命令拿到其 HTTP 状态码 (405 为正常, 000 为失败), SmartDNS 配置重做之后, 这个现象已经大大改善.

图来了.
[]( https://imgur.com/C11efUD)
[]( https://imgur.com/EXZdzIn)

@asuraa #60 可以参考基于 Docker 的教程, 因为我的实例也基于 Docker.
https://hub.docker.com/r/coturn/coturn

首先要确保整个网络环境具有公网 IPv4, 双栈公网 (公网 IPv4 + 公网 IP v6) 最佳.
如果在 Docker 中运行 coturn, 网络模式不建议使用桥接 (bridge), 因为对于 coturn 这种需要计划映射大量端口的容器, 桥接模式会导致容器启动非常慢, 可选模式为 host.

暴露到公网的操作期间 IP 地址与端口相关:
端口: 对外开放端口 3478 (TCP / UDP) / 5349 (TCP / UDP) / 49152 ~ 65535 (UDP);
IPv4: 如果 coturn 实例所处的机器 (或 coturn 的容器) 没有获取到公网 IP 地址, 那么需要上游的路由器或类似设备转发外部的流量到实例所处的机器 (或 coturn 的容器) 的上述端口;
IPv6: 确保该机器 (或 coturn 的容器) 能获取到公网 IP 地址 (类似 240* 开头的那种), 确保该机器的防火墙放行上述端口的入站流量.

可以额外为 coturn 实例的 IP 地址分配一个域名方便在各种场合调用.

--------
自用配置文件参考 (配置文件位于 /etc/turnserver.conf):
```
# 冗余的日志输出
verbose

# 启用认证
use-auth-secret
# 值为认证时使用的密钥
static-auth-secret=

# 数据库路径
userdb=/var/db/turndb

# 值为你给 coturn 实例分配的域名 (它可以不和你的域名完全一致, 但至少必须有)
realm=

# 证书公钥 (证书最好是带完整证书链 (fullchain) 的)
cert=/etc/cert.pem
# 证书私钥
pkey=/etc/pkey.pem

# 忽略所有 STUN 入站流量
no-stun

no-rfc5780
no-stun-backward-compatibility
response-origin-only-with-rfc5780

# 限定 TLS 版本 (以下几行会导致仅启用 TLS 1.3)
no-sslv2
no-sslv3
no-tlsv1
no-tlsv1_1
no-tlsv1_2

```

@vemodalen821 #20
刚才看了一下 VoceChat 的文档, 它有一个对位于境内的服务器来说很致命的问题: Android 客户端的推送依赖 FCM, 这一点不如 Element. Element (G2) 支持使用 ntfy 作为推送网关, 而 ntfy 也可以自建, 从而解决了移动客户端的推送问题.
至于 iOS, Synapse 不需要额外配置, 仅需要其所在的系统环境 (或容器) 能正常请求 matrix.org/_matrix/push/v1/notify 即可.

@vemodalen821 #20
鉴于苹果要求 "完成备案的应用才能上架" 的原因, Element (包括各种兼容 Matrix 的第三方客户端) 在国区 AppStore 一定会找不到, 如果你青睐了这个方向, 则需要一个外区账号安装客户端.

另外: Element 是第二代官方客户端 (推送流程需要代理辅助, 而且客户端截至停更也依旧不稳定经常崩溃), 现已事实上停更, 第三代 Element X 还处于早期阶段 (功能不全).
其实此时 Android 机器的门槛客观上更低.

@YamatoRyou #17
然而毕竟 Matrix + Element 方案最适用的场景是真人或机器人聊天, 单纯的通知推送, 用这个有杀鸡用牛刀个感觉. 那些专用的推送工具会更合适. 我说的这些都是一些废话, 当个参考就好.

@YamatoRyou #16
刚才没注意看要求细节, 补充一些内容:
ntfy 发送图像只能以附件的形式 (甚至可能不能直接查看), iOS 客户端当前版本不显示发送的图像, Android 客户端恶要求下载到本地才能查看. 这种情况下 ntfy 可能不适合你.

建议部署 Matrix + Element 或其它兼容的客户端, 我的其中用法之一是每小时收集指定 URL 显示的网页并对其截图 (截图工具是无头 Chrome), 最后通过 Matrix 发送到我的手机或其它机器上. 这种是可行的, 并且已经用了很久.
图像的呈现方式: Element 在 iOS 上不能直接在通知条目上显示图像, Android 则可能取决于系统 (我的 2 个手机都可以直接在通知上显示那张图像的一部分). 但共同点是只需点击对应的通知即可跳到对应的图像.

Markdown 问题: Element 支持 Markdown, 但在所有移动客户端上存在渲染和排版上的缺陷, 比如行距过大导致的不美观.

ntfy 可以跨平台 (现在正在 Windows / Android / iOS 下同时使用), 但 iOS 有一些额外注意事项.
https://github.com/binwiederhier/ntfy

非二次开发, 仅以满足需求为目的自建 Matrix + Element 体验 2 年的感受:
1. 毕竟是国外项目, 本土化不足是必然;
2. 服务端 (Synapse) 客户端 (Element) 均有长期存在并且未修复的 bug, 特定条件下会影响使用;
3. 和 Telegram 一样不支持 CJK 文字搜索, 有时会很难受;
4. 推送需要慢慢调教, 我在这方面走过一些弯路.

Matrix 基金会疑似资金原因在上个月存档了 Synapse (Dendrite 目前存活), Element HQ fork 了一个继续维护;
官方的客户端 (Element 家族) 要说能用也确实能用, 但也仅限于能用, 仍有许多奇怪的小问题. 如今他们大多数人力资源着重开发下一代客户端 (Element X), 现有客户端除 Web 外均已进入摆烂状态 (仅修复安全问题和高优先级错误, 隐约感觉到一股微软的作风). 过去 2 年我给他们的仓库反馈了一些 issues, 但大多数被 tag 后就再也没有下文.

ntfy +1, Bark 无法跨平台.
需要注意如果是自建的 ntfy 在 iOS 上使用, 需要在服务端配置文件中加一行: upstream-base-url: "https://ntfy.sh"
否则会导致 iOS 客户端接收通知延误甚至丢失.

@totoro625 #2 最近在站内外疯狂翻阅 "因私自架设 Web 服务导致宽带被掐" 的遭遇帖, 但我和家里人又有这类刚需.

通过 Update Blocker 禁用更新不靠谱, 在 Windows 11 上存在 "禁用不彻底" 的现象, 中枪若干次.
禁用更新后并且系统启动一段时间后关机或重启, 仍然提示 "正在配置更新".
鉴于我用 Shadow Defender 防止系统意外更改, 前几天甚至出现了在影子模式下 "关机 -> 开机 -> 正在配置更新 -> 重启 -> 正在配置更新 -> 重启 -> 正在配置更新 -> 重启..." 的死循环, 只能在 PE 下解除影子模式后开机, 更新完毕后再进入影子模式.

路由器上执行一些脚本发送到邮箱相对靠谱 (2017 至今很稳, 收件箱攒了当时至今的所有邮件).

@yangyang2022 #57 ntfy 甚至还能让自己的实例作为推送网关, 不用担心未来因为上级服务 (unifiedpush.org) 被墙导致 Android 客户端收不到推送.