Self-hosted GitLab OAuth callback ignores Internal URL and attempts HTTPS (443) causing ECONNREFUSED

[isboyjc]

To Reproduce

1. Deploy self-hosted GitLab using Docker.

   • GitLab listens internally on port 80 only.
   • HTTPS is terminated externally via Traefik.
   • external_url is set to https://gitlab.sentenceend.com
   • nginx['listen_https'] = false
   • nginx['listen_port'] = 80

2. Ensure GitLab and Dokploy are on the same Docker network.

3. In Dokploy Git Provider settings:

   • GitLab URL: https://gitlab.sentenceend.com
   • Internal URL: http://gitlab
   • Group Name: se

4. Authorize GitLab OAuth successfully.

5. During OAuth callback, Dokploy fails with ECONNREFUSED on port 443.

Current vs. Expected behavior

Current Behavior

During OAuth callback (code → token exchange), Dokploy attempts to connect to:

10.0.1.101:443

Resulting in:

TypeError: fetch failed
[cause]: Error: connect ECONNREFUSED 10.0.1.101:443

Internal connectivity verification shows:

curl http://gitlab/api/v4/version

works (returns 401 as expected).

However:

curl http://gitlab/oauth/token

returns:

HTTP/1.1 302 Found
Location: https://gitlab/users/sign_in

GitLab redirects GET /oauth/token to HTTPS login page.

But:

curl -X POST http://localhost/oauth/token

returns:

HTTP/1.1 400 Bad Request
Missing required parameter: grant_type

This confirms that POST /oauth/token works correctly over HTTP and does NOT require HTTPS.

Despite this, Dokploy callback still attempts to connect via HTTPS (443).

Expected Behavior

When Internal URL is set to:

http://gitlab

Dokploy should:

Use the internal HTTP endpoint for OAuth token exchange

Send POST /oauth/token to port 80

Not attempt to connect to port 443

Not follow redirect to HTTPS

Provide environment information

Operating System:
OS: Ubuntu 22.04
Arch: amd64

Dokploy version: v0.28.2
GitLab version: 18.7.3-ce.0

VPS Provider: Racknerd

Docker Network Driver:
(Insert result of: docker network inspect dokploy-network --format '{{.Driver}}')

Deployment type:
Single server, Docker-based, same server where Dokploy is installed.

GitLab configuration:
- external_url 'https://gitlab.sentenceend.com'
- nginx['listen_port'] = 80
- nginx['listen_https'] = false
- nginx['redirect_http_to_https'] = false

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Dokploy container can successfully access:

http://gitlab/api/v4/version

But cannot access:

https://gitlab.sentenceend.com (internal overlay network 443 blocked)

The failure only occurs during OAuth callback token exchange.

It appears that Internal URL is not respected during callback, and Dokploy attempts to use HTTPS instead.

Will you send a PR to fix it?

No

[dosubot]

Hi @isboyjc! I'm Dosu and I’m helping the dokploy team.

I found the issue. Looking at the OAuth callback handler, Dokploy is designed to use the Internal URL for token exchange:

const baseUrl = gitlab.gitlabInternalUrl || gitlab.gitlabUrl;

However, there's a bug in lines 29-36 that incorrectly uses the URL constructor:

const url = gitlabUrl.username && gitlabUrl.password
    ? new URL(gitlabUrl, {
        ...gitlabUrl,
        username: "",
        password: "",
    }).toString()
    : gitlabUrl.toString();

The URL constructor expects new URL(input, base) where both parameters are strings, but it's incorrectly passing an object as the second parameter. This could cause unpredictable URL handling.

Similar issues have been reported: #2720 describes the same ECONNREFUSED 10.0.1.x:443 error pattern with self-hosted GitLab on Docker networks.

Workarounds to try:

1. Verify the Internal URL (http://gitlab) is actually saved in the database
2. Try explicitly specifying the port: http://gitlab:80
3. Edit and re-save the GitLab provider configuration to ensure the Internal URL field persists

This appears to be a genuine bug that should be addressed in the codebase.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[isboyjc]

Hi @isboyjc! I'm Dosu and I’m helping the dokploy team.

I found the issue. Looking at the OAuth callback handler, Dokploy is designed to use the Internal URL for token exchange:

const baseUrl = gitlab.gitlabInternalUrl || gitlab.gitlabUrl;
However, there's a bug in lines 29-36 that incorrectly uses the URL constructor:

const url = gitlabUrl.username && gitlabUrl.password
? new URL(gitlabUrl, {
...gitlabUrl,
username: "",
password: "",
}).toString()
: gitlabUrl.toString();
The URL constructor expects new URL(input, base) where both parameters are strings, but it's incorrectly passing an object as the second parameter. This could cause unpredictable URL handling.

Similar issues have been reported: #2720 describes the same ECONNREFUSED 10.0.1.x:443 error pattern with self-hosted GitLab on Docker networks.

Workarounds to try:

1. Verify the Internal URL (http://gitlab) is actually saved in the database
2. Try explicitly specifying the port: http://gitlab:80
3. Edit and re-save the GitLab provider configuration to ensure the Internal URL field persists

This appears to be a genuine bug that should be addressed in the codebase.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

   

Thanks a lot @dosu, this is very helpful — and your analysis matches what I’m seeing on my side 👍

I can confirm the following from my environment:

1. Internal URL is correctly configured and reachable

   • Internal URL is set to: http://gitlab
   • From the Dokploy container:
     • curl http://gitlab/api/v4/version → reachable (401 expected)
     • POST http://gitlab/oauth/token → returns 400 (missing grant_type), NOT a redirect
   • This confirms that token exchange over HTTP:80 is valid on the GitLab side.

2. Despite this, OAuth callback still attempts HTTPS internally

   • Dokploy logs consistently show:
     connect ECONNREFUSED 10.0.1.x:443
   • Even after deleting + re-adding the GitLab provider and re-authorizing OAuth.
   • This strongly suggests the callback path is still constructing an HTTPS URL internally.

3. I also confirmed that GET /oauth/token redirects to HTTPS

   • GET http://gitlab/oauth/token → 302 → https://gitlab/users/sign_in
   • But POST does NOT redirect, so this should not affect a correct OAuth token exchange.

Given your pointer to the URL constructor usage, this makes sense.
If the Internal URL is being passed through new URL(gitlabUrl, {...}) with an object base,
it could explain why the final resolved URL ends up as HTTPS / port 443 unexpectedly.

I also tried the suggested workarounds:

• Explicitly setting http://gitlab:80
• Editing and re-saving the provider
• Verifying the value is persisted

…but the behavior remains the same.

So yes, this looks like a real bug in the OAuth callback URL construction logic,
specifically around how Internal URL is normalized/overridden.

If helpful, I’m happy to:

• Test a patch
• Verify a fix on my setup
• Or provide DB values / additional logs

Thanks again for the investigation!

[dosubot]

Thanks for confirming! The bug is now clear — looking at the current callback code, the URL constructor misuse in lines 29-36 is still present in v0.28.2:

const url =
    gitlabUrl.username && gitlabUrl.password
        ? new URL(gitlabUrl, {
                ...gitlabUrl,
                username: "",
                password: "",
            }).toString()
        : gitlabUrl.toString();

Interestingly, PR #2361 was supposed to fix this, but it appears the buggy URL constructor code is still in place. The fix should sanitize the URL properly:

const sanitizedUrl = new URL(gitlabUrl.toString());
if (gitlabUrl.username && gitlabUrl.password) {
    sanitizedUrl.username = "";
    sanitizedUrl.password = "";
}
const url = sanitizedUrl.toString();

Since you're willing to test a patch, that would be really valuable. The fix is straightforward — replace lines 29-36 with proper URL property manipulation instead of the invalid constructor call. Would you like to submit a PR with this fix? I can help verify the exact changes needed.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[isboyjc]

Thanks for confirming! The bug is now clear — looking at the current callback code, the URL constructor misuse in lines 29-36 is still present in v0.28.2:

const url =
gitlabUrl.username && gitlabUrl.password
? new URL(gitlabUrl, {
...gitlabUrl,
username: "",
password: "",
}).toString()
: gitlabUrl.toString();
Interestingly, PR #2361 was supposed to fix this, but it appears the buggy URL constructor code is still in place. The fix should sanitize the URL properly:

const sanitizedUrl = new URL(gitlabUrl.toString());
if (gitlabUrl.username && gitlabUrl.password) {
sanitizedUrl.username = "";
sanitizedUrl.password = "";
}
const url = sanitizedUrl.toString();
Since you're willing to test a patch, that would be really valuable. The fix is straightforward — replace lines 29-36 with proper URL property manipulation instead of the invalid constructor call. Would you like to submit a PR with this fix? I can help verify the exact changes needed.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

   

Thanks @dosu — I’ve submitted a PR that implements exactly this fix 👍

PR: #3852

Summary of the changes:

• Replaced the invalid new URL(input, object) usage with proper URL sanitization via new URL(gitlabUrl.toString())
• Explicitly strip username/password via property assignment
• Use URL.origin to ensure a clean protocol + host without trailing slash or credentials
• Prevent silent redirect-following to unreachable HTTPS endpoints during token exchange

Happy to adjust anything if you’d prefer a different approach or scope.

[dosubot]

Excellent work on PR #3852! 🎉

Your analysis is spot-on — I particularly like the additional insight about the double-slash path issue causing GitLab's nginx to redirect to HTTPS. Using URL.origin to get a clean protocol + host without trailing slash is a smart approach to avoid the "http://gitlab//oauth/token" concatenation problem that triggers the redirect.

The fix looks solid. Thanks for taking this on and submitting the PR!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Siumauricio]

why internalUrl is https://gitlab? @isboyjc