Proxy support broke in Gitea 1.18 #10055

New Issue

GiteaMirror · 2025-11-02T08:57:02-06:00

GiteaMirror commented

2025-11-02 08:57:02 -06:00

Originally created by @zfLQ2qx2 on GitHub (Jan 4, 2023).

Description

I run gitea as a tor service so that I do not have to expose ports on my home firewall. Applications on my tor server do not have direct access to the internet, instead the tor daemon acts as a socks5 proxy and is responsible for name resolution and forwarding outgoing traffic through the tor network.

To have gitea work with tor I added the following lines to my app.ini:

[proxy]
ENABLED = true
PROXY_URL = socks://127.0.0.1:9050/
PROXY_HOSTS = *

In versions upto 1.16.1 this worked correctly and I setup mirrors of a number repos from github, gitlab, and .onion domains without issue.

I jumped from 1.16.1 to 1.18.0 and in the latest version all of my mirror connections fail with DNS resolution errors which suggests that gitea is still trying to resolve the names itself instead of entrusting them to the socks5 proxy. This makes it impossible to reach onion addresses also since only the tor client can resolve those.

My test cases to show tor is working are:

ALL_PROXY=socks5h://127.0.0.1:9050/ curl -vvv http://github.com/
ALL_PROXY=socks5h://127.0.0.1:9050/ curl -vvv http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/

(the later is the gitlab run by the tor project)

I should point out that in curl there is a difference, socks5 and socks5h, where the former uses the libc resolver and the later uses the socks5 resolver. The golang base libraries don't have a distinction.

Gitea Version

1.18

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Linux

How are you running Gitea?

gitea-1.18.0-linux-amd64 from github releases

Database

SQLite

Originally created by @zfLQ2qx2 on GitHub (Jan 4, 2023). ### Description I run gitea as a tor service so that I do not have to expose ports on my home firewall. Applications on my tor server do not have direct access to the internet, instead the tor daemon acts as a socks5 proxy and is responsible for name resolution and forwarding outgoing traffic through the tor network. To have gitea work with tor I added the following lines to my app.ini: [proxy] ENABLED = true PROXY_URL = socks://127.0.0.1:9050/ PROXY_HOSTS = * In versions upto 1.16.1 this worked correctly and I setup mirrors of a number repos from github, gitlab, and .onion domains without issue. I jumped from 1.16.1 to 1.18.0 and in the latest version all of my mirror connections fail with DNS resolution errors which suggests that gitea is still trying to resolve the names itself instead of entrusting them to the socks5 proxy. This makes it impossible to reach onion addresses also since only the tor client can resolve those. My test cases to show tor is working are: ALL_PROXY=socks5h://127.0.0.1:9050/ curl -vvv http://github.com/ ALL_PROXY=socks5h://127.0.0.1:9050/ curl -vvv http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/ (the later is the gitlab run by the tor project) I should point out that in curl there is a difference, socks5 and socks5h, where the former uses the libc resolver and the later uses the socks5 resolver. The golang base libraries don't have a distinction. ### Gitea Version 1.18 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Linux ### How are you running Gitea? gitea-1.18.0-linux-amd64 from github releases ### Database SQLite

GiteaMirror added the type/bug label 2025-11-02 08:57:02 -06:00

GiteaMirror closed this issue

2025-11-02 08:57:02 -06:00

GiteaMirror commented

2025-11-02 08:57:03 -06:00

@zeripath commented on GitHub (Jan 12, 2023):

Have you tried adding *.onion to [migrations] ALLOWED_DOMAINS ?

@zeripath commented on GitHub (Jan 12, 2023): Have you tried adding `*.onion` to `[migrations]` `ALLOWED_DOMAINS` ?

GiteaMirror commented

2025-11-02 08:57:03 -06:00

@zfLQ2qx2 commented on GitHub (Jan 15, 2023):

@zeripath I will try that, but all of the connections are failing. The majority are GitHub (dozens) a couple Gitlab, and a couple .onion.

@zfLQ2qx2 commented on GitHub (Jan 15, 2023): @zeripath I will try that, but all of the connections are failing. The majority are GitHub (dozens) a couple Gitlab, and a couple .onion.

GiteaMirror commented

2025-11-02 08:57:03 -06:00

@zeripath commented on GitHub (Jan 15, 2023):

Then have you tried setting ALLOWED_DOMAINS=* presumably your proxy is not going to allow connections to local machines?

@zeripath commented on GitHub (Jan 15, 2023): Then have you tried setting `ALLOWED_DOMAINS=*` presumably your proxy is not going to allow connections to local machines?

GiteaMirror commented

2025-11-02 08:57:04 -06:00

@zfLQ2qx2 commented on GitHub (Jan 28, 2023):

@zeripath Apologies, it took me a while to try these. I added a migrations section and tried adding ALLOWED_DOMAINS=*, although the documentation says that by default all domains are allowed so I don't think this is needed, and got the same result. I also tried adding ALLOW_LOCALNETWORKS=true under migrations because the way Tor works it maps resolved onion names to a local address and then requests to that address get forwarded to the onion address. I had no luck with this either. So I think we are back to something having changed in Gitea 1.18 (or 1.17, the last version this worked for sure was 1.16) where Gitea is attempting to resolve the addresses itself rather than allowing the Socks5 proxy to do it.

So to test I need to configure tor to answer DNS queries on 127.0.0.1:53 and we'll see if that is a workaround for this new behavior.

@zfLQ2qx2 commented on GitHub (Jan 28, 2023): @zeripath Apologies, it took me a while to try these. I added a migrations section and tried adding ALLOWED_DOMAINS=*, although the documentation says that by default all domains are allowed so I don't think this is needed, and got the same result. I also tried adding ALLOW_LOCALNETWORKS=true under migrations because the way Tor works it maps resolved onion names to a local address and then requests to that address get forwarded to the onion address. I had no luck with this either. So I think we are back to something having changed in Gitea 1.18 (or 1.17, the last version this worked for sure was 1.16) where Gitea is attempting to resolve the addresses itself rather than allowing the Socks5 proxy to do it. So to test I need to configure tor to answer DNS queries on 127.0.0.1:53 and we'll see if that is a workaround for this new behavior.

GiteaMirror commented

2025-11-02 08:57:04 -06:00

@zfLQ2qx2 commented on GitHub (Jan 29, 2023):

@zeripath So I did need [migrations] with ALLOWED_DOMAINS=* in order to update the host in the mirroring config. It looks like the Tor project changed the address of their git server which is the test case I used at start of this ticket.

I verified that the gitea user and resolve the onion address and reach it via socks 4, 5, and 5h - onion addresses resolve from command line via 127.0.0.1:53. Test case which works is:

ALL_PROXY=socks://127.0.0.1:9050/ curl -v -v -v http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion:80/tor.git

Error from gitea is now:

Failed to update mirror repository '/home/gitea/gitea-repositories/tor/tor.git': fatal: unable to access 'http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion/tor.git/': Failed to connect to gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion port 80 after 0 ms: Connection refused
error: Could not fetch origin

Which is not a resolution error so thats ok now but seems like Gitea is not using the Socks proxy for outgoing connections - otherwise would take more then 0ms to fail.

It looks like [proxy] ENABLED is now [proxy] PROXY_ENABLED, made that change but did not help.

I tried changing [proxy] PROXY_HOSTS to , **, ",**", and *.onion (four different settings) but did not help.

I'm not sure what other settings there are or how I can diagnose further. If gitea uses the socks proxy on 127.0.0.1:9050 like curl does, it should have no issue connecting out.

@zfLQ2qx2 commented on GitHub (Jan 29, 2023): @zeripath So I did need [migrations] with ALLOWED_DOMAINS=* in order to update the host in the mirroring config. It looks like the Tor project changed the address of their git server which is the test case I used at start of this ticket. I verified that the gitea user and resolve the onion address and reach it via socks 4, 5, and 5h - onion addresses resolve from command line via 127.0.0.1:53. Test case which works is: ALL_PROXY=socks://127.0.0.1:9050/ curl -v -v -v http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion:80/tor.git Error from gitea is now: ``` Failed to update mirror repository '/home/gitea/gitea-repositories/tor/tor.git': fatal: unable to access 'http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion/tor.git/': Failed to connect to gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion port 80 after 0 ms: Connection refused error: Could not fetch origin ``` Which is not a resolution error so thats ok now but seems like Gitea is not using the Socks proxy for outgoing connections - otherwise would take more then 0ms to fail. It looks like [proxy] ENABLED is now [proxy] PROXY_ENABLED, made that change but did not help. I tried changing [proxy] PROXY_HOSTS to *, **, "*,**", and *.onion (four different settings) but did not help. I'm not sure what other settings there are or how I can diagnose further. If gitea uses the socks proxy on 127.0.0.1:9050 like curl does, it should have no issue connecting out.

GiteaMirror commented

2025-11-02 08:57:04 -06:00

@zeripath commented on GitHub (Jan 29, 2023):

So the error is now coming from git not being able to resolve the host which implies that it isn't using the tor proxy.

This is strange because the proxy settings should set it.

@zeripath commented on GitHub (Jan 29, 2023): So the error is now coming from git not being able to resolve the host which implies that it isn't using the tor proxy. This is strange because the proxy settings should set it.

GiteaMirror commented

2025-11-02 08:57:04 -06:00

@zfLQ2qx2 commented on GitHub (Jan 30, 2023):

@zeripath In the gitea user's .gitconfig I also have an [http] proxy = socks5h://127.0.0.1:9050 setting, if I do '''git clone http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion/tor.git''' I get a "repository not found" error from the remote which is significant in that it shows the git binary itself can talk to the remove server. The error itself is completely different issue, I need to open an issue with the tor project, neither their new or old onion addresses seem to allow git requests. The "gzgme..." address is the one they list on the bottom of their page https://gitweb.torproject.org/tor.git
...

@zfLQ2qx2 commented on GitHub (Jan 30, 2023): @zeripath In the gitea user's .gitconfig I also have an [http] proxy = socks5h://127.0.0.1:9050 setting, if I do '''git clone http://gzgme7ov25seqjbphab4fkcph3jkobfwwpivt5kzbv3kqx2y2qttl4yd.onion/tor.git''' I get a "repository not found" error from the remote which is significant in that it shows the git binary itself can talk to the remove server. The error itself is completely different issue, I need to open an issue with the tor project, neither their new or old onion addresses seem to allow git requests. The "gzgme..." address is the one they list on the bottom of their page https://gitweb.torproject.org/tor.git ...

GiteaMirror commented

2025-11-02 08:57:04 -06:00

@zfLQ2qx2 commented on GitHub (Feb 12, 2023):

Now looking at https://github.com/xjasonlyu/tun2socks as a workaround which does not depend on gitea or git having explicit knowledge of the proxy.

@zfLQ2qx2 commented on GitHub (Feb 12, 2023): Now looking at https://github.com/xjasonlyu/tun2socks as a workaround which does not depend on gitea or git having explicit knowledge of the proxy.

GiteaMirror commented

2025-11-02 08:57:05 -06:00

@lunny commented on GitHub (Jul 27, 2023):

Is this still a problem?

@lunny commented on GitHub (Jul 27, 2023): Is this still a problem?

GiteaMirror commented

2025-11-02 08:57:05 -06:00

@yp05327 commented on GitHub (Sep 26, 2024):

Any updates?

@yp05327 commented on GitHub (Sep 26, 2024): Any updates?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10055