Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Squid Reverse Proxy permanent redirects?

    Scheduled Pinned Locked Moved Cache/Proxy
    2 Posts 1 Posters 1.1k Views 1 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • tleadleyT Offline
      tleadley
      last edited by

      Not sure where to go and how to change this behavior. I am running Squid with a reverse proxy and redirecting all my  http:// sites to https://.

      I am looking for a PfSense solution since PfSense is what i am using. I am probably not alone with this situation.

      I have tested the output of the redirects and it shows up like this
      –------------------------------------------------------------------------------
      http://example.ca

      HTTP/1.1 302 Found
      Server: squid
      Mime-Version: 1.0
      Date: Wed, 02 Aug 2017 16:59:45 GMT
      Content-Type: text/html;charset=utf-8
      Content-Length: 0
      Location: https://example.ca/
      X-Squid-Error: 403 Access Denied
      X-Cache: MISS from secure.example.com
      X-Cache-Lookup: NONE from secure.example.com:3128
      Via: 1.1 secure.example.com (squid)
      Connection: keep-alive

      https://example.ca/

      NOT A PERMITTED URL CRAWL DUE TO robots.txt
      –-------------------------------------------------------------------------------

      I would be great if the output shows HTTP/1.1 301 Found instead!

      I want to do this because it is considered by most as a best practice and someone with a higher pay grade has requested it be corrected!

      Where and what has to be changed to make this work?

      "It's not that I'm so smart, it's just that I stay with problems longer" –Albert Einstein

      tleadleyT 1 Reply Last reply Reply Quote 0
      • tleadleyT Offline
        tleadley @tleadley
        last edited by

        @tleadley This has never been answered, it was a configuration error with a hairpin DNS. It was corrected by creating the correct rules to forward to the appropriate server behind our DMZ interface. We also switched to HAproxy which gave us the ablility to host multiple sites with multiple certs!

        We can mark this solved!

        "It's not that I'm so smart, it's just that I stay with problems longer" –Albert Einstein

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.