これは、自分のWeComアプリ用に固定のAPI転送入口を用意するための記事だ。呼び出し側は自分のドメインにリクエストを送り、Caddyがそれを qyapi.weixin.qq.com へ転送する。WeComへのログインを代替するものでも、アプリの権限や管理画面のアクセス制限を回避するものでもない。
説明図：WeCom APIの転送：上流を固定し、呼び出し側を制限する
ドメインとサーバーを用意する
WeCom APIに到達できるサーバーを用意し、自分のドメインをそこに向ける。この記事では wecom.example.com をプレースホルダーとして使うので、デプロイ時は必ず実際のドメインに置き換える。サーバーの実際の出口IPも、WeCom管理画面側の制限とあわせて確認しておこう。海外サーバーしか使えないわけではない。
公開側の入口はHTTPSにする。Caddyが証明書を自動取得するには、ドメインの名前解決と検証用ポートが正常に通っている必要がある。手間を省きたいからといって、access_tokenを含む呼び出しを平文HTTPに通してはいけない。
Caddyfile
以下では、呼び出し元の公開IPを1つだけ許可する。198.51.100.10 はドキュメント用のサンプルアドレスなので、必ず置き換えること。そのまま使ってはならない。
wecom.example.com {
@allowed remote_ip 198.51.100.10
handle @allowed {
reverse_proxy https://qyapi.weixin.qq.com {
header_up Host {upstream_hostport}
}
}
handle {
respond "Forbidden" 403
}
}
この設定は上流を固定しており、クライアントが任意の転送先を指定できるオープンプロキシではない。許可リストはCaddyが実際に見た送信元IPで照合される。入口の前にCDNや別のプロキシがある場合、そのIPをそのまま実クライアントのアドレスとして扱うことはできない。信頼できるプロキシの連鎖を別途設計する必要がある。
header_up Host {upstream_hostport} は、すべてのバージョンで必須の決まった書き方というわけではない。現在のCaddy 2.11以降はHTTPS上流に対してHostを自動処理する。ここで明示しているのは、リクエストの関係と互換性のある設定を示すためであり、明示的なHost設定がすべてのバージョンの要件だと受け取らないでほしい。
公式Caddyイメージで動かす
services:
caddy:
image: caddy:2
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
まず実際のCaddyfileを用意し、設定を検証する。
docker compose run --rm caddy caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
docker compose up -d
docker compose logs --tail=100 caddy
htnanako/wxproxy は別のサードパーティ製プロキシコンテナであり、公式Caddyイメージではない。両者は異なるデプロイ方法なので、同じサービスとして混同して書かないこと。
アプリに組み込むときはAPIのベースアドレスだけを置き換える
アプリがもともと https://qyapi.weixin.qq.com/cgi-bin/... をリクエストしているなら、カスタムのWeCom APIアドレスに対応している前提で、自分の https://wecom.example.com/cgi-bin/... に変更する。パスと業務パラメータはWeCom APIの仕様に従って記述する。
WeComのsecret、access_token、メッセージ本文を公開サンプルに書かないこと。リクエストログを有効にする前に、クエリ文字列に含まれるtokenをまず考える。トラブルシューティングのスクリーンショットでも隠す。まず実際の認証情報を含まないリクエストで送信元制限を確認し、その後、自分の環境で権限のあるAPIテストを完了させる。
Discordの招待リンクはWebhookではない。両者は接続方法が異なり、招待URLをメッセージAPIとして使うことはできない。
参考：Caddyのインストール、reverse_proxy、WeCom開発者ドキュメント。この記事はドキュメントと設定構造の確認までで、あなたのサーバー上での実際のデプロイやメッセージ送信は行っていない。