Come capire se un errore di Immich proviene dal client o dal server
Determina se un errore di Immich è lato client o lato server riproducendo la stessa azione con una sola variabile modificata e seguendo la richiesta non riuscita lungo il percorso.
Un banner mobile che dice “errore del server” può comunque avere origine dallo stato del client, da TLS, da un reverse proxy o da una richiesta rifiutata correttamente dal server. Allo stesso modo, un errore che si verifica solo nel browser non dimostra che il browser sia danneggiato. Mantieni invariati account, risorsa e azione; confronta client e percorsi, quindi usa i codici di stato e i log sincronizzati per individuare il primo livello in cui si verifica l’errore.
Riproduci la stessa azione su un secondo client
Scegli un’azione deterministica, come effettuare l’accesso, aprire una risorsa nota, caricare la stessa foto di piccole dimensioni o eseguire la stessa ricerca. Ripetila con lo stesso account su un browser e su un client mobile, mantenendo invariato il percorso di rete. Registra l’ora esatta e il risultato di entrambi i tentativi.
Un recente report su Immich in cui un client Android non riusciva a connettersi mentre venivano testati altri percorsi di accesso illustra il valore del confronto tra client. La causa emersa in una singola discussione non è generalizzabile, ma un risultato specifico di un client restringe nettamente il campo delle verifiche successive.
Se ogni client non riesce a eseguire la stessa azione nello stesso momento, server, database, spazio di archiviazione o percorso di rete condiviso diventano ipotesi più probabili. Se fallisce un solo client mentre un altro ha successo attraverso lo stesso endpoint, controlla la versione del client, lo stato memorizzato nella cache, i permessi, l’attendibilità dei certificati locali e la richiesta esatta che differisce.
Cambia il percorso senza modificare account o risorsa
Confronta quindi un percorso locale affidabile con il normale percorso tramite reverse proxy, VPN, tunnel o accesso remoto. Usa lo stesso account e la stessa azione. Un successo locale associato a un errore remoto allontana l’attenzione dalla risorsa multimediale e la sposta verso DNS, TLS, proxy, firewall o livelli di instradamento a monte.
La guida di ZimaSpace sulla diagnosi dei percorsi locali e remoti spiega perché il successo sulla LAN e quello su Internet costituiscano prove diverse. Applica questa distinzione a Immich prima di reinstallare un’app mobile o ricostruire il server.
Se entrambi i percorsi falliscono nello stesso modo, interrompi le modifiche alle impostazioni del proxy e analizza la richiesta a livello applicativo. Se fallisce solo il percorso tramite proxy, acquisisci lo stato del proxy, il risultato TLS, la risposta upstream e il timeout. Questo confronto con una sola variabile modificata impedisce che un messaggio del client indirizzi l’indagine verso il livello sbagliato.
Usa i codici di stato come indizi, non come verdetti definitivi
Le classi dei codici HTTP aiutano a stabilire dove cercare, ma non identificano automaticamente il componente che ha causato la condizione. Un codice 4xx indica spesso che la richiesta, l’autenticazione o l’autorizzazione non erano accettabili; un codice 5xx indica che un componente lato server non ha potuto soddisfare la richiesta. I proxy possono generare entrambe le classi prima che Immich riceva la richiesta.
La guida ai campi dei log di accesso evidenzia il codice di stato, il percorso URL, l’ora della richiesta, l’host remoto e gli identificativi della richiesta come campi utili per la risoluzione dei problemi. Acquisisci questi valori per la singola azione che non riesce, invece di esaminare migliaia di righe non correlate.
Se il proxy registra un 502 o un timeout senza una richiesta Immich corrispondente, segui il percorso upstream. Se Immich registra una richiesta e restituisce un 4xx deterministico, controlla autenticazione, permessi o contenuto della richiesta. Se il client segnala un errore ma tutti i livelli lato server mostrano 2xx, analizza l’interpretazione della risposta da parte del client, la cache locale o le richieste successive.
Correla frequenza degli errori, latenza e log del server allo stesso timestamp
Una singola richiesta non riuscita può essere un caso isolato. Riproduci l’azione da cinque a dieci volte e registra frequenza dei successi e latenza mentre osservi i log pertinenti del server e del proxy. Se gli errori aumentano durante picchi di pressione sulle risorse o della coda, il server potrebbe essere intermittentemente non disponibile anche se un secondo tentativo va a buon fine.
La panoramica di Better Stack sui segnali di servizio rappresentati da errori e latenza distingue la frequenza degli errori dalla latenza e dal traffico. Questa impostazione aiuta a distinguere una singola richiesta client malformata da un percorso server che peggiora solo sotto carico.
Se i log del server contengono la stessa eccezione per più client, considerala lato server finché non viene dimostrato il contrario. Se il server non riceve mai la richiesta che fallisce, traccia DNS, TLS, proxy e rete del client. Se un solo client genera una struttura di richiesta diversa, aggiorna o reimposta quel client dopo aver conservato prove sufficienti a confermare la differenza.
Formula il giudizio finale con un test a matrice due per due
Usa due client e due percorsi: browser-locale, browser-remoto, mobile-locale e mobile-remoto. Mantieni lo stesso account e la stessa risorsa di test. Questa matrice separa gli errori specifici del client da quelli specifici del percorso e dagli errori del server che interessano ogni combinazione.
Un’origine nel client è supportata quando un client fallisce su entrambi i percorsi mentre l’altro funziona. Un’origine nel percorso è supportata quando entrambi i client falliscono solo attraverso un determinato percorso. Un’origine nel server è supportata quando tutte e quattro le combinazioni riproducono lo stesso errore applicativo e i log del server mostrano la stessa operazione non riuscita.
Dopo aver corretto il livello individuato, esegui nuovamente tutte e quattro le combinazioni e un riavvio del componente interessato. Interrompi la verifica quando la combinazione che originariamente falliva funziona senza compromettere i controlli. Per l’escalation, fornisci la matrice, i timestamp, i codici di stato HTTP, estratti dei log del proxy e del server, le versioni dei client e una richiesta riproducibile, anziché un semplice screenshot generico.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
