Git push => fatal: unable to access 'http://gitlab-ci-token.....': The requested URL returned error: 400

Hello,
We’re on a self hosted gitlab server and want to configure our CD/CI with Runners.
gitlab-ce version 12.10.13
gitlab-runner version 13.2.1
I’ve tested a .gitlab-ci.yml file :

image: node:latest

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - echo 'DEPLOY!!!'

But pipe failed with those messages:

Logs in gitrunner:

runner=XXXXX status=couldn't execute POST against https://DOMAIN/api/v4/jobs/request: Post https://DOMAIN/api/v4/jobs/request: dial tcp 127.0.0.1:443: connect: connection refused

Logs in gitlab:

fatal: unable to access 'http://gitlab-ci-token:[MASKED]@DOMAIN:443/group/test-first-npm.git/': The requested URL returned error: 400

And below a screenshot of our runner config

image (6)

In your opinion, what is wrong?

i think i have the same problem here :frowning:
after some time i’ve run some CI, and found this problem in the runner

Initialized empty Git repository in /builds/charles/bistro/.git/
[18](https://gitlab.alembiq.net/charles/bistro/-/jobs/897#L18)Created fresh repository.
[19](https://gitlab.alembiq.net/charles/bistro/-/jobs/897#L19)fatal: unable to access 'http://gitlab.alembiq.net:443/charles/bistro.git/': The requested URL returned error: 400 

i’ve tried cloning the repo by the link and got the same reply
however when i’ve changed url from http to https directly, and remove the 443 port, it was asked for user/password

i can see that this link is provided by the gitlab - docker logs

Checking for jobs... received                       job=898 repo_url=http://gitlab.alembiq.net:443/charles/bistro.git runner=scHP-WzA

but how should i force gitlab-runner to try proper links and not this weird http://xxx:443/ ?

my bad, had an error in gitlab configuration :frowning:

     port: 443 # Set to 443 if using HTTPS, see installation.md#using-https for additional HTTPS configuration details
    https: false # Set to true if using HTTPS, see installation.md#using-https for additional HTTPS configuration details

after changing https from false to true, the links started to work correctly