UI Breaks with Nginx proxy_pass #1821

New Issue

GiteaMirror · 2025-11-02T04:14:18-06:00

GiteaMirror commented

2025-11-02 04:14:18 -06:00

Originally created by @methodbox on GitHub (May 25, 2018).

Gitea version (or commit ref): 1.3.2
Git version: 2.7.4
Operating system: Ubuntu 16.04
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Using a basic proxy_pass in Nginx breaks asset paths instantly. Fresh install with proxy_pass URL specified doesn't work.

Updating app.ini doesn't work

Proxy pass settings:

location / {
		proxy_pass http://[ip address]:3000;
		proxy_set_header Host $host;
    		proxy_set_header X-Real-IP $remote_addr;

		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
	}

App works without Nginx on 3000, but that's kind of useless. I'm afraid it will break using a valid domain name.

Screenshots

Originally created by @methodbox on GitHub (May 25, 2018).  - Gitea version (or commit ref): 1.3.2 - Git version: 2.7.4 - Operating system: Ubuntu 16.04 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description Using a basic proxy_pass in Nginx breaks asset paths instantly. Fresh install with proxy_pass URL specified doesn't work. Updating app.ini doesn't work Proxy pass settings: ``` location / { proxy_pass http://[ip address]:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. try_files $uri $uri/ =404; } ``` App works without Nginx on 3000, but that's kind of useless. I'm afraid it will break using a valid domain name. ## Screenshots <img width="1895" alt="screen shot 2018-05-24 at 10 49 55 pm" src="https://user-images.githubusercontent.com/12660440/40525311-fdefc950-5fa4-11e8-8a7a-3e03751ac9da.png">

GiteaMirror added the type/question label 2025-11-02 04:14:18 -06:00

GiteaMirror closed this issue

2025-11-02 04:14:18 -06:00

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@niclashoyer commented on GitHub (May 25, 2018):

This is the location block that I use:

        location / {
                proxy_pass http://unix:/var/run/gitea/gitea.sock;
                proxy_set_header Host $host;
        }

don't know if the try_files is actually necessary?

@niclashoyer commented on GitHub (May 25, 2018): This is the location block that I use: ``` location / { proxy_pass http://unix:/var/run/gitea/gitea.sock; proxy_set_header Host $host; } ``` don't know if the `try_files` is actually necessary?

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@jonasfranz commented on GitHub (May 25, 2018):

Please checkout our guide for using reverse proxies: https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy

Do the problems occur still after following our guide?

@jonasfranz commented on GitHub (May 25, 2018): Please checkout our guide for using reverse proxies: https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy Do the problems occur still after following our guide?

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@lunny commented on GitHub (May 25, 2018):

@niclashoyer maybe you can also contribute to https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy when using unixsock protocols.

@lunny commented on GitHub (May 25, 2018): @niclashoyer maybe you can also contribute to https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy when using unixsock protocols.

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@methodbox commented on GitHub (May 25, 2018):

My config is very much the same but I did not specify the server name and you might be right about the try methods; they’re in their by default and I’ve only ever had to add to them.

I’ll give this a try later.

Did not realize you had a special guide but to be honest I’ve never had to use special configuration for proxying a given web app from its port to port 80.

I build Nodejs apps and haven’t experienced this problem, but not familiar with Go enough to understand if it’s somehow different.

@methodbox commented on GitHub (May 25, 2018): My config is very much the same but I did not specify the server name and you might be right about the try methods; they’re in their by default and I’ve only ever had to *add* to them. I’ll give this a try later. Did not realize you had a special guide but to be honest I’ve never had to use special configuration for proxying a given web app from its port to port 80. I build Nodejs apps and haven’t experienced this problem, but not familiar with Go enough to understand if it’s somehow different.

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@jonasfranz commented on GitHub (May 25, 2018):

@methodbox You could also set the port of gitea to 80 or 433 (if you prefer https) but this may require root.

@jonasfranz commented on GitHub (May 25, 2018): @methodbox You could also set the port of gitea to 80 or 433 (if you prefer https) but this may require root.

GiteaMirror commented

2025-11-02 04:14:19 -06:00

@techknowlogick commented on GitHub (May 25, 2018):

Here is a sample configuration that @thehowl posted to our Forum: https://discourse.gitea.io/t/call-gitea-as-a-subdomain-of-nginx/266/2

@techknowlogick commented on GitHub (May 25, 2018): Here is a sample configuration that @thehowl posted to our Forum: https://discourse.gitea.io/t/call-gitea-as-a-subdomain-of-nginx/266/2

GiteaMirror commented

2025-11-02 04:14:20 -06:00

@methodbox commented on GitHub (May 26, 2018):

@JonasFranzDEV That’s a terrible recommendation from a security standpoint.

Your application should never also be it’s own web server, let alone be allowed to handle HTTPS transactions.

This coupled with the idea that you suggested root being the owner of the process makes me question the technical knowledge behind this project.

I appreciate that you may be a qualified Go developer but your grasp of server administration may be lacking if you’d even consider that response as one to be taken seriously.

@methodbox commented on GitHub (May 26, 2018): @JonasFranzDEV That’s a terrible recommendation from a security standpoint. Your application should never also be it’s own web server, let alone be allowed to handle HTTPS transactions. This coupled with the idea that you suggested root being the owner of the process makes me question the technical knowledge behind this project. I appreciate that you may be a qualified Go developer but your grasp of server administration may be lacking if you’d even consider that response as one to be taken seriously.

GiteaMirror commented

2025-11-02 04:14:20 -06:00

@jonasfranz commented on GitHub (May 26, 2018):

@methodbox I don't see your point why a reverse proxy with no additional configuration should make a web application more secure. The only advantage might be that you could hide your gitea instance from the public. In addition you so called web server will be started also as root because no process could use a port <1024 without root permissions. I don not recommend running gitea as root but you could use other solutions like running gitea via docker which might be easier for not experienced user.

This project comes to you for free and the support many users are giving to you are also free.

@jonasfranz commented on GitHub (May 26, 2018): @methodbox I don't see your point why a reverse proxy with no additional configuration should make a web application more secure. The only advantage might be that you could hide your gitea instance from the public. In addition you so called web server will be started also as root because **no** process could use a port <1024 without root permissions. I don not recommend running gitea as root but you could use other solutions like running gitea via docker which might be easier for not experienced user. This project comes to you for free and the support many users are giving to you are also free.

GiteaMirror commented

2025-11-02 04:14:20 -06:00

@techknowlogick commented on GitHub (May 26, 2018):

To bind to a port below 1024, you can use setcap on Linux: sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea.

@techknowlogick commented on GitHub (May 26, 2018): To bind to a port below 1024, you can use setcap on Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`.

GiteaMirror commented

2025-11-02 04:14:20 -06:00

@methodbox commented on GitHub (May 28, 2018):

The reverse proxy is only part of the few steps to add additional security but an application should never run as its own web server, if nothing else.

Nginx is definitely going to be able to handle more requests than the Go service daemon, for example.

There’s also the benefit of something that can manage all kinds of different insecure header requests, block POST requests by default and the list goes on.

Your app server should never be your web server. There’s plenty of info out there in the Nodejs world that you can google if you want to learn more.

Here’s the first Reddit thread I found in a lazy google which has plenty of good reasons: https://www.reddit.com/r/node/comments/6b3voh/why_would_you_use_a_reverse_proxy_for_node/

That said, I missed a step in my Nginx server block - server_name - which seems to have resolved the issue.

@methodbox commented on GitHub (May 28, 2018): The reverse proxy is only part of the few steps to add additional security but an application should never run as its own web server, if nothing else. Nginx is definitely going to be able to handle more requests than the Go service daemon, for example. There’s also the benefit of something that can manage all kinds of different insecure header requests, block POST requests by default and the list goes on. Your app server should never be your web server. There’s plenty of info out there in the Nodejs world that you can google if you want to learn more. Here’s the first Reddit thread I found in a lazy google which has plenty of good reasons: https://www.reddit.com/r/node/comments/6b3voh/why_would_you_use_a_reverse_proxy_for_node/ That said, I missed a step in my Nginx server block - server_name - which seems to have resolved the issue.

GiteaMirror commented

2025-11-02 04:14:20 -06:00

@MiguelNdeCarvalho commented on GitHub (Mar 8, 2019):

Hey, I am having the same issue. Can you guys help me?

@MiguelNdeCarvalho commented on GitHub (Mar 8, 2019): Hey, I am having the same issue. Can you guys help me?

GiteaMirror commented

2025-11-02 04:14:21 -06:00

@techknowlogick commented on GitHub (Mar 8, 2019):

@MiguelNdeCarvalho perhaps this page could help you: https://docs.gitea.io/en-us/reverse-proxies/

@techknowlogick commented on GitHub (Mar 8, 2019): @MiguelNdeCarvalho perhaps this page could help you: https://docs.gitea.io/en-us/reverse-proxies/

GiteaMirror referenced this issue

2025-11-02 15:40:52 -06:00