技術 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"
  }
}

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

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

從入門到進階：Tailscale + ShellCrash 異地組網和科學上網

Mon, 14 Apr 2025 10:10:25 +0000

在幾次旅途中，我試圖將新拍的照片上傳到長沙家中的 Immich 伺服器。過去我用 Cloudflare Tunnel 做反代，但由於國內特殊的網絡環境，連線慢速、頻繁中斷、上傳失敗幾乎成了常態。後來我開始嘗試 Tailscale —— 一個基於 WireGuard 的內網穿透工具，它終於讓我在全國各地都能穩定、高速地訪問家中的 NAS 和照片庫。

但新的問題也隨之而來：Tailscale 在 Android 手機上執行時，需要作為 VPN 服務接管系統流量，而我平時使用的 Clash 同樣依賴 VPN 介面進行分流。由於 Android 系統限制（只能啓用一個 VPN 服務），兩者無法共存，導致我必須在「訪問家中服務」和「科學上網」之間二選一。

這篇文章從 Tailscale 的原理講起，到自建 DERP 伺服器最佳化連線質量，再到如何用 iptables 劫持 Tailscale Exit Node 的流量並轉發給 ShellCrash，實現流量的靈活轉發與安全穿透。無論你是想訪問家庭區域網上的 NAS、照片庫，還是希望在陌生網絡中保護自己的資料安全，這篇文章都能為你提供一套實用、穩定的解決方案。

什麼是 Tailscale

Tailscale 是一款基於 WireGuard 協議的零配置虛擬區域網工具，它能夠讓分佈在不同網絡環境中的裝置像處於同一個安全內網中一樣互聯互通。透過自動穿透 NAT、防火牆等網絡障礙，Tailscale 讓你無需公網 IP、無需埠轉發，也能輕鬆訪問家中的 NAS、個人伺服器、開發環境等內網資源。它的核心優勢在於簡單、安全、穩定，啓動即用，資料傳輸全程加密，適合個人開發者、遠端辦公者、家庭用戶等多種場景使用。

Tailscale 的技術實現非常巧妙：其構建在 WireGuard 加密協議之上，卻顛覆了傳統 VPN 的 IP 分配邏輯。每個裝置透過 SSO/OAuth2 完成身份認證後，會獲得一個終身繫結的節點金鑰。這種基於身份的組網模式，讓「長沙的 NAS」和「香港的手機」在虛擬網絡中如同辦公室同事般直接對話。

Tailscale 的連線過程原理

中心控制伺服器（Control Server）

每個 Tailscale 客户端在啓動後，首先會連線控制伺服器（controlplane），進行身份驗證，並拉取整個網絡中其他節點的資訊，包括每台裝置的公網 IP、埠、NAT 型別等。這一步相當於是「認識朋友」。

Tailscale 的控制伺服器不會轉發任何資料，只負責協調連線 —— 類似一個排程中心。

DERP 伺服器

説到 Tailscale 能保持高連線成功率的關鍵，就不得不提到 Tailscale 自研的中轉協議 DERP，在 Tailscale 的網絡架構裏，DERP（Designated Encrypted Relay for Packets）是一個很重要但通常只在必要時介入的元件。簡單來説，它就是一個基於 HTTP 的加密中繼伺服器，用來在兩台裝置無法直接通訊時，作為它們之間的「中轉站」。

所有客户端之間的連線都是先選擇 DERP 模式（中繼模式），這意味着連線立即就能建立，用戶無需等待。然後連線雙方開始並行地進行路徑發現，通常幾秒鐘之後，Tailscale 就能發現一條更優路徑，然後將現有連線透明升級（upgrade）過去，變成點對點連線（直連）。¹

需要注意的是：

所有透過 DERP 的資料都是端到端加密的，DERP 伺服器無法檢視內容；
Tailscale 會盡可能少地使用 DERP，一旦直連建立成功，就會自動切換過去；
官方部署了多個分散式 DERP 節點，客户端會自動選擇延遲最低的那個；
你也可以自建 DERP 節點（比如在國內），來解決延遲高或連線不穩定的問題。

可以把 DERP 理解為一個兜底機制，雖然效能不如直連，但確保了即便不能打洞成功，裝置之間也始終能保持連線。

NAT 穿透（NAT Traversal）

拿到對端的地址資訊後，Tailscale 會嘗試透過 NAT 穿透來建立點對點（P2P）連線。這個過程使用了 STUN 協議，雙方互相傳送探測包，嘗試在 NAT 路由器上打出一條直連的通道。如果雙方的網絡條件允許，就可以成功建立起一個 UDP 的直連隧道，資料走直連，速度快、延遲低。

受制於篇幅，我無法完整細緻的講述 NAT 穿透的原理，若對這部分感興趣，可以閲讀 Tailscale 官方的「How NAT traversal works」一文。

完整連線流程圖示

flowchart TD
    A[裝置 A 啓動 Tailscale] --> B[透過 DERP 伺服器建立初始連線]
    B --> C[交換網絡資訊和 WireGuard 金鑰]
    C --> D[雙方並行進行 NAT 型別探測]
    D --> E{能否直連？}
    E -- 是 --> F[建立 P2P 直連隧道]
    F --> G[定期檢測連線質量]
    G --> H{直連優於 DERP？}
    H -- 是 --> I[切換大部分流量至直連通道]
    H -- 否 --> J[繼續透過 DERP 轉發部分或全部流量]
    E -- 否 --> J

    style B fill:#e3f2fd,stroke:#2196f3,color:#000
    style F fill:#e8f5e9,stroke:#4caf50,color:#000
    style J fill:#fff3e0,stroke:#ff9800,color:#000

自建 DERP

Tailscale 的安裝在各個平台上都相對簡單，官方文件已經提供了詳細的操作指南。本文將不再贅述安裝過程，以下內容預設你已經在相關裝置上成功安裝並登入了 Tailscale。

為什麼要自建 DERP？

Tailscale 在全球部署了眾多 DERP ²中繼伺服器，用於在打洞失敗時接管流量中轉。但由於眾所周知的原因，中國大陸並沒有官方部署的 DERP 節點。這意味着：

一旦 NAT 打洞失敗，所有流量都必須繞行海外的 DERP 節點，延遲高、速度慢，體驗極差；
某些官方 DERP 節點容易被 GFW 干擾，可能出現連線中斷、握手失敗等問題；
即使打洞成功，Tailscale 仍需透過 DERP 交換路由資訊和 WireGuard 金鑰，如果 DERP 不可達，連線質量也會受到影響。

因此，在國內網絡環境下，自建一個本地 DERP 節點，不僅可以顯著提高連線穩定性和傳輸效能，還能規避部分網絡封鎖所帶來的不可預期問題，是一個非常值得做的最佳化。

準備工作

前面提到，DERP 是基於 HTTP 的，所以你需要準備好一個 HTTP 反代服務，並自行解決 SSL 證書的簽發等基礎問題。本文使用 Docker 部署，在部署開始之前，你需要在你的伺服器上裝好 Docker 以及 Docker Compose 等附加元件。為了編輯配置檔案，你當然也得知道如何使用 nano 之類的編輯器。為了最好的效果，你的伺服器最好擁有靜態公網 IPv4+IPv6 雙棧地址。

如果以上條件都具備，就可以開始部署了。

mkdir tailscale-derp && cd tailscale-derp
nano docker-compose.yml

docker-compose.yml

services:
  derper:
    name: tailscale-derp
    image: fredliang/derper
    environment:
      - DERP_DOMAIN=derp.nightcity.pub
      - DERP_VERIFY_CLIENTS=true
      - DERP_ADDR=:4433
    network_mode: host
    restart: unless-stopped
    volumes:
      - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

network_mode: host是一個關鍵配置，表示容器將共享宿主機的網絡棧。如果使用 Docker 預設的 bridge 網絡模式，容器的網絡會經過 Docker 內網轉發，會造成 DERP 的 STUN 服務識別到 Docker 172.17.0.0/16網段下的地址，而無法識別到客户端正確的外網地址，導致 Tailscale 客户端無法正確連線。

volumes:
  - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

前面提到所有透過 DERP 的資料都是端到端加密的，DERP 並不知道是誰在使用，這意味着如果不採取措施，任何知道你 DERP 伺服器地址和埠號的人都可以使用它。這條配置的作用是掛載宿主機的 Tailscale 套接字檔案到容器內，目的是允許 derper 服務透過 Tailscale 的 tailscaled 服務進行身份驗證。配合DERP_VERIFY_CLIENTS=true，可以防止你的 DERP 節點被他人白嫖。

需要注意的是：

宿主機必須已經安裝並登陸 Tailscale 客户端（tailscaled），否則這個檔案不存在，容器會報錯；
tailscaled 必須以 root 許可權執行，才能建立這個 sock 檔案。

反向代理

以 Caddy 為例，需要反向代理 4433 埠，併為其部署 SSL 證書。

{
        email webmaster@l3zc.com
}

*.l3zc.com {
        encode gzip

        tls {
                dns dnspod APP_ID,APP_KEY
                resolvers 119.29.29.29 223.5.5.5
        }

        @derp host derp.l3zc.com
        reverse_proxy @derp :4433
}

需要注意的是，如果你和我一樣使用 Caddy 配合 dnsproviders 申請泛域名證書，Tailscale 的 MagicDNS 可能會導致 Caddy 本地證書驗證失敗而報錯，需要手動指定resolvers引數解決。

訪問剛剛反代的節點，如果出現以下頁面，説明配置正確。

配置 ACL 策略

開啓 Tailscale 控制枱的「Access Controls」頁面配置 ACL 策略，將配置好的 DERP 加上。

Tailscale 的 ACL 策略是用 HuJSON³ 寫的，想要在 VSCode 中編輯，選擇語言為「JSON with Comments（jsonc）」即可。以下是一個配置示例：

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],

  // 自建 DERP 配置
  "derpMap": {
    "OmitDefaultRegions": false, // 改為 true 以排除官方 DERP
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale 保留RegionID中的 1-899 作為官方節點，自建節點的 RegionID 必須大於等於 900。

測試連線

配置好 ACL 並儲存，Tailscale 會自動為所有客户端同步配置，稍等片刻在客户端用tailscale netcheck測試連線。

需要注意返回的 IP 是否是自己真實的公網 IP，若返回了172.17.0.0/16網段的地址，説明你 Docker 部分配置錯了。

與科學上網並存：在 Exit Node 劫持流量到 Clash 核心

宣告 Exit Node

在家中準備一個 24 小時開機的裝置，可以是樹莓派，可以是 MacMini。在上面安裝 Tailscale 並將其宣告為 Exit Node，並根據需要在 Tailscale 內網宣告家庭內網網段，隨後在控制枱啓用這個裝置作為 Exit Node，你就獲得了一個免費的 VPN，可以讓你在陌生的網絡環境中保持安全。

sudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24

廣播完成後，無論身處何地，只要能連上 Tailscale 網絡，就能訪問家中所有的內網裝置。

啓用 IP 轉發和禁用 UDP GRO⁴

啓用 IP 轉發是樹莓派等裝置作為 Exit Node 所必須的配置，這裏以樹莓派為例，如果你使用其他裝置，請自行查閲 Tailscale 官網教程。

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

根據 Tailscale 官方的説法⁵，禁用 UDP GRO⁶ 可以提升轉發效能，但官方的持久化教程似乎在樹莓派上無效，好在我們可以手動配置。

# 安裝 ethtool
sudo apt update && sudo apt install ethtool -y

# 關閉 UDP GRO
sudo ethtool -K eth0 gro off

針對持久化的問題手動編寫 systemd 配置檔案：

# 建立服務檔案
sudo nano /etc/systemd/system/ethtool.service

檔案內容如下：

[Unit]
Description=Configure eth0 GRO
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off

[Install]
WantedBy=multi-user.target

隨後啓動服務：

sudo systemctl daemon-reload
sudo systemctl enable ethtool
sudo systemctl start ethtool

在 Exit Node 劫持流量

我的 Exit Node 是一台樹莓派，在樹莓派上配置好 Exit Node 之後就來到了最後一步，也就是劫持手機傳送到 Exit Node 上的流量，實現科學上網。出於穩定性原因，我不希望在家庭主路由上直接執行代理軟件，為了實現這一點，直接在樹莓派上劫持流量是唯一的選擇。

首先安裝 ShellCrash，請自行根據你的需要匯入配置檔案、配置自動任務等：

export url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' && wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh  && bash /tmp/install.sh && source /etc/profile &> /dev/null

隨後啓動服務，修改修改防火牆執行模式為純淨模式，我個人建議將 SNI 嗅探開啓，並將 DNS 模式從fake-ip切換為redir-host⁷，同時啓用 IPv6 透明代理。

設定純淨模式的目的是手動配置 iptables 以實現更精準的流量劫持。我們直接用 iptables 劫持所有 tailscale 網絡卡作為 Exit Node 轉發的流量，首先用ifconfig檢視 tailscale 網絡卡的名稱，預設情況下一般為 Tailscale 0：

root@raspberrypi:~# ifconfig
eth0: ......

tailscale0: flags=4305  mtu 1280
        inet 100.111.19.50  netmask 255.255.255.255  destination 100.111.19.50
        inet6 fd7a:115c:a1e0::3d01:1332  prefixlen 128  scopeid 0x0
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 6780155  bytes 958732442 (914.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4811113  bytes 10858316472 (10.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

劫持tailscale0網絡卡的所有流量到本地 Clash 核心監聽埠7892，這個設定在 ShellCrash 中叫做「靜態路由埠」。以及，如果你不想和我一樣遇到莫名其妙的網絡問題，就一定不要忘記劫持 IPv6。

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

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

進階：用 TProxy 劫持 UDP 流量

iptables 的 REDIRECT 只能重定向 TCP 流量，UDP 沒有連線狀態（無連線協議），所以 REDIRECT 無法保留目標地址，導致透明代理無法知道原始目標地址。

所以，如果你用如下方式劫持 UDP 流量：

iptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892

則這個規則不會生效或代理行為不正常。

那麼，有辦法代理 UDP 流量嗎？有的兄弟，有的。但前提是：

核心支援 UDP 透明代理（Clash Premium 和 Mihomo 都支援）；
使用 TProxy 模式，而不是 REDIRECT；
正確配置了 iptables mangle 表和 policy routing；
代理配置檔案中啓用了 UDP 代理（如 mode: rule + udp: true）。

假設你已經滿足第一條、第二條和最後一條，則以下是一個示例⁸：

# 建立自定義鏈
sudo iptables -t mangle -N SHELLCRASH

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

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

# 介面跳轉
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

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

當然，不要忘記 IPv6：

# 建立鏈
sudo ip6tables -t mangle -N SHELLCRASH6

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

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

# 介面跳轉
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

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

路由規則持久化

ip rule和ip route建立的規則在重啓後會丟失，所以需要我們手動持久化，最簡單直接的方法就是建立一個指令碼，並將其新增至 crontab。

建立一個指令碼：

sudo nano /usr/local/bin/policy-route.sh

編輯為如下內容：

#!/bin/bash

# IPv4 策略路由
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 策略路由
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

授予執行許可權後編輯 Crontab：

sudo chmod +x /usr/local/bin/policy-route.sh
sudo crontab -e

在 crontab 檔案底部加上如下內容：

@reboot /usr/local/bin/policy-route.sh

原理解釋：TProxy 到底是怎麼轉發 UDP 流量的？

如果你看到這裏，也許會產生疑惑：為什麼整個流程中，我們沒有在 iptables 裏寫--to-ports，也沒看到目標地址被改寫，UDP 流量就莫名其妙地被代理了？這是怎麼做到的？

要解釋這個問題，我們先來看 TProxy 和 REDIRECT 的根本區別：

REDIRECT 模式：

使用 iptables nat 表；
將目標地址改寫為本地地址（比如 127.0.0.1:7892）；
通常用於 TCP 流量；
不能保留真實目標地址；
需要指定--to-ports。

flowchart TB
    A[客户端裝置
透過 Tailscale 發起 TCP 請求]
    B[tailscale0 介面接收流量]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash 本地監聽
127.0.0.1:7892]
    E[ShellCrash 發起新 TCP 請求
→ 目標伺服器]
    F[響應從網絡返回
ShellCrash 轉發響應]
    G[響應回到客户端裝置]

    A --> B --> C --> D --> E --> F --> G

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TPROXY 模式：

使用 iptables mangle 表；
不修改目標 IP，而是保留原始目標地址；
透過 fwmark 和 policy routing 將報文路由到 lo；
代理程式監聽一個特殊埠（例如 7893），並啓用 IP_TRANSPARENT；
支援 UDP 和 TCP；
不需要 iptables 內指定 --to-ports，因為不是 NAT，而是標記 + 路由。

flowchart TB
    A[客户端裝置
透過 Tailscale 發起 TCP/UDP 請求]
    B[tailscale0 介面接收流量]
    C[iptables MANGLE PREROUTING
打上 fwmark 233]
    D[ip rule: fwmark 233
使用 routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash 在 lo:7893 監聽
IP_TRANSPARENT 模式]
    G[ShellCrash 獲取原始目標地址
發起代理連線]
    H[響應從網絡返回
ShellCrash 轉發響應]
    I[響應回到客户端裝置]

    A --> B --> C --> D --> E --> F --> G --> H --> I

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TProxy 不使用 DNAT/REDIRECT，而是透過 mangle 表給資料包打上 mark，然後透過 policy routing（ip rule + ip route）將這些資料包送到 lo 介面。代理程式（如 Clash / ShellCrash）監聽在 lo⁹ 上的埠（例如 7893），透過啓用 IP_TRANSPARENT 選項，可以讀取資料包的原始目標 IP 和埠並進行代理轉發。

簡而言之，TProxy 模式只需要：

iptables 給資料包打上 mark；
ip rule + ip route 將這些包送到 lo；
程式監聽 lo 上的埠並開啓 IP_TRANSPARENT。

所以不需要在 iptables 中指定 --to-ports，因為目標 IP 和埠保持不變，代理程式自己可以感知並處理。

iptables 規則持久化

安裝iptables-persistent：

sudo apt update
sudo apt install iptables-persistent

安裝過程中會提示你是否儲存當前的 IPv4 和 IPv6 配置，選擇「是」即可。之後如果你新增了新的規則，記得執行儲存命令：

# 儲存當前 IPv4/IPv6 規則
sudo netfilter-persistent save

儲存後的規則檔案路徑：

IPv4：/etc/iptables/rules.v4
IPv6：/etc/iptables/rules.v6

你也可以直接編輯上面的rules.v4/rules.v6檔案，按需修改。

最終效果

這套方案的使用體驗取決於你家的上行頻寬，我家的網絡是下行 500M 上行 60M，目前沒有遇到一次打洞失敗的情況，所以基本都能跑滿，延遲也尚可接受，並且可以在外地隨時隨地端到端加密訪問家中的 Immich 和 OpenWRT 路由器等裝置以及實現科學上網，總體來看，我還算比較滿意。

蔘考: https://icloudnative.io/posts/custom-derp-servers/ ↩︎
蔘考: https://tailscale.com/kb/1232/derp-servers ↩︎
有關 HuJSON: https://github.com/tailscale/hujson ↩︎
蔘考： https://tailscale.com/kb/1408/quick-guide-exit-nodes ↩︎
蔘考: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes ↩︎
UDP GRO（Generic Receive Offload）是 Linux 核心中的一種網絡最佳化技術，主要用於合併多個小資料包以提高處理效率。但在裝置作為網絡轉發節點的使用場景下，這可能會導致轉發延遲增加和高丟包率環境下的吞吐量下降。 ↩︎
相較於fake-ip，redir-host相容性更好，出現問題的機率更低，也不會出現開關代理之後短時間內因為fake-ip殘留而斷網的情況，所以一般情況下我建議使用redir-host搭配 GeoSite 分流規則使用。我這台樹莓派的 DNS 上游是已經配置好的 SmartDNS，不存在 DNS 污染的問題，體驗良好。 ↩︎
蔘考: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo 是 Linux 系統中預設的「迴環介面（Loopback Interface）」，在透明代理中，它不僅處理 localhost 流量，還被用來接收原本屬於外部世界的網絡連線，實現對外部流量的本地劫持和轉發。 ↩︎

Google Play 商店的國內 CDN：從密碼學入門到分流策略最佳化

Sat, 15 Mar 2025 13:15:01 +0000

改用自己的 Mihomo 覆寫規則後，手機從 Google Play 上下載應用就會一直轉圈圈，而換用機場的規則就沒問題，非常奇怪。遂調取 Mihomo 核心日誌檢視。

play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 靜態資源[🇭🇰 香港 07]
play.googleapis.com:443 match GeoSite(GFW) using 節點選擇[🇭🇰 香港 07]
play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 靜態資源[🇭🇰 香港 07]
play-fe.googleapis.com:443 match GeoSite(GFW) using 節點選擇[🇭🇰 香港 07]
services.googleapis.cn:443 match GeoSite(CN) using 全球直連[DIRECT]

（以上日誌已精簡）

國行手機內建的 Google Play 服務使用services.googleapis.cn而非services.googleapis.com域名提供服務，而這個域名在大多數分流規則中都是直連，對，問題就出在這裏，修改規則把這個域名分流到代理就萬事大吉了！

……萬事大吉了，嗎？

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07]
rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07]
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using 漏網之魚[🇭🇰 香港 07]

等等，為什麼每次從 Play 商店下載應用都會出現這些奇怪的域名？在網上查詢一番資料後，新世界的大門就此開啓。

與 Google 截然相反卻又異曲同工的 Ångströ

看到 xn–ngstr-lra8j.com，熟悉域名的同學肯定知道，這是 PunyCode 編碼，這串字元解碼後就是 ångströ.com。Anders Jonas Ångström 是一位瑞典物理學家，他是光譜學的奠基人。¹埃斯特朗（Ångström）是為紀念他而以他的名字命名的長度單位，$ 1 Å = 10^{-10} m = \frac{1}{10} nm $，通常用於描述非常短的距離，比如原子和分子尺寸或光的波長。其代表極端小的量級，尤其是在物理學和化學中用於精細測量。

雖然 Google 的名字並不是直接取自「Googol」，但是它的靈感來源於該詞。「Googol」是一個數學術語，表達$10^{100}$，即1後面跟着100個零，是一個極其龐大的數字，常用來表示電腦科學中涉及的巨大數字或資訊量。

在命名哲學上，Google 與Ångströ 這對看似分處光譜兩端的科技概念，卻展現出耐人尋味的對稱美學。前者源於數學概念「Googol」的創造性改寫，後者則脱胎於物理單位「Ångström」的意象重構。這兩個經過藝術化變奏的稱謂，恰似科技文明的雙螺旋：Google 之稱承載着駕馭浩如星海的數字宇宙的雄心，Ångströ 之謂則暗喻着雕琢精微的原子級技術圖景。當這兩個經過創造性變形的專業術語在矽谷相遇，恰好構成了一組完美的認知座標——既指向人類處理資訊的尺度極限，也昭示着科技文明同時向宏觀與微觀進軍的壯闊征程。

入門密碼學：Google 基礎設施域名的規律²

OK，enough。現在讓我們把視角轉回 Google 的基礎設施。先來看一些完整的連線域名：

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com
rr5---sn-i3b7knzs.xn--ngstr-lra8j.com

這些看似隨機的字串，實際上是經過一些簡單的密碼學加密後的結果。讓我們拆解其中的核心部件。

城市名稱的轉換規則

以rr1---sn-j5o76n7z為例，關鍵的資訊段在sn-後面的 8 位：r1---sn-[123][45][6][78]。前三位，也就是本例中的j5o是城市名稱，由該城市主要機場的 IATA 碼透過一定的密碼學變換轉換而來。

首先構建一張 5 * 7 的數字字母表：

行0: 1 0 2 3 4
行1: 5 6 7 8 9
行2: a b c d e
行3: f g h i j
行4: k l m n o
行5: p q r s t
行6: u v w x y

逆時針旋轉這張表，即從新表格的左下角開始，依次按照原表格「從左到右，從上到下」的順序，把原表的資料在新表上按照「從下到上，從左到右」的順序謄抄。

旋轉完成後，可以得到下表：

| 6 d k r y |
| --------- |
| 5 c j q x |
| 4 b i p w |
| 3 a h o v |
| 2 9 g n u |
| 0 8 f m t |
| --------- |
| 1 7 e l s |

表格中間用線條框出來的 5*5 的部分就是最終的密碼錶，一共有 25 個字元，「從左到右，從上到下」依次代表字母a到字母y。例如，上海虹橋國際機場的 IATA 代碼為sha,我們可以透過這張表得到加密後的密文：

s在字母表中是第 19 個字母，「從左到右，從上到下」依次在密碼錶中數到第 19 個字元，也就是n
h在字母表中是第 8 個字母，「從左到右，從上到下」依次在密碼錶中數到第 8 個字元，也就是i
a在字母表中是第 1 個字母，「從左到右，從上到下」依次在密碼錶中數到第 1 個字元，也就是5

加密後的密文就是ni5。

反之亦然，回到一開始的城市名稱j5o，從我們剛剛得到的密碼錶中反推出原文：

j按照「從左到右，從上到下」的順序是第 3 個字元，也就是c
5按照「從左到右，從上到下」的順序是第 1 個字元，也就是a
o按照「從左到右，從上到下」的順序是第 14 個字母，也就是n

翻譯完成的明文是can，也就是廣州白雲國際機場的 IATA 碼，顯然，我們連線到的伺服器位於廣州。

要是谷歌有某個伺服器位於蘇黎世，而蘇黎世機場的 IATA 碼是zrh，有一個字母z，可是我們的密碼錶只有a到y啊？別擔心，Google 當然也考慮到了這個問題，z對應密碼錶中的1。

將這套規則用代碼表示如下：

table = "5cjqx4bipw3ahov29gnu08fmt1"
def iata2cipher(iata):
    global table
    iata = iata.upper()
    cipher = ""
    for element in iata:
        index = ord(element) - 65
        cipher += table[index]
    return cipher

def cipher2iata(cipher):
    global table
    cipher = cipher.lower()
    iata = ""
    for element in cipher:
        index = table.find(element)
        iata += chr(65 + index)
    return iata

# print(iata2cipher(input("IATA:")))
# print(cipher2iata(input("Cipher:")))

伺服器組編號

[45]和[78]位，如76和7z，表示伺服器組（接入點）編號，由下表第一列（已經用分隔線隔開）包含的字元組成，7elsz6dkry分別代表0123456789。所以，76的明文是05，7z的明文是04。

  | 1 2 3 4 5 6
7 | 8 9 a b c d
e | f g h i j k
l | m n o p q r
s | t u v w x y
z | 0 1 2 3 4 5
6 | 7 8 9 a b c
d | e f g h i j
k | l m n o p q
r | s t u v w x
y | z

以 Python 表示如下：

codeTable = "7elsz6dkry"
def cipher2code(cipher):
    global codeTable
    cipher = cipher.lower()
    codeString = ""
    for element in cipher:
        index = codeTable.find(element)
        codeString += chr(index + 48)
    return codeString

# print(cipher2code(input("Cipher:")))

同樣要將數字加密為密文同理，這裏不再贅述。

支援協議

[6]位表示網絡協議資訊：

n：IPv6（地址段 0x000-0x3FF）
u：IPv6（地址段 0x400-0x7FF）
m：僅支援 IPv4

例如：

a5mekn7r，IPv6 字首：2607:f8b0:4007:a::/64，IPv4 字首：74.125.103.0/24
a5m7zu7r，IPv6 字首：2607:f8b0:4007:407::/64，IPv4 字首：74.125.215.0/24
a5mekm76，僅支援 IPv4，字首：208.117.242.0/24

正確的分流處理

⚠️ 警告

Google 顯然不會為這些位於中國大陸的，未經 ICP 備案的 CDN 的穩定性和速度背書。如果流量足夠，那還是直接將services.googleapis.cn加入代理列表吧。

瞭解了 Google 基礎設施域名的加密規律後，我們可以根據這些資訊實現更精準的分流策略。目前已知 Google 在中國大陸的 CDN 節點主要分佈在北京（2x3）、上海（ni5）和廣州（j5o），對應的域名特徵可以透過正規表示式識別：

rules:
  - DOMAIN-REGEX,^r+[0-9]+(---|\.)sn-(2x3|ni5|j5o)\w{5}\.xn--ngstr-lra8j\.com$,DIRECT

這條規則會匹配所有形如 rr1---sn-j5o76n7z.xn--ngstr-lra8j.com 的國內 CDN 域名，並將其標記為直連。而對於其他未被覆蓋的 Google 域名（如 play.googleapis.com 等），仍遵循原有的代理規則。

事實上，GeoSite 數據庫的上游 v2fly/domain-list-community 已針對 Google Play 的國內 CDN 節點進行了最佳化³。只需在 Mihomo 配置中啓用 GEOSITE,GOOGLE-PLAY@CN 規則，即可自動實現國內 CDN 直連與海外域名代理的智慧分流：

rules:
  - GEOSITE,GOOGLE-PLAY@CN,直連
  - GEOSITE,GOOGLE,代理

最速 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-party-org/override-hub 內的 ACL4SSR 規則為靈感，幾乎完全重新編寫，具有以下優點：

整合 SukkaW/Surge 和 Cats-Team/AdRules 規則集，最佳化廣告攔截、隱私保護及流量分流精度
新增 Truth Social、E-Hentai、TikTok、加密貨幣等實用分流規則
移除冗餘規則集
引入 Loyalsoldier/v2ray-rules-dat 完整版 GeoSite/GeoIP 數據庫
針對 IP 規則新增 no-resolve 引數，避免本地 DNS 解析，提升上網速度，無 DNS 泄露
JS 格式覆寫現已實現節點國家動態識別與分組，自動為實際存在的各國家/地區節點生成對應代理組，節點變動時分組自動變化，省心省力。例如：你的訂閲沒有韓國的節點，則最終生成的配置中「韓國節點」這個代理組就不會出現。

JavaScript 格式覆寫

複製 JavaScript 格式覆寫檔案的 raw 連結https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.js，並根據需要在後面附加引數，格式如下：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.js#引數1=true&引數2=true

目前支援如下引數：

引數	功能
`loadbalance`	啓用國家/地區節點組的負載均衡
`landing`	啓用落地節點功能
`ipv6`	啓用 IPv6 支援
`full`	生成針對純核心使用場景的完整配置
`keepalive`	啓用 TCP KeepAlive

例如，若有負載均衡和 IPv6 需求，最終的覆寫指令碼連結為：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/convert.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}.yaml

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

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

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

生成下載連結

儲存成功後點選分享按鈕生成分享連結，設定分享有效期後點選「建立分享」，生成的連結即最終成型的 Mihomo 配置檔案，將其作為訂閲連結在你的代理軟件內訂閲就大功告成了。

我的家庭網絡域名解析方案

Thu, 06 Feb 2025 09:01:51 +0000

人在中國，用起 DNS 會碰到兩個問題，一個是 DNS 污染，另一個是 DNS 泄露。想要上網上得痛快，就必須要先解決 DNS 的問題。

什麼是 DNS 泄露

如果你現在正在開着代理看這篇文章，可以先開啓這個網站檢測一下自己的 DNS 請求是否被髮送到了國內的 DNS 伺服器上。

簡單來説，當你在使用 VPN 等代理工具時，你認為你的請求不會被除了你和 VPN 提供商以外的第三方看到，然而主機的 DNS 請求卻被髮送送給了運營商的 DNS 伺服器或者是公共 DNS 伺服器(阿里、騰訊等)進行解析，而你的真實 IP 地址和請求的域名都會被記錄下來。如果 DNS 請求解析一些敏感網站的域名(比如電報、維基解密等)，就會被監管者注意到，從而被警告或者請去喝茶。¹

因此，正確地配置代理工具的分流策略來避免 DNS 泄露就顯得尤為重要。

SmartDNS 的配置

防止 DNS 泄露

DNS 作為上網的指路人，排在第一位的要求就是必須要快，在這樣的要求下本地部署 SmartDNS 充當家庭網絡的 DNS 伺服器真的再合適不過了。關於 SmartDNS 的作用和配置技巧，以及其如何優選 CDN 加快網絡訪問速度，Sukka 的「我有特別的 DNS 配置和使用技巧」已經講的很好，推薦在繼續閲讀本文之前先去看看這篇文章，其中的內容我在這裏便不再贅述，我的敍述重心將會放在如何在 Luci 介面上實現這些配置。

如果你和我一樣使用 OpenWRT，SmartDNS 的 Luci App 會在每次啓動時根據面板上儲存的配置自動生成新的配置檔案，所以，不要直接修改/etc/smartdns目錄下原有的配置檔案，所有的更改都應該在 Luci App 裏操作。

基本上，SmartDNS 上游數量越多越好，因為較多的上游並不會影響 SmartDNS 的效能²，並且多個上游可以增加冗餘。為了防止 DNS 泄露，在配置上游時，應當在預設分組新增國外 DNS 上游（當然，最好是加密 DNS），並將國內的伺服器歸入一個單獨的分組（例如domestic），並加上-exclude-default-group的額外引數以將它們從預設分組中排除。

加速國內域名解析

設定好國外上游，DNS 泄露的問題就解決了，但因為我們在預設分組中排除了國內上游，訪問新的域名時需要等待國外上游返回結果，這顯然會拖慢國內網站的訪問速度，並且還會劣化 CDN。

dnsmasq-china-list 是 Felix Yan 的專案，目前支援透過 Makefile 生成 SmartDNS 格式的配置檔案，目前已經有人做好了現成的 Github Action 每天自動更新，直接下載就可以了，注意這些配置檔案只會在國內 DNS 上游分組名稱為domestic時生效。

cd /etc/smartdns
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

隨後在 SmartDNS 中引入這些配置檔案，將下面的內容貼上到「自定義設定」欄的末尾。

conf-file /etc/smartdns/accelerated-domains.china.domain.smartdns.conf
conf-file /etc/smartdns/apple.china.domain.smartdns.conf
conf-file /etc/smartdns/chinalist.domain.smartdns.conf
conf-file /etc/smartdns/google.china.domain.smartdns.conf

這樣配置之後，國內域名的訪問速度便不再會受到影響，訪問國外域名時，也不會再有 DNS 泄露的問題了。

去廣告

DNS 層面的去廣告效果有限，重點應該放在防止誤殺上，所以不要用那臭名昭著³的號稱自己是「致力於成為中文區命中率最高的廣告過濾列表」的 Anti AD，而是使用一些別的規則。個人使用的規則是 217heidai/adblockfilters，這是一個已經整理好的聚合規則，直接拉取即可。

wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf

最後引入配置檔案：

conf-file /etc/smartdns/adblock.conf

自動更新規則

設定如下 Crontab 即可在每天凌晨三點自動更新所有規則。

0 0 3 * * ?  wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/accelerated-domains.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/apple.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/chinalist.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/google.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

旁路由可以用嗎

除非不使用 IPv6，否則最好還是將 OpenWRT 路由器作為主路由。在作為旁路由的情況下，某些系統（説的就是你，Windows）會不遵守旁路由廣播的 IPv4 DNS，而執意使用運營商光貓廣播的 IPv6 DNS 進行解析，我嘗試修改過一些相關的登錄檔鍵值，但毫無作用。無奈只好讓運營商上門將光貓改為橋接模式，並將 OpenWRT 用作主路由。

覆寫 Clash 規則

這時如果你開着 Clash 去跑 DNS 泄露測試，大機率還是會看到你的 DNS 請求被髮到了中國的 DNS 伺服器上——幾乎所有機場的預設配置都會使用騰訊、阿里等國內大廠的加密 DNS，雖然不至於明文泄露到運營商 DNS 而導致你接到反詐中心的電話，但總讓人膈應 ~~（強迫症犯了）~~，更有甚者甚至完全沒有相關配置。

好在如果使用的是 Clash Verge Rev，那麼可以很方便的覆寫機場的配置，這裏分享我的覆寫配置，將其貼上到全域性擴充套件配置中即可覆寫機場的配置。

dns:
  enable: true
  ipv6: false
  prefer-h3: true
  use-system-hosts: true
  nameserver:
    - "https://dns.cloudflare.com/dns-query"
    - "https://dns.sb/dns-query"
    - "https://dns.google/dns-query"
    - "https://public.dns.iij.jp/dns-query"
    - "https://jp.tiar.app/dns-query"
    - "https://jp.tiarap.org/dns-query"
  nameserver-policy:
    "geosite:cn":
      - system
  fallback:
    - "tls://8.8.4.4"
    - "tls://1.1.1.1"
  proxy-server-nameserver:
    - "https://doh.pub/dns-query"
    - "https://223.5.5.5/dns-query"
  direct-nameserver:
    - system

配置解析

根據 Mihomo 文件⁴，其 DNS 請求的流程如下：

flowchart TD
  Start[客户端發起請求] --> rule[匹配規則]
  rule -->  Domain[匹配到基於域名的規則]
  rule --> IP[匹配到基於 IP 的規則]

  Domain --> |域名匹配到直連規則|DNS
  IP --> DNS[透過 Clash DNS 解析域名]


  Domain --> |域名匹配到代理規則|Remote[透過代理伺服器解析域名並建立連線]

  Cache --> |Redir-host/FakeIP-Direct 未命中|NS[匹配 nameserver-policy 並查詢 ]
  Cache --> |Cache 命中|Get
  Cache --> |FakeIP 未命中,代理域名|Remote

  NS --> |匹配成功| Get[將查詢到的 IP 用於匹配 IP 規則]
  NS --> |沒匹配到| NF[nameserver/fallback 併發查詢]

  NF --> Get[查詢得到 IP]
  Get --> |快取 DNS 結果|Cache[(Cache)]
  Get --> S[透過 IP 直接/透過代理建立連線]

  DNS --> Redir-host/FakeIP
  Redir-host/FakeIP --> |查詢 DNS 快取|Cache

其中nameserver-policy的優先順序高於nameserver和fallback，指定geosite:cn中的網站以系統 DNS 查詢，也就是使用之前配置好的 SmartDNS 查詢，可以享受到區域網級別的響應速度和自帶測速的 CDN 選擇。而不在geosite:cn中的網站則使用nameserver/fallback查詢，使用國外加密上游就可以確保解析結果的可信並防止 DNS 泄露。

替換 geoip 和 geosite 數據庫

Mihomo 預設使用 V2Ray 官方的 geoip 和 geosite 數據庫，這個數據庫其實不太全，而且更新的頻率也很慢，所以我還是用 Loyalsoldier/v2ray-rules-dat 這個「加強版」數據庫替換了原來的數據庫，只需下載geoip.dat和geosite.dat以後丟進核心目錄即可。當然，也可以新增幾行覆寫配置以實現自動/一鍵更新：

geodata-mode: true
geox-url:
  geoip: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
  geosite: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"

Clash Meta For Android

對於手機上的 Clash Meta For Android（以下簡稱 Clash），覆寫設定時需要更加考慮手機的實際情況。

首先手機上的 Clash 覆寫設定選項就不如桌面端的 Clash Verge Rev 這麼靈活，很多鍵值都不能覆寫。另外，手機不像電腦，需要經常切換網絡環境，這就導致系統 DNS 也會換得很頻繁，經測試，在這種情況下，每次更換網絡環境都需要開關一次 Clash 才能讓其更新system所代表的 DNS。於是我們只能退而求其次，固定一個國內加密 DNS 作為國內查詢。

進入 Clash ->「設定」->「覆寫」以下是所有覆寫設定：

「DNS」->「策略」：強制啓用
「DNS」->「Prefer h3」：已啓用
「DNS」->「Name Server」：新增兩個國外加密 DNS
「DNS」->「Name Server 策略」：在「鍵」一欄中填寫geosite:cn，值一欄填寫https://doh.pub/dns-query

提前從 Github 上下載geoip.dat和geosite.dat，最後進入 Clash ->「設定」->「Meta Features」，分別用「匯入 GeoIP 數據庫」和「匯入 GeoSite 數據庫」功能匯入它們。

完成

最後再開啓一個 DNS 泄露測試，看一看問題是否解決，如果不再出現國內的 DNS，説明配置正確，好好享受 SmartDNS 和 Clash 帶來的網絡最佳化和防泄漏吧~

蔘考自: https://blog.lololowe.com/posts/8f1e/ ↩︎
SmartDNS 在設計時就考慮到了延遲問題，具體機制可以蔘考「中場休息：SmartDNS 是如何避免因測速導致 DNS 解析過慢的」。 ↩︎
有人整理了 Anti AD 的光榮事蹟。 ↩︎
引用自: https://wiki.metacubex.one/config/dns/diagram/ ↩︎

Windows Hiccup 小日常：處理時間同步服務的問題

Mon, 18 Nov 2024 10:03:47 +0000

不知出了什麼問題，我的電腦的時間從來不會自動和 NTP 伺服器同步，雖然短期內並不會對使用造成什麼影響，但倘若放任不管，時鐘的偏移量太多，則可能會造成 SSL 和 TOTP 等依賴時間戳的應用出現問題，再者，手動按同步鍵也很不方便，今天我決定必須要解決這個問題。

SpecialPollInterval

在網上搜尋一番之後，我發現有人提到SpecialPollInterval這個鍵值，其具體位置是HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient，微軟官方文件對其的描述如下：

This entry specifies the special poll interval in seconds for manual peers. When the SpecialInterval 0x1 flag is enabled, W32Time uses this poll interval instead of a poll interval determine by the operating system. The default value on domain members is 3,600. The default value on stand-alone clients and servers is 604,800.

對於一般客户端，這個鍵值的預設值是604800，也就是一個星期同步一次，這個間隔顯然太久，於是我將其設定成了3600令其一小時同步一次。

w32tm

幾天後，當我再次檢查時間時，卻發現時間仍然沒有自動同步，這一次的偏移量已經達到了 15.8 秒。

於是查詢「SpecialPollInterval」想要知道其具體的作用和未及預期目的的原因，卻發現了微軟的一篇疑難解答。這篇疑難解答指出：「每次客户端輪詢時間樣本到 NTP 伺服器時，NTP 客户端都會進入 SPIKE 狀態。時間服務管理其內部狀態，如果客户端進入 SPIKE 狀態，則客户端不會同步其時間。」

為了解決這個問題，需要將 Windows 時間配置為使用 MinPollInterval/MaxPollInterval 作為輪詢間隔。

w32tm /config /update /manualpeerlist:cn.pool.ntp.org /syncfromflags:MANUAL

服務尚未啓動

執行這一行配置時出現了「服務尚未啓動」的提示，這説明用於時間同步的服務根本沒有啓動。如此基礎的服務竟然不會自動開機啓動，我也不知道這是 Windows 的 Bug 還是我後期使用無意間製造的問題，不管怎樣，首先啓動這個服務：

net start w32time
w32tm /register   # 註冊一些基本的登錄檔鍵值和相關服務

隨後 Win + R 執行services.msc開啓服務管理面板，找到「Windows Time」服務，將其啓動型別設定為「自動」，即可讓其開機自動啓動。

再次重新啓動電腦，這次開啓「設定」–>「時間和語言」–>「日期和時間」–>「附加時鐘」，切換到「Internet 時間」選項卡，如果出現了「下次同步」的字樣，説明這套系統終於是正常運作了。

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 就完成了。