SimpleX 채팅 서버 VPS 직접 구축 및 운영 가이드

SimpleX 채팅 서버를 직접 호스팅한다는 것의 의미

SimpleX 채팅 서버를 직접 호스팅하려면 VPS에서 하나의 데몬인 smp-server를 실행해야 합니다. 이는 SMP(SimpleX Messaging Protocol)를 위한 릴레이 역할을 합니다. 이 서버는 연락처가 메시지를 쓰고 읽는 메시지 큐를 보관합니다. 선택 사항으로 파일 전송을 중계하는 xftp-server이라는 두 번째 데몬을 실행할 수 있습니다. 두 데몬 모두 동일한 프로젝트인 simplexmq에서 제공하며, 각각 단일 바이너리, 설정 파일, 추가 전용(append-only) 로그로 구성됩니다.

이 문서는 앱 사용자가 아닌 운영자를 위해 작성되었습니다. 릴레이는 계정, 연락처 목록, 채팅 기록을 보관하지 않습니다. 대신 큐, 아직 전달되지 않은 암호문, 그리고 서버를 식별하는 인증서만을 보관합니다. 운영자가 책임져야 할 부분은 가동 시간(uptime), 약간의 디스크 공간, 그리고 서버를 통과하는 메타데이터입니다.

아래의 모든 명령어, 경로, 포트, 플래그는 프로젝트 자체 문서인 SMP 서버 호스팅 페이지, XFTP 서버 페이지, 프로토콜 보안 문서를 기반으로 합니다. 숫자가 중요한 경우, 해당 숫자가 출처인 페이지를 옆에 명시했습니다.

사용자 식별자가 없는 네트워크에서도 릴레이가 필요한 이유

SimpleX는 사용자 이름, 전화번호, 계정 ID를 사용하지 않습니다. 연락처는 단방향 큐로 구성됩니다. 이는 한쪽이 쓰고 다른 쪽이 읽는 릴레이상의 주소입니다. 사용자의 두 연락처는 서버가 결합할 수 있는 어떠한 식별자도 공유하지 않습니다.

이러한 큐는 단순한 이유로 어딘가에 존재해야 합니다. 두 대의 휴대폰이 동시에 온라인 상태인 경우는 드뭅니다. 누군가는 메시지를 즉시 수신하여 다른 기기가 요청할 때까지 보관해야 합니다. 이것이 바로 SMP 릴레이의 전체 역할입니다. 또한 이는 두 기기가 서로 직접 연결되지 않음을 의미하므로, 어느 쪽도 상대방의 IP(인터넷 프로토콜) 주소를 알 수 없습니다. 릴레이가 대신 그 노출을 감당합니다.

릴레이의 호스트 이름은 큐 주소의 일부이므로, 사용자가 배포하는 모든 초대 링크에 포함됩니다. 이 문서 끝부분의 위협 모델을 읽을 때 이 점을 유념하십시오.

릴레이가 볼 수 있는 것과 없는 것

프로젝트는 이를 protocol/security.md에서 위협 모델로 명시하고 있습니다. 무언가를 설치하기 전에 이 내용을 읽어보는 것이 좋습니다. 이 가이드를 마친 후에는 해당 릴레이가 귀하의 소유가 되기 때문입니다. 공격자가 완전히 제어하는 릴레이를 포함하여, 어떤 릴레이도 메시지의 내용이나 유형을 알 수 없으며, 개별 메시지를 탐지되지 않게 추가, 복제 또는 변조할 수 없습니다. 또한 능동적 공격으로 종단 간 암호화를 해독할 수도 없습니다.

같은 페이지에 릴레이가 할 수 있는 작업도 나열되어 있습니다. 릴레이는 큐 수신자가 언제 온라인 상태인지 알 수 있습니다. 큐를 통과하는 메시지 수를 셀 수 있습니다. 수신자의 IP 주소를 알 수 있습니다. 큐의 향후 모든 메시지를 삭제하거나 큐 상태에 대해 거짓 정보를 제공할 수 있습니다.

따라서 구분은 명확합니다. 기밀성은 클라이언트의 책임이며, 자체 호스팅은 이에 영향을 주지 않습니다. 메타데이터와 가용성은 릴레이 운영자의 책임이며, 자체 호스팅을 통해 이 두 가지 책임이 귀하에게 넘어오게 됩니다.

시작하기 전에 필요한 것

• Ubuntu 22.04 또는 24.04가 설치된 VPS. 이 프로젝트는 해당 운영 체제용으로 빌드된 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 릴리스는 2026년 4월 29일에 게시된 v6.5.0입니다. 릴리스 페이지에서 원하는 태그를 확인한 후, 아래 모든 과정에서 해당 태그를 사용하십시오.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp은 비밀번호를 설정하지 않으므로 아무도 smp 계정으로 직접 로그인할 수 없습니다. 다른 작업을 수행하기 전에 먼저 두 개의 디렉터리를 직접 생성하십시오. /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 계정으로 실행되므로, 서비스가 침해당하더라도 실행 중인 바이너리를 덮어쓸 수 없습니다.

서버 초기화 및 출력된 두 가지 비밀값 저장

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는 누구나 귀하의 릴레이에서 큐를 생성할 수 있게 합니다. 비공개로 유지하려면 초기화 후 /etc/opt/simplex/smp-server.ini의 [AUTH] 아래에 create_password을 설정하십시오. 명령줄에 직접 --password를 전달하는 방식은 셸 기록이나 실행 중인 프로세스 목록에 노출되므로 권장하지 않습니다.

초기화 과정에서 인증서가 생성되며, 반드시 보관해야 할 두 가지 값이 출력됩니다. 첫 번째는 지문(fingerprint)으로, /etc/opt/simplex/fingerprint에도 기록되는 base64 문자열입니다. 두 번째는 전체 서버 주소이며, 이는 지문과 호스트 이름을 합친 값입니다. 지금 두 값을 모두 복사하십시오.

초기화 시 /etc/opt/simplex/ca.key도 생성되는데, 문서에서는 이 파일을 오프라인 저장소로 옮길 것을 권장합니다. 그 이유는 다음과 같습니다. 클라이언트는 해당 인증 기관의 지문을 고정(pin)하므로, ca.key를 가진 사람은 누구나 클라이언트가 귀하의 것으로 인식하는 새로운 서버 인증서를 발급할 수 있기 때문입니다. 이 파일은 나중에 smp-server cert을 사용하여 서버 인증서를 교체할 때만 다시 필요합니다.

초기화는 일회성 작업으로 간주하십시오. 주소에 포함된 지문은 생성된 인증 기관에서 유래하므로, 인증 기관을 다시 생성하면 주소가 변경되어 기존에 배포한 주소는 사용할 수 없게 됩니다.

비권한 사용자로 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.target

업스트림 유닛에는 AmbientCapabilities=CAP_NET_BIND_SERVICE도 포함되어 있습니다. 이 줄이 존재하는 이유는 프로세스가 smp 권한으로 실행되기 때문입니다. 1024번 미만의 포트는 root가 아닌 프로세스에 닫혀 있으므로, 이 설정 없이는 데몬이 80번이나 443번 포트에 바인딩할 수 없습니다. 해당 포트를 서비스한다면 이 설정을 추가하십시오. LimitNOFILE=65535은 중요한데, 구독 중인 모든 클라이언트가 열린 TCP 연결을 유지하며 기본 제한값은 바쁜 릴레이가 필요로 하는 수준보다 훨씬 낮기 때문입니다. ExecStopPost은 중지될 때마다 스토어 로그를 .bak 파일로 복사하며, 이를 통해 무료 롤백 지점을 하나 확보할 수 있습니다.

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의 서비스별 계정에서 설명한 습관과 동일하며, 이는 네트워크 데몬의 버그가 root 셸 권한 탈취로 이어지는 것을 방지합니다.

개방할 포트와 차단해야 할 포트

문서에는 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 enable

5224 포트는 개방하지 마십시오. 이는 제어용 포트이며, 문서는 nc 127.0.0.1 5224을 사용하여 서버 내부에서 이 포트에 접근하도록 안내합니다. 이 포트는 서버 상태를 출력하고 큐를 삭제하는 기능을 수행하므로, [AUTH] 아래에 관리자 및 사용자 비밀번호를 설정한 상태로 루프백 인터페이스에만 바인딩해야 합니다. 이 도구를 처음 사용한다면 VPS에서 ufw의 기초 문서를 통해 규칙 순서와 서버 접근 차단 방지 방법을 확인하십시오.

주의해야 할 제어 요소가 하나 더 있습니다. 대부분의 호스팅 제공업체는 서버 내부의 ufw와 별개로 제어판에서 네트워크 방화벽을 운영합니다. ufw에서 포트를 개방하더라도 패킷이 서버에 도달하기 전에 네트워크 방화벽에서 차단될 수 있습니다.

클라이언트가 사용할 서버 주소

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

이 문자열이 클라이언트 측 설정의 전부입니다. 앱의 서버 설정에 붙여넣거나, 앱에서 생성된 QR 코드를 스캔하게 하십시오. 문서에 따르면 QR 코드에는 비밀번호가 포함되어 있으므로, 이를 스캔한 사람은 귀하의 서버를 통해 메시지를 수신할 수 있습니다.

문서화된 동작 중 하나는 사용자들을 놀라게 합니다. 앱에 서버를 추가하는 것은 그 시점 이후에 생성하는 연락처에만 영향을 미칩니다. 기존 연락처는 대기열이 생성된 릴레이에 그대로 유지되며, 자동으로 이전되지 않습니다. 이것이 바로 릴레이를 교체한 다음 날 바로 릴레이를 끌 수 없는 이유입니다.

XFTP 파일 릴레이 추가

XFTP(SimpleX file transfer protocol)는 네트워크의 파일 전송을 담당하며, 고유 주소를 가진 별도의 데몬으로 동작합니다. 프로젝트의 XFTP 발표에 따르면, 릴레이는 파일 메타데이터를 전혀 보유하지 않습니다. 릴레이는 256kb, 1mb, 4mb 단위의 개별 청크만 인식하며, 익명 자격 증명을 통해 접근이 승인됩니다. 송신자는 하나의 파일 청크를 여러 릴레이에 분산할 수 있으므로, 서버에는 파일 전체가 아닌 조각들만 저장됩니다.

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 유닛은 User=xftp 및 ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS와 동일한 형태를 가집니다. 초기화 시 xftp:// 주소가 SMP와 동일한 형식으로 출력되며, 고유 지문(fingerprint)은 /etc/opt/simplex-xftp/fingerprint에서 확인할 수 있습니다.

포트 충돌에 대비해야 합니다. XFTP 서버의 기본 포트는 443으로 지정되어 있으며, SMP 설정 역시 443을 사용합니다. 두 프로세스가 동일한 주소의 같은 포트를 점유할 수 없으므로, 하나의 VPS에서는 설정을 조정해야 합니다. 가장 간단한 해결책은 SMP의 [TRANSPORT] 섹션에서 port: 5223를 설정하여 443 포트를 파일 릴레이에 양보하는 것입니다. 이 경우 제한적인 네트워크 환경의 클라이언트가 443 포트로 접속하는 대체 경로를 사용할 수 없게 됩니다. 다른 대안으로는 동일한 VPS에 두 번째 IP 주소를 할당하거나, 별도의 VPS를 사용하는 방법이 있습니다.

할당량(quota)은 정직하게 설정하십시오. -q '20gb'는 가용 디스크 용량에 대한 약속입니다. 파일 릴레이는 디스크와 대역폭을 주로 소모하는 구성 요소입니다. 반면 메시지 릴레이는 디스크와 대역폭을 거의 사용하지 않습니다.

디스크에 저장되는 데이터와 백업으로 복구되는 항목

두 개의 디렉터리가 중요합니다. /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를 복원하고 동일한 도메인 이름을 연결하면, 지문(fingerprint)이 변경되지 않으므로 기존에 배포한 모든 주소가 그대로 작동합니다. 해당 디렉터리를 분실하면 복구할 방법이 없습니다. 새로 설치하면 지문이 바뀌고 주소도 변경되므로, 해당 릴레이를 거치던 모든 연락처와의 연결이 끊어지게 됩니다.

TLS: 서로 다른 역할을 수행하는 두 개의 인증서

SMP 전송은 공인 인증 기관을 사용하지 않습니다. Init은 사설 인증 기관과 서버 인증서를 생성하며, 해당 기관의 지문(fingerprint)은 서버 주소 내부에 포함되어 전달됩니다. 클라이언트는 서버가 제시하는 인증서를 고정된(pinned) 지문과 대조하여 확인하며, 프로젝트에서는 이를 통해 클라이언트-서버 연결을 중간자 공격으로부터 보호한다고 설명합니다. 해당 포트에서 실행할 ACME(automatic certificate management environment) 클라이언트는 없으며, 인증서 교체는 SMP_SERVER_CFG_PATH을 설정한 상태에서 smp-server cert를 실행하는 수동 작업입니다.

선택 사항인 정보 페이지는 다른 인증서를 사용합니다. 해당 페이지의 [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에 히든 서비스를 추가하는 Tor 섹션이 포함되어 있습니다:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

두 개의 mode 라인을 주의 깊게 읽으십시오. Single hop과 non-anonymous는 릴레이 자신의 위치가 숨겨지지 않음을 의미합니다. onion 주소는 속도가 빠르며 클라이언트가 귀하에게 IP 주소를 노출하지 않고 접속할 수 있는 방법을 제공하지만, 서버 자체는 공인 IP를 통해 계속 찾을 수 있는 상태로 유지됩니다. /var/lib/tor/simplex-smp/hostname의 onion 호스트 이름은 서버 주소 끝에 쉼표 뒤에 추가합니다. 서버의 위치까지 숨기고 싶다면 구성이 달라지며, VPS에서 실제 onion 서비스 운영하기에서 해당 내용을 다룹니다. 각 도구가 무엇을 숨기는지에 대한 차이는 Tor와 VPN 비교의 주제이며, 이 경우에도 그대로 적용됩니다.

위협 모델: 셀프 호스팅으로 달라지는 점

셀프 호스팅의 이점은 다음과 같습니다. 메타데이터(어떤 큐가 존재하는지, 언제 읽히는지, 어떤 주소가 연결되는지)가 사용자가 제어하는 머신에 저장되며, 보관 기간 또한 사용자가 직접 설정합니다. 또한, 한 번의 요청으로 대량의 데이터를 가져갈 수 있는 거대한 풀(pool)의 일부가 되지 않습니다.

셀프 호스팅으로 얻을 수 없는 점을 명확히 밝힙니다.

• 암호화 방식은 변하지 않습니다. 메시지는 구축 전에도 종단간 암호화(end to end encrypted)가 적용되었으며, 구축 후에도 동일하게 적용됩니다. 셀프 호스팅은 메타데이터에 관한 결정이지, 암호화에 관한 결정이 아닙니다.
• VPS 제공업체는 귀하의 IP 주소로 향하는 트래픽을 볼 수 있으며 귀하의 결제 정보를 보유합니다. 귀하는 신뢰 대상을 메시징 운영자에서 호스팅 운영자로 옮긴 것일 뿐, 신뢰 자체가 사라진 것은 아닙니다.
• 귀하의 릴레이는 소규모 그룹입니다. 만약 한 가구만을 위한 릴레이라면, 해당 릴레이에 연결하는 것만으로도 그 가구가 식별되며, 릴레이의 호스트네임은 귀하가 보내는 모든 초대 링크에 포함됩니다. 이 측면에서는 사용자가 많은 공개 릴레이가 귀하를 더 잘 숨겨주며, 이것이 실제적인 트레이드오프입니다.
• 가용성에 대한 책임은 이제 귀하에게 있습니다. 디스크가 꽉 차거나 서버가 다운되면 메시지 전달이 중단되며, 귀하의 연락처는 이를 우회할 방법이 없습니다.

이러한 논리는 이 릴레이뿐만 아니라 귀하가 소유한 서버에 올리는 모든 개인 서비스, 즉 직접 구축한 VPS의 WireGuard VPN에도 동일하게 적용됩니다. 귀하는 누가 메타데이터를 볼 것인지 대상을 선택하는 것이지, 메타데이터 자체를 사라지게 만드는 것이 아닙니다.

작동하지 않을 때

서비스가 시작되었다가 즉시 종료됩니다. sudo journalctl -u smp-server -n 50를 읽어 보십시오. 바인딩 실패 시 점유할 수 없었던 포트 번호가 표시됩니다. 그 후 sudo ss -tlnp | grep :443를 실행하여 어떤 프로세스가 해당 포트를 이미 사용 중인지 확인하십시오. 새로 설치한 서버라면 보통 nginx, Caddy 또는 한 시간 전에 설치한 XFTP 서버가 원인입니다.

Init이 설정을 기록할 수 없습니다. /etc/opt/simplex이 존재하기 전에 smp 사용자로 smp-server init을 실행하면 권한 오류가 발생합니다. /etc/opt의 소유자가 root이기 때문입니다. 먼저 올바른 소유자로 디렉터리를 생성한 다음 init을 다시 실행하십시오.

클라이언트가 릴레이에 연결할 수 없습니다. dig +short smp1.example.com을 사용하여 도메인 이름이 올바른 주소로 해석되는지 확인하십시오. 그런 다음 서버 내부가 아닌 노트북에서 nc -vz smp1.example.com 5223 명령으로 포트를 테스트하십시오. 서버에서 ss를 실행했을 때 소켓이 열려 있음에도 외부에서 연결이 실패한다면, 이는 ufw와는 별도로 관리되는 제공업체의 네트워크 방화벽 문제일 가능성이 큽니다.

상대방이 릴레이를 통해 연결할 수 없습니다. 공유한 주소의 지문(fingerprint)이 /etc/opt/simplex/fingerprint의 현재 내용과 일치해야 합니다. [AUTH] 아래에 create_password를 설정했다면, 주소에도 해당 비밀번호가 포함되어야 합니다. 그렇지 않으면 클라이언트는 큐를 생성할 권한을 얻지 못합니다.

앱에 서버를 추가했는데 아무런 변화가 없습니다. 이는 의도된 동작입니다. 새로 추가된 릴레이는 새로 생성되는 연락처에만 사용됩니다. 기존 연락처는 이미 가지고 있는 큐를 그대로 유지합니다.

FAQ

SimpleX 서버를 직접 호스팅하면 메시지가 더 안전해집니까?

아니요, 이는 설계 의도에 따른 것입니다. SimpleX는 기기 간 종단간 암호화(end-to-end encryption)를 수행하므로, 누가 서버를 운영하든 릴레이는 암호화 키를 가질 수 없습니다. 직접 호스팅을 하면 메시지 주변의 메타데이터(어떤 큐가 존재하는지, 언제 읽히는지, 어떤 IP 주소가 연결되는지 등)를 누가 관찰할 수 있는지가 달라질 뿐입니다. 이는 메타데이터에 관한 결정입니다. 더 강력한 암호화를 위해 직접 호스팅을 고려한다면, 이미 암호화는 적용되어 있다는 점을 기억하십시오.

SimpleX 릴레이 운영자는 실제로 무엇을 볼 수 있습니까?

프로젝트의 protocol/security.md에 명시되어 있습니다. 릴레이는 메시지 내용이나 유형을 읽을 수 없으며, 개별 메시지를 탐지되지 않게 수정할 수 없고, 능동적 공격으로 종단간 암호화를 해독할 수 없습니다. 릴레이가 확인할 수 있는 정보는 수신자의 온라인 상태, 큐를 통과하는 메시지 수, 수신자의 IP 주소이며, 특정 큐의 향후 메시지를 삭제하거나 해당 큐의 상태에 대해 거짓 정보를 제공할 수 있습니다. 이러한 권한은 릴레이를 직접 운영할 때 갖게 되는 능력입니다.

도메인 이름과 TLS 인증서가 필요합니까?

사용 가능한 환경을 구성하려면 도메인이 필요하며, 정말로 도메인이 없다면 smp-server init에서 --ip을 허용합니다. 메시징 포트에 대해 공인 기관의 인증서가 필요한 것은 아닙니다. 초기화 과정에서 자체 인증 기관(CA)을 생성하며, 클라이언트는 smp:// 주소에 나타나는 핑거프린트를 고정(pinning)합니다. 공인 기관의 인증서는 선택 사항인 웹 정보 페이지에만 필요하며, 이는 smp-server.ini의 [WEB] 섹션에서 cert 및 key로 설정합니다.

/etc/opt/simplex를 분실하면 어떻게 됩니까?

배포한 모든 주소가 작동을 멈춥니다. 해당 디렉터리에는 서버 주소에 포함된 핑거프린트의 인증 기관이 들어 있으므로, 서버를 재구축하면 다른 핑거프린트가 생성되어 결과적으로 다른 서버가 됩니다. 해당 릴레이에 큐를 둔 연락처는 클라이언트 측에서 복구할 수 없습니다. 해당 디렉터리를 암호화하여 외부 저장소에 백업하고, ca.key는 문서의 지침에 따라 오프라인에 보관하십시오. 이를 탈취한 사람은 귀하의 릴레이를 사칭할 수 있습니다.

SMP 릴레이와 XFTP 파일 릴레이를 같은 VPS에서 실행할 수 있습니까?

네, 단 하나의 충돌만 해결하면 됩니다. XFTP 서버의 기본 포트는 443이며 기본 SMP 설정도 port: 5223,443을 사용하므로 두 서비스가 같은 소켓을 요구합니다. 둘 중 하나에 443 포트를 할당하십시오. SMP 서버에 port: 5223을 설정하거나, 파일 릴레이를 두 번째 IP 주소 또는 다른 VPS로 옮기십시오. 또한 파일 릴레이가 디스크와 대역폭을 소모하는 주된 구성 요소이므로, 실제 디스크 용량에 맞춰 저장소 할당량을 설정하십시오.