Caddy on 亂筆

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

科學上網：用 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 正統了。 ↩︎