immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

I encountered a connectivity issue when using the Immich mobile client over my cellular (4G/5G) network. #7946

New Issue
Closed
opened 2026-02-05 13:25:47 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-05 13:25:47 +03:00
Owner
Copy Link

Originally created by @forrest-x on GitHub (Nov 28, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

Hi team,

I encountered a connectivity issue when using the Immich mobile client over my cellular (4G/5G) network.

My Immich server is hosted inside my home network. When I access it from my cellular network, I often receive a large number of TCP RST packets, which interrupt the connection unexpectedly. After capturing network traffic, it seems that the issue occurs mainly when I rapidly scroll through the photo timeline on the mobile app’s main screen.

My observation is that during fast scrolling, the Immich mobile client sends a burst of requests in a short time. This causes a high number of concurrent connections, and my ISP appears to interpret this as suspicious or attack-like behavior, resulting in the connection being forcibly reset.

This issue makes it difficult to browse photos smoothly from outside my home network.

Environment

  • Immich server deployed on a private/home network
  • Accessing via mobile network
  • Issue happens on Immich mobile client when quickly scrolling
  • Captured many TCP RST packets from ISP side

Expected Behavior

Normal photo browsing without excessive resets or dropped connections.

Actual Behavior

Connections are frequently reset when the UI triggers many parallel requests (fast scrolling).

Question / Request

Is there a possibility to reduce or batch requests on fast scroll?
Or limit concurrency on the mobile client to avoid triggering ISP rate/connection limits?

Any guidance or improvements would be appreciated.

Thanks!

The OS that Immich Server is running on

Debian12

Version of Immich Server

v2.3.1

Version of Immich Mobile App

v2.3.1

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

Android15

Your docker-compose.yml content

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always

volumes:
  model-cache:

Your .env content

UPLOAD_LOCATION=/data/photos/immich-library
DB_DATA_LOCATION=./postgres
IMMICH_VERSION=release

Reproduction steps

  1. Open the Immich mobile app and stay on the main/home screen (photo timeline).
  2. Swipe down the screen slightly until the scroll bar appears on the right side.
  3. Drag the scroll bar quickly to jump through the timeline and load older photos.
  4. Observe whether the thumbnails load properly or if the connection gets interrupted (e.g., many TCP RST packets, failed thumbnail loads).

Relevant log output

Additional information

No response

Originally created by @forrest-x on GitHub (Nov 28, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug Hi team, I encountered a connectivity issue when using the Immich mobile client over my cellular (4G/5G) network. My Immich server is hosted inside my home network. When I access it from my cellular network, I often receive a large number of TCP **RST** packets, which interrupt the connection unexpectedly. After capturing network traffic, it seems that the issue occurs mainly when I **rapidly scroll through the photo timeline** on the mobile app’s main screen. My observation is that during fast scrolling, the Immich mobile client sends a burst of requests in a short time. This causes a high number of concurrent connections, and my ISP appears to interpret this as suspicious or attack-like behavior, resulting in the connection being forcibly reset. This issue makes it difficult to browse photos smoothly from outside my home network. #### **Environment** - Immich server deployed on a private/home network - Accessing via mobile network - Issue happens on Immich mobile client when quickly scrolling - Captured many TCP RST packets from ISP side #### **Expected Behavior** Normal photo browsing without excessive resets or dropped connections. #### **Actual Behavior** Connections are frequently reset when the UI triggers many parallel requests (fast scrolling). #### **Question / Request** Is there a possibility to reduce or batch requests on fast scroll? Or limit concurrency on the mobile client to avoid triggering ISP rate/connection limits? Any guidance or improvements would be appreciated. Thanks! ### The OS that Immich Server is running on Debian12 ### Version of Immich Server v2.3.1 ### Version of Immich Mobile App v2.3.1 ### Platform with the issue - [ ] Server - [ ] Web - [x] Mobile ### Device make and model Android15 ### Your docker-compose.yml content ```YAML name: immich services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} # extends: # file: hwaccel.transcoding.yml # service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding volumes: # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file - ${UPLOAD_LOCATION}:/data - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - '2283:2283' depends_on: - redis - database restart: always healthcheck: disable: false immich-machine-learning: container_name: immich_machine_learning image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration # file: hwaccel.ml.yml # service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable volumes: - model-cache:/cache env_file: - .env restart: always healthcheck: disable: false redis: container_name: immich_redis image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571 healthcheck: test: redis-cli ping || exit 1 restart: always database: container_name: immich_postgres image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file - ${DB_DATA_LOCATION}:/var/lib/postgresql/data shm_size: 128mb restart: always volumes: model-cache: ``` ### Your .env content ```Shell UPLOAD_LOCATION=/data/photos/immich-library DB_DATA_LOCATION=./postgres IMMICH_VERSION=release ``` ### Reproduction steps 1. Open the Immich mobile app and stay on the main/home screen (photo timeline). 2. Swipe down the screen slightly until the scroll bar appears on the right side. 3. Drag the scroll bar **quickly** to jump through the timeline and load older photos. 4. Observe whether the thumbnails load properly or if the connection gets interrupted (e.g., many TCP RST packets, failed thumbnail loads). ### Relevant log output ```shell ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 13:25:49 +03:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 28, 2025):

This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

@github-actions[bot] commented on GitHub (Nov 28, 2025): This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.
OVERLORD commented 2026-02-05 13:25:50 +03:00
Author
Owner
Copy Link

@forrest-x commented on GitHub (Nov 28, 2025):

confirm not duplicate

@forrest-x commented on GitHub (Nov 28, 2025): confirm not duplicate
OVERLORD commented 2026-02-05 13:25:51 +03:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Nov 28, 2025):

Hello, this is not a bug. It seems your ISP is hostile to self hosters. Maybe you can reach out to have you account approved or change ISPs.

@mmomjian commented on GitHub (Nov 28, 2025): Hello, this is not a bug. It seems your ISP is hostile to self hosters. Maybe you can reach out to have you account approved or change ISPs.
OVERLORD commented 2026-02-05 13:25:52 +03:00
Author
Owner
Copy Link

@forrest-x commented on GitHub (Nov 28, 2025):

Thank you for the response.

I agree that the TCP RST packets themselves are caused by the cellular carrier.
However, I believe there is still an issue on the app side:

After some network requests are interrupted by the carrier, a portion of the thumbnails fail to load, which is expected due to the connection reset.
But the problem is that even when I scroll to completely different photos afterward, newly requested thumbnails also fail to load. It feels like the app’s internal network state gets stuck after the interruption.

The only way to restore normal behavior is to force-stop the app and reopen it—then all thumbnails load normally again.

This suggests that the app might not fully recover after a temporary network disruption, and some internal request queue / connection pool / caching state may remain in a bad state.

So while the initial RST is indeed caused by the carrier, I believe there is still a genuine issue in the mobile client regarding:

Not properly handling partial connection resets

Thumbnail loading getting into an unrecoverable state

Recovery only working after restarting the app

Would it be possible for the team to investigate how the app handles failed or interrupted thumbnail requests?

Thank you for your help, and I’m happy to provide logs or additional details if needed.

@forrest-x commented on GitHub (Nov 28, 2025): Thank you for the response. I agree that the TCP RST packets themselves are caused by the cellular carrier. However, I believe there is still an issue on the app side: After some network requests are interrupted by the carrier, a portion of the thumbnails fail to load, which is expected due to the connection reset. But the problem is that even when I scroll to completely different photos afterward, newly requested thumbnails also fail to load. It feels like the app’s internal network state gets stuck after the interruption. The only way to restore normal behavior is to force-stop the app and reopen it—then all thumbnails load normally again. This suggests that the app might not fully recover after a temporary network disruption, and some internal request queue / connection pool / caching state may remain in a bad state. So while the initial RST is indeed caused by the carrier, I believe there is still a genuine issue in the mobile client regarding: Not properly handling partial connection resets Thumbnail loading getting into an unrecoverable state Recovery only working after restarting the app Would it be possible for the team to investigate how the app handles failed or interrupted thumbnail requests? Thank you for your help, and I’m happy to provide logs or additional details if needed.
OVERLORD commented 2026-02-05 13:25:52 +03:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Nov 28, 2025):

Any further investigation would need to be done by you as you are experiencing the issue. If you hop in the discord someone might be able to chat about it as well.

@mmomjian commented on GitHub (Nov 28, 2025): Any further investigation would need to be done by you as you are experiencing the issue. If you hop in the discord someone might be able to chat about it as well.
OVERLORD commented 2026-02-05 13:25:53 +03:00
Author
Owner
Copy Link

@skatsubo commented on GitHub (Dec 4, 2025):

Somewhat related / partial duplicate, it discusses both DNS and HTTP:

@skatsubo commented on GitHub (Dec 4, 2025): Somewhat related / partial duplicate, it discusses both DNS and HTTP: - https://github.com/immich-app/immich/issues/22652
OVERLORD commented 2026-02-05 13:25:54 +03:00
Author
Owner
Copy Link

@forrest-x commented on GitHub (Dec 4, 2025):

Thanks for referencing the related issue (#22652: “Timeline is making hundreds of DNS requests per second on scroll”).
I reviewed the discussion and also performed additional tests on my setup.

In my case, the behavior does not match #22652:

  • When I quickly scroll through the timeline on the Immich Android app, my private DNS server does not observe hundreds of DNS requests per second.
  • DNS traffic remains normal, so it appears that my issue is not caused by excessive DNS lookups.

My problem is specifically about carrier-side TCP RST packets, and after these resets occur, the Immich mobile app fails to recover. Even new thumbnails (that were never loaded before) stop loading completely until I force-stop the app and relaunch it.

This suggests the mobile client may be getting stuck after certain HTTP requests are interrupted.

I also experimented with the timeline layout:

  • Previously I displayed 4 photos per row.
  • After changing it to 2 photos per row, the issue occurs less frequently.
  • However, when scrolling quickly, connection resets and stuck thumbnail loading still happen, just slightly less often.

This makes me believe the issue is tied to how the app handles a burst of thumbnail requests combined with interrupted connections—not DNS behavior as described in #22652.

Because of this, I think my issue is not a duplicate and may need separate investigation into:

  • How thumbnail HTTP requests behave after abrupt network resets
  • Whether the request queue / connection pool gets into an unrecoverable state
  • Why normal behavior only returns after force-stopping the app

I’m happy to provide logs, packet captures, or a screen recording if that would help.

@forrest-x commented on GitHub (Dec 4, 2025): Thanks for referencing the related issue (#22652: *“Timeline is making hundreds of DNS requests per second on scroll”*). I reviewed the discussion and also performed additional tests on my setup. In my case, the behavior does **not** match #22652: - When I quickly scroll through the timeline on the Immich Android app, my private DNS server does **not** observe hundreds of DNS requests per second. - DNS traffic remains normal, so it appears that my issue is not caused by excessive DNS lookups. My problem is specifically about **carrier-side TCP RST packets**, and after these resets occur, the Immich mobile app fails to recover. Even new thumbnails (that were never loaded before) stop loading completely until I force-stop the app and relaunch it. This suggests the mobile client may be getting stuck after certain HTTP requests are interrupted. I also experimented with the timeline layout: - Previously I displayed **4 photos per row**. - After changing it to **2 photos per row**, the issue occurs less frequently. - However, when scrolling quickly, connection resets and stuck thumbnail loading still happen, just slightly less often. This makes me believe the issue is tied to how the app handles a burst of thumbnail requests combined with interrupted connections—not DNS behavior as described in #22652. Because of this, I think my issue is not a duplicate and may need separate investigation into: - How thumbnail HTTP requests behave after abrupt network resets - Whether the request queue / connection pool gets into an unrecoverable state - Why normal behavior only returns after force-stopping the app I’m happy to provide logs, packet captures, or a screen recording if that would help.
OVERLORD commented 2026-02-05 13:25:54 +03:00
Author
Owner
Copy Link

@forrest-x commented on GitHub (Dec 4, 2025):

Additional Observation

I also performed another test just now:
After the issue occurs during fast scrolling (thumbnails stop loading due to the TCP resets), if I disable mobile data and then re-enable it, the Immich app is able to load new thumbnails again without needing a full app restart.

This further suggests that the app gets stuck in an unrecoverable network state after interrupted requests, and resetting the network interface temporarily clears that state.

I hope this helps narrow down the cause.

@forrest-x commented on GitHub (Dec 4, 2025): ### **Additional Observation** I also performed another test just now: After the issue occurs during fast scrolling (thumbnails stop loading due to the TCP resets), if I **disable mobile data and then re-enable it**, the Immich app is able to load new thumbnails again without needing a full app restart. This further suggests that the app gets stuck in an unrecoverable network state after interrupted requests, and resetting the network interface temporarily clears that state. I hope this helps narrow down the cause.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#7946
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?