I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.
The bug
The "Local Network" feature for Automatic URL Switching works perfectly when a single Wi-Fi SSID is configured. However, the feature breaks when more than one SSID is added to the list. The user interface explicitly allows adding multiple SSIDs, creating the expectation that the app will use the local URL when connected to any of the Wi-Fi networks in the list.
Instead, when more than one SSID is configured, the app fails to identify the local network. This results in a long hang on the splash screen (approx. 7-10 seconds) while the initial connection times out, before the app eventually falls back to the external URL. This behavior negates the purpose of the feature for users with multiple access points (e.g., 2.4GHz/5GHz networks, mesh networks).
The issue stems from a mismatch between the UI (which correctly handles a list of SSIDs) and the backend logic, which appears to only be able to compare against a single string value.
This log snippet was captured while launching the app on a trusted Wi-Fi network that was configured as part of a multi-SSID list in the "Local Network" settings.
It clearly shows the sequence of failure:
At 14:27:12, the app's first connection attempt fails immediately with an ApiException 503: Server is not reachable.
Exactly 7 seconds later, at 14:27:19, a TimeoutException is logged.
This 7-second gap directly corresponds to the user-facing delay where the app hangs on the splash screen.
The OS that Immich Server is running on
ZimaOS v1.4.4-1
Version of Immich Server
v1.140.1 (via docker)
Version of Immich Mobile App
v1.142.0
Platform with the issue
Device make and model
Samsung Galaxy S22 / Android 15 / One UI 7.0
Your docker-compose.yml content
Your .env content
Reproduction steps
1.Navigate to Settings -> Connections.
2.Enable Automatic URL Switching.
3.In the "Local Network" section, add more than one Wi-Fi SSID to the list (e.g., MyHomeWiFi, MyHomeWiFi_5G).
4.Set a valid local URL.
5.Configure a valid URL in the "External Network" section.
7.Force close the app.
8.Connect the device to one of the Wi-Fi networks from the list in step 3 (e.g., MyHomeWiFi).
9.Launch the app.
10.Observed Result: The app hangs on the splash screen for 7-10 seconds. Logs confirm a connection timeout on the initial attempt before successfully connecting via the external URL.
11.Expected Result: The app should instantly recognize that the current Wi-Fi SSID is in the trusted list and connect to the configured local URL without any delay.
Relevant log output
2025-09-13 14:27:19.488512 | severe | AuthenticationNotifier | Error getting user information from the server [CATCH ALL] | TimeoutException after 0:00:07.000000: Future not completed |
#0 Future.timeout.<anonymous closure> (dart:async/future_impl.dart:1045)
<asynchronous suspension>
#1 AuthNotifier.saveAuthInfo (package:immich_mobile/providers/auth.provider.dart:134)
<asynchronous suspension>
#2 SplashScreenPageState.resumeSession.<anonymous closure> (package:immich_mobile/pages/common/splash_screen.page.dart:54)
<asynchronous suspension>
2025-09-13 14:27:12.491168 | info | BackupNotifier | [_resumeBackup] not authenticated - abort |
2025-09-13 14:27:12.470641 | info | SplashScreenPage | Resuming session at http://192.168.0.200:2283/api |
2025-09-13 14:27:12.402560 | severe | AuthService | Cannot resolve endpoint | ApiException 503: Server is not reachable |
Additional information
An analysis of the source code pinpoints the exact location of this logical flaw. The issue lies within the setOpenApiServiceEndpoint function in the following file:
File: mobile/lib/services/auth.service.dart
The relevant code block is:
`Future<String?> setOpenApiServiceEndpoint() async {
...
final wifiName = await _networkService.getWifiName();
final savedWifiName = _authRepository.getPreferredWifiName();
String? endpoint;
if (wifiName == savedWifiName) {
endpoint = await _setLocalConnection();
}
...
}`
The comparison if (wifiName == savedWifiName) treats the entire saved SSID configuration (savedWifiName) as a single string. When the user has saved a list (e.g., "MyHomeWiFi, MyHomeWiFi_5G"), this string comparison will always fail unless the current Wi-Fi name is exactly "MyHomeWiFi, MyHomeWiFi_5G".
Suggested Fix (Feature Implementation):
To properly support the multi-SSID feature that the UI already allows, the logic should be changed to treat savedWifiName as a list of strings and check if the current wifiName is contained within that list.
A corrected logic would look something like this:
`// Psuedo-code for the corrected logic
final List savedSsidList = _authRepository.getPreferredWifiNamesAsList(); // Should return a List
if (savedSsidList.contains(wifiName)) {
endpoint = await _setLocalConnection();
}`
This change would align the app's logic with its user interface, fully implementing the multi-SSID support for the "Local Network" feature.
I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.
The bug
The "Local Network" feature for Automatic URL Switching works perfectly when a single Wi-Fi SSID is configured. However, the feature breaks when more than one SSID is added to the list. The user interface explicitly allows adding multiple SSIDs, creating the expectation that the app will use the local URL when connected to any of the Wi-Fi networks in the list.
Instead, when more than one SSID is configured, the app fails to identify the local network. This results in a long hang on the splash screen (approx. 7-10 seconds) while the initial connection times out, before the app eventually falls back to the external URL. This behavior negates the purpose of the feature for users with multiple access points (e.g., 2.4GHz/5GHz networks, mesh networks).
The issue stems from a mismatch between the UI (which correctly handles a list of SSIDs) and the backend logic, which appears to only be able to compare against a single string value.
This log snippet was captured while launching the app on a trusted Wi-Fi network that was configured as part of a multi-SSID list in the "Local Network" settings.
It clearly shows the sequence of failure:
At 14:27:12, the app's first connection attempt fails immediately with an ApiException 503: Server is not reachable.
Exactly 7 seconds later, at 14:27:19, a TimeoutException is logged.
This 7-second gap directly corresponds to the user-facing delay where the app hangs on the splash screen.
The OS that Immich Server is running on
ZimaOS v1.4.4-1
Version of Immich Server
v1.140.1 (via docker)
Version of Immich Mobile App
v1.142.0
Platform with the issue
Device make and model
Samsung Galaxy S22 / Android 15 / One UI 7.0
Your docker-compose.yml content
.Your .env content
.Reproduction steps
1.Navigate to Settings -> Connections.
2.Enable Automatic URL Switching.
3.In the "Local Network" section, add more than one Wi-Fi SSID to the list (e.g., MyHomeWiFi, MyHomeWiFi_5G).
4.Set a valid local URL.
5.Configure a valid URL in the "External Network" section.
7.Force close the app.
8.Connect the device to one of the Wi-Fi networks from the list in step 3 (e.g., MyHomeWiFi).
9.Launch the app.
10.Observed Result: The app hangs on the splash screen for 7-10 seconds. Logs confirm a connection timeout on the initial attempt before successfully connecting via the external URL.
11.Expected Result: The app should instantly recognize that the current Wi-Fi SSID is in the trusted list and connect to the configured local URL without any delay.
Relevant log output
Additional information
An analysis of the source code pinpoints the exact location of this logical flaw. The issue lies within the setOpenApiServiceEndpoint function in the following file:
File: mobile/lib/services/auth.service.dart
The relevant code block is:
`Future<String?> setOpenApiServiceEndpoint() async {
...
final wifiName = await _networkService.getWifiName();
final savedWifiName = _authRepository.getPreferredWifiName();
String? endpoint;
if (wifiName == savedWifiName) {
endpoint = await _setLocalConnection();
}
...
}`
The comparison if (wifiName == savedWifiName) treats the entire saved SSID configuration (savedWifiName) as a single string. When the user has saved a list (e.g., "MyHomeWiFi, MyHomeWiFi_5G"), this string comparison will always fail unless the current Wi-Fi name is exactly "MyHomeWiFi, MyHomeWiFi_5G".
Suggested Fix (Feature Implementation):
To properly support the multi-SSID feature that the UI already allows, the logic should be changed to treat savedWifiName as a list of strings and check if the current wifiName is contained within that list.
A corrected logic would look something like this:
`// Psuedo-code for the corrected logic
final List savedSsidList = _authRepository.getPreferredWifiNamesAsList(); // Should return a List
if (savedSsidList.contains(wifiName)) {
endpoint = await _setLocalConnection();
}`
This change would align the app's logic with its user interface, fully implementing the multi-SSID support for the "Local Network" feature.