Lycolog

Google Analyticsを廃止してMatomoを導入してみた結果、SQLでログを読めるようになったので、Apacheのログをインポートした結果から、来訪ユーザーのIPバージョン比率を集計してみた。

集計期間は2025年5月13日～2025年8月14日。

サイト別のIPバージョン比率

国内と国外からのアクセスのうちIPv4, IPv6の比率。

サイト別のIPバージョン数

サイト別のIPバージョン比率の導出に使った元ネタ。各項目のユニークIPの個数。

ECO-Wikiの統計

ECO-WikiのIPv4とv6の数と比率。Googleからまともにインデックスされてないからか、かなり実際のユーザーの数に近い値が出たため、特別に取り上げている。

このサイトは1日のPVが200前後あり、集計期間が93日であることを考えると18.6kほどのPVがあったと思われるが、IPの本数としては非常に少なく、ほとんど固定ユーザーで回っていることが伺える。

雑感

自宅サーバーに移行する場合、IPv6シングルスタックとなるわけだが、この割合だとかなり厳しい。特にメインコンテンツである、このブログのIPv6率が1%すらないのは極めて致命的だ。

むしろ特に価値のないlycolia.infoは31%ほどあり、比較的まともだ。ECO-Wikiに至っては57%を超えており、IPv6率が顕著に高い。

ただECO-Wikiはアクセスするユーザーが固定されていると考えており、大半が常連であるためこういう結果になっているのだとは思う。対してこのブログには恐らく常連はいないか、いても全体の1%いるかどうかだと思われる。

つまり常連が全員IPv6だとしても精々1%になるわけだ。

とはいえ、日本国内のIPv6対応状況はGoogleによると56%ほどあるとされており、来訪者が完全にランダムだとしても1%未満というのは異常すぎる。意味があるかは不明だが、念のためにaレコードより先にaaaaレコードを配置してみた。間違いなく意味はないと思う。

このままでは移行しても実質私以外見れないことが予想されるため、Matomoのカスタムディメンジョンを使ってIPv6に対応しているがIPv4でアクセスしているユーザーを調べることにした。

カスタムディメンジョンというのはアクセスログを取るときに追加のパラメーターを設定する機能だ。AAAAレコードしかないhttps://ipv6.lycolia.info/というドメインを切り、ここに疎通するかどうかを記録することにしている。1～3月くらい収集して、Matomoの生ログに以下のクエリを打てばおおよその比率は分かるだろう。

SELECT
  SUM(CASE WHEN LENGTH(location_ip)=4 THEN 1 ELSE 0 END) AS ipv4_count,
  ROUND(SUM(CASE WHEN LENGTH(location_ip)=4 THEN 1 ELSE 0 END)/COUNT(*)*100, 2) AS ipv4_ratio,
  SUM(CASE WHEN LENGTH(location_ip)=16 THEN 1 ELSE 0 END) AS ipv6_count,
  ROUND(SUM(CASE WHEN LENGTH(location_ip)=16 THEN 1 ELSE 0 END)/COUNT(*)*100, 2) AS ipv6_ratio,
  SUM(CASE WHEN LENGTH(location_ip)=4 AND custom_dimension_1='v6ok' THEN 1 ELSE 0 END) AS ipv4_v6ok_count,
  ROUND(SUM(CASE WHEN LENGTH(location_ip)=4 AND custom_dimension_1='v6ok' THEN 1 ELSE 0 END)/COUNT(*)*100, 2) AS ipv4_v6ok_ratio
FROM
	matomo_log_visit
WHERE
	custom_dimension_1 IS NOT NULL;

またApacheのログとGoogle Analyticsの内容に著しい乖離があったため、Apacheのログの信頼性も怪しい部分がある。というのはBOTの類が相当入っている可能性があり、BOTによるアクセスで比率が狂っている可能性も否定できない。とはいえ、本ブログではv6のIPが13個しか検出されてなかったので、BOT以前の問題だろう。

サーバーログとGoogle Analyticsとの乖離内容としてはシンガポールからのアクセスIP数が33kもあり、アメリカからも4kで、日本からのはたった1.5kしかなかったのだ。Google Analyticsのユーザーベースでは同じ期間で日本4.7k、シンガポール92、アメリカ29だったため、あからさまに異なる。これは恐らく多くのBOTはJSが動かない環境で動いており、GAのカウントから外れるのが大きいだろう。ApacheのログからはじけるBOTは精々UAに丁寧に書いてくれているか、ブラウザのバージョンが極端に古い典型的なものくらいで、まともに偽装しているやつは識別しようがないのでどうしようもない。

再三にはなるが本ブログではv6のIPが13個しか検出されてなかったので、それ以前の問題であることは明白なのだが…。

あとがき

MatomoのDBに入ったApacheのログが余りにもノイズなので消した。余りにも新規で取れるデータと内容に乖離がありすぎて、アクセス数が-300%みたいに出るし、通常運用では混入しない膨大なBOTアクセスログが見えるのが嫌だった。

消した時の行動としては、まずSSHで/path/to/matomoに移動し、./console core:delete-logs-data --dates=2025-04-01,2025-08-14のように削除したい期間を指定してコマンドを叩く、これでvisit系テーブルのデータが根こそぎ消える。次にmatomo_archive_blob_とmatomo_archive_numeric_で始まるテーブルをすべて消し、/console core:archive --url=<Matomoの設置URL>を叩いたら綺麗になった。

DROP TABLE matomo_archive_blob_2025_08;
...
DROP TABLE matomo_archive_numeric_2025_08;
...

visit系テーブルのデータを消しただけだと日別アクセス数は消えないので、これを消すために日別のレポートを記録しているテーブルを消し飛ばし、更にレポートのキャッシュをクリアする必要があった。

最近仕事で全然SQL打たないので、今回の一連の作業（統計出しを含む）はなんとも新鮮だった。

Google Analyticsには長らく不満があり、ほとんど活用できていなかったが、今回Matomoというアクセス解析を発見したので、これに乗り換えることにした。

• 何故Google Analyticsを使っていたか？
• セルフホスティングで動くアクセス解析には何があるか探してみた
• Matomoを選んだ理由
• アクセス解析に求めるもの
  • 日時別のアクセス統計
  • リファラデータ
  • ユーザートラッキング
  • UserAgentや国、地域情報などの環境情報
  • IPアドレス
• Matomoを選んでよかった理由
  • 既存のアクセスログの解析ができた
  • 画面読み込みが圧倒的に軽い
  • リアルタイム解析が見やすい
  • さくらのレンタルサーバーで動く
  • ログDBが手元にあるので調査に便利
• あとがき：地味にある日本語由来のソフトウェア

何故Google Analyticsを使っていたか？

端的に言うと当時は他に選択肢を知らなかったから。

元々アクセス解析にはデジロックが運営するAccessAnalyzer.comというサービスを使っていたのだが、これがサービス終了したので仕方なくGoogle Analyticsに乗り換えたという経緯がある。

AccessAnalyzer.comは素晴らしく、ページ別のアクセスは勿論のこと、来訪者の検索ワードや検索エンジン、IPなどが分かりやすく見れる高機能なアクセス解析だった。今からしてみればプライバシーもなんもないが、アクセス解析というのは当時そういうものだった。更に動作も軽く、画面はパッと出てきた。

しかしGoogle Analyticsはそうではない。AccessAnalyzer.comで見れていた情報の大半は見れなくなり、精々ページ別のアクセス数が見れるだけだ。しかも画面が超絶重い。StableDiffusionが動くマシンでさえ重い。これは異常だ。

画面構成も判り辛く、とっつきづらい。ほぼ毎日のようにアクセス解析を眺めていた私は、Google Analyticsに移行してからは年に数回しか見なくなった。

それほどまでに魅力がなかった。プライバシーポリシーをサイトに書かないといけないのも癪だった。

セルフホスティングで動くアクセス解析には何があるか探してみた

まず私は昨今、さくらインターネットで動いているサイトを自宅サーバーへ移行することを考えている。その過程で、アクセス解析もセルフホスティングに移せないかを考えていた。

そこでセルフホスティングベースのアクセス解析を調べてみて、興味を引くものを幾つか見つけたので、簡単に機能比較をしてみた。GoAccessはアクセス解析というよりサーバーログ解析なので別物として扱った方がよい。

Matomoを選んだ理由

まずは何よりもCGIとして動作することだ。私はWebスクリプトの動作要件ではCGI動作可能かどうかを最重要視している。

理由としてはレンタルサーバーで動くからという部分が大きいが、自宅サーバーにおいてもリソースを食わないことや、メモリリークを起こしづらいことが魅力に感じている。個別にサーバーが起動しないため死活監視が不要なのもメリットだろう。nginxで動かす場合は、FastCGIの生死が見れたらよい。

また上の表でも最も〇評価が多く、私の求めている要件に大きく合致しているからだ。市場シェアと歴史もあり、継続的にメンテナンスされそうという期待も大きい。

アクセス解析に求めるもの

私は趣味でWebサイト運営をしているため、どういったユーザーが来ているのか、常連はどれほどいるのか？みたいな興味関心の部分に注視している。

日時別のアクセス統計

ある日時にどのページにどの程度アクセスがあったかをグラフなどで表示できる機能は基本的に欲しい。逆にこれがないのならサーバーログをパースして見た方がマシだ。

リファラデータ

セキュリティが強化された現在においては、具体的にどこからアクセスがあったかというのは追いづらいが、それでもドメインくらいは見れるため、Googleから来たのか、Xから来たのか、社内SNSから来たのかなど、ある程度特定できるのは個人的に興味がある。

ユーザートラッキング

ユーザーにトラッキングCookieを付与することで、いったいどれほどのユーザーが再訪しているのか、何を見ているのか？というのを見るのに使っている。古典的なサイト運営者としては常連がいることが分かると、やはり嬉しい。

UserAgentや国、地域情報などの環境情報

どんなブラウザや、国、地域から来ているのかわかるのは興味深い。例えば私は神戸に住んでいるので関西圏からのアクセスが多ければ少し嬉しくなったりするし、シンガポールからアクセスがあれば驚くこともある。

他にも使用しているブラウザやOSなどもわかるとなんとなく楽しい。

IPアドレス

トラッキングIDがなかった時代はこれをトラッキングコードの代わりにしていたが、実は今では重要性はほとんどない。

個人的な直近の需要としてはIPv4とIPv6の比率が分かればいいので、IPアドレスそのものはなくてもかまわない。但し現状ではDBの生ログをベースに集計せざるを得ない状況なので、有用な機能だ。

Matomoを選んでよかった理由

既存のアクセスログの解析ができた

さくらのレンタルサーバーにあるApacheのログを食わせてDBに登録できるため、SQLベースの解析ができるのは有益だった。Google Analyticsでは見れない角度で見ることもできた。

但しサーバーログはノイズも多く、トラッキングもできないため、自分のアクセスすら特定が困難で、あまり使えなかった。この結果については別記事にする予定だ。

画面読み込みが圧倒的に軽い

私のマシンはCore Ultra 7 265FにRTX 5070 Ti、メモリを64GB積み、fast.comでの回線速度が360Mbps、遅延が5msの性能があるが、この環境をもってしてもGoogle Analyticsの画面読み込みや、画面遷移は非常に遅く、使うのが億劫だった。

しかしMatomoは画面遷移が極めて速く、何らストレスがない。

リアルタイム解析が見やすい

ここまで直感的にわかるのは便利だ。いつだれがどこに、どんな環境でどこから来ているかが一目瞭然である。

さくらのレンタルサーバーで動く

さくらのレンタルサーバーでも動くのはありがたい。自宅サーバーへの移行はまだできていないし、色々あって前途が怪しい部分もあるからだ。

ログDBが手元にあるので調査に便利

ログDBが手元にあるため、画面上では見れないデータを見る場合にも便利だ。

例えばApacheのログを食わせた後に自分がどのサイトをどの端末から見ていて、IPのバージョンを追跡したい場合、次のようにして調べることが出来る。このようにMatomo画面では見れないデータも柔軟に見れるのは非常に便利だ。

SELECT
*
FROM
(
    SELECT
        visit_last_action_time,
        idsite,
        CASE
            WHEN LENGTH(location_ip) <= 4 THEN INET6_NTOA(location_ip)
                ELSE ''
        END AS ipv4,
        CASE
            WHEN LENGTH(location_ip) > 4 THEN INET6_NTOA(location_ip)
                ELSE ''
        END AS ipv6,
        config_browser_name,
        config_os
    FROM matomo_log_visit
) TBL
WHERE
	ipv4 = '自分のIPv4アドレス'
OR	ipv6 LIKE '自分のIPv6アドレスの先頭4フィールド%'
ORDER BY
	visit_last_action_time DESC;

あとがき：地味にある日本語由来のソフトウェア

UmamiとかMatomoとか、日本語ベースのアクセス解析が複数あるのはちょっと面白いなと思った。見た感じ、どちらも日本人の開発ではなさそうだ。

由来としてはUmamiはご飯のアイコンからして旨味なのだろうが、明確な由来は見つけられなかった。Matomoは日本語におけるhonestyの意味から取られたそうだ。

よく考えてみるとWebソフトウェアには日本語由来のものが結構あるかもしれない。例えば他にもPythonのJinjaやCSSフレームワークのBulmaが日本語に由来している。

デフォルトではeth2は無効化されており、繋いでも何も起きない。

LuCIで設定してゆく。

• 確認環境
• 手順

確認環境

• R86S U1
• OpenWrt 24.10.0

手順

1. LuCIに入る
2. Network→InterfacesからDevicesタブを開く
3. br-lanのConfigureを開く
4. General device optionsタブのBridge portsでeth2を選択する
   

   

   

5. 保存してSave & Apply

R86S U1を買ってOpenWrtをインストールしてから今までずっとSPF+ポートが認識されていなかったので認識可能にした。

• 確認環境
• 前提条件
• 手順
• なぜこれをしようと思ったか？
• 有効化したSPF+ポートをLANに繋ぐ方法

確認環境

• R86S U1
• OpenWrt 24.10.0

前提条件

• インターネット環境があること

手順

1. 認識されているかどうか確認し、何も出てこなければ次のステップへ

   dmesg | grep mlx4
   

2. ドライバをインストール

   opkg install kmod-mlx4-core
   

3. 再び認識されているかどうかを確認する

   dmesg | grep mlx4
   

なぜこれをしようと思ったか？

最初はeth0, eth1との排他制御かと考えていたが、RJ45とSPF+でNICが分離している構造上ありえないので、有効化できるはずだと思ったためやってみた。ポートはあればあるほど都合がいいし、RJ45が使えればSPF+に対応してない機器もつなげて便利なので。

有効化したSPF+ポートをLANに繋ぐ方法

機材不足で未検証だが、基本的にはOpenWrtでR86S U1のeth2ポートをLANに繋ぐ方法でLANに繋ぐものが出来ると思う。

参考までに有効化したSPF+ポートはeth3, eth4として認識されていることを確認している。これはdmesg | grep mlx4すると分かる。

本記事はここ昨今のOpenWrtセットアップシリーズの続きである。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けない。しかし、IPv6であれば、理論上全部のポートが使えるはずで、それであればサーバーを建てられるのではないかと考えたので、やってみた記録。

セキュリティを考慮し、サーバー以外にはアクセスできないよう、NATのような仕組みで構築する。

• 確認環境
• 前提条件
• 今回の要件
• やり方
  • サーバーとDNSの設定
  • ルーターのファイアウォールに穴をあける
    • 設定ファイルを編集する方法
    • LuCIでやる方法
• 備考
  • OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない
  • IPv4アクセスをどうするか？
  • Cloudflare Tunnelを使わない理由
  • 疎通検証に使える簡易サーバーの作り方
  • 疎通確認に使えるcurl例
  • 複数ポートの開き方
• 関連記事

確認環境

前提条件

IPv4環境下でのHTTPSアクセスが可能で、かつ以下のセットアップが終わっているものとする。

• 自作ルーターを作っていくのにR86S U1を買ったのでOSのインストールをした
• R86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモ

今回の要件

ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりIPv4のNATにあったセキュリティの再現を行うことで、関係ない端末が攻撃されないようにする。

やり方

サーバーとDNSの設定

1. nginxの設定を開きlisten [::]:443を追加して再起動
   1. sudo service nginx restart
2. サーバーマシンのIPv6(Global Unique Address, GUA)を控える

   ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
   

3. Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する

ルーターのファイアウォールに穴をあける

設定ファイルを編集する方法

1. vi /etc/config/firewallで以下の行を追加

   config rule
           option name 'Allow-Server-IPv6'
           option src 'wan'
           option dest 'lan'
           option proto 'tcp udp'
           option dest_ip 'さっき控えたサーバーのIPv6アドレス'
           option dest_port '443'
           option family 'ipv6'
           option target 'ACCEPT'
   

2. service firewall restartでfirewallを再起動する

LuCIでやる方法

1. LuCIに入りNetwork→Firewall→Traffic Rulesを開く

2. Addボタンを押し、次の要領で入力して保存
   General Settings

   項目	値
   Name	Allow-Server-IPv6
   Protocol	TCP│UDP
   Source zone	wan
   Destination zone	lan
   Destination address	さっき控えたサーバーのIPv6アドレス
   Destination port	443

   Advanced Settings

   項目	値
   Restrict to address family	IPv6 only

3. 穴をあけたIP以外が外部から疎通しないことを確認

4. 穴をあけたIPが外部から疎通することを確認

備考

OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない

結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。

v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。

つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。

IPv4アクセスをどうするか？

現状は2案検討している。

1. どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
2. SNSなどのOGP対策で、簡単なプロキシを組んでおき、OGPだけ出るようにしておく

2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。

Cloudflare Tunnelを使わない理由

Cloudflare Tunnelを使えればIPv4を利用でき、デュアルスタック対応もできるだろう、しかしなぜ使わないのかという話。

基本的にオンプレミス至上主義だからというのが答えにはなるが、実務的な理由もある。

まずCloudflare Tunnelを利用する場合、ネームサーバーを委任する必要があるが、CloudflareのDNSはさくらインターネットのSPFレコードを扱おうとするとバリデーションエラーを吐いて使えない。他にも、管理画面のUIがお世辞にもよくなく、言葉を選ばず言えばクソである点もある。勿論、余計なレイヤーを増やすことによる運用コストの増大もあるため、使わなくて済むのであれば、それに越したことはないという考えだ。

またCloudflareのWAF機能やhCAPTCHAがユーザーとして嫌いなのもあり、自分が嫌いなものをユーザーに提供したくないのもあるし、Cloudflareのエラー画面を見て嬉しく思う人もいないと思うので、あのインフラには乗りたくない思いもある。

IPv4のデュアルスタック対応としては、VPNにリバプロをかけるのも検討したが、レガシーに縋っていても仕方がなく、今のところはIPv6に注力する方向にしようとしている。世界のIPv6移行に末端からでも貢献出来たらいいなくらいの気持ちでやっていくのだ。

疎通検証に使える簡易サーバーの作り方

PHP

php -S "[::]:80"でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。

Node.js

http-serverだとhttp-server -p 80 -a "[::]"でいける。serveは未対応っぽい。

疎通確認に使えるcurl例

IPv6はURL形式が特殊なのでアドレス部分を[]で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。

curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"

ドメインを利用する場合に、リクエスト先をAレコードとAAAAレコードで明示的に分ける場合は、以下の書き分けができる。

# IPv4向け
curl -4 -v "http://example.com/"
# IPv6向け
curl -6 -v "http://example.com/"

複数ポートの開き方

option dest_portに値を半角スペース区切りで追加すればよい。LuCIでも同じ書き方で通用する。

例：

option dest_port '80 443 8080'

連番で開ける場合は公式ドキュメントによると、'1024:65535'のような書式にすれば、連番で開けられるようだ。

例：

option dest_port '8000:8999'

関連記事

• OpenWrtを使ってLAN内DNSを設定する
• R86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモ
• 自作ルーターを作っていくのにR86S U1を買ったのでOSのインストールをした