Docker on 亂筆

拋棄所謂「客戶端」，直接使用 Mihomo 內核

Thu, 03 Jul 2025 10:30:00 +0000

自從開始使用 Clash/Mihomo，我和大多數人一樣選擇了基於其內核的圖形化客戶端——圖方便。實際上，這些 Mihomo 客戶端本質上都差不多：內核都是同一個，他們主要負責提供一個易用的界面、管理配置文件、訂閱更新，以及 GUI 下的系統代理設置。基於這一點，我認為判斷一個 Mihomo 客戶端優劣的關鍵，便是看它的「覆寫」功能做得如何。每一個通過客戶端下載或者訂閱的配置文件，都會經過一系列「覆寫」過程，比如更換 mixed-port、添加 sniffer 配置等，最後生成用於啟動 Mihomo 內核的最終配置。

然而，並非所有客戶端都能勝任這一核心工作。比如 ShellCrash，其覆寫功能經常莫名其妙出岔子，說到底還是實現得太粗糙。如果連覆蓋和修改配置都做不好，這種客戶端實在難稱合格。

與其依賴這些~~屎一樣的~~不盡如人意的 Mihomo 客戶端，不如自己動手，直接自己編寫、管理配置文件交給內核啟動，而不是依賴「黑箱」一般的各種「客戶端」，不僅更純淨、更穩定，而且更可控。

需要的預備知識

基本的 Linux 操作
知道如何使用 CLI 編輯器，如 nano
已經搭建 Substore（可選）
默認使用 root 用戶操作，非 root 用戶請自行注意提權

安裝 Mihomo 內核

對於基於 Debian 的分支，可以使用預編譯的.deb包安裝，對於其他使用systemd的系統，下載編譯好的二進制文件，重命名為mihomo，放到/usr/local/bin：

curl -o /usr/local/bin/mihomo <下載鏈接>
chmod +x /usr/local/bin/mihomo

然後新建/etc/systemd/system/mihomo.service：

[Unit]
Description=mihomo Daemon, Another Clash Kernel.
After=network.target NetworkManager.service systemd-networkd.service iwd.service

[Service]
Type=simple
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
Restart=always
ExecStartPre=/usr/bin/sleep 1s
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

使用systemctl daemon-reload重新加載systemd，此時還沒有配置文件，不能直接啟動內核，但可以使用systemctl enable mihomo讓內核開機自啟，方便後續使用。

配置文件

內核啟動時會加載/etc/mihomo/config.yaml，沒有了黑箱一樣的礙事「客戶端」，配置文件可以隨心所欲的定製。部分機場會下發完整的配置文件，直接用curl下載即可。

對於訂閱的管理，我目前使用 Substore，我之前分享過「最速 Substore 訂閱管理指南」，可以直接參考這篇文章來定製自己的訂閱。為了實現純內核啟動，現在我的 Substore JS 格式覆寫已經加入了full參數，可以生成完整的配置文件，包括各種端口設置、統一延遲和外部控制器等，開箱即用。

在 Substore 配置完成以後便可以下載配置文件並啟動內核：

sudo curl -o /etc/mihomo/config.yaml 配置文件鏈接
sudo systemctl start mihomo

自定義覆寫

我的配置文件不能滿足你的所有需求？沒問題！你可以自己添加覆寫，想要什麼加什麼。

我用過各種覆寫規則，後來也開始自己從零開始編寫覆寫規則，即使使用自己的覆寫規則能滿足 99% 的場景，但有極個別的域名還是會在規則中有遺漏，更不用說用別人寫的覆寫規則了。這些遺漏的規則大多是形如我服務器的非標準端口 SSH 的前置代理等相對隱私的規則，直接上傳到 Github 公開顯然不太合適，那麼在自定義規則的基礎上再添加覆寫就成了唯一的選擇。

好在 Substore 可以添加多個腳本操作，只需要在生成配置文件時額外添加一個腳本操作就能解決我們的問題。

function main(config) {
  config["rules"].unshift("DOMAIN-SUFFIX,xxx,DIRECT")
  return config
}

需要注意的是覆寫rules時必須要使用.unshift()放在最前面，而不是用.push()放到最後面，因為放在MATCH後面的規則是永遠都匹配不到的。

自定義配置文件

完全不喜歡我的覆寫規則？不會用/不喜歡用 Substore？沒問題！你也可以參考 Mihomo 文檔，自己從頭開始手搓配置文件：

mode: rule
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
log-level: info
ipv6: true
external-controller: 127.0.0.1:8000
# secret: yoursecret
unified-delay: true
routing-mark: 7894
tcp-concurrent: true
disable-keep-alive: true # 推薦在給移動設備代理時啟用，可以解決待機異常耗電的問題

dns:
  # 你的 DNS 配置

sniffer:
  # 你的域名嗅探配置

geodata-mode: true
geox-url:
  # 自定義 Geodata 文件 URL

proxy-providers:
  # 你的機場訂閱

rule-providers:
  # 外部規則

rules:
  # 分流規則

proxy-groups:
  # 自定義代理分組

管理面板

管理面板可以根據個人喜好選擇，以 Zashboard 為例，我在使用 mihomo 自帶的external-ui時遇到了一些莫名其妙的問題，所以乾脆直接運行一個 Docker 容器，畢竟這東西就真的只是一個 Web 面板，只要確保內核 API 使用 HTTP 時，Web 面板也使用 HTTP 即可，如果此時 Web 面板使用 HTTPS，則會因為 CORS 策略問題無法連接。

$ mkdir zashboard && cd zashboard
$ nano compose.yml
$ docker compose up -d

compose.yml內容：

services:
  zashboard:
    image: ghcr.io/zephyruso/zashboard:latest
    ports:
      - "8899:80"
    restart: "unless-stopped"

自動維護

內核已經運行起來，自動更新訂閱這種功能怎麼實現？

答曰：自行編寫一個 Shell 腳本，配合 Crontab 即可實現自動更新訂閱的功能。例如我希望每天凌晨 3 點自動更新訂閱並重啟服務，遂編寫/etc/mihomo/auto_update.sh：

#!/bin/bash

# === 配置信息 ===
CONFIG_URL=""
CONFIG_PATH="/etc/mihomo/config.yaml"
BACKUP_DIR="/etc/mihomo"
BACKUP_PREFIX="config.yaml"
MAX_BACKUPS=7
TMP_PATH="/tmp/config.yaml.tmp"
LOG_FILE="/var/log/mihomo_update.log"

# === 日誌 ===
log() {
    echo "$(date '+%F %T') $1" | tee -a "$LOG_FILE"
}

# === 備份現有配置，並自動清理舊備份 ===
backup_config() {
    if [ -f "$CONFIG_PATH" ]; then
        backup_file="$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak"
        cp "$CONFIG_PATH" "$backup_file"
        log "配置文件已備份到 $backup_file"
        # 清理多餘的備份，只保留最新的 $MAX_BACKUPS 個
        old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2>/dev/null | tail -n +$(($MAX_BACKUPS+1)))
        for f in $old_backups; do
            rm -f "$f" && log "已刪除舊備份 $f"
        done
    else
        log "未找到現有配置文件，無需備份"
    fi
}

# === 下載新配置 ===
download_config() {
    log "開始下載新配置..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "下載配置失敗，請檢查網絡或地址"
        return 1
    fi
    # 基本校驗：檢測文件體積
    if [ ! -s "$TMP_PATH" ]; then
        log "下載文件為空，停止更新"
        return 2
    fi
    log "配置下載完成"
    return 0
}

# === 更新配置文件 ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "配置文件已更新"
}

# === 重啟 mihomo 服務 ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "mihomo 服務已重啟"
    else
        log "mihomo 服務重啟失敗，請手動檢查"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "操作終止：配置文件未更新，保留原有配置"
        exit 1
    fi

    replace_config

    restart_service

    log "=== 更新流程完成 ==="
}

main "$@"

使用crontab -e編輯 Crontab，設置如下 Crontab 即可在每天凌晨三點自動更新配置：

0 3 * * * /etc/mihomo/update_config.sh

防火牆

手動配置防火牆把流量劫持到 Mihomo 內核其實並不是什麼難事，我之前在「從入門到進階：Tailscale + ShellCrash 異地組網和科學上網」（以下簡稱「Tailscale 那篇文章」中的兩個小節中提到過具體的操作方法，這裡只提操作，不做解說。

根據我的情況，我需要把tailscale0上的網卡的所有流量劫持到 Mihomo 內核，其它的情況（例如本機代理）操作也大同小異。如果只是想劫持 TCP 流量，那麼用iptables的 REDIRECT 功能已經足夠，但若還想劫持 UDP、QUIC 等流量，則必須用到 Tproxy。最後，不要忘了 IPV6。

以下是我的防火牆配置：

# 創建自定義鏈
iptables -t mangle -N MIHOMO

# 根據自己的需要忽略本地流量
iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN
iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN
iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN

# mark UDP 和 TCP 到代理
iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip rule add fwmark 233 lookup mihomo
ip route add local 0.0.0.0/0 dev lo table mihomo

# IPv6
# 創建鏈
ip6tables -t mangle -N MIHOMO6

# 跳過本地地址
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# 標記 TCP/UDP
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip -6 rule add fwmark 233 lookup mihomo
ip -6 route add local ::/0 dev lo table mihomo

大多數系統默認不會保存防火牆規則，關於規則持久化的內容我已經分別在 Tailscale 那篇文章的「路由規則持久化」和「iptables 規則持久化」兩小節做了詳細說明，直接參考即可。

本機代理怎麼配置？

大多數代理軟件默認的配置（其實就是 ShellCrash 的默認配置）是 REDIRECT，用它也基本能滿足大多數需求，REDIRECT 的示例如下：

# IPv4 劫持 eth0
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 eth0
ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

其中 7892 要和 Mihomo 配置中的redir-port一致，eth0就是想要劫持的 Interface，相比 Tproxy 那可真是簡單太多了。

實際上我個人並不喜歡用把本機所有流量都劫持到防火牆，我更喜歡在需要時直接通過環境變量、proxy-chains和各種軟件自帶的代理配置把流量指向 Mihomo 內核，例如想讓 Docker 走代理，則可以直接編輯 Docker 的/etc/docker/daemon.json來指定代理，而不是直接一股腦把網卡上的所有流量都劫持到代理：

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "127.0.0.0/8"
  }
}

這麼折騰，何必呢？用客戶端不香嗎？

別問，問就是玩虛空終端玩的。

最速 Substore 訂閱管理指南

Fri, 07 Mar 2025 10:54:29 +0000

當我趁著春節各家機場的促銷訂閱多個機場之後，如何充分利用每個節點就變成了說難不難說簡單也不簡單的問題，我當然可以訂閱各家機場提供的配置文件，然後在他們之間切換，但這樣未免也太麻煩了。更何況我還有自建節點，我可不想為了這一個節點專門去開一個新的配置。

Sub-Store 很好的解決了這個問題，它可以從多個訂閱中抽取節點信息，通過正則表達式或者 JS 整理它們，最後輸出一個整合了所有節點信息的訂閱。

部署它可以直接使用 xream 打包好的鏡像，這個鏡像整合了前後端，如果在公網部署，記得更改一下後端路徑，否則你的配置文件很可能會被盜用。

services:
  sub-store:
    image: xream/sub-store
    container_name: substore
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path
    ports:
      - "3001:3001"
    volumes:
      - ./data:/opt/app/data

反代 3001 端口即可訪問 Substore 的前端，這裡以 Caddy 為例：

sub-domain.example.com {
        reverse_proxy :3001
}

當然，初次進入前端別忘了新增後端地址，這時的後端地址取決於之前 compose file 裡的設置，在本文的例子中，後端地址為https://sub-domain.example.com/super-random-path。

組合訂閱的管理

添加所有機場上游和自建節點之後，就可以開始把它們全都加進單個組合訂閱，但各個機場對節點的命名五花八門，默認情況下看起來非常雜亂，甚至不同機場之間的節點還有重名的可能。好在 Sub-Store 有通過腳本對節點進行批量重命名操作的功能，這裡推薦一個腳本，能夠幫我們為所有的機場節點重命名。

欲使用這個腳本，只需在編輯訂閱時將以下地址粘貼到腳本操作處即可。

https://raw.githubusercontent.com/Keywos/rule/main/rename.js

最後再進行一些你喜歡的節點操作，可以整理出一個統一規範的節點列表。

生成 Clash 配置

現在雖然已經有了節點列表，但現在生成的配置文件並不包含任何規則，需要自行編寫或者拉取第三方規則。

轉到 Substore 的文件管理，創建一份新的 Mihomo 配置：

「來源」選擇組合訂閱，並在訂閱名稱上選擇你的訂閱組
在腳本操作中填入自己的覆寫配置

這是我自己的覆寫規則 powerfullz/override-rules，為 Mihomo/Substore 設計，核心特色如下：

集成 SukkaW/Surge 與 217heidai/adblockfilters 等優質規則，兼容性強，覆蓋面廣。
針對 Truth Social、E-Hentai、TikTok、加密貨幣等場景，新增專用分流規則，滿足多樣化需求。
精簡冗餘，結構清晰，維護便捷。
深度融合 Loyalsoldier/v2ray-rules-dat GeoSite/GeoIP，分流更精準。
IP 規則默認添加 no-resolve，有效減少本地 DNS 解析，提升速度與隱私。
動態覆寫：自動識別節點國家/地區，僅生成實際存在的分組，節點名稱實時枚舉，配置更智能。

JavaScript 格式覆寫

複製 JavaScript 格式覆寫文件的鏈接https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js，並根據需要在後面附加參數，格式如下：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#參數1=true&參數2=true

目前支持如下參數：

參數	功能
`loadbalance`	啟用國家/地區節點組的負載均衡
`landing`	啟用落地節點功能
`ipv6`	啟用 IPv6 支持
`full`	生成針對純內核使用場景的完整配置
`keepalive`	啟用 TCP KeepAlive
`quic`	允許 QUIC 流量¹
`fakeip`	DNS 增強模式使用 fake-ip²
`regex`	各國家代理組改用 include-all + 正則過濾模式³
`threshold`	國家/地區節點數量小於該值時不顯示分組（默認 0）

例如，若有負載均衡和 IPv6 需求，最終的覆寫腳本鏈接為：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#loadbalance=true&ipv6=true

將最終的覆寫腳本鏈接粘貼到腳本操作處，使用 Substore 的生成預覽功能確認沒有問題後即可保存。

YAML 格式覆寫

~~YAML 格式覆寫我自己已經不用了，隨緣維護，但歡迎 PR~~

寫了個 Github Actions 自動根據 JS 格式覆寫生成 YAML 格式覆寫，所以現在 YAML 格式又開始維護了。

除了直接引用 convert.js 動態覆寫，你也可以使用倉庫中預先生成好的 32 份 YAML 格式覆寫——它們都放在 yamls/ 目錄裡，由 GitHub Actions 在每次推送後自動重新生成、覆蓋。適用於諸如 Clash Verge 等不支持 JS 覆寫的客戶端和轉換服務。

文件命名規則：

config_lb-{0|1}_landing-{0|1}_ipv6-{0|1}_full-{0|1}_keepalive-{0|1}_fakeip-{0|1}_quic-{0|1}.yaml

示例（開啟 full，其餘關閉）：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/yamls/config_lb-0_landing-0_ipv6-0_full-1_keepalive-0_fakeip-0_quic-0.yaml

CI 只是套用一份假的fake_proxies.json來生成覆寫，所以不可能實現 JS 覆寫自動根據節點匹配生成對應代理組的功能，只能把所有地區節點組都放進去。如果你已經搭建 Substore，並且想要「動態識別國家 + 傳參」的靈活性，還是推薦使用 JS 覆寫。

生成下載鏈接

保存成功後點擊分享按鈕生成分享鏈接，設置分享有效期後點擊「創建分享」，生成的鏈接即最終成型的 Mihomo 配置文件，將其作為訂閱鏈接在你的代理軟件內訂閱就大功告成了。

部分機場 UDP 性能差，開啟後可能出現體驗降級。 ↩︎
開啟後可能有助於解決 TUN 模式無法上網的問題。 ↩︎
各國家代理組改用 include-all + 正則過濾模式，由 Mihomo 內核在運行時按正則動態篩選節點，而非在腳本執行時枚舉節點名稱（默認 false） ↩︎

OBS 多路推流折騰記：那些本不必要的麻煩

Wed, 18 Sep 2024 06:16:51 +0000

長話短說，最近我開始直播我的遊戲實況，我並不指望有多少人看，Just, Why not? 再者每個直播平臺都會有直播回放。相當於免費保存我每一次遊戲的錄像，何樂而不為？

扯遠了，如你所見，近期我有了多平臺同時直播的需求，然而 OBS 本身顯然不支持同時推流，同時也因為不支持設置代理的特點和眾所周知的原因，無法推流到 twitch.tv，於是我開始尋找解決方案。

明確需求

多路平臺同時直播
最好對性能影響小
其中一路需要推流需要代理

多路推流

多路推流有現成的插件可用：Github

在 Release 頁面下載.exe安裝包，安裝完成後記得在「停靠窗口」菜單裡勾選「多路推流」。這時候默認會彈出一個獨立窗口，可以趁這個機會順便調整一下 OBS 的佈局。

插件的設置也沒什麼好說的，用在原版 OBS 的填法在這個插件裡如法炮製即可。

Bilibili 直播姬

莫名其妙，B 站小於 50 粉絲的 Up 主只能使用直播姬開播，其他國內平臺做出類似規定者大概也不在少數，啟用第三方推流模式之後，直播面板會顯示推流的配置。此時的不需要按照直播姬給出的推流地址進行配置，因為直播姬莫名其妙的給了一個每次都會變的內網 IP，直接以127.0.0.1或者localhost替換即可。

推流到 Twitch

推流到 Twitch 則會因為 GFW 多出很多不必要的麻煩。

OBS 本身並不支持設置代理，起初我打算用 Clash 的 TAP 模式強制代理 OBS 的流量，而 Clash 的 TAP 並不監聽 rtmp 流量，宣告失敗。我決定直接架設一個轉發服務器，這個服務器需要既可以與 Twitch 通信，又可以不受 GFW 的干擾。

在網上查到一些信息，Caddy 似乎不支持 RTMP 協議，而 nginx-rtmp 插件則專門為 RTMP 協議設計。這幾乎是唯一的選擇。

部署的前提：

熟悉基本的 Linux 命令行操作。
服務器已經安裝好docker和docker compose插件。
有合適的命令行文本編輯器，比如nvim或者絕大部分 distro 自帶的nano。

新建目錄：

mkdir nginx-rtmp && cd nginx-rtmp

創建docker-compose.yml：

services:
  nginx-rtmp:
    image: tiangolo/nginx-rtmp:latest
    container_name: nginx_rtmp
    ports:
      - "1935:1935" # RTMP port
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    restart: unless-stopped

創建nginx.conf：

worker_processes  auto;

events {
    worker_connections  1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            push rtmp://live.twitch.tv/app/{Twitch 主直播密鑰};
        }
    }
}

啟動編排：

docker compose up -d
# 老版本 compose 插件則是 docker-compose up

當然，別忘了開放防火牆端口。我的防火牆參考了 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置，相應地，開放端口的命令如下：

ufw route allow proto tcp from any to any port 1935

配置完成後，OBS 內的推流目標地址填入rtmp://服務器ip/live，推流碼填寫任意值均可。設置完成後即可開始推流。

Netch

如果沒有服務器，亦可以使用 Netch 代理 OBS 進程進行推流。

首先下載 Netch 1.9.2 版本，注意一定要是 1.9.2 版本。添加一個進程模式，將 OBS 文件夾加入，隨後啟用該進程模式的代理即可。

尾聲

這次為了在同時在 Twitch 和 B 站上推流，遇到了很多原本不必要的麻煩。我可以怪 OBS 沒有內置代理功能，也可以怪 Clash Verge 等代理工具不支持 RTMP，轉來轉去，最終要怪的，還得是 GFW。雖然最後的結果還算令人滿意，僅僅為了推流而折騰這些東西的體驗實在是稱不上良好。也許我今後我應該去研究修改 Mihomo 內核，讓其支持 RTMP 協議，亦或是自己寫一套獨立的實現單獨轉發 OBS 的流量，不論如何，在這片土地上，想要暢快的直播，道阻且長。

最後，歡迎關注我的 Twitch 頻道: https://www.twitch.tv/powerfullz233

docker-mailserver 郵件服務器搭建記錄

Fri, 06 Sep 2024 03:57:18 +0000

某天早上醒來，發現收件箱裡多了封郵件，通知我的郵箱在韓國登錄，當時認為只是偶爾的 IP 誤判，也就沒有多想。可接下來幾天，時不時又有新的郵件進來，而且每次 IP 都不一樣，這下可就有些問題了，再不採取行動，怕不是郵箱真的要被拿去群發郵件。於是趕緊刪掉了域名的 MX、SPF、DMARC 記錄，尋找新的解決方案。

我原本只是想改改密碼，結果呢，騰訊企業郵箱改密碼的入口真的巨能藏，到處都找不到。算了，遷移，何必受這氣。

於是就有了這篇文章，從最開始的開放防火牆端口開始，到最後的優化送達率，我將分享我搭建 docker-mailserver 郵件服務器的經驗，希望能幫你少踩些坑。

搭建 docker-mailserver 郵件服務器前的準備

防火牆的處理

首先先開放防火牆的郵件服務常用端口，分別是25、143、465、587、993，各分支開放端口的操作不同，請自行谷歌或詢問 AI，以 Ubuntu 使用的ufw為例：

ufw allow 25
ufw allow 143
ufw allow 465
ufw allow 587
ufw allow 993

我的防火牆比較特殊，用到了ufw和 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置。所以當我想要把 Docker 容器的端口暴露在外時需要做出額外的配置。

# 開放郵件服務器所需的端口
ufw route allow proto tcp from any to any port 25
ufw route allow proto tcp from any to any port 143
ufw route allow proto tcp from any to any port 465
ufw route allow proto tcp from any to any port 587
ufw route allow proto tcp from any to any port 993

驗證你的服務器是否具備搭建條件

很多服務器，尤其是各種廉價的 VPS，並不適合搭建 docker-mailserver，各大郵件服務商為了過濾垃圾郵件，索性將所有曾經有過 Spam 行為的 IP 全部列入黑名單。如果你的 IP 被某個 Spammer 使用過，而恰好又被你的服務器提供商分配給了你，而你折騰了幾個小時的郵件服務器卻愣是收不到郵件，最後發現竟是 IP 被列入黑名單的原因，我不知道你會作何感想。

有的服務器提供商的 IP 乍一看確實不在郵件黑名單中，但實際上搭建好之後還是無法發送郵件，為什麼？因為服務器提供商擔心 IP 被濫用，索性將郵件服務的端口全都封鎖了。

使用如下腳本檢測你的服務器是否具備搭建郵件服務器的條件：

bash <(curl -sL IP.Check.Place)

如果在這一步發現你的服務器不適合搭建甚至不能搭建docker-mailserver，那就趁早打住吧，想辦法換一個更乾淨、限制更少的 IP 再說。

搭建過程

拉取配置文件

docker-mailserver 需要配置的配置文件有兩個，compose.yaml和mailserver.env，分別拉取配置文件：

mkdir mailserver && cd mailserver
sudo apt install wget
wget -O compose.yaml "https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/compose.yaml"
wget -O mailserver.env "https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env"

根據需求，可以修改不同的配置，下面是我修改的部分：

POSTMASTER_ADDRESS=webmaster@l3zc.com
TZ=Asia/Shanghai
SSL_TYPE=manual
SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

用 Caddy 準備和自動維護 TLS 證書¹

因為我已經在使用 Caddy，所以我這次就打算直接使用 Caddy 來自動維護證書。根據項目的官方文檔，我只需要在 Caddyfile 裡新增一個子域名，Caddy 就可以自動幫我維護證書。

mail.example.com {
  tls internal {
    # ?? 這不是直接生成的內部證書麼
    key_type rsa2048
  }

  # Optional, can be useful for troubleshooting
  # connection to Caddy with correct certificate:
  respond "Hello DMS"
}

當我更新完 DNS 記錄，實際操作起來發現，我的情況比較特殊：我這臺服務器上並沒有用到 Caddy 的自動申請證書功能，而是使用了15年有效期的泛域名 Cloudflare Origin Certificate。即使我不為這個子域名指定證書文件，Caddy 也會在加載這張泛域名證書後認為無需再申請新的證書。這就很尷尬了，用 Caddy 的時候 Cloudflare Origin Certificate 和郵件服務器只能二選一。只好安裝了dns.providers.cloudflare，並放棄使用 Cloudflare Origin Certificate，轉而讓 Caddy 自動為每個子域名申請和維護 TLS/SSL 證書，反正都是自動的，眼不見心不煩。

安裝dns.providers.cloudflare後的全局配置：

{
        acme_dns cloudflare {API_KEY}
}

最後把 Caddy 的證書存儲位置映射到 docker-mailserver 容器內。

volumes:
  - /home/user/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/:/certs/

如果 Caddy 以 root 用戶運行，則證書的位置應當為/root/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/，做出相應的修改即可。

然後就是之前提到過的配置，我將證書存儲位置映射到了容器內的/certs/目錄，所以配置為：

SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

首次啟動容器

首次啟動容器需要立即（120 秒內）創建新的 Postmaster 賬號。

docker compose up -d
docker exec -it  setup email add

優化送達率

DNS 記錄

一條 A 記錄，名稱隨意（假設為mail），指向服務器 IP（Cloudflare 需使用「僅 DNS」）
一條 MX 記錄，Apex 域（@），指向mail.yourdomain.tld
一條 TXT 記錄（SPF），Apex 域（@），可以在這裡生成(可選)。
一條 TXT 記錄（DMARC），名稱_dmarc，可以在這裡生成（可選）。
一條 TXT 記錄（DKIM），名稱mail._domainkey，具體配置在後文（可選）。

DKIM, SPF 和 DMARC²

什麼是 DKIM，SPF 和 DMARC？簡單來說，DKIM 是一個數字簽名機制；SPF 類似於「員工名單」，記錄所有合法的發件服務器；DMARC 則用於指示收件方的服務器如何處理未通過 DKIM 和 SPF 驗證的郵件。³

首先設置 DKIM，在服務器上生成公私鑰對。

docker exec -it  setup config dkim

生成後的公私鑰對可以在映射的容器目錄./docker-data/dms/config/opendkim/keys/下找到。

下載 mail.txt（複製其內所有內容粘貼到本地文件也可以），將其導入到 Cloudflare Dashboard 即可完成 DKIM 設置。需要注意配置完成 DKIM 後需要重啟容器才能生效。⁴

docker compose up -d --force-recreate

前面提到 SPF 相當於一個「員工名單」，既然我合法的發件服務器只有一臺，那麼 DNS 填寫如下設置即可。

"v=spf1 mx ~all"

再就是 DMARC，可以使用前面提到的模板生成，這裡不再贅述。

如果你的域名服務商擁有自己的設置嚮導（例如 Cloudflare），亦可以使用它們簡化設置流程。

客戶端設置

客戶端設置相對就很簡單了，IMAP 和 SMTP 服務器都是mail.yourdomain.ltd，開啟 SSL 後端口分別是 465 和 993，登錄即可。

善用 MailTester

至此我們已經完成了搭建 docker-mailserver 郵件服務器的整個過程，在開始發送郵件之前，我們可以使用 MailTester 測試我們的配置是否正確。如果測試結果是 10/10，那麼我們的 docker-mailserver 郵件服務器應該會擁有漂亮的送達率，好好享受吧。

如果不是 10/10，也不要著急，認真查看扣分的原因，對症下藥，一項一項解決即可。

TODO-List

配套 WebUI

參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#caddy ↩︎
參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/ ↩︎
更加具體的介紹: https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/ ↩︎
在官方文檔中有提及。 ↩︎

Firefish 數據庫升級記錄

Fri, 30 Aug 2024 04:45:12 +0000

我的 Firefish 實例搭建於去年的 11 月，使用的數據庫版本自然不是最新的，確切的說，是 PGroonga 12，一個基於 5 年前的 Postgres 的遠古版本。為了避免今後的兼容性問題和安全問題，同時為了更好的性能，今天這數據庫是非升級不可。

升級一個用 Docker 跑起來的數據庫和升級其他的 Docker 容器有很大不同，並不是拉取一個新的鏡像就可以宣告結束。因為 Postgres 幾乎每個大版本都有 Breaking Changes，新老版本產生的持久化文件並不兼容，如果直接拉取一個新的鏡像運行，數據庫是無法啟動的，必須要採用一定的手段進行數據的遷移。

Postgres 有官方的升級工具pg_upgrade¹，這一次我不採用，因為我的數據庫跑了一年多，而且用的還是 5 年前的老版本，用這個工具我不確定會不會出問題。這次遷移，大致思路是先導出 SQL，再將導出的 SQL 導入新版本。

升級前的部署概況

以下是一些升級前需要了解的配置信息：

項目	配置
實例部署方式	Docker Compose
數據庫容器名稱	firefish_db
升級前的數據庫容器鏡像	groonga/pgroonga:3.1.9-alpine-12-slim
數據庫用戶	example-firefish-user
數據庫名稱	firefish

Docker Compose 的數據庫部分如下：

db:
  restart: unless-stopped
  image: groonga/pgroonga:3.1.9-alpine-12-slim
  container_name: firefish_db
  networks:
    - calcnet
  env_file:
    - .config/docker.env
  volumes:
    - ./db:/var/lib/postgresql/data
  healthcheck:
    test: pg_isready --user="$${POSTGRES_USER}" --dbname="$${POSTGRES_DB}"
    interval: 5s
    timeout: 5s
    retries: 5

導出當前數據庫

對數據庫進行升級之前，首先下線 Firefish 的編排：

docker compose down

單獨啟動數據庫容器，導出當前數據庫為 SQL：

docker compose up -d db
docker exec -it firefish_db pg_dumpall -U example-firefish-user > backup.sql

由於 Firefish 的數據庫比較大，導出過程可能需要很長一段時間，比如我的個人實例就用了十幾分鍾。

導出文件的處理

可能是由於新版的 Postgres 認證方式有所變更，如果直接向新數據庫導入之前導出的backup.sql文件，就會改變新數據庫的 Authentication Scheme，導致之後 Firefish 連接數據庫時認證失敗。要避免這個問題需要對目前的backup.sql進行一些處理，只抽取出其中的firefish數據庫的部分，而不是直接導入所有數據。²

#!/bin/bash
[ $# -lt 2 ] && { echo "Usage: $0  "; exit 1; }
sed  "/connect.*$2/,\$!d" $1 | sed "/PostgreSQL database dump complete/,\$d"

編輯一個 Shell 腳本為以上內容，保存至script.sh，用以處理目前的backup.sql：

nvim script.sh  # 或者任何你喜歡的編輯器
chmod +x script.sh
./script.sh backup.sql firefish >> upgrade.sql

如果一切順利，當前目錄下就會出現一個名為upgrade.sql的文件，可以打開它看一下，確保其被正確導出。

向新數據庫導入現有數據

修改docker-compose.yml：

db:
  restart: unless-stopped
  image: groonga/pgroonga:3.2.2-alpine-16-slim # 最新的容器
  container_name: firefish_db
  networks:
    - calcnet
  env_file:
    - .config/docker.env
  volumes:
    - ./database:/var/lib/postgresql/data # 注意這一行的變動
  healthcheck:
    test: pg_isready --user="$${POSTGRES_USER}" --dbname="$${POSTGRES_DB}"
    interval: 5s
    timeout: 5s
    retries: 5

注意數據庫目錄映射配置由./db:/var/lib/postgresql/data變為./database:/var/lib/postgresql/data，這麼做是為了給新的數據庫一個 Fresh Start，同時也保存老的持久化數據，即使出現問題，也可以隨時用回老的數據庫。

拉取並啟動新容器：

docker compose pull
docker compose up db -d

向新數據庫導入upgrade.sql：

cat upgrade.sql | docker exec -i firefish_db psql -U example-firefish-user -d firefish

取決於數據庫的大小，導入過程也會持續較長的時間。

收尾工作

導入完成，啟動整個編排：

docker compose stop db
docker compose up

導入後的首次啟動不建議帶-d參數，建議不帶參數啟動，確保啟動過程沒有問題後再以-d參數啟動。

最後，登入剛剛啟動的 Firefish 實例，檢查是否有任何數據損失，沒有問題的話就大功告成啦🎉

官方文檔：https://www.postgresql.org/docs/current/pgupgrade.html ↩︎
參考：https://thomasbandt.com/postgres-docker-major-version-upgrade ↩︎

科學上網：用 Caddy 反向代理 VLESS

Tue, 13 Aug 2024 08:24:26 +0000

上一篇文章提到，我搭建了一個基於 Aria2 的 BT 離線下載服務器。為了用 Caddy 反向代理部署好的容器，我把原來偷懶用一鍵腳本部署的 Trojan 給卸載了，問就是因為這腳本把 80 和 443 端口都佔用了，不卸載掉根本沒法繼續。

於是離線下載服務器是搭建好了，可時不時需要的代理卻不得不下線。仔細一想，之前看到過有人 Cloudflare + V2Ray + WS 復活被牆的 VPS，既然是 WebSocket，還能用 Cloudflare 反代，那用 Caddy 反代又有何不可呢？況且 Caddy 還有自動 TLS，比起 Nginx + Certbot 的組合配置起來肯定更簡單。只要配置成功，我就可以在為 Caddy 留住 443 端口的同時跑代理了。

安裝 VLESS 和 Caddy

安裝VLESS 可以直接使用 v2fly/fhs-install-v2ray 一鍵腳本：

# 安裝執行檔和 .dat 資料檔
bash <(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh)

Caddy 的安裝請參考官方教程，例如，我使用 Debian 12，則使用以下命令：

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

配置 VLESS

編輯/usr/local/etc/v2ray/config.json：

{
  "log": {
    "access": "/var/log/v2ray/access.log",
    "error": "/var/log/v2ray/error.log",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 1234, //任意端口
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "super-random-uuid", //隨機生成一個 UUID 替換即可
            "level": 0,
            "email": "example@example.com"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "ws",
        "security": "none",
        "wsSettings": {
          "path": "/" // 需要與之後的 Caddy 配置保持相同
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

編輯完成後保存退出即可。

配置 Caddy

在你喜歡的位置創建一個 Caddyfile，或者編輯已有的 Caddyfile，加入如下內容，反向代理剛才在 VLESS 配置文件中設置的端口：

yourdomain.com {
        # 用一個 Matcher 匹配所有指定路徑的 Websocket 請求
        @websockets {
                path /      # 與前面 VLESS 的 path 保持一致
                header Connection Upgrade
                header Upgrade websocket
        }
        reverse_proxy @websockets :1234
}

至此，服務端所有配置文件都編輯完畢。

啟動服務

啟動 VLESS，並設置開機自啟動：

systemtcl enable v2ray && systemctl start v2ray

啟動 Caddy/更新 Caddy 配置：

caddy start
caddy reload  # 更新配置用

以上操作全部完成後，Caddy 反向代理 VLESS 就完成了。

客戶端設置

客戶端方面需要手動設置：

地址是綁定給 VLESS 的域名。
端口是 443
TLS 打開
傳輸方式選擇 websocket
UUID 是之前填入 VLESS 配置文件的 UUID

所有的客戶端設置大同小異，至於 Clash 的配置文件，可以參考 Mihomo 文檔¹，以下是我的示例配置文件：

proxies:
  - name: "A Random Name"
    type: vless
    server: yourdomain.com
    port: 443
    udp: true
    uuid: super-random-uuid
    flow: xtls-rprx-vision
    packet-encoding: xudp

    tls: true
    servername: yourdomain.com
    alpn:
      - h2
      - http/1.1
    skip-cert-verify: false

    network: ws

    smux:
      enabled: false

需要生成 Clash 配置文件可以使用 V2RaySE 提供的工具。

完成

好了，現在我們已經擁有了一個 VLESS 服務器，Caddy 會自動為我們申請和維護 TLS 證書，非常好用。

只需要這麼小小折騰一下，我彷彿又找到了當年用一鍵腳本搭建 SSR 時的愉悅，好好享受這種能順利打開 google.com 時的興奮吧。

TODO List

基本搭建
偽裝

畢竟繼承 Clash Meta 衣缽的 Mihomo 也算是 Clash 正統了。 ↩︎

搭建一個 BT 離線下載服務器

Sat, 10 Aug 2024 07:46:40 +0000

自從買了一些廉價 VPS 以後，手上就閒置了一臺 Azure 的學生機，除了用來跑個 Trojan 暫時沒有其他的用途。正好最近想要下一些 BT 資源，而國內的 BT 環境懂的都懂，遂決定用這臺接近閒置的機器離線下載 BT。

首先聲明，所有 BT 下載行為需要自行承擔被版權投訴的風險。

安裝 Aria2

對於這些不是「基礎設施」的軟件，我更喜歡直接拉取一個 Docker 容器的方案。我採用了P3TERX/Aria2-Pro-Docker¹，這套已經修改好的 Docker 容器。Docker 容器部署起來如出一轍：首先編輯docker-compose.yml，docker compose up把所有容器都跑起來，最後反代暴露的端口即可。

我的docker-compose.yml如下²：

services:
  Aria2-Pro:
    container_name: aria2-pro
    image: p3terx/aria2-pro
    environment:
      - PUID=65534
      - PGID=65534
      - UMASK_SET=022
      - RPC_SECRET=replace-me # 記得修改這一行
      - RPC_PORT=6800
      - LISTEN_PORT=6888
      - DISK_CACHE=64M
      - IPV6_MODE=false
      - UPDATE_TRACKERS=true
      - CUSTOM_TRACKER_URL=
      - TZ=Asia/Shanghai
    volumes:
      - ./aria2-config:/config
      - ./aria2-downloads:/downloads
    network_mode: bridge # 如果你需要用到 IPV6 網絡，也可以使用 host 模式
    ports:
      - 6800:6800
      - 6888:6888
      - 6888:6888/udp
    restart: unless-stopped
    # 防止日誌塞滿硬盤
    logging:
      driver: json-file
      options:
        max-size: 1m

  # 也可以使用其他面板
  AriaNg:
    container_name: ariang
    image: p3terx/ariang
    command: --port 6880 --ipv6
    network_mode: bridge
    ports:
      - 6880:6880
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: 1m

用 Caddy 反向代理

之前的反向代理，我都是用的基於 Nginx 的方案，而在這段時間裡關於 Caddy 的好評不絕於耳，這次的我便換用了 Caddy，當然，主要也是想嘗試一些新東西、新技術。

Caddy 的使用真的非常簡單，即使對新人也極其友好，例如，常用的反向代理本機某個端口，只需三行 Caddyfile 即可搞定。

domain.com {
  reverse_proxy :1234
}

安裝 Caddy 請參考官方文檔，例如，我的服務器使用 Debian，則使用以下命令安裝：

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

安裝完成後記得開放防火牆和從服務商策略組的 80 和 443 端口。

在域名服務商處將要綁定的域名指向服務器，就可以開始寫 Caddyfile 了。我們需要反向代理三個端口，分別用作不同的用途。我的 Caddyfile 如下：

# Aria-NG 面板
download.l3zc.com {
  reverse_proxy :6880
}

# Aria2 API
arapi.l3zc.com {
  reverse_proxy :6800
}

# Alist
downloaded.l3zc.com {
  reverse_proxy :5244
}

看到如此簡潔的配置文件，不由得感嘆，相比於 Nginx，Caddy 用起來真是令人心情舒暢。寫入配置完成後，重新啟動 Caddy³，就可以開始欣賞 Caddy 自動幫你申請 SSL 證書配置好 HTTPS 的絕贊過程。至此，反向代理的部分也就完成了。

配置 Aria-NG

Aria-NG 只是一個前端面板，可以和任何 Aria2 後端通信，為此，我們需要給 Aria-NG 提供配置信息。進入剛剛反代好的 Aria-NG 面板，轉到 AriaNG 設置，填入配置信息。

其中，RPC 地址是剛剛反代好的 RPC 地址，協議選擇 HTTPS，請求方法選擇 POST，RPC 密鑰是在docker-compose.yml裡replace-me處你所替換的值。

若「Aria2 狀態」旁出現「已連接」，說明配置正確。

用 Alist 映射下載目錄

我們通過 Alist 映射下載目錄，以更方便的查看、管理和下載服務器上已經下載好的文件。Alist 同樣也通過 Docker 部署，由於 Alist 本身在容器內運行們，無法訪問容器外的文件，部署時需要將 Aria2 的下載目錄提前 Bind 到 Alist 的容器下。

我的docker-compose.yml如下：

services:
  alist:
    image: "xhofe/alist:latest"
    container_name: alist
    volumes:
      - "/etc/alist:/opt/alist/data"
      - "/home/azureuser/aria2/aria2-downloads:/aria2-downloads" #這裡需要視情況綁定你自己的目錄
    ports:
      - "5244:5244"
    environment:
      - PUID=0
      - PGID=0
      - UMASK=022
    restart: unless-stopped

第一次啟動 Alist 時，Alist 會隨機生成admin用戶的密碼，所以，第一次啟動這套編排時，最好不要帶-d參數，而是直接docker compose up，並把容器啟動後的輸出妥善保存。如果不小心沒有保存管理員密碼，可以用這個命令重新隨機生成一個：

docker exec -it alist ./alist admin random

成功登錄 Alist 之後就可以開始掛載目錄了。

驅動選擇本機存儲，掛載路徑需要注意，按照我的編排，我將容器外的/home/azureuser/aria2/aria2-downloads目錄掛載到了容器內的/aria2-downloads，所以掛載路徑應該是/aria2-downloads。

完成

現在所有的服務都已經部署上線了，打開 AriaNG 可以添加下載任務，下載好的文件可以打開 Alist 看到，下載，以及在線觀看。

搭建這套服務之前，請仔細查看 VPS 提供商的服務條款，確保 BT 下載行為不會違規。以及，除了盧森堡等少數國家/地區，下載被 DMCA 保護的資源可能會遭到投訴，這些風險都需要你自行承擔。

反正我這 Azure 的學生機也是白嫖的，被投訴回收了我也無所謂，不管怎樣，現在可以心無旁騖的享受找資源的快樂了。

當然也可以試一試SuperNG6/docker-aria2 ↩︎
參考原作者的docker-compose.yml ↩︎
caddy stop和caddy start，參考Caddy文檔 ↩︎

最速 Firefish 部署指南

Mon, 04 Dec 2023 09:17:56 +0000

需要的環境

Docker 和 Docker Compose
任意 Web 服務器

最速教程

為 Firefish 準備一個目錄：

mkdir firefish && cd firefish

⚠️注意：近期 Firefish 更新頻繁，本文的docker-compose.yml已經過時，請參考官方倉庫中的docker-compose.example.yml和Notice for server administrators進行配置。

用你喜歡的文本編輯器創建docker-compose.yml：

version: "3"

services:
  web:
    image: registry.joinfirefish.org/firefish/firefish:stable-amd64
    container_name: firefish_web
    restart: unless-stopped
    depends_on:
      - db
      - redis
      ### Uncomment one of the following to use a search engine
      #     - meilisearch
      - sonic
    ports:
      - "6666:3000" # 6666換成需要的端口
    networks:
      - calcnet
    #     - web
    environment:
      NODE_ENV: production
    volumes:
      - ./files:/firefish/files
      - ./.config:/firefish/.config:ro

  redis:
    restart: unless-stopped
    image: redis:7.0-alpine
    container_name: firefish_redis
    networks:
      - calcnet
    volumes:
      - ./redis:/data

  db:
    restart: unless-stopped
    image: postgres:12.2-alpine
    container_name: firefish_db
    networks:
      - calcnet
    env_file:
      - .config/docker.env
    volumes:
      - ./db:/var/lib/postgresql/data

  ### Only one of the below should be used.
  ### Meilisearch is better overall, but resource-intensive. Sonic is a very light full text search engine.

  #  meilisearch:
  #    container_name: meilisearch
  #    image: getmeili/meilisearch:v1.1.1
  #    environment:
  #      - MEILI_ENV=${MEILI_ENV:-development}
  #    ports:
  #      - "7700:7700"
  #    networks:
  #      - calcnet
  #    volumes:
  #      - ./meili_data:/meili_data
  #    restart: unless-stopped

  sonic:
    restart: unless-stopped
    image: valeriansaliou/sonic:v1.4.0
    logging:
      driver: none
    networks:
      - calcnet
    volumes:
      - ./sonic:/var/lib/sonic/store
      - ./sonic/config.cfg:/etc/sonic.cfg:ro

networks:
  calcnet:
  #  web:
  #    external:
  #      name: web

你也可以用 Melisearch，但這是最速指南，只講 Sonic。

創建.config目錄：

mkdir .config && cd .config

創建docker.env：

# db settings
POSTGRES_PASSWORD=example-firefish-pass
POSTGRES_USER=example-firefish-user
POSTGRES_DB=firefish

創建default.yml：

#━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Firefish configuration
#━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# After starting your server, please don't change the URL! Doing so will break federation.

#   ┌─────┐
#───┘ URL └─────────────────────────────────────────────────────

# Final accessible URL seen by a user.
url: https://你的域名/
port: 3000

db:
  host: db
  port: 5432
  #ssl: false
  # Database name
  db: firefish

  # Auth
  user: example-firefish-user
  pass: example-firefish-pass

#   ┌─────────────────────┐
#───┘ Redis configuration └─────────────────────────────────────

redis:
  host: redis
  port: 6379

#   ┌─────────────────────┐
#───┘ Sonic configuration └─────────────────────────────────────

sonic:
  host: sonic
  port: 1491
  auth: SecretPassword
  collection: notes
  bucket: default

# Reserved usernames that only the administrator can register with
reservedUsernames: ["root", "admin", "administrator", "me", "system"]

signToActivityPubGet: true

回到上一層目錄，創建./sonic/config.cfg：

# Sonic
# Fast, lightweight and schema-less search backend
# Configuration file
# Example: https://github.com/valeriansaliou/sonic/blob/master/config.cfg

[server]

log_level = "debug"

[channel]

inet = "0.0.0.0:1491"
tcp_timeout = 300

auth_password = "SecretPassword"

[channel.search]

query_limit_default = 10
query_limit_maximum = 100
query_alternates_try = 4

suggest_limit_default = 5
suggest_limit_maximum = 20

list_limit_default = 100
list_limit_maximum = 500

[store]

[store.kv]

path = "./data/store/kv/"

retain_word_objects = 1000

[store.kv.pool]

inactive_after = 1800

[store.kv.database]

flush_after = 900

compress = true
parallelism = 2
max_files = 100
max_compactions = 1
max_flushes = 1
write_buffer = 16384
write_ahead_log = true

[store.fst]

path = "./data/store/fst/"

[store.fst.pool]

inactive_after = 300

[store.fst.graph]

consolidate_after = 180

max_size = 2048
max_words = 250000

全部創建好以後的目錄結構應該看起來像這樣：

.
├── .config
│   ├── default.yml
│   └── docker.env
├── docker-compose.yml
└── sonic
    └── config.cfg

最後執行docker compose up，綁定域名、反代端口，實例就搭建完成了。

Firefish 已經自動 Minify 了所有的前端文件，如果你使用 Cloudflare 或其他類似的服務，記得關掉 Auto Minify，否則會出現一些奇怪的問題。¹

以上就是最速教程。

一些問題

Q：docker.env和./sonic/config.cfg密碼和用戶名不改沒問題嗎？

A：沒很大問題，因為兩個服務沒有暴露到公網上，僅做個人使用不改也沒什麼大事。

Q：為什麼 network 要叫calcnet？

A：因為這個項目本來叫做 Calckey。

https://github.com/misskey-dev/misskey/issues/10328 ↩︎

重新撿起 RSS：RSSHub + FreshRSS 建立我的信息流

Mon, 17 Jul 2023 20:33:00 +0000

不知從什麼時候開始，我的生活就慢慢的被推薦算法淹沒，推薦視頻、猜你喜歡……，幾乎每天，我都或多或少的被他們所影響。我曾半開玩笑：「網速越快，其傳遞的信息就越少」，甚至有些一語成讖。這並不是互聯網能傳遞的信息變少了，而是越來越快的網速、越來越準的推薦算法養廢了我們，奪走了我們從網上獲取信息的能力與主動權。

RSS 已是信息獲取手段中的老古董了，但它的體驗真的一點都不老古董：相反，用它來獲取信息，體驗極佳——不光無廣告，還能讓那些分散在一個一個網頁上的信息自動跑到你面前，豈不美哉？我沒有經歷過那個時代，但聽聞當年的大家，人人都拿著 Google Reader（Google 打造的 RSS 閱讀器）讀他們想讀的內容，倒也真想回到那個年代體驗一番。

可惜 Google Reader 這一產品早就關停了，曾經大多數網站都提供的 RSS 訂閱源也悉數消失，想要重新拾起 RSS，就需要一點折騰了。

RSSHub：萬物皆可 RSS

GitHub 倉庫

這是 ~~DIYDog~~DIYGod 大佬發起的項目，就和它的標語一樣，萬物皆可 RSS，這個項目能通過爬取網頁內容的方式生成 RSS 信息流，從而通過 RSS 訂閱本不支持 RSS 的網站。

由於是爬取，難免會受到目標網頁反爬取策略的影響，而有的目標網頁（比如大陸的政府網站）會屏蔽他國 IP 的訪問，亦或者屏蔽掉風險 IP。這些因素就比較考驗機房了，但只要不是被特別「照顧」的 IP，一般問題不大。出於這些原因，我在分別在洛杉磯和上海部署了 RSSHub。

Docker 部署 RSSHub 非常簡單，首先拉取已經寫好的docker-compose.yml：

$ mkdir rsshub && cd rsshub
$ wget https://raw.githubusercontent.com/DIYgod/RSSHub/master/docker-compose.yml

然後檢查有無需要修改的配置：

$ vim docker-compose.yml

我最終修改完成後，配置如下：

version: "3"

services:
  rsshub:
    image: diygod/rsshub:chromium-bundled
    restart: always
    ports:
      - "1200:1200"
    environment:
      NODE_ENV: production
      CACHE_TYPE: redis
      REDIS_URL: "redis://redis:6379/"
    depends_on:
      - redis

  redis:
    image: redis:alpine
    restart: always
    volumes:
      - redis-data:/data

volumes:
  redis-data:

為什麼要新建一個 Redis 鏡像？主要是懶得配置容器互聯，而 RSSHub 用 Redis 佔不了多少資源，遂直接寫進一個docker-compose.yml裡，省去容器互聯的麻煩。

啟動編排：

$ docker compose up		# 老的寫法是 docker-compose up

隨後使用 Nginx 反代localhost:1200至域名，部署 SSL 證書，RSSHub 就全部搭建完成了。

反爬嚴格網站的部分解決

前面已經提到由於 RSSHub 的工作原理是爬取，其勢必會受到不同網站反爬策略的影響。以 B 站為例，如果僅僅部署 RSSHub 而不採取任何措施，當你訂閱時，大概率會出現「521 - 風控校驗失敗」的提示。

這時，先去查找 RSSHub 的文檔，看看相應的網站是否有 Cookie 可以被設置為容器的環境變量，對於大部分需求，只要環境變量配置正確，就可以有效緩解反爬問題。

還是以 B 站為例，查閱 RSSHub 文檔，可以發現有一些額外的環境變量需要配置。¹

按照文檔，打開對應的網頁，按下 F12 打開開發者工具，轉到「網絡」面板，刷新網頁，就可以找到 dynamic*new 請求，複製整個 Cookie（或者 SESSDATA=xxx；字段），修改docker-compose.yml文件，將BILIBILI_COOKIE*你的B站UID: "SESSDATA=xxx"添加到environment部分，即可完成配置。

配置好的docker-compose.yml看起來像下面這樣：

version: "3"

services:
  rsshub:
    # two ways to enable puppeteer:
    # * comment out marked lines, then use this image instead: diygod/rsshub:chromium-bundled
    # * (consumes more disk space and memory) leave everything unchanged
    image: diygod/rsshub:chromium-bundled
    restart: always
    ports:
      - "1200:1200"
    environment:
      NODE_ENV: production
      CACHE_TYPE: redis
      REDIS_URL: "redis://redis:6379/"
      BILIBILI_COOKIE_你的B站UID: "SESSDATA=xxx"
    depends_on:
      - redis

  redis:
    image: redis:alpine
    restart: always
    volumes:
      - redis-data:/data

volumes:
  redis-data:

修改文件並保存，重啟編排：

$ docker compose up -d --force-recreate
# docker-compose up -d --force-recreate

配置完成後，即可正常訂閱 B 站 Up 主投稿等相關路由。

RSS 閱讀器推薦

RSSHub 可以解決掉大多數訂閱源的問題，接下來推薦幾個 RSS 閱讀器，解決的是最後一步如何呈現到設備上的問題。

Windows

Fluent Reader

我目前在用的 RSS 閱讀器，開源小巧，遵循 Fluent Design，如果需要 Windows 上的免費 RSS 閱讀器，那麼大概率就是它了。需要注意的是，這是開源軟件，但在應用商店裡需要付費才能下載，不想付費則可以直接在 GitHub 上下載其安裝包安裝，當然，如果喜歡，鼓勵大家支持這個項目。

Github倉庫

ThunderBird

這個不是 RSS 閱讀器，但也提供了 RSS 功能，比較適合打造郵件 RSS All in one。

ThunderBird 是由 Mozilla 基金會開發的一款開源郵件和新聞聚合客戶端，已經有快 20 年的歷史。

官網

MacOS 和 iOS

NetNewsWire

開源，Swift UI 原生編寫，幾乎完美的 RSS 閱讀器，說實話我很驚訝這位作者維護這個項目的時間跨度。

NetNewsWire 是由 Brent Simmon 出於愛好和支持 RSS 發展開發的 RSS 閱讀器，遺憾的是，由於是 Swift UI 編寫，只支持 Mac OS 和 iOS。

Reeder

這個就是收費 App 了，但功能做的很不錯。作為「骨灰級」應用，Reeder 一度被人稱為 iOS 與 macOS 上最好用的 RSS 閱讀器。不光設計精緻，還支持如桌面小組件等各種 Mac OS 和 iOS 上原生的功能，如果你的預算充足，可以考慮。

官網

Fluent Reader

又是之前提到的 Fluent Reader 也提供了 Mac 版本，實測在 Mac OS 上體驗也還不錯，在 iOS 上雖然看起來是原生 UI，但實際上是 React 寫的跨平臺版本，而且還需要收費，如果想要支持這個項目，可以考慮購買。

鏈接：

Linux

NewsFlash

NewsFlash is a program designed to complement an already existing web-based RSS reader account.

It combines all the advantages of web based services like syncing across all your devices with everything you expect from a modern desktop program: Desktop notifications, fast search and filtering, tagging, handy keyboard shortcuts and having access to all your articles for as long as you like.

這是一個很現代化的 RSS 閱讀器，一般用 flatpak 安裝，也有人為其製作了 Snap 封裝的版本，不過幾乎不怎麼更新維護。它的界面很好看，對在線服務²支持的很全，而且是原生運行，非常推薦。

Fluent Reader

又雙叒是 Fluent Reader，跨平臺這麼容易嗎。

有人給它製做了 Snap 封裝的 App，Ubuntu 可以直接去應用商店下載使用。官方倉庫裡提供了 AppImage 給其它分支使用。

安卓

Fluent Reader

又雙叒叕是 Fluent Reader，在安卓上，Fluent Reader 依然是貼合 iOS 的 UI，用起來有點牛頭人的感覺，若不在意這一點，體驗倒還不錯。

Github倉庫

FeedMe

評論區網友的推薦，FeedMe 支持的服務繁多，功能齊全，界面也較為現代化，一樣支持 FreshRSS 等在線 API。

Github 倉庫

如果有其他好用的 RSS 閱讀器歡迎在評論區留言。

總感覺還缺點什麼？

理論上來說，解決了訂閱源的問題，還解決了呈現在設備上的問題，我們已經還原出 Google Reader 的體驗了，但我在實際使用中，總是覺得缺少了一些特性，體驗並不完整。

這個特性就是「同步」。我所希望的，是我在 A 設備上閱讀，閱讀進度可以同步到 B 設備上，在 A 設備上收藏的文章，打開 B 設備，能原封不動的呈現在我眼前。

同時，還有一個體驗上的要求：我希望我在拉取 Feed 時更加快速，不需要等待 RSSHub 抓取網頁。

於是，一個自託管的 RSS 聚合服務就很有必要了。

以 FreshRSS 完善體驗

FreshRSS 是一個免費，自託管的 RSS 聚合器，相似的項目還有 Tiny Tiny RSS（TTRSS），選擇 FreshRSS 是因為它提供兩種 API，和各個 RSS 客戶端配合的更好。

Github倉庫：https://github.com/FreshRSS/FreshRSS

部署

部署 FreshRSS 的過程也很輕鬆。

創建目錄：

$ mkdir freshrss
$ cd freshrss

創建docker-compose.yml：

$ vim docker-compose.yml		# 或者任意編輯器編輯

docker-compose.yml如下：

version: "3"

services:
  freshrss:
    image: freshrss/freshrss:latest
    container_name: freshrss
    restart: unless-stopped
    ports:
      - "9999:80" # 將9999更改成需要的端口
    volumes:
      - ./data:/var/www/FreshRSS/data
      - ./extensions:/var/www/FreshRSS/extensions
    environment:
      PUID: 0
      PGID: 0
      CRON_MIN: "1,31"
      TZ: "Asia/Shanghai"

最後執行：

$ docker compose up		# 老的寫法是 docker-compose up

隨後反代端口，部署 SSL 證書。初始設置時，數據庫選現有的數據庫類型，如果沒有部署數據庫，直接選 SQLite 即可。至此，FreshRSS 部署完成。

如果之前有訂閱源，將其以 OPML 格式導出，然後導入 FreshRSS 就可以獲得幾乎無縫的體驗。

![FreshRSS](截屏2023-07-18 15.17.39.png)

如果有現成的 PHP 環境而不想用 Docker 部署，還可以像安裝 Wordpress 一樣安裝好 FreshRSS。

設置 FreshRSS

RSSHub 充當的是提供訂閱源的中心，而 FreshRSS 充當的是一個閱讀訂閱源的「Hub」，幫助我們集中管理訂閱源，同步各設備間的閱讀進度。現在訂閱源已經集中管理起來，同步個設備間的閱讀進度就需要 FreshRSS 提供的 API 了。

FreshRSS 提供 GReader 和 Fever 兩種 API，具體的啟用方法如下：

登入 FreshRSS 進入「設置」->「認證」開啟「允許API 訪問」
進入「賬戶」在頁面底部設置一個 API 密鑰
編輯./freshrss/data/config.php中的base_url，改為你的域名根目錄地址，比如我的就需要改成https://rss.l3zc.com/
轉到https://example.com/api/查看檢測是否通過

設置各設備上的客戶端

NetNewsWire

部署完成後，在手機上和電腦上支持的應用裡使用設置好的用戶名和 API 密鑰登陸，就可以享受到全程絲滑的 RSS 體驗了，下面以 NetNewsWire 為例：

打開NetNewsWire添加賬號的選項卡，NetNewsWire貼心的集成了FreshRSS，可以很方便的添加賬號：

NetNewsWire 要求 Greader 的 API，直接在 /api 上覆制就可以了。

FluentReader

在設置中選擇 Google Reader API：

然後填入相關信息：

API端點直接從/api網頁上覆制 Google Reader API 的 API 端點即可
用戶名填寫安裝 FreshRSS 時設置的用戶名
密碼是前文設置的 API 秘鑰

即可設置完成。

其他的客戶端設置大同小異，無外乎上面兩大類，可以參考上面的方法進行設置。

RSS 訂閱什麼呢

我們已經裝好了 RSSHub，這極大的方便了我們的訂閱以及豐富了我們的訂閱源。RSSHub 的官方文檔中維護著一份詳細的支持列表，支持的項目不可謂不繁多：媒體、博客……甚至大學通知，Twitter 更新都能覆蓋。

以訂閱「湖南省政府採購網」的「採購公告」為例，首先需要在 RSSHub 的文檔中找到「湖南省政府採購網」以獲取其訂閱的「路由」：

查詢文檔可知我們所需要的路由是/gov/hunan/notice/:type，其中:type是一個必選參數，我們需要獲取的是「採購公告」所以:type應該是cg，最終需要的路由就是/gov/hunan/notice/cg。將這個路由附加在我們部署（反代）RSSHub 的網址後，即可得到完整的訂閱地址，例如：部署rsshub的網址是https://rsshub.app，則最終的訂閱地址為：https://rsshub.app/gov/hunan/notice/cg，將其加入 FreshRSS 的訂閱即可。

需要注意的是，FreshRSS 似乎不支持自動轉換訂閱鏈接裡的非 ASCII 字符，如果你的訂閱鏈接裡含有這些字符，如https://rsshub.app/sspai/tag/派早報，則建議在瀏覽器內先訪問一下，再將轉換後的鏈接粘貼進 FreshRSS 以轉換鏈接中的非 ASCII 字符。

對於原本就有 RSS 的網站，推薦使用 RSSHub Radar，這是一款瀏覽器插件，可以實現 RSS 訂閱源的自動嗅探，而不必在網站上四處尋找。推薦它是因為，它不光可以嗅探 RSS 鏈接，如果目標網站可以用 RSSHub 訂閱，這個插件可以自動匹配支持的 RSSHub 路由。

Github 倉庫

最後……

經過了這一番折騰，基本體驗到了當時人人都用著 Google Reader 的樂趣。即便如此，屬於 Google Reader 的時代終究還是過去了，那個人人都可以從網上收穫純粹的知識與快樂的時代，也已然一去不復返。這些年來網速越來越快，但給我的上網體驗卻越來越差。大多數人都開始上網的時候，內容農場，推薦算法……只要有利可圖，互聯網精神，那個曾經作為互聯網基石的精神，就全被這些追逐利益的資本和官商勾結的政府拋在腦後。我甚至可以說：至少在中國，那個曾經「互聯網」的理想已死。

RSS 的沒落只是大環境的縮影，「技術」固然需要進步，但沒有與之相匹配的「人文」，這種進步就會成為一場災難。以我們現在的狀態來看，賽博朋克真的離我們不遠——技術進步，不但不能消除不平等，反而會加劇壓迫與控制。

即使大環境再怎麼黑暗，我們依然能看到一線生機，依然會有人去發揚幾乎被大環境拋在腦後但彌足珍貴的互聯網精神，散發光和熱，通過自己的方式捍衛互聯網的開放與自由。

感謝所有這些開源項目的貢獻者，也向所有熱愛分享的同路人致敬。

參考

以及這篇文章裡所有提到的鏈接。

近期 RSSHub 經歷了一次大重構，相應地，新增的路由所需的環境變量配置可以在路由對應文檔處找到，而不需要翻閱「部分 RSS 模塊配置」這一部分。 ↩︎
無論是自託管還是非自託管。 ↩︎

Docker Minecraft 開服記

Fri, 09 Jun 2023 13:52:54 +0000

我大概從2013年開始接觸到了 Minecraft ，算下來，今年正好是我接觸 Minecraft 的第十個年頭。

熟悉 Docker 以後，我著手開始把我現在跑的服務容器化，從某種意義上，這非常「優雅」——可以很方便的管理各個服務，還不用擔心各種環境不兼容的問題。

暑假將至，為了方便和朋友們聯機玩 MC，遂自行搭建一個服務器，順便進一步熟悉 Docker 和 Docker Compose。

服務器選擇

服務器有兩個要求，一是性能要足夠強，二是距離要足夠近，目前我手頭有三臺機器，分別位於香港和洛杉磯，不是性能不夠就是距離太遠，延遲太高。所以，都無法滿足需求。

最近恰逢618，各大雲主機廠商都有活動，遂購入一臺某大廠輕量服務器，位於上海，2C4G5M，對於一個入門 MC 服務器來說完全足夠。當然，買了這一個服務器不可能只是跑跑 MC，別的一些對帶寬要求不高的服務我肯定也會放在上面。

那麼直接 Deploy，似乎用的還是 AMD 的新 EPYC，還行。

安裝 Docker

相比於一鍵腳本，我個人還是偏好手動安裝 Docker。個人為了方便直接用了 Root，這不是最佳實踐，儘可能用普通用戶並在必要的時候用sudo。

添加 PGP 密鑰:

$ curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

向source.list添加軟件源：

$ echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

更新軟件包緩存並安裝 Docker：

$ apt update
$ apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

啟動 Docker:

$ systemctl enable docker
$ systemctl start docker

至此 Docker 已經安裝完成，順遍裝好了 Docker Compose。

Docker 換源

國內服務器這點非常蛋疼。

換源還要有一個命令行的文本編輯器，於是我決定先裝個 Vim：

$ apt install vim

編輯/創建/etc/docker/daemon.json：

$ vim /etc/docker/daemon.json

編輯成如下內容:

{
  "registry-mirrors": ["https://mirror.ccs.tencentyun.com"]
}

https://mirror.ccs.tencentyun.com是某大廠的內網鏡像，內網拉取速度極快，還不計流量，不在內網裡的服務器無法使用，應當換成下列鏡像：

https://hub-mirror.c.163.com
https://ustc-edu-cn.mirror.aliyuncs.com
https://mirror.baidubce.com

隨後重啟 Docker 服務即可完成換源：

$ systemctl restart docker

粗略部署

我部署服務的原則是先 Get it to work，再 Polish。

對於 MC 這種 community driven 的遊戲來說，社區的力量是強大的，基本上什麼樣的需求都能在社區裡找到對應的解決方案。我直接採用了 itzg/docker-minecraft-server。

不得不吐槽的是，這個項目的文檔寫得實在是沒有那麼友好，摸索了一下，總算是把這個服務基本的跑起來了。這時我的docker-compose.yml如下：

version: "3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - 25565:25565
    environment:
      EULA: "TRUE"
    tty: true
    stdin_open: true
    restart: unless-stopped
    volumes:
      # attach a directory relative to the directory containing this compose file
      - ./minecraft-data:/data

這樣的 Docker Compose 配置能以最新的版本把一個基礎的 Vanilla Server 跑起來，只能勉強滿足幾個人的聯機需求，肯定也沒幾個人會將這樣的配置用到生產環境。

進一步調整

要進一步調整，要先確認調整的方向，否則就是無頭蒼蠅，誤打誤撞，沒有目標，十分痛苦。實際感受一番後，我大致整理出了此時配置的問題，有些是 Vanilla 客戶端的問題：

版本不固定
缺少基本的性能數據
圖標和 MOTD 需要調整
沒有白名單
不能裝插件
有正版驗證(無所謂，我有正版)

有了這個方向，我就可以有目標的去調整這個 Server 的配置。接下來要做的，就是查閱這個項目的文檔，做出自己需要的修改。

固定版本

說實話 MC 的版本更新還挺頻繁的，前一個版本尚未體驗下一個版本就會出現。我暫時先固定這服務器的 MC 版本為1.19.4，日後充分遊玩再慢慢升級。

同時 Vanilla Server 實在是太垃圾，順便將其換成 PAPER 豈不美哉？分別設置VERSION和TYPE兩個環境變量即可。藉由 Paper 的優點，這樣也同時解決了服務器插件和性能數據的問題。

白名單

設置ENABLE_WHITELIST和ENFORCE_WHITELIST兩個環境變量，即可強制服務器核查白名單。同時，不要忘記將自己加入白名單，由於服務器的 OP 會被自動加入白名單，只需要將自己提前設置為 OP 即可，設置OPS即可做到這一點。

圖標和 MOTD

設置ICON和MOTD兩個環境變量即可自定義服務器的圖標和標語。

正版驗證

設置ONLINE_MODE變量即可控制正版驗證的開關。

需要注意的是，關閉ONLINE_MODE後，服務器會根據玩家的離線 UUID 判斷身份，離線 UUID 和在線 UUID 不同，此時添加 OP 和黑白名單都需要改用離線 UUID 進行。

最終的 docker-compose.yml

version: "3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - 25565:25565
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VERSION: "1.19.4"
      VIEW_DISTANCE: 8
      ENABLE_WHITELIST: "TRUE"
      ENFORCE_WHITELIST: "TRUE"
      OPS: ""
      ONLINE_MODE: "TRUE"
      SERVER_NAME: "Pub of NightCity"
      MOTD: "Want to have a drink?"
      ICON: ""
      OVERRIDE_SERVER_PROPERTIES: "TRUE"
    tty: true
    stdin_open: true
    restart: unless-stopped
    volumes:
      # attach a directory relative to the directory containing this compose file
      - ./minecraft-data:/data

一些雜七雜八的事情

RCON 的連接

服務器運行後，若要在不進入遊戲的情況下管理服務器，就需要用到 RCON。方法很簡單，使用這個項目綁定的 rcon-cli 即可：

$ docker exec -i  rcon-cli

注意將<name_of_container>換成自己的容器名。

作者還推薦了一個叫做rcon-web-admin的項目，打算過一陣子嘗試。

安裝插件

Paper 支持 Bukkit 的插件，還有自己的插件，插件數量上完全無需擔心。

我們在配置docker-compose.yml時，已經做了 bind 操作，會在docker-compose.yml所在目錄的相對路徑下創建一個叫做minecraft-data的文件夾，並綁定到容器的data目錄，將下載好的插件.jar文件丟進./minecraft-data/plugins目錄就完成了插件的安裝。

我選用了 World Edit，Grief Prevention 和 Dead Chest 三個插件，保證原汁原味的生存體驗。

最後

如果你有開服經驗並且偏向手動修改server.properties，將OVERRIDE_SERVER_PROPERTIES設置為FALSE即可將server.properties的控制權交還到我們手中，這也是一種配置的手段。

Docker 開服還是相對容易的，社區已經造好了輪子，免去了很多不必要的麻煩。稍後我會繼續 play around with the server，繼續探索這個遊戲無限的可能性。

Docker on 亂筆

拋棄所謂「客戶端」，直接使用 Mihomo 內核

需要的預備知識

安裝 Mihomo 內核

配置文件

自定義覆寫

自定義配置文件

管理面板

自動維護

防火牆

本機代理怎麼配置？

這麼折騰，何必呢？用客戶端不香嗎？

最速 Substore 訂閱管理指南

組合訂閱的管理

生成 Clash 配置

JavaScript 格式覆寫

YAML 格式覆寫

生成下載鏈接

OBS 多路推流折騰記：那些本不必要的麻煩

明確需求

多路推流

Bilibili 直播姬

推流到 Twitch

Netch

尾聲

docker-mailserver 郵件服務器搭建記錄

搭建 docker-mailserver 郵件服務器前的準備

防火牆的處理

驗證你的服務器是否具備搭建條件

搭建過程

拉取配置文件

用 Caddy 準備和自動維護 TLS 證書1

首次啟動容器

優化送達率

DNS 記錄

DKIM, SPF 和 DMARC2

客戶端設置

善用 MailTester

TODO-List

Firefish 數據庫升級記錄

升級前的部署概況

導出當前數據庫

導出文件的處理

向新數據庫導入現有數據

收尾工作

科學上網：用 Caddy 反向代理 VLESS

安裝 VLESS 和 Caddy

配置 VLESS

配置 Caddy

啟動服務

客戶端設置

完成

TODO List

搭建一個 BT 離線下載服務器

安裝 Aria2

用 Caddy 反向代理

配置 Aria-NG

用 Alist 映射下載目錄

完成

最速 Firefish 部署指南

需要的環境

最速教程

一些問題

重新撿起 RSS：RSSHub + FreshRSS 建立我的信息流

RSSHub：萬物皆可 RSS

反爬嚴格網站的部分解決

RSS 閱讀器推薦

Windows

Fluent Reader

ThunderBird

MacOS 和 iOS

NetNewsWire

Reeder

Fluent Reader

Linux

NewsFlash

Fluent Reader

安卓

Fluent Reader

FeedMe

用 Caddy 準備和自動維護 TLS 證書¹

DKIM, SPF 和 DMARC²