Reverse Proxy redirecting to where I want to proxy to

Help
1

1. Caddy version (v2.4.6):

2. How I run Caddy:

CLI

a. System environment:

Windows server 2016

b. Command:

caddy_windows_amd64.exe reverse-proxy --from localhost:8443 --to localhost:8080

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

N/A

3. The problem I’m having:

We have a requirements database that is currently hosted at http://localhost:8080/database/. Our goal is to set up a reverse proxy so it’s accessible at https://localhost:8443/database/. We chose caddy for the easy https and certificate handling (we will be getting a public DNS in the future). Using the command above worked the other day and functionality was as expected, but we had a power outage and we had to restart our server. Restarting caddy with the command above and navigating to https://localhost:8443/database/ simply takes us to http://localhost:8080/database/ instead of https://localhost:8443/database/. http://localhost:8080/database/ was and continues to be accessible and behaves as expected.

To our understanding, this should work, but we are very new to Caddy (used for the first time two days ago) so we might be missing something glaringly obvious or it might not even be a caddy issue but we’re trying to explore every avenue for help.

4. Error messages and/or full log output:

No browser errors. Command line output: 
C:\caddy>caddy_windows_amd64.exe reverse-proxy --from localhost:8443 --to localhost:8080
2021/12/17 17:51:45.590  [33mWARN [0m   admin   admin endpoint disabled
2021/12/17 17:51:45.591  [34mINFO [0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "proxy"}
2021/12/17 17:51:45.591  [34mINFO [0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000236c40"}
2021/12/17 17:51:45.596  [34mINFO [0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\doorA\\AppData\\Roaming\\Caddy"}
2021/12/17 17:51:45.598  [34mINFO [0m   tls     finished cleaning storage units
2021/12/17 17:51:45.609  [33mWARN [0m   pki.ca.local    installing root certificate (you might be prompted for password)        {"path": "storage:pki/authorities/local/root.crt"}
2021/12/17 09:51:45 Note: NSS support is not available on your platform
2021/12/17 09:51:48 certificate installed properly in Java keystore
2021/12/17 09:51:51 certificate installed properly in windows trusts
2021/12/17 17:51:51.243  [34mINFO [0m   http    enabling automatic TLS certificate management   {"domains": ["localhost"]}
2021/12/17 17:51:51.244  [34mINFO [0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\doorA\\AppData\\Roaming\\Caddy\\autosave.json"}
Caddy proxying https://localhost:8443 -> http://localhost:8080
2021/12/17 17:51:51.250  [34mINFO [0m   tls.obtain      acquiring lock  {"identifier": "localhost"}
2021/12/17 17:51:51.254  [34mINFO [0m   tls.obtain      lock acquired   {"identifier": "localhost"}
2021/12/17 17:51:51.258  [34mINFO [0m   tls.obtain      certificate obtained successfully       {"identifier": "localhost"}
2021/12/17 17:51:51.261  [34mINFO [0m   tls.obtain      releasing lock  {"identifier": "localhost"}
2021/12/17 17:51:51.265  [33mWARN [0m   tls     stapling OCSP   {"error": "no OCSP stapling for [localhost]: no OCSP server specified in certificate"}

5. What I already tried:

-Originally followed the reverse-proxy quickstart guide at Reverse proxy quick-start — Caddy Documentation and this worked and was satisfactory for us for the time being
-Stopping and restarting Caddy
-Restarting the server and it’s components
-Deleted files in AppData/Roaming/Caddy
-Running Caddy as admin and not admin
-Creating a caddy file instead of using the command above:

localhost

reverse-proxy --from localhost:8443 --to localhost:8080

6. Links to relevant resources:

2

Please make the request with curl -v and show us what’s happening. We should see a Location header if a redirect is being performed. If not, then it’s your browser caching something incorrectly, or your upstream app triggering a redirect for whatever reason.

The Caddyfile doesn’t take CLI commands as input. It takes Caddyfile directives. See this page in the docs to better understand:

Using the reverse-proxy command is fine for quick-and-dirty local development tasks. For a longer-running Caddy, using a config file is highly recommended, because it’s much more flexible.

1 Like
3

Thanks, we’re looking into switching over to a caddyfile.

In the meantime, here’s the curl -vk https://localhost:8443/database/ (curl did not like the self-signed) output:

C:\curl\curl-7.80.0-win64-mingw\bin>curl -vk https://localhost:8443/database/
*   Trying 127.0.0.1:8443...
* Connected to localhost (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Dec 17 17:51:51 2021 GMT
*  expire date: Dec 18 05:51:51 2021 GMT
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x19edd550ab0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /database/ HTTP/2
> Host: localhost:8443
> user-agent: curl/7.80.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 302
< date: Fri, 17 Dec 2021 21:11:17 GMT
< location: http://localhost:8080/database/welcome/welcome.jsp
< server: Caddy
< server: Apache-Coyote/1.1
< set-cookie: JSESSIONID=8C4104D20B2FF0D7A67FFDC3B98B7C19; Path=/database; HttpOnly
< content-length: 0
<
* Connection #0 to host localhost left intact
4

Alright so since we see Server: Apache, we know the response was written by the upstream, and the Location header is the redirect. So you’ll need to check what your upstream is doing.

1 Like
5

I was thinking that was the case. Thanks for the help anyways!

6

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