概要

オープンソースのWeb解析、

WordPressとMatomoを別々のサーバーで運用し、wp-matomo(現在の名称は「Connect Matomo」)を使用して連携させる手順を整理しました。

この設定により、WordPress側で収集したデータを別サーバーのMatomoへ送信し、WordPressの管理画面内でアクセス統計を確認できるようになります。

環境

Matomo側

  • Ubuntu 24.04
  • Apache 2.4
  • Mod Security v2

WordPress専用サーバ

  • Connect Matomoプラグイン

さっくりとした手順

  1. Matomo サーバでセキュリティトークンを発行します。
  2. WordPressのプラグインを設定します。

1. Matomoサーバー側での準備

まず、データの受け皿となるMatomo側で「接続許可証(トークン)」と「サイトID」を確認します。

  1. Matomoにログインします。
  2. サイトの追加: まだWordPressサイトを登録していない場合は、[管理(歯車アイコン)] > [ウェブサイト] > [管理] から「新しいウェブサイトを追加」でWordPressサイトを登録します。この際表示される 「サイトID」(通常は1, 2…といった数字)をメモしておきます。
  3. Authトークンの発行:
    [管理(歯車アイコン)] > [個人] > [セキュリティ] を開きます。
    ページ下部の 「認証トークン(Auth tokens)」 セクションで「新しいトークンを作成」をクリックします。
    パスワードを入力し、用途(例: WP-Connection)を入力して作成します。
    表示された 長い英数字の文字列(トークン) をコピーして控えておきます。

注意
※注意
トークンは一度しか表示されません。必ずこのタイミングでコピーしてください。

2. WordPress側での設定

次に、WordPressにインストールしたプラグインにMatomoの情報を入力します。

  1. 設定画面を開く: WordPress管理画面の [設定] > [WP-Matomo](または Connect Matomo)を開きます。
  2. 接続設定(Matomoへ接続o)タブ:
  • Matomo モード: 「自己ホスト (HTTP API, デフォルト)」を選択します。
  • Matomo URL: MatomoがインストールされているサーバーのURLを入力します(例: https://analytics.example.com/)。末尾に / を含めてください。
  • 認証トークン: 先ほどMatomo側でコピーしたトークンを貼り付けます。
  1. 変更を保存: 「変更を保存」をクリックします。
  • 接続に成功すると、上部に緑色のメッセージが表示され、「Select site」 ドロップダウンからMatomoに登録したサイト名が選べるようになります。

3. トラッキングの有効化

接続しただけでは計測が始まらない場合があるため、以下の設定を確認します。

  1. トラッキングを有効化タブ をクリックします。
  2. トラッキングコードを追加: 「デフォルトのトラッキング」を選択します。これにより、WordPressの各ページに自動で計測タグが挿入されます。
  3. 変更を保存 をクリックして完了です。

よくあるトラブルと確認事項

別サーバー構成でうまく動かない場合は、以下をチェックしてください。

-URLの正確さ: Matomo URLが httphttps か、またサブディレクトリ(/matomo/ など)にインストールしていないか再確認してください。

  • ファイアウォール: WordPressサーバーからMatomoサーバーへの通信(ポート80または443)が許可されているか確認してください。
  • キャッシュ: WordPress側でキャッシュプラグインを使用している場合、設定反映後に一度キャッシュをクリアしてください。

自分がドハマリしたポイント

接続に失敗し、その接続ログが出てこない事態も発生しました。

その答えは、筆者が設定したapacheの.confファイルに入りました。

SSL設定を、筆者の標準の

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

から、以下の形で修正。

SSLProtocol -ALL +TLSv1.2 +TLSv1.3

これにより通信ができるようになりました。これには以下の理由があります。

1. 通信プロトコルの不一致(ハンドシェイクの失敗)

当初の設定: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 (意訳:TLS 1.3 のみを許可し、それ以外をすべて禁止する)

修正後の設定: SSLProtocol -ALL +TLSv1.2 +TLSv1.3 (意訳:TLS 1.2 と 1.3 の両方を許可する)

WordPressサーバーがMatomo APIにアクセスする際、内部ではPHPの cURL や openssl ライブラリが使用されます。もしWordPress側のOSやライブラリのバージョンが少し古い場合、あるいは最新であってもクライアント側の設定が TLS 1.2 までしか対応していない場合、Matomoサーバーが「TLS 1.3以外は受け付けない」という設定になっていると、共通の通信言語が見つからず、接続が即座に遮断されます。

2. PHP / cURL / OpenSSL の依存関係

WordPress(PHP)が外部サーバーと通信する際、バックグラウンドではシステム標準のOpenSSLライブラリが動いています。

TLS 1.3 を利用するには、OpenSSL 1.1.1以上が必要です。

もしWordPress側のサーバーOSが少し前の世代(例:Ubuntu 18.04やCentOS 7など)であったり、PHPのコンパイル環境が古い場合、TLS 1.3でのハンドシェイクを完遂できず、TLS 1.2での接続を試みようとします。

このとき、Matomo側が -TLSv1.2(1.2禁止)としていると、WordPress側は「接続できるプロトコルがない」と判断し、エラーを出します。

3. 「接続ログが出ない」という現象の理由

Apacheのアクセスログ(access.log)には、HTTPリクエストが成功または失敗した記録が残ります。しかし、SSL/TLSのハンドシェイク(暗号化の交渉)は、HTTPリクエストが送られる前段階で行われます。

TLS 1.2が禁止されている場合: 通信路を確立する前の「挨拶(ハンドシェイク)」の時点でサーバー側が「そのプロトコルは使えません」と接続を切断します。

こういうとき、以下のコマンドが有効です。

openssl s_client -connect analytics.example.com:443 -tls1_2

もし、このコマンドを実行して CONNECTED(00000003) と表示され、その後に証明書の情報がズラッと出てくれば、「インフラ(OS/ネットワーク/Apache)の土台は完璧である」という証明になります。

逆にここでエラーが出るなら、WordPressの設定(プラグイン)をいくらいじっても解決しないということが一瞬で分かります。

そのため、Apacheは「Webサイトへのアクセス」として認識する前に通信が終了してしまい、通常のアクセスログには一行も記録されないという事態が起こった話。

厳格な設定が裏目に出たという話でした。