Om Matrix Synapse i CasaOS visar ”container is unhealthy” bör du börja med containerloggarna och den genererade homeserver.yaml i stället för att installera om på måfå. Synapse har en officiell Docker-avbild, men en produktionsserver behöver också beständig konfiguration/data, ett korrekt servernamn, PostgreSQL samt planering för HTTPS och federering.
SQLite kan användas för testning, men aktuell Synapse-dokumentation rekommenderar PostgreSQL för nästan alla riktiga installationer. En container kan starta men ändå förbli unhealthy när konfigurationen, databasen, behörigheterna eller migreringen vid uppstart misslyckas.
Använd den officiella Synapse-avbilden
Den aktuella installationsguiden för Synapse anger ghcr.io/element-hq/synapse som en officiell containeravbild.
Generera den första konfigurationen
Skapa en beständig katalog och generera konfigurationen en gång före normal uppstart:
mkdir -p /DATA/AppData/synapse
docker run --rm -it -v /DATA/AppData/synapse:/data -e SYNAPSE_SERVER_NAME=matrix.example.com -e SYNAPSE_REPORT_STATS=no ghcr.io/element-hq/synapse:latest generateErsätt exempeldomänen med det Matrix-servernamn du tänker behålla.
Kontrollera varför containern är unhealthy
docker ps -a | grep synapse
docker inspect synapse --format '{{json .State.Health}}'
docker logs --tail 200 synapseLeta efter YAML-fel, saknade filer, behörighetsfel, databasanslutningsfel eller migreringar som aldrig slutförs.
Använd PostgreSQL i produktion
Den aktuella PostgreSQL-guiden för Synapse beskriver den databasinstallation som stöds. Se till att PostgreSQL-data lagras beständigt och säkerhetskopiera den tillsammans med Synapse-tillståndet.
Ändra inte server_name senare utan planering
Dina Matrix-ID:n härleds från servernamnet, till exempel @user:example.com. Välj den långsiktiga domänen innan du bjuder in användare.
HTTPS krävs för praktisk användning
Synapse lyssnar normalt internt på HTTP (vanligen port 8008). Använd en reverse proxy med HTTPS för klienter och federering i stället för att exponera containerns råa port offentligt.
Federering medför ytterligare krav på DNS och proxy
Om du vill kommunicera med andra Matrix-servrar måste du konfigurera det offentliga servernamnet, HTTPS och federeringsidentifieringen korrekt. Ett lokalt test kan vara mycket enklare.
Säkerhetskopiera mer än containern
Bevara homeserver.yaml, signeringsnycklar, uppladdade medier och PostgreSQL-databasen. Att hämta avbilden på nytt återställer inte en homeserver-identitet.
Docker-felsökningsguiden beskriver den allmänna modellen för felsökning av containrar.
Kontrollera filägarskap på den beständiga datamappen
Om containerloggen rapporterar permission denied när homeserver.yaml, signeringsnycklar eller medier läses ska du korrigera ägarskapet för den mapp som är kopplad till Synapse-data så att det motsvarar det UID/GID som avbilden förväntar sig. Undvik att göra hela CasaOS-dataträdet skrivbart för alla.
Vänta tills databasens migreringar är klara innan du bedömer hälsan
Efter en uppgradering eller den första PostgreSQL-anslutningen kan Synapse behöva tid för att köra schemamigreringar. Följ loggarna i stället för att starta om containern upprepade gånger, eftersom avbrutna migreringar kan göra felsökningen svårare.
Testa det lokala API:t före reverse proxyn
Bekräfta att Synapses interna HTTP-slutpunkt svarar från CasaOS-värden innan du lägger till HTTPS, DNS eller federering. Om det lokala API:t är unhealthy kan en reverse proxy inte reparera det.
Vanliga frågor
Varför är Synapse unhealthy?
Kontrollera loggarna och hälsoutdata efter konfigurations-, behörighets-, databas- eller migreringsfel; källtråden angav inte en enda verifierad orsak.
Kan jag använda SQLite?
Ja, för testning. Den aktuella Synapse-dokumentationen rekommenderar PostgreSQL för nästan alla produktionsinstallationer.
Vilken port använder Synapse internt?
Vanliga Docker-konfigurationer exponerar klient-/server-API:t på port 8008 bakom en reverse proxy.
Behöver jag Element?
Nej. Synapse är homeservern; Element är en möjlig klient/webbfrontend.
