著者 VPSでSimpleX SMPリレーを自分で運用する方法
VPSでSimpleX SMPリレーを自分で構築する手順です。固定したインストール、クライアントに必要なfingerprint、ポート、非特権ユーザー、バックアップ、TLS、脅威モデルを解説します。
自分で運用する SimpleX チャットサーバーの役割
SimpleX チャットサーバーを自分で運用するには、VPS 上で 1 つのデーモンを実行します。smp-server は SMP（simplex messaging protocol）のリレーです。連絡先がメッセージを書き込み、読み取るメッセージキューを保持します。xftp-server という別のオプションのデーモンは、ファイル転送を中継します。どちらも同じプロジェクト simplexmq に含まれ、それぞれ単一のバイナリ、設定ファイル、追記専用ログで構成されます。
この説明はアプリのユーザーではなく、運用担当者を対象としています。リレーはアカウント、連絡先リスト、チャット履歴を保持しません。保持するのはキュー、一部の未配信暗号文、そして自身を識別する証明書です。運用上必要になるのは、稼働時間、少量のディスク容量、そしてサーバーを通過するメタデータです。
以下のコマンド、パス、ポート、フラグはすべて、プロジェクト公式ドキュメントの SMP server hosting page、XFTP server page、protocol security document に基づいています。数値が重要な場合は、その数値の出典ページを直後に示します。
ユーザー識別子のないネットワークにもリレーが必要な理由
SimpleX には、ユーザー名、電話番号、アカウント ID がありません。連絡先は一方向キューです。一方が書き込み、他方が読み取る、あるリレー上のアドレスです。2 つの連絡先には、サーバーが関連付けられる共通の識別子がありません。
それでも、これらのキューをどこかに置く必要があります。理由は単純です。2 台のスマートフォンが同じ秒にオンラインになることは、ほとんどありません。どこかでメッセージを受け取り、相手のデバイスが要求するまで保持する必要があります。それが SMP relay の役割です。これにより、2 台のデバイスは互いに直接接続しないため、どちらも相手の IP アドレスを知りません。代わりに、リレーがその露出を引き受けます。
リレーのホスト名はキューのアドレスの一部です。そのため、そのリレーから配布するすべての招待リンクに含まれます。後半の脅威モデルを読む際は、この点に注意してください。
リレーに見える情報と見えない情報
このプロジェクトでは、protocol/security.mdで脅威モデルを定義しています。何かをインストールする前に読む価値があります。このガイドの手順を終えると、そのリレーはあなたが管理するものになるためです。攻撃者が完全に制御するリレーであっても、メッセージの内容や種類を知ることはできません。個々のメッセージを検知されずに追加、複製、改ざんすることもできません。能動的な攻撃によってエンドツーエンド暗号化を破ることもできません。
同じページには、リレーにできることも記載されています。キューの受信者がオンラインになった時刻を知ることができます。キューを通過したメッセージの数を数えることができます。受信者の IP アドレスを知ることができます。キューに今後届くすべてのメッセージを破棄したり、そのキューの状態について偽ったりすることもできます。
この区分は明確です。機密性はクライアントの役割であり、セルフホスティングによって変わることはありません。メタデータと可用性はリレー運用者の役割であり、セルフホスティングによってその両方をあなたが担うことになります。
開始前に必要なもの
- Ubuntu 22.04 または 24.04 を実行している VPS。プロジェクトは、この2つの環境向けに x86-64 と aarch64 のリリースバイナリを公開しています。
- VPS を指す A レコードを設定したドメイン名。IPv6 を使用する場合は、AAAA レコードも必要です。ドキュメントでは
smp1.example.comを例に使用します。 - root または
sudoアクセス。ファイアウォールを操作する間は、別の SSH セッションも開いておきます。 - サーバー外部にバックアップを保存する場所。設定ディレクトリがサーバーの識別情報になるためです。
ARM インスタンスでは、x86-64 ではなく aarch64 アセットを使用します。このガイドの他の手順は変わりません。ARM と x86 の VPS プランの選択は、価格とコアあたりの速度に関するものであり、このソフトウェアが動作するかどうかには関係しません。
固定したリリースをインストールし、「latest」は使用しません
このプロジェクトには、現在のリリースを取得して simplex-servers-update コマンドを登録するインストールスクリプトがあります。動作します。ただし、バージョンは固定してください。動作中にバイナリが変わるリレーは、障害発生時に原因を切り分けられません。
2026 年 8 月時点での simplexmq の現行リリースは v6.5.0 で、2026 年 4 月 29 日に公開されています。リリースページ で使用するタグを確認し、以下ではそのタグを一貫して使用してください。
sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplexuseradd -m smp ではパスワードを設定しないため、smp として直接ログインすることはできません。他の操作を行う前に、2 つのディレクトリを自分で作成してください。/etc/opt は root 所有でモード 755 となるため、smp ユーザーが独自の設定ディレクトリを書き込める場所がなくなるためです。
VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-serverそのハッシュを、同じタグのリリースノートに掲載されている SHA2-256 チェックサムと照合してください。プロジェクトは、SimpleX Chat の鍵 FB44AF81A45BDE327319797C85107E357D4A17FC を使ってリリースチェックサムにも署名しています。この鍵はサーバーページに記載されています。ハッシュを確認したページを無条件に信頼するのではなく、署名を検証できます。
sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server意図的に root 所有でインストールしてください。サービスは smp として実行されるため、サービスが侵害されても、起動元のバイナリを書き換えることはできません。
サーバーを初期化し、表示される2つの秘密情報を保存する
sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"--store-log（-l）はキューの追記専用ログを/var/opt/simplex/smp-server-store.logに書き込むため、リレーは再起動後も状態を維持します。これがないと再起動時にすべてのキューが破棄され、あなたを経由するすべての連絡が機能しなくなります。--daily-stats（-s）はカウンターをCSV形式で/var/opt/simplex/smp-server-stats.daily.logに書き込みます。--fqdnは生成する証明書にドメインを含めます。ドメインがない場合は--ipを使用します。--no-passwordを指定すると、誰でもリレーにキューを作成できます。非公開にするには、ここで--passwordを渡すのではなく、初期化後に/etc/opt/simplex/smp-server.iniの[AUTH]の下へcreate_passwordを設定します。コマンドラインは実行中、shell の履歴とプロセス一覧に表示されるためです。
Init は証明書を生成し、保存すべき2つの値を表示します。1つ目はfingerprintで、base64文字列として/etc/opt/simplex/fingerprintにも書き込まれます。2つ目は完全なサーバーアドレスで、fingerprintとホスト名を組み合わせたものです。今すぐ両方をコピーしてください。
Init は/etc/opt/simplex/ca.keyも作成します。ドキュメントでは、このファイルをオフラインストレージへ移動するよう指示しています。その理由は明確です。クライアントはこの認証局のfingerprintをピン留めするため、ca.keyを持つ人は、クライアントが自分のサーバー証明書として受け入れる新しいサーバー証明書を発行できます。後でsmp-server certを使用してサーバー証明書をローテーションするときだけ、このファイルを戻せば十分です。
Initは1回だけ実行する手順として扱ってください。アドレスに含まれるfingerprintは、Initが生成した認証局に由来します。そのため認証局を再生成すると別のアドレスになり、配布済みのアドレスは使用できなくなります。
systemd で非特権ユーザーとして実行する
ドキュメントの記載どおり、/etc/systemd/system/smp-server.service を記述します。
[Unit]
Description=SMP server systemd service
[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity
[Install]
WantedBy=multi-user.targetupstream の unit には AmbientCapabilities=CAP_NET_BIND_SERVICE も含まれています。この行が必要なのは、プロセスが smp として実行され、1024 未満のポートは non-root プロセスから閉じられているためです。この行がないと、daemon は 80 または 443 に bind できません。これらのポートを提供する場合は追加してください。LimitNOFILE=65535 も重要です。購読中の各クライアントが開いた TCP 接続を保持するため、デフォルトの上限では負荷の高い relay に不足します。ExecStopPost は停止するたびに store log を .bak ファイルへコピーします。これにより、ロールバック用の復元ポイントを 1 つ確保できます。
sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server正常に起動すると、server address がログに出力されます。続いて、ソケットが実際に開いていることを確認します。
sudo ss -tlnp | grep -E ':(443|5223)'両方の行に smp-server と表示されるはずです。独自のアカウントで daemon を実行し、sudo 権限を与えない方法は、VPS 上のサービス単位のアカウントで説明した運用と同じです。これにより、1 つの network daemon のバグが root shell につながることを防げます。
開放するポートと、閉じておくポート
ドキュメントに記載されているポートは3つです。5223/tcp、443/tcp、80/tcpです。5223はSMPトランスポートです。提供時の設定では port: 5223,443 が [TRANSPORT] の下に設定されているため、同じプロトコルが443でも応答します。多くの制限されたネットワークでは、外向き通信で443だけが許可され、他のポートは許可されないため、この設定が重要になります。80は、オプションの情報ページとHTTPSへのリダイレクトを使用する場合にだけ必要です。
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable5224は開放しないでください。これは制御ポートです。ドキュメントでは、ボックス自身から nc 127.0.0.1 5224 を使用してアクセスします。このポートではサーバーの状態を表示したり、キューを削除したりできるため、[AUTH] の下で admin パスワードと user パスワードを設定したうえで、loopback だけで待ち受ける構成にします。このツールを初めて使う場合は、VPSでのufwの基本で、ルールの順序とロックアウトを避ける方法を確認できます。
もう1つ、見落としやすい制御があります。多くのプロバイダーでは、サーバー上の ufw とは別に、管理パネルでネットワークファイアウォールを提供しています。ufwでポートを開放していても、サーバーに到達する前にそのファイアウォールで破棄される場合があります。
クライアントが必要とするサーバーアドレス
smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]この文字列が、クライアント側の設定全体です。アプリのサーバー設定に貼り付けるか、アプリに表示された QR コードを読み取ってもらいます。ドキュメントには、QR コードにパスワードも含まれると記載されています。そのため、QR コードを読み取った人は、あなたのサーバー経由でメッセージを受信できます。
ドキュメントに記載された動作の中で、特に分かりにくいものがあります。アプリにサーバーを追加しても、その時点以降に作成する連絡先にしか影響しません。既存の連絡先は、そのキューが作成された relay 上に残り、移行されません。そのため、relay を置き換えた翌日に、以前の relay を停止することもできません。
XFTP ファイルリレーの追加
XFTP（SimpleX file transfer protocol）はネットワークのファイル転送部分です。独自のアドレスを持つ別のデーモンとして動作します。プロジェクトの XFTP announcement によると、リレーはファイルメタデータを一切保持しません。リレーが認識するのは、256kb、1mb、または 4mb 単位の個々のチャンクだけです。アクセスは匿名資格情報によって承認されます。送信者は、1 つのファイルのチャンクを複数のリレーに分散できます。そのため、サーバーに保存されるのはファイルそのものではなく、その一部です。
sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"設定は /etc/opt/simplex-xftp/ に、状態は /var/opt/simplex-xftp/ に保存されます。ファイルチャンクの保存先は -p で指定します。systemd unit は User=xftp と ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS を使う同じ形式です。Init は SMP と同じ形式の xftp:// アドレスを表示し、専用の fingerprint は /etc/opt/simplex-xftp/fingerprint に表示します。
事前にポートの競合を考慮する必要があります。XFTP サーバーの文書化されたポートは 443 で、SMP の設定にも 443 が記載されています。同じアドレス上で 2 つのプロセスが同じポートを bind することはできません。そのため、1 台の VPS ではどちらかを変更する必要があります。最も簡単な方法は、SMP の [TRANSPORT] セクションで port: 5223 を設定し、443 をファイルリレー用に残すことです。ただし、制限の厳しいネットワーク上のクライアント向けの 443 fallback は利用できなくなります。別の方法として、同じ VPS に 2 つ目の IP アドレスを割り当てるか、2 台目の VPS を使用します。
quota は実際に確保できる容量に合わせて設定します。-q '20gb' は、使用できるディスク容量についての約束です。ディスク容量と帯域幅を消費するのは主にファイルリレーです。メッセージリレーが消費する量は、どちらもごくわずかです。
ディスク上に保存されるものと、バックアップから復元されるもの
重要なディレクトリは 2 つあります。/etc/opt/simplex/ は識別情報です。smp-server.ini、サーバー証明書と鍵、ca.key、fingerprint が含まれます。/var/opt/simplex/ は状態情報です。smp-server-store.log にキューが保存され、restore_messages: on の場合は未配信メッセージも保存されます。日次統計ファイルもここにあります。
sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-serverこのアーカイブの意味を明確にしておきます。これはメッセージアーカイブではありません。キュー内の項目は、relay が保持していない鍵向けの暗号文です。また、同梱されている [STORE_LOG] の設定では、メッセージは 21 日後に期限切れになります。これは ca.key を含むサーバーの識別情報のコピーです。そのため、このファイルを取得した第三者は、連絡先に対してあなたの relay になりすますことができます。暗号化し、サーバー本体の外部に保管してください。
バックアップの価値は復元にあります。新しい VPS に /etc/opt/simplex を戻し、同じ DNS 名を向ければ、フィンガープリントは変わりません。そのため、配布済みのすべてのアドレスを引き続き使用できます。このディレクトリを失うと復旧できません。新規インストールでは新しいフィンガープリントが生成されます。すると新しいアドレスになり、relay 経由でルーティングしていたすべての連絡先が失われます。
TLS: 異なる役割を担う 2 つの証明書
SMP トランスポートでは、公開認証局を使用しません。Init によってプライベート認証局とサーバー証明書が生成され、その認証局のフィンガープリントがサーバーアドレスに含まれます。クライアントは、サーバーが提示した内容を固定済みのフィンガープリントと照合します。これにより、プロジェクトが説明する、マシン・イン・ザ・ミドル攻撃からクライアントとサーバー間の接続を保護する仕組みが実現します。そのポートで ACME（自動証明書管理環境）クライアントを実行する必要はありません。ローテーションは、smp-server cert を実行し、SMP_SERVER_CFG_PATH を設定して手動で行います。
オプションの情報ページでは、もう一方の証明書を使用します。その [WEB] セクションでは、static_path、https: 443、cert: /etc/opt/simplex/web.crt、key: /etc/opt/simplex/web.key を指定します。ブラウザーはプライベート認証局を認識しないため、公開認証済み証明書を使用するのはここです。ドキュメントの Docker クイックスタートで Caddy をサーバーの前段に置いているのは、まさにこのためです。Caddy が証明書を自動的に発行します。
Tor 経由でリレーに接続する
ドキュメントには、Tor Project のリポジトリから Tor をインストールし、/etc/tor/torrc に hidden service を追加する Tor のセクションがあります。
SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:4432 つのモード行を注意して確認してください。Single hop と non-anonymous では、リレー自体の場所は隠れません。onion address は高速で、クライアントの IP アドレスをサーバー側に公開せずに接続できる経路を提供します。ただし、サーバー自体は公開 IP から特定できます。/var/lib/tor/simplex-smp/hostname の onion hostname は、コンマの後に server address の末尾へ追加します。サーバーの場所も隠したい場合は、別の構成が必要です。VPS 上で実際の onion service を実行するでは、そのトレードオフを説明しています。各ツールが隠す対象の違いについては、Tor と VPN の比較で説明しており、ここにも直接当てはまります。
脅威モデル: self-hosting で変わること
得られるもの。メタデータ（存在するキュー、読み取られた時刻、接続するアドレス）は、自分が管理するマシン上に保存され、その保持期間も自分で設定できます。また、一度に照会される可能性がある大規模な利用者群の一部にもなりません。
得られないものを、明確に示します。
- 暗号化は変わりません。これを構築する前からメッセージはエンドツーエンドで暗号化されており、構築後もエンドツーエンドで暗号化されています。self-hosting はメタデータに関する判断であり、暗号化に関する判断ではありません。
- VPS provider は自分の IP アドレスへのトラフィックを確認でき、請求情報を保持します。信頼する相手をメッセージング事業者からホスティング事業者へ移しただけです。信頼をなくしたわけではありません。
- 自分の relay は小さな集団です。1 世帯だけが利用する場合、そこへ接続すること自体がその世帯を特定し、そこから送信するすべての招待リンクにそのホスト名が含まれます。多数が利用する公開 relay なら、この点では身元を隠しやすくなります。ここが実際のトレードオフです。プライベートな検索サーバーも同じ構造です。そのため、自分の VPS 上で SearXNG が実際に隠すもの は、同じインスタンスを何人で共有しているかに左右されます。
- 可用性も自分の責任になります。ディスクが満杯になったりマシンが停止したりすると、メッセージの配信が止まり、連絡先は別の経路で回避できません。
この考え方は、自分が所有するマシンに配置するあらゆるプライベートサービスに当てはまります。この relay であっても、自分の VPS 上の WireGuard VPN であっても同じです。どの事業者にメタデータを見せるかを選んでいるのです。メタデータを消しているわけではありません。
動作しない場合
サービスが起動直後に停止する。 sudo journalctl -u smp-server -n 50 を確認します。bind に失敗すると、確保できなかったポートが表示されます。次に sudo ss -tlnp | grep :443 を実行して、そのポートをすでに使用しているプロセスを確認します。新しいサーバーでは、通常 nginx、Caddy、または 1 時間前にインストールした XFTP server が該当します。
Init が設定を書き込めない。 /etc/opt/simplex が存在する前に、smp ユーザーとして smp-server init を実行すると、権限エラーになります。/etc/opt は root が所有しているためです。最初に適切な所有者を設定してディレクトリを作成し、その後で init を再実行します。
クライアントが relay に接続できない。 dig +short smp1.example.com で名前が正しいアドレスに解決されることを確認します。次に、サーバーではなくノート PC からポートをテストします。nc -vz smp1.example.com 5223 を実行します。ss でサーバー上の socket が開いているのに、外部からの接続に失敗する場合は、プロバイダー側のネットワークファイアウォールが原因です。これは ufw とは別の制御です。
連絡先が relay 経由で接続できない。 共有したアドレス内の fingerprint が、/etc/opt/simplex/fingerprint の現在の内容と一致している必要があります。[AUTH] の下で create_password を設定した場合、アドレスにもその password を含める必要があります。含まれていない場合、クライアントは queue を作成できません。
アプリで server を追加した後も何も移動しない。 これは想定された動作です。新しく追加した relay を使用するのは、新しい連絡先だけです。既存の連絡先は、すでに保持している queue を使い続けます。
FAQ
SimpleX サーバーをセルフホストすると、メッセージの安全性は高まりますか？
いいえ。これは設計どおりの動作です。SimpleX はデバイス間でメッセージをエンドツーエンド暗号化するため、誰がリレーを運用していても、リレーは暗号鍵を持ちません。セルフホストによって変わるのは、メッセージに関連するメタデータを誰が監視するかです。存在するキュー、キューが読み取られた時刻、接続する IP アドレスなどが対象になります。これはメタデータに関する選択です。セルフホストの理由がより強い暗号化であれば、その暗号化はすでに適用されています。
SimpleX リレーの運用者には、実際に何が見えますか？
プロジェクトの protocol/security.md に記載されています。リレーはメッセージの内容や種類を読み取れません。個々のメッセージを検知されずに変更することも、アクティブ攻撃によってエンドツーエンド暗号化を破ることもできません。一方で、キューの宛先がオンラインになった時刻、キューを通過したメッセージ数、宛先の IP アドレス、キュー内の今後のメッセージの破棄、キューの状態に関する虚偽の通知は確認できます。リレーを自分で運用すると、これらが可能になります。
ドメイン名と TLS 証明書は必要ですか？
利用可能な構成にはドメインが必要です。ただし、ドメインがまったくない場合は smp-server init が --ip を受け付けます。メッセージングポートに公開認証局の証明書は必要ありません。init が独自の認証局を生成し、クライアントは smp:// アドレスに表示されるフィンガープリントをピン留めします。公開で信頼された証明書が必要なのは、オプションの Web 情報ページだけです。このページは smp-server.ini の [WEB] セクションで cert と key として設定します。
/etc/opt/simplex を失うとどうなりますか？
配布したすべてのアドレスが機能しなくなります。そのディレクトリには、サーバーアドレスにフィンガープリントが埋め込まれている認証局が保存されています。そのため、再構築するとフィンガープリントが変わり、別のサーバーになります。そのリレー上にキューがある連絡先は、クライアント側から復旧できません。ディレクトリは暗号化した状態でバックアップし、サーバー外に保管してください。また、ドキュメントの指示に従って ca.key をオフラインで保管してください。これを持つ人は、あなたのリレーになりすませます。
SMP リレーと XFTP ファイルリレーを同じ VPS で実行できますか？
はい。ただし、解決すべき競合が1つあります。XFTP サーバーのドキュメント上のポートは 443 で、SMP のデフォルト設定には port: 5223,443 が記載されています。そのため、両方が同じソケットを使用しようとします。443 はどちらか一方に割り当ててください。SMP サーバーに port: 5223 を設定するか、ファイルリレーを2つ目の IP アドレスまたは2つ目の VPS に移動します。また、実際に使用できるディスク容量に合わせてストレージクォータを設定してください。ディスク容量と帯域幅を消費するのはファイルリレーだからです。