Migration from behind proxy fails

[jaybubs]

Description

does the migrate functionality ignore proxy settings? our k8s gitea deployment is behind a firewall so we gotta use a proxy to connect to the outside world. I saw there's a bunch of apparently relevant configs but none seem to work:

1. i've set

config:
  proxy:
    PROXY_ENABLED: true
    PROXY_URL: "http://our.proxy.with:port"
    PROXY_HOSTS: "*.gh.neting.cc"

however this results in the only debug/error couple of lines spat out in the logs:

.../web/repo/migrate.go:142:handleMigrateRemoteAddrError() [E] Error whilst updating url: migration/cloning from 'github.com' is not allowed: unknown hostname
.../s/context/context.go:204:HTML() [D] Template: repo/migrate/github

2. i've left just PROXY_ENABLED set to true, the rest blank, and configured:

env:
  - name: HTTP_PROXY
    value: "http://our.proxy.with:port"
# same for HTTPS_PROXY, http_proxy and https_proxy
  - name: no_proxy
    value: "local.network.com,localhost"

yet again, getting unknown hostname results

3. finally i've even tried to force git config thru the container's git user as git confg --global http.proxy http://our.proxy.with:port , with this setup i'm able to execute a raw git clone within the container succesfully, but as far as gitea goes it makes no difference, so i guess the gitea program itself never really calls git clone behind the scenes for this particular function

the proxy settings are all def correct as i'm able to curl https://github.com which prints out the entire webpage into my console

Some more investigation notes:
I noticed the handleMigrateRemoteAddrError got triggered, either by line 184 or 200 in the MigratePost function (no trace beyond last call shown - even with debug logging enabled - so i had to dig thru both);
if it was 184 - ParseRemoteAddr which calls to https://pkg.go.dev/net/url#Parse that literally just parses a string, returns a url pointer, it doesn't actually ping the url or anything other fancy in the process, so a remoteAddr should be returned by the ParseRemoteAddr function, but it might be the one returning an error?
in a similar vein IsMigrateURLAllowed might be the one spitting out the error instead - namely the call to net.LookupIP that looks up the ip using the local resolver ...could this be the culprit? the local resolver is different to the one behind the proxy right? so this resolver method looks more appropriate if an alternative resolver is set up somehow before its called...

i'm p much out of other ideas at this point and hoping that someone more familiar with the codebase knows where the fix lies, any help is much appreciated!

Gitea Version

1.16.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.30.3

Operating System

alpine3.15

How are you running Gitea?

Using the official helm chart from https://gitea.com/gitea/helm-chart/src/branch/master/values.yaml with no modifications to the original image

Database

PostgreSQL

[wxiaoguang]

Thank you for your detailed report!

Two PRs:

• For 1.16 Ignore DNS error when doing migration allow/block check (#19566) #19567
• For 1.17 Ignore DNS error when doing migration allow/block check #19566