Skip to main content
Solved

Docker bad gateway

R
Hero
Forum|alt.badge.img+13

What could be causing a bad gateway message with an Indicium docker container?

I've already verified that all containers (including traefik) are on the same Docker network (the default network made by docker compose).

This is the line from the traefik log:

502 Bad Gateway error="dial tcp 172.18.0.6:8080: connect: connection refused"

According to “docker network inspect” 172.18.0.6 is the correct internal IP address for the Indicium container.

This weirdly doesn't happen with the Universal container as it serves the login page just fine.

Each container uses its own subdomain as the external host.

This is my docker-compose.yaml:

---
services:
  proxy:
    image: traefik
    restart: unless-stopped
    ports:
      - 80:80
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--accesslog=true"
      - "--log.level=DEBUG"
      - "--log.filePath=/logs/traefik.log"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
      - ./logs/:/logs/

  universal_prod:
    image: registry.thinkwisesoftware.com/public/universal:${TAGPROD}
    restart: unless-stopped
    environment:
      - SERVICE_URL=http://${EXTERNAL_HOST_INDICIUM_PROD}/indicium/iam/iam
      - DEFAULT_APPLICATION=APP
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.frontend.rule=Host(`${EXTERNAL_HOST_UNIVERSAL_PROD}`)"

  indicium_prod:
    image: registry.thinkwisesoftware.com/public/indicium:${TAGPROD}
    restart: unless-stopped
    environment:
      - SQL_SERVER=${SQL_SERVER_PROD}
      - SQL_DATABASE=${SQL_DATABASE_PROD}
      - SQL_USERNAME=${SQL_USERNAME_PROD}
      - SQL_PASSWORD=${SQL_PASSWORD_PROD}
      - ENABLE_REVERSE_PROXY=true
      - ALLOWED_HEADERS=All
      - TRUSTED_NETWORKS=0.0.0.0/0
      - EXTERNAL_PATH_BASE=/indicium
      - CUSTOM_JSON={"Agent":{"Enabled":false}}
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.backend.rule=(Host(`${EXTERNAL_HOST_INDICIUM_PROD}`) && PathPrefix(`/indicium`))"
      - "traefik.http.middlewares.backend.stripprefix.prefixes=/indicium"
      - "traefik.http.routers.backend.middlewares=backend"

This is my .env file:

# Versions of the images to pull
TAGPROD=2025.1

# Hostnames/IP addresses to access the platforms
EXTERNAL_HOST_INDICIUM_PROD=indicium.domain.local
EXTERNAL_HOST_UNIVERSAL_PROD=universal.domain.local

# Hostnames/IP addresses of the database servers
SQL_SERVER_PROD=HOSTNAME

# Databases to use
SQL_DATABASE_PROD=DBNAME

# Usernames to access the databases
SQL_USERNAME_PROD=******

# Passwords to access the databases
SQL_PASSWORD_PROD=******

 

Best answer by Leon Kroon

Hi ​@Roland, for what reason are you running Indicium and Universal on two seperate subdomains? When the current issue is solved you might stumble onto another, more difficult to solve issue; CORS.

Indicium does not trust traffic coming from other domains and will discard it by default, this includes subdomains.

As for the issue mentioned in this post, I am not able to replicate it with the supplied configuration. 
Could you check the logging of the Indicium container? The easiest way to do this is with docker compose logs [service_name], so there is no need to look up the container name. Maybe the Indicium service is crashing.

If Indicium is running, without any errors, can you give me the output of netstat -tunlp? It provides a bit more information about the processes related to it.

In my case, it shows:
 

 

Sidenote about the IP 127.0.0.11, it is part of the loopback interface. Anything on the IP block 127.0.0.0/8 refers to localhost 😁.

View original
Did this topic help you find an answer to your question?

7 replies

R
Hero
Forum|alt.badge.img+13
  • RolandHero
  • Author
  • Hero
  • 155 replies
  • July 7, 2025

I might’ve found a clue but I don't have a solution yet. Indicium is listening on 127.0.0.11 inside the container and according to online sources this should probably be changed to 0.0.0.0 (all addresses).

This is what I saw inside the Indicium container:


Shouldn't this be 0.0.0.0:8080? I don't have a lot of knowledge on this topic and I'm basically just guessing now.

L
Moderator
  • Leon Kroon
  • 21 replies
  • Answer
  • July 7, 2025

Hi ​@Roland, for what reason are you running Indicium and Universal on two seperate subdomains? When the current issue is solved you might stumble onto another, more difficult to solve issue; CORS.

Indicium does not trust traffic coming from other domains and will discard it by default, this includes subdomains.

As for the issue mentioned in this post, I am not able to replicate it with the supplied configuration. 
Could you check the logging of the Indicium container? The easiest way to do this is with docker compose logs [service_name], so there is no need to look up the container name. Maybe the Indicium service is crashing.

If Indicium is running, without any errors, can you give me the output of netstat -tunlp? It provides a bit more information about the processes related to it.

In my case, it shows:
 

 

Sidenote about the IP 127.0.0.11, it is part of the loopback interface. Anything on the IP block 127.0.0.0/8 refers to localhost 😁.

R
Hero
Forum|alt.badge.img+13
  • RolandHero
  • Author
  • Hero
  • 155 replies
  • July 7, 2025

Hi ​@Leon Kroon. Running docker compose logs revealed that Indicium wasn't able to reach the SQL Server host. It turned out that resolving hostname from inside the container doesn't work. I've replaced this with hostname.domain.local everywhere it's used (Docker compose, SF, relevant IAMs) and now Indicium works as expected. It’s probably more elegant to append domain.local automatically when trying to resolve a hostname as is done on the host. However I didn't find an easy way to achieve that.

As to using different subdomains: having a specific API subdomain makes it stand out better so it seemed like a good idea to separate it from the frontend like that. But to prevent the CORS issue you mentioned I switched back to the default method of sharing the same (sub)domain between Indicium and Universal. Universal now loads the end-product properly.

It all seems to work now. 😀 The final step is enabling HTTPS and generating and installing an SSL certificate which then also needs to be accepted by all devices inside the domain.

I have one more small follow-up question. Loading the end-product via SF works but it takes a while (30 seconds or more) for the first list to load after logging in. Subsequent lists seem to load a lot faster. Is there anything I could try to improve this behavior? This also happens on Indicium for Windows so perhaps it’s an SF or IAM issue?

L
1 person likes this
  • L
    Leon Kroon
L
Moderator

Hi ​@Roland, maybe the DNS options in Docker might help resolving DNS names, maybe the --dns-search flag https://docs.docker.com/engine/network/#dns-services . 

For enabling SSL, there already was a topic, it might help you further;


I am unable to assist with loading the end-product, could you make a new question on the community for this?

R
Hero
Forum|alt.badge.img+13
  • RolandHero
  • Author
  • Hero
  • 155 replies
  • July 8, 2025

​@Leon Kroon I tried the dns_search option in docker-compose.yaml but after destroying/rebuilding the containers with docker compose up -d resolving an existing hostname inside the container still returned a bad address. I'll just keep using fully stated domain names for now. Thank you for the helpful advice and I'll look into the tips for any remaining steps and issues.

R
Hero
Forum|alt.badge.img+13
  • RolandHero
  • Author
  • Hero
  • 155 replies
  • July 9, 2025

These are some endnotes on how I got to a working setup using a traefik dynamic configuration and a self-signed SSL certificate.

Starting inside my docker compose working directory I created a new ./cert directory. In there I created a new certificate of 1 year validity via the following command:

openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout key2025.pem -out cert2025.pem

I stuck to 1 year validity because modern browsers no longer accept certificates that are valid longer than that.

I then added both PEM files to a new tls.yaml file, also in ./cert and with the following content:

tls:
  stores:
    default:
      defaultCertificate:
        certFile: ./cert/cert2025.pem
        keyFile: ./cert/key2025.pem
  certificates:
    - certFile: ./cert/cert2025.pem
      keyFile: ./cert/key2025.pem
      stores:
        - default

Then I included tls.yaml for only the traefik container in docker-compose.yaml as a dynamic configuration via the option: "--providers.file.filename=/cert/tls.yaml"

To give the traefik container access to ./cert/tls.yaml I added the following volume mapping:

    volumes:
      - ./cert:/cert

Because this is a dynamic configuration it's possible to hotplug a new certificate without taking the containers down. Simply changing the filenames inside tls.yaml and saving these changes makes traefik switch to the new certificate files on the fly.

The Indicium and Universal containers don't need to know about the actual certificates because they're served by traefik to the browser and other client software. The containers only need to have TLS enabled via traefik labels:

Universal: "traefik.http.routers.frontend.tls=true"
Indicium: "traefik.http.routers.backend.tls=true"

Finally just give docker compose up -d one more spin and all containers come up again with a working SSL setup.

L
1 person likes this
  • L
    Leon Kroon
L
Moderator

Hi ​@Roland, thank you for the followup and clear instructions. When I have time I will include your instructions for the Compose file in our documentation 😃.

R
1 person likes this
  • R
    Roland

Reply


Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings