This is not a bug, so this is just for information.
When using a reverse proxy like nginx proxy manager, remember to enable http/2 support on the configured proxy host, in SSL settings.
If not, the gitea-mirror website will not load properly (specifically the MainLayout.*.js file).
Originally created by @MadsBen on GitHub (Jul 15, 2025).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/43
Originally assigned to: @arunavo4 on GitHub.
This is not a bug, so this is just for information.
When using a reverse proxy like nginx proxy manager, remember to enable http/2 support on the configured proxy host, in SSL settings.
If not, the gitea-mirror website will not load properly (specifically the MainLayout.*.js file).
I've investigated the codebase and confirmed that Gitea Mirror doesn't actually require HTTP/2 - it works perfectly fine with HTTP/1.1. The issue you
experienced with MainLayout.*.js not loading is likely related to how nginx proxy manager handles HTTP/1.1 connections (possibly buffering, chunking, or
timeout settings).
Enabling HTTP/2 resolves it because of better connection handling and multiplexing that HTTP/2 provides, which seems to work around whatever issue the proxy
was having with HTTP/1.1.
I've added a troubleshooting section to our README to the v3 branch to help future users who might encounter this. Thanks for sharing the solution - it will definitely help
others!
For reference, the application:
Uses standard HTTP/1.1 compatible asset loading
Has no HTTP/2 specific dependencies or requirements
Works with any modern reverse proxy configuration
Your workaround of enabling HTTP/2 is a great solution, and I'd recommend it for performance benefits anyway. Thanks again for the helpful feedback!
<!-- gh-comment-id:3077482333 -->
@arunavo4 commented on GitHub (Jul 16, 2025):
Hey @MadsBen, thanks for reporting this!
I've investigated the codebase and confirmed that Gitea Mirror doesn't actually require HTTP/2 - it works perfectly fine with HTTP/1.1. The issue you
experienced with MainLayout.*.js not loading is likely related to how nginx proxy manager handles HTTP/1.1 connections (possibly buffering, chunking, or
timeout settings).
Enabling HTTP/2 resolves it because of better connection handling and multiplexing that HTTP/2 provides, which seems to work around whatever issue the proxy
was having with HTTP/1.1.
I've added a troubleshooting section to our README to the `v3` branch to help future users who might encounter this. Thanks for sharing the solution - it will definitely help
others!
For reference, the application:
- Uses standard HTTP/1.1 compatible asset loading
- Has no HTTP/2 specific dependencies or requirements
- Works with any modern reverse proxy configuration
Your workaround of enabling HTTP/2 is a great solution, and I'd recommend it for performance benefits anyway. Thanks again for the helpful feedback!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @MadsBen on GitHub (Jul 15, 2025).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/43
Originally assigned to: @arunavo4 on GitHub.
This is not a bug, so this is just for information.
When using a reverse proxy like nginx proxy manager, remember to enable http/2 support on the configured proxy host, in SSL settings.
If not, the gitea-mirror website will not load properly (specifically the MainLayout.*.js file).
@arunavo4 commented on GitHub (Jul 16, 2025):
Hey @MadsBen, thanks for reporting this!
I've investigated the codebase and confirmed that Gitea Mirror doesn't actually require HTTP/2 - it works perfectly fine with HTTP/1.1. The issue you
experienced with MainLayout.*.js not loading is likely related to how nginx proxy manager handles HTTP/1.1 connections (possibly buffering, chunking, or
timeout settings).
Enabling HTTP/2 resolves it because of better connection handling and multiplexing that HTTP/2 provides, which seems to work around whatever issue the proxy
was having with HTTP/1.1.
I've added a troubleshooting section to our README to the
v3branch to help future users who might encounter this. Thanks for sharing the solution - it will definitely helpothers!
For reference, the application:
Your workaround of enabling HTTP/2 is a great solution, and I'd recommend it for performance benefits anyway. Thanks again for the helpful feedback!