Multiple reverse proxy redirect to first site running on port 80

1. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

2. How I installed and ran Caddy:

I follow this links to install caddy

a. System environment:

Operating System: Debian 11
Kernel: 5.4.128-1-pve
Architecture: x86_64

b. Command:

caddy start
caddy stop

c. My complete Caddy config:

:80 {
        reverse_proxy localhost:3002

        handle_path /v1/api/* {
                root * /var/www/html/api/public
                file_server
                encode zstd gzip
                php_fastcgi unix//run/php/php8.2-fpm.sock
        }

        handle_path /v1/* {
                root * /var/www/html/v1/prod
                file_server
        }

        handle_path /admin/* {
                root * /var/www/html/admin
                file_server
        }

        handle_path /lot1/* {
                reverse_proxy localhost:9001
        }

        handle_path /lot2/* {
                reverse_proxy localhost:9002
        }

        handle_path /ws/* {
                reverse_proxy localhost:3005
                file_server
                # this a websocket apps
        }

        handle_path /ps/* {
                root * /var/www/html/some_php_scripts
                encode zstd gzip
                php_fastcgi unix//run/php/php8.2-fpm.sock {
                        try_files {path} {path}/index.php =404
                }
                file_server
        }

        handle_path /backend/* {
                reverse_proxy ip:8080
        }

        log {
                output file /var/log/caddy/access.log {
                        roll_size 3MiB
                        roll_keep 5
                        roll_keep_for 48h
                }
                format console
        }
}

3. The problem I’m having:

I’m new to Caddy. I have Java, NodeJS, PHP application & a WebSocket running on a domain. A NodeJS application running on port:80 is working fine. but the resources of all the other applications are redirected with 302 to port:80 NodeJS application. like as you can see on my caddy config I have the applications running on ports 9001, 9002, 3002, 3005. Here port 9001 and 9002 is using the resources of the port 3002 application and WebSocket is going to example.com/socket.io instead of example.com/ws/socket.io. Is there a way to solve this by Caddy? if yes. Help me write the config.

See this article:

You need to configure your applications with a “base path” if you want to serve it from a subpath.

Thanks for your reply. I created the subdomain by,

abc.xyz.example.com {
        reverse_proxy localhost:9001
}

Now I’m getting the DNS issue

2023/07/09 15:14:44.316 ERROR   http.acme_client        challenge failed        {"identifier": "abc.xyz.example.com", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:dns", "title": "", "detail": "DNS problem: NXDOMAIN looking up A for abc.xyz.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for abc.xyz.example.com - check that a DNS record exists for this domain", "instance": "", "subproblems": []}}
2023/07/09 15:14:44.317 ERROR   http.acme_client        validating authorization        {"identifier": "abc.xyz.example.com", "problem": {"type": "urn:ietf:params:acme:error:dns", "title": "", "detail": "DNS problem: NXDOMAIN looking up A for abc.xyz.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for abc.xyz.example.com - check that a DNS record exists for this domain", "instance": "", "subproblems": []}, "order": "https://acme-v02.api.letsencrypt.org/acme/order/1053929057/193845171797", "attempt": 1, "max_attempts": 3}
2023/07/09 15:14:45.371 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "abc.xyz.example.com", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/"}
2023/07/09 15:14:45.371 INFO    http    waiting on internal rate limiter        {"identifiers": ["abc.xyz.example.com"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "caddy@zerossl.com"}
2023/07/09 15:14:45.371 INFO    http    done waiting on internal rate limiter   {"identifiers": ["abc.xyz.example.com"], "ca": "https://acme.zerossl.com/v2/DV90", "account": "caddy@zerossl.com"}
2023/07/09 15:14:47.127 INFO    http.acme_client        trying to solve challenge       {"identifier": "abc.xyz.example.com", "challenge_type": "http-01", "ca": "https://acme.zerossl.com/v2/DV90"}
2023/07/09 15:14:53.645 ERROR   http.acme_client        challenge failed        {"identifier": "abc.xyz.example.com", "challenge_type": "http-01", "problem": {"type": "", "title": "", "detail": "", "instance": "", "subproblems": []}}
2023/07/09 15:14:53.645 ERROR   http.acme_client        validating authorization        {"identifier": "abc.xyz.example.com", "problem": {"type": "", "title": "", "detail": "", "instance": "", "subproblems": []}, "order": "https://acme.zerossl.com/v2/DV90/order/r4x3rJADBcEas65Gudqsow", "attempt": 1, "max_attempts": 3}
2023/07/09 15:14:53.645 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "abc.xyz.example.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "HTTP 0  - "}
2023/07/09 15:14:53.645 ERROR   tls.obtain      will retry      {"error": "[abc.xyz.example.com] Obtain: [abc.xyz.example.com] solving challenge: abc.xyz.example.com: [abc.xyz.example.com] authorization failed: HTTP 0  -  (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 1, "retrying_in": 60, "elapsed": 9.913113418, "max_duration": 2592000}

Are you sure you set up DNS for your domain? Do you have an A record pointing to your IP address?

Sorry, I added the DNS. Now with my caddy configuration successfully running after adding the tls internal Problem i’m having now from the browser it says redirected you too many times. with status code 308

abc.xyz.example.com {
        reverse_proxy localhost:9001
        tls internal
}

Here is the log

2023/07/27 05:57:59.483 INFO    using adjacent Caddyfile
2023/07/27 05:57:59.489 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/07/27 05:57:59.489 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc00028fa40"}
2023/07/27 05:57:59.491 INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2023/07/27 05:57:59.491 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/07/27 05:57:59.491 WARN    http    server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server {"server_name": "srv1", "http_port": 80}
2023/07/27 05:57:59.509 WARN    pki.ca.local    installing root certificate (you might be prompted for password)        {"path": "storage:pki/authorities/local/root.crt"}
2023/07/27 05:57:59.509 INFO    not NSS security databases found
2023/07/27 05:58:00.111 ERROR   pki.ca.local    failed to install root certificate      {"error": "failed to execute keytool: exit status 1", "certificate_file": "storage:pki/authorities/local/root.crt"}
2023/07/27 05:58:00.112 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2023/07/27 05:58:00.112 INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
2023/07/27 05:58:00.112 INFO    failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2023/07/27 05:58:00.112 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/07/27 05:58:00.112 INFO    http.log        server running  {"name": "srv1", "protocols": ["h1", "h2", "h3"]}
2023/07/27 05:58:00.112 INFO    http    enabling automatic TLS certificate management   {"domains": ["abc.xyz.example.com", "efgh.xyz.example.com", "websocket.xyz.example.com"]}
2023/07/27 05:58:00.113 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [abc.xyz.example.com]: no OCSP server specified in certificate", "identifiers": ["abc.xyz.example.com"]}
2023/07/27 05:58:00.113 INFO    tls     finished cleaning storage units
2023/07/27 05:58:00.113 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [efgh.xyz.example.com]: no OCSP server specified in certificate", "identifiers": ["efgh.xyz.example.com"]}
2023/07/27 05:58:00.113 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [websocket.xyz.example.com]: no OCSP server specified in certificate", "identifiers": ["websocket.xyz.example.com"]}
2023/07/27 05:58:00.114 INFO    autosaved config (load with --resume flag)      {"file": "/root/.config/caddy/autosave.json"}
2023/07/27 05:58:00.114 INFO    serving initial configuration
Successfully started Caddy (pid=1474) - Caddy is running in the background

Please use curl -v to test instead of browsers, make sure to use https:// with your address.

Is your upstream app redirecting HTTP to HTTPS?

With the https it says

*   Trying x.x.x.x:443...
* connect to x.x.x.x port 443 failed: Connection refused
* Failed to connect to abc.xyz.example.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to abc.xyz.example.com port 443: Connection refused

I think my upstream doesn’t redirect to HTTPS.

The upstream application required the .crt and .key files then I use those files from pki/authorities/local now it curl -v https://ip_address:port/ says

*   Trying x.x.x.x:9011...
* Connected to x.x.x.x (x.x.x.x) port 9011 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300492 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300492 milliseconds with 0 out of 0 bytes received

This implies there’s a networking issue preventing the connection from ever reaching Caddy. Make sure port 443 is open and port forwarded to your server. Make sure there’s no firewall blocking use of that port.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.