著者 Matt Connor
SimpleX SMPサーバーをVPSで自分でホストする方法
VPSでSimpleX SMPリレーを運用する手順です。固定したインストール版、クライアントに必要なfingerprint、ポート、非特権ユーザー、バックアップ、TLS、脅威モデルを確認できます。
自分でホストする SimpleX チャットサーバーの役割
SimpleX チャットサーバーを自分でホストするには、VPS 上で 1 つのデーモンを実行します。smp-server は SMP（simplex messaging protocol）のリレーです。連絡先がメッセージを書き込み、読み出すメッセージキューを保持します。オプションの 2 つ目のデーモン xftp-server は、ファイル転送を中継します。どちらも同じプロジェクト simplexmq に含まれており、それぞれ単一のバイナリ、設定ファイル、追記専用ログで構成されます。
この説明はアプリのユーザーではなく、運用担当者を対象としています。リレーはアカウント、連絡先リスト、チャット履歴を保持しません。保持するのはキュー、未配信の暗号文の一部、そして自身を識別する証明書です。運用で必要になるのは、稼働時間の確保、少量のディスク容量、そしてサーバーを通過するメタデータの管理です。
以下のコマンド、パス、ポート、フラグはすべて、プロジェクトの公式ドキュメントに基づいています。参照したのは SMP server hosting page、XFTP server page、protocol security document です。数値が重要な場合は、その直後に出典のページを示します。
ユーザー識別子のないネットワークにもリレーが必要な理由
SimpleX には、ユーザー名、電話番号、アカウント ID がありません。連絡先は一方向キューです。これは、いずれかのリレー上にあるアドレスで、一方が書き込み、もう一方が読み取ります。2 つの連絡先には、サーバーが突き合わせられる共通の識別子がありません。
それでも、これらのキューはどこかに置く必要があります。理由は単純です。2 台のスマートフォンが同じ時刻にオンラインになることは、ほとんどありません。どこかでメッセージを受け取り、もう一方のデバイスが要求するまで保持する必要があります。これが SMP リレーの役割です。また、2 台のデバイスは互いに直接接続しないため、どちらも相手の IP（internet protocol）アドレスを知りません。リレーがその情報の露出を引き受けます。
リレーのホスト名はキューのアドレスの一部です。そのため、そのリレーから配布するすべての招待リンクに含まれます。終盤の脅威モデルを読むときは、この点に注意してください。
リレーが確認できる情報と確認できない情報
プロジェクトは 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つの Secret を保存する
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に書き込むため、relay は再起動後も状態を保持します。これがないと、再起動時にすべてのキューが破棄され、あなた経由でルーティングされたすべての連絡が機能しなくなります。--daily-stats（-s）はカウンターを CSV 形式で/var/opt/simplex/smp-server-stats.daily.logに書き込みます。--fqdnは生成される証明書にドメインを含めます。ドメインがない場合は--ipを使用します。--no-passwordを指定すると、誰でも relay にキューを作成できます。非公開にする場合は、初期化後に/etc/opt/simplex/smp-server.iniの[AUTH]の下へcreate_passwordを設定してください。ここで--passwordを渡さないでください。コマンドラインは、実行中に shell の履歴とプロセス一覧から見えるためです。
初期化によって証明書が生成され、保存すべき2つの値が出力されます。1つ目は fingerprint で、/etc/opt/simplex/fingerprint にも書き込まれる base64 文字列です。2つ目は完全なサーバーアドレスで、fingerprint にホスト名を加えたものです。ここで両方をコピーしてください。
初期化では /etc/opt/simplex/ca.key も作成されます。ドキュメントでは、このファイルをオフラインストレージへ移動するよう指示しています。その理由は明確です。クライアントはその認証局の fingerprint を固定するため、ca.key を持つ人は、クライアントが自分のサーバーのものとして受け入れる新しいサーバー証明書を発行できます。これを再び使用するのは、後で smp-server cert によりサーバー証明書をローテーションするときだけです。
初期化は1回だけ実行する手順として扱ってください。アドレスに含まれる fingerprint は、初期化で生成された認証局に基づいています。そのため、認証局を再生成すると別のアドレスになり、配布済みのアドレスは使用できなくなります。
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 未満のポートは root 以外のプロセスから閉じられているためです。この行がないと、デーモンは 80 または 443 に bind できません。これらのポートを提供する場合は追加してください。LimitNOFILE=65535 も重要です。購読中の各クライアントが開いた TCP 接続を保持するため、デフォルトの上限では負荷の高いリレーに対応できません。ExecStopPost は停止するたびにストアのログを .bak ファイルへコピーします。これにより、ロールバック用のポイントを1つ確保できます。
sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server正常に起動すると、サーバーのアドレスがログに出力されます。続いて、ソケットが実際に開いていることを確認します。
sudo ss -tlnp | grep -E ':(443|5223)'両方の行に smp-server が示されていることを確認します。専用アカウントでデーモンを実行し、sudo 権限を与えない方法は、VPS 上のサービス単位のアカウントで説明した運用と同じです。これにより、1つのネットワークデーモンのバグが root shell につながることを防げます。
開放するポートと、閉じたままにするポート
ドキュメントには、5223/tcp、443/tcp、80/tcp の3つが記載されています。5223 は SMP トランスポート用のポートです。提供時の設定では、[TRANSPORT] の下で port: 5223,443 が設定されているため、同じプロトコルが 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] の下で管理者パスワードとユーザーパスワードを設定し、loopback 上だけで利用できるようにします。このツールを初めて使う場合は、VPS での ufw の基本で、ルールの順序と自分自身を締め出さない方法を確認できます。
もう1つ、見落としやすい制御があります。多くのプロバイダーでは、サーバー上の ufw とは別に、管理パネルでネットワークファイアウォールを運用しています。ufw でポートを開放していても、サーバーに到達する前に破棄されることがあります。
クライアントが必要とするサーバーアドレス
smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]この文字列が、クライアント側の設定全体です。アプリのサーバー設定に貼り付けるか、アプリに表示される QR コードを読み取ってもらいます。ドキュメントには、QR コードにパスワードも含まれると記載されています。そのため、読み取った人はあなたのサーバー経由でもメッセージを受信できます。
ドキュメントに記載された動作の中には、誰もが驚くものがあります。アプリにサーバーを追加しても、その時点以降に作成する連絡先にしか影響しません。既存の連絡先は、キューの作成先となったリレーに残り、移行されません。そのため、リレーを置き換えた翌日に、古いリレーを停止することもできません。
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:// アドレスを出力し、固有のフィンガープリントを /etc/opt/simplex-xftp/fingerprint に示します。
事前に解決すべきポート競合があります。XFTP サーバーの公開ポートは 443 で、SMP の設定にも 443 が記載されています。同じアドレスで 2 つのプロセスが同じポートを bind することはできないため、1 台の VPS ではどちらかを変更する必要があります。最も簡単な方法は、SMP の [TRANSPORT] セクションで port: 5223 を設定し、443 をファイルリレー用に残すことです。ただし、制限の厳しいネットワークにいるクライアント向けの 443 フォールバックは利用できなくなります。別の方法として、同じ VPS に 2 つ目の IP アドレスを割り当てるか、2 台目の VPS を使用します。
クォータは実際に確保できる容量に基づいて設定してください。-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このアーカイブの内容を正しく理解してください。これはメッセージアーカイブではありません。キュー内の項目は、リレーが保持していない鍵向けの暗号文です。また、同梱される[STORE_LOG]設定では、メッセージは21日後に期限切れになります。これはca.keyを含むサーバーのアイデンティティのコピーです。そのため、このファイルを取得した人物は、連絡先に対してあなたのリレーになりすますことができます。暗号化し、サーバー外に保管してください。
復元できることが、このバックアップの利点です。新しい VPS に/etc/opt/simplexを戻し、同じ DNS 名を割り当てれば、フィンガープリントは変わりません。そのため、配布済みのすべてのアドレスを引き続き使用できます。このディレクトリを失うと、復旧できません。新規インストールではフィンガープリントが変わり、新しいアドレスになります。その結果、リレー経由で接続していたすべての連絡先を失います。
TLS: 異なる役割を担う2つの証明書
SMP transport では、公開認証局を使用しません。Init はプライベート認証局とサーバー証明書を生成し、その認証局のフィンガープリントをサーバーアドレスに含めます。クライアントは、サーバーが提示した内容を固定されたフィンガープリントと照合します。これにより、プロジェクトが説明する machine-in-the-middle 攻撃からクライアントとサーバー間の接続を保護します。このポートで実行する ACME (automatic certificate management environment) クライアントはありません。証明書のローテーションは、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 を配置し、証明書を自動的に発行します。
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 つの mode 行を注意して確認してください。Single hop と non-anonymous では、リレー自体の場所は隠れません。onion address は高速で、クライアントは IP アドレスをサーバー側に一切明かさずに接続できます。ただし、サーバー自体は公開 IP から特定できます。/var/lib/tor/simplex-smp/hostname の onion hostname は、コンマの後ろに server address の末尾として追加します。サーバーの場所も隠したい場合は、別の構成が必要です。VPS 上で実際の onion service を実行する では、そのトレードオフを説明しています。各ツールが隠す対象の違いについては Tor と VPN の比較 で扱っており、ここにもそのまま当てはまります。
脅威モデル: セルフホスティングで変わること
得られるもの。メタデータ（存在するキュー、読み取られる時刻、接続するアドレス）は、自分が管理するマシン上に置かれ、保持期間も自分で設定します。また、一度に要求される可能性がある大規模な利用者群の一部にもなりません。
得られないものを、明確に説明します。
- 暗号化は変わりません。これを構築する前からメッセージはエンドツーエンドで暗号化されており、構築後も暗号化されています。セルフホスティングはメタデータに関する判断であり、暗号方式に関する判断ではありません。
- VPS プロバイダーには、自分の IP アドレスとの間のトラフィックが見え、請求情報も保持されます。信頼する相手をメッセージング事業者からホスティング事業者へ移しただけです。信頼をなくしたわけではありません。
- 自分のリレーは小さな集団です。1 世帯だけにサービスを提供する場合、そのリレーへの接続からその世帯が特定されます。また、そこから送信するすべての招待リンクに、そのホスト名が含まれます。利用者の多い公開リレーを使えば、この点ではより匿名性を高められます。これが実際のトレードオフです。
- 可用性は自分で確保する必要があります。ディスクが満杯になったりマシンが停止したりすると、メッセージの配信も停止します。連絡相手が自分を迂回して配信する方法もありません。
この考え方は、所有するマシンに配置するすべてのプライベートサービスに当てはまります。このリレーでも、自分の 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 で名前が正しいアドレスに解決されることを確認します。次に、サーバーではなくラップトップからポートをテストします。nc -vz smp1.example.com 5223。外部からの接続は失敗する一方、ss でサーバー上のソケットが開いている場合は、プロバイダーのネットワークファイアウォールが原因です。これは ufw とは別の制御です。
連絡先が relay 経由で接続できない。 共有したアドレスに含まれるフィンガープリントが、/etc/opt/simplex/fingerprint の現在の内容と一致している必要があります。[AUTH] で create_password を設定した場合、アドレスにもそのパスワードを含める必要があります。含まれていないと、クライアントはキューを作成できません。
アプリにサーバーを追加した後も何も移動しない。 これは意図した動作です。新しく追加した relay を使用するのは、新しい連絡先だけです。既存の連絡先は、すでに作成済みのキューを引き続き使用します。
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 に移動します。また、実際に確保できるディスク容量に合わせてストレージクォータを設定してください。ディスクと帯域幅を消費するのはファイルリレーだからです。