Przekierowanie "302" - problem

Wgrałem na serwer certyfikaty Let’s Crypt. Domena jest poprawnie podpięta.
Przekierowania są usunięte z .htaccess.

Wchodząc na witrynę z https na początku nieoczekiwanie przekierowuje na http, jednakże, gdy to samo zrobi się np. w stosunku do pliku PHP nie związanego z CMS (np. hello_world.php), w formularzu logowania (https://www.**********.pl/user/loginUser), albo backendu, a także plików nie będących PHP to wczytuje się normalnie pod https bez żadnych przekierowań na http.

Sprawdzając poprzez curl --include https://www.*****.pl mam taki oto wynik:

W konsoli dev w przeglądarce też widać, że z HTTPS jest przekierowanie 302 na domenę w zwykłym HTTP.

Jak najprościej znaleźć źródło przekierowania, konkretne pliki, które to powodują ?

Po ustawieniu przekierowań z http na https w .htaccess jest jeszcze gorzej, bo strona wpada w pętlę przekierowań. (oprócz formularza logowania i backendu)

Źle skonfigurowałeś przekierowanie.

Problem w tym, że żadne przekierowanie nie jest skonfigurowane, a podkładając np. index.php z hello word zamiast tego oryginalnego index.php z CMS nie wywala przekierowania 302 z https na http.
Potrzebowałbym jakiegoś narzędzia, co wskaże co realizuje te przekierowanie.

Może plik z cms zobacz, potem każdy plik z cms-a.

Jest ich ok 1500 (nie licząc obrazków, css)
Domyślam się tylko, że gdzieś jest header("Location : ...) skoro generuje się standardowy dla 302 html z http-equiv="refresh"
Liczyłem, że są jakieś narzędzia, które wskażą skąd zostało wywołane przekierowanie.

Jeśli nie jest to jakim cudem działa? To, że nie zrobiłeś tego świadomie nie znaczy, że nie jest skonfigurowane.

Oczywiście że istnieją narzędzia, można zacząć od choćby dev toolsów które ma każda przeglądarka, a jeśli nie wiesz w jakim pliku jest ustawiony location to jest coś takiego jak przeszukiwanie plików. Ale bardziej obstawiałbym, że to konfiguracja CMS jest ustawiona na http.

1lajk

A więc pozostaje przeglądnięcie wszystkich configów. Trochę dłubaniny, bo to ustrojstwo oparte o symfony framework i nie trzyma konfiguracji w bazie danych.
Dev toolsy w przeglądarce wskazują błędnie, bo na plik, który aktualnie jest wywoływany.
W każdym razie wydaje mi się, że raczej bezmyślnie nie jest ustawiony header “na sztywno” tylko właśnie ma odwołanie do jakiegoś pliku konfiguracyjnego CMS.

No właśnie wskazują poprawnie. Po prostu masz tak zbudowany system a nie inaczej i to co Ci one pokazują zależne jest od Twojego systemu.

Również się nie zgodzę, symfony bardzo fajnie da się debugować i konfigurować, właśnie ze względu, że nie trzyma ustawień w bazie. W sumie dobrą praktyką jest nie trzymanie ustawień środowiskowych w bazie danych bo to nie są dane, a ustawienia aplikacji.

Problemy jakie masz wynikają jedynie z Twojej niewiedzy i całkowitej nieznajomości tworzenia aplikacji webowych w szczególności opartych o symfony.