Reverse proxy with PathPrefix, using Docker Compose, returns 500 Internal Server Error' caused by: unsupported protocol scheme \"\""

Traefik Traefik v2
1

For a CI/CD test scenario I'm working on, I set up a Traefik reverse proxy with a PathPrefix using Docker Compose. Running it in Docker Desktop, I get this error:
500 Internal Server Error' caused by: unsupported protocol scheme \"\""
when I query a URL that matches the configured prefix (with one exception, detailed below).

I've read that this is a pretty generic error that can be returned due to a range of configuration issues, so I've done by best to keep things simple and follow the online docs.

I added a whoami service with no path prefix on the same port, and it is working.

Here are extracts from the relevant parts of the various docker compose files:

#-----------------------------------
version: '3.4'
networks:
  my-network:
    name: my-network
#-----------------------------------

# Services
services:
  my-service:
    build: .
    environment:
      <env vars>
    ports:
      - "3000:3000"
      - "3501:3501"
    depends_on:
      <other services>
    networks:
      - my-network
    image: "my-container:local"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.my-service.rule=PathPrefix(`/myprefix/`)" 
      - "traefik.http.routers.my-service.entrypoints=web"
      - "traefik.http.services.my-service.loadbalancer.server.port=3000"
      # - "traefik.http.routers.my-service.rule=Host(`localhost`) && PathPrefix(`/myprefix/`)" 
      # - "traefik.http.routers.my-service.rule=Host(`my-service.localhost`) && PathPrefix(`/myprefix/`)" 

  reverse-proxy:
    image: traefik:v2.11
    command:
      - --api.insecure=true
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --providers.docker.allowEmptyServices=true
      - --entrypoints.web.address=:3100
      - --api.dashboard=true
      - --log.level=DEBUG
      - --accesslog=true
    ports:
      - "3100:3100"
      - "8999:8080"
    volumes:
    - "/var/run/docker.sock:/var/run/docker.sock:ro"
    networks:
      - my-network

  whoami:
    image: "traefik/whoami"
    container_name: "simple-service"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.localhost`)"
      - "traefik.http.routers.whoami.entrypoints=web"
    networks:
      - my-network
  • I exposed port 3000 for testing without the path prefix, and it works as expected.
  • The service is configured to expect the path prefix, so stripping it isn't necessary. It works as expected via port 3000. We're testing using this port for now, but we want to mimic the deployed environment as much as possible in our testing, as there is another service planned for the same entrypoint and a different prefix.
  • I get a 404 if I query localhost:3000/myprefix (no trailing '/'). The 500 only happens with the '/' following the prefix.
  • The same thing happens if I use one of the commented rules in place of the un-commented one.

I would appreciate any insight into what I am doing wrong, or troubleshooting tips.

Thanks in advance!

2

I realize now this is because the trailing '/' is necessary for the PathPrefix to match. When I remove it from the PathPrefix, the 500 occurs without it too

3

It doesn’t make sense to use build and image in same compose service.

You publish post 3100 with Traefik and curl port 3000, so the service directly.

Compare to simple Traefik example.

4 
It doesn’t make sense to use build and image in same compose service.

That's not true. See here: https://docs.docker.com/compose/compose-file/build/

5

The problem was that Docker thought the service was unhealthy, so Traefik never assigned it a URL.

Docker thought the service was unhealthy because the health check uses curl and we had at some point switched to a base image that doesn't include it.

I didn't see that the service was unhealthy because it was working and accessible via its exposed port, and Docker Desktop displayed it as green in the Containers list. Apparently to determine the health status it's necessary to use Docker Inspect (which is available in the Desktop UI via the Inspect tab on the container page) and look under State.Health.Status.

I don't understand why Docker Desktop shows services in green when their health check is failing, but that's not a Traefik issue.

What is a Traefik issue, I feel, is that errors like this one are so hard to diagnose. Had I not found this post Faulty configuration cannot reach container - #11 by svx and followed this piece of advice:

  • Use tools like docker inspect to check your container settings`

I would still be struggling