Μια μικρή εργαλειοθήκη για την αποσφαλμάτωση redirects και HTTP headers στην παραγωγή

Το πρόβλημα με την αποσφαλμάτωση HTTP στην παραγωγή

Τα περισσότερα προβλήματα HTTP είναι αόρατα στον browser. Μια αλυσίδα redirect αποτυγχάνει σιωπηλά, ένα cache header είναι λάθος κατά έναν χαρακτήρα, μια πολιτική CORS μπλοκάρει ένα αίτημα χωρίς εξήγηση. Τα developer tools του browser σας δείχνουν το αποτέλεσμα της συνομιλίας, αλλά συχνά κρύβουν την ακατέργαστη ανταλλαγή που προκάλεσε το πρόβλημα.

Αυτό έχει τη μεγαλύτερη σημασία στην παραγωγή, όπου δεν μπορείτε να προσθέσετε logging ή να επανεκκινήσετε υπηρεσίες για να δείτε τι άλλαξε. Χρειάζεστε εργαλεία που σας δείχνουν την πραγματική HTTP συνομιλία: request headers, response headers, status codes, redirect targets, timing. Ακολουθούν τα πέντε εργαλεία που κάνουν αξιόπιστα αυτή τη δουλειά, μαζί με τις τεχνικές browser που τα συμπληρώνουν.

curl: η βάση

Το curl είναι το πρώτο εργαλείο στο οποίο πρέπει να στραφείτε, επειδή σας δείχνει ακριβώς τι έστειλε ο server, χωρίς ενδιάμεση ερμηνεία από browser.

Για να δείτε response headers χωρίς το body:

curl -I https://example.com

Για να ακολουθήσετε redirects και να δείτε κάθε βήμα:

curl -L -v https://example.com

Το flag -v (verbose) εμφανίζει το πλήρες request και response, συμπεριλαμβανομένων όλων των headers. Το flag -L ακολουθεί αυτόματα τα redirects. Μαζί, σας δείχνουν ολόκληρη την αλυσίδα redirect, δηλαδή το σημείο όπου βρίσκονται τα περισσότερα προβλήματα παραγωγής.

Για να δείτε μόνο τις redirect locations:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Αυτό είναι χρήσιμο όταν χρειάζεται να επαληθεύσετε μια αλυσίδα redirect χωρίς τον θόρυβο των πλήρων headers. Το flag -w μορφοποιεί την έξοδο ώστε να εμφανίζει μόνο το status code και το επόμενο URL στην αλυσίδα.

Το curl σας επιτρέπει επίσης να στέλνετε custom headers, κάτι απαραίτητο για δοκιμές συμπεριφοράς CDN, authentication ή API endpoints:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl με καλύτερα defaults

Το httpie είναι ένα εργαλείο Python που κάνει ό,τι κάνει το curl, αλλά με σύνταξη που είναι πιο εύκολη στην απομνημόνευση και έξοδο που είναι πιο εύκολη στην ανάγνωση. Δεν είναι αντικατάσταση — το curl είναι πιο ισχυρό και πιο ευρέως εγκατεστημένο — αλλά για γρήγορους ελέγχους, το httpie είναι ταχύτερο.

Για να δείτε headers:

http HEAD https://example.com

Για να ακολουθήσετε redirects:

http --follow --all https://example.com

Το flag --all εμφανίζει κάθε response στην αλυσίδα redirect, όχι μόνο το τελικό. Είναι το αντίστοιχο του curl -L -v, αλλά η έξοδος είναι χρωματικά κωδικοποιημένη και πιο εύκολη στη γρήγορη ανάγνωση.

Για να στείλετε JSON:

http POST https://api.example.com name=value

Το httpie υποθέτει JSON από προεπιλογή, κάτι που μειώνει την πληκτρολόγηση όταν δοκιμάζετε APIs. Επίσης κάνει pretty-print το response, διευκολύνοντας τον εντοπισμό κακοσχηματισμένων headers ή απροσδόκητων τιμών.

Browser DevTools: καρτέλα Network

Η καρτέλα Network του browser είναι το σημείο από το οποίο πρέπει να ξεκινήσετε αν το πρόβλημα συμβαίνει μόνο στον browser. Σας δείχνει τις ίδιες πληροφορίες με το curl, αλλά σας δείχνει επίσης την ερμηνεία του browser: αν μπλόκαρε ένα request, πώς χειρίστηκε το caching, αν έστειλε cookies.

Για να δείτε τα πλήρη request και response headers, κάντε κλικ σε οποιοδήποτε request στην καρτέλα Network και μετά κοιτάξτε την ενότητα Headers. Η προβολή "Raw" εμφανίζει τα headers ακριβώς όπως στάλθηκαν, χωρίς μορφοποίηση.

Για να δείτε αλυσίδες redirect, αναζητήστε requests με status codes 3xx. Ο browser τα ομαδοποιεί κάτω από το τελικό request, αλλά μπορείτε να τα αναπτύξετε για να δείτε κάθε βήμα. Εκεί θα βρείτε redirect loops, ελλιπή Location headers ή redirects που δείχνουν σε λάθος domain.

Για να δείτε timing, κοιτάξτε την καρτέλα Timing για οποιοδήποτε request. Αυτό σας δείχνει πόσο χρόνο αφιέρωσε ο browser σε DNS lookup, TCP connection, TLS handshake και αναμονή για τον server. Αν ένα redirect είναι αργό, η καρτέλα timing σας δείχνει αν το πρόβλημα είναι network latency ή server processing.

Ένας περιορισμός: ο browser κρύβει ορισμένα headers για λόγους ασφάλειας. Τα Set-Cookie headers είναι ορατά, αλλά οι πραγματικές τιμές των cookie αποκρύπτονται. Τα Authorization headers μερικές φορές κρύβονται εντελώς. Αν χρειάζεται να τα δείτε, χρησιμοποιήστε curl.

mitmproxy: ο παρεμβαλλόμενος proxy

Το mitmproxy είναι ένα εργαλείο Python που τοποθετείται μεταξύ του browser σας και του server, δείχνοντάς σας κάθε request και response σε πραγματικό χρόνο. Είναι πιο σύνθετο από το curl, αλλά είναι το μόνο εργαλείο που σας δείχνει τι στέλνει πραγματικά ο browser, συμπεριλαμβανομένων των headers που προσθέτει αυτόματα.

Για να το ξεκινήσετε:

mitmproxy

Στη συνέχεια, ρυθμίστε τον browser σας ώστε να χρησιμοποιεί το localhost:8080 ως HTTP proxy. Το mitmproxy θα σας δείχνει κάθε request σε ένα terminal interface. Μπορείτε να επιθεωρήσετε headers, να επεξεργαστείτε requests πριν σταλούν ή να επαναλάβετε requests με διαφορετικές παραμέτρους.

Αυτό είναι χρήσιμο για την αποσφαλμάτωση προβλημάτων που συμβαίνουν μόνο στον browser: CORS preflight requests, χειρισμός cookie ή requests που αποτυγχάνουν όταν υπάρχουν συγκεκριμένα headers. Είναι επίσης χρήσιμο για τη δοκιμή της συμπεριφοράς του site σας πίσω από εταιρικό proxy ή VPN, επειδή το mitmproxy μπορεί να προσομοιώσει αυτά τα περιβάλλοντα.

Το μειονέκτημα είναι η πολυπλοκότητα της εγκατάστασης. Πρέπει να εγκαταστήσετε ένα root certificate ώστε το mitmproxy να μπορεί να παρεμβάλλεται σε HTTPS traffic, και πρέπει να ρυθμίσετε τον browser σας να χρησιμοποιεί τον proxy. Για γρήγορους ελέγχους, το curl είναι ταχύτερο. Για βαθιά αποσφαλμάτωση, το mitmproxy αξίζει τον χρόνο εγκατάστασης.

webpagetest: οπτική παραγωγής

Το WebPageTest είναι μια δωρεάν υπηρεσία που φορτώνει τη σελίδα σας από πραγματικούς browsers σε διαφορετικές τοποθεσίες και σας δείχνει την πλήρη HTTP συνομιλία. Είναι πιο αργό από το curl, αλλά σας δείχνει τι βιώνουν οι πραγματικοί χρήστες, συμπεριλαμβανομένων της συμπεριφοράς CDN, του DNS resolution και του TLS negotiation.

Οι προβολές "Request Headers" και "Response Headers" σας δείχνουν ακριβώς τι έστειλε και τι έλαβε ο browser. Η προβολή "Waterfall" σας δείχνει το timing κάθε request, συμπεριλαμβανομένων των redirects. Εκεί θα βρείτε προβλήματα που συμβαίνουν μόνο σε συγκεκριμένες περιοχές ή σε συγκεκριμένα δίκτυα.

Το WebPageTest σας δείχνει επίσης την αλυσίδα redirect για το κύριο document, όπου βρίσκονται τα περισσότερα προβλήματα redirect. Αν το site σας κάνει redirect από http:// σε https://, έπειτα από www. σε non-www., και μετά από / σε /en/, το WebPageTest σας δείχνει και τα τρία βήματα και πόσο χρόνο πήρε το καθένα.

Για εργαλεία που σας βοηθούν να επικυρώσετε και να βελτιστοποιήσετε αυτά τα θεμελιώδη στοιχεία HTTP, το Wux Webtools προσφέρει αρκετά utilities που εκτελούνται εξ ολοκλήρου στον browser σας, συμπεριλαμβανομένων header analyzers και redirect checkers που σέβονται το απόρρητό σας επεξεργαζόμενα τα πάντα client-side.

Όταν τα headers λένε ψέματα

Τα δυσκολότερα προβλήματα HTTP είναι εκείνα όπου ο server στέλνει αντικρουόμενα headers. Ένα Cache-Control header λέει no-cache, αλλά ένα Expires header λέει ότι ο πόρος είναι έγκυρος για έναν χρόνο. Ένα Location header δείχνει σε σχετικό URL, αλλά το Content-Location header δείχνει αλλού. Ο browser πρέπει να μαντέψει ποιο να εμπιστευτεί, και διαφορετικοί browsers μαντεύουν διαφορετικά.

Όταν συμβαίνει αυτό, πρέπει να δείτε τα ακατέργαστα headers με τη σειρά που τα έστειλε ο server. Το curl -v το κάνει αυτό. Το ίδιο και το mitmproxy. Τα DevTools του browser μερικές φορές αναδιατάσσουν τα headers για λόγους αναγνωσιμότητας, κάτι που κρύβει το πρόβλημα.

Ένα άλλο συνηθισμένο ζήτημα: headers που προστίθενται από CDN ή load balancer, όχι από την εφαρμογή σας. Αν αποσφαλματώνετε ένα πρόβλημα caching, πρέπει να ξέρετε αν το Cache-Control header προήλθε από την εφαρμογή σας ή από το CDN. Το curl σας δείχνει το τελικό αποτέλεσμα, αλλά δεν σας λέει από πού προήλθε κάθε header. Για αυτό, πρέπει να παρακάμψετε το CDN (χτυπώντας απευθείας τον origin server) και να συγκρίνετε τα headers.

Το πρόβλημα του redirect loop

Τα redirect loops είναι το πιο συνηθισμένο πρόβλημα HTTP στην παραγωγή. Συμβαίνουν όταν δύο servers διαφωνούν για το πού πρέπει να δείχνει ένα URL: το CDN κάνει redirect προς το origin, το origin κάνει redirect πίσω στο CDN. Ή ο load balancer κάνει redirect από HTTP σε HTTPS, αλλά η εφαρμογή κάνει redirect από HTTPS πίσω σε HTTP επειδή δεν βλέπει το X-Forwarded-Proto header.

Για να το αποσφαλματώσετε, πρέπει να δείτε την πλήρη αλυσίδα redirect, συμπεριλαμβανομένου του Location header σε κάθε βήμα. Το curl -L -v το κάνει αυτό, αλλά σταματά μετά από 50 redirects για να αποτρέψει άπειρους βρόχους. Αν φτάνετε αυτό το όριο, έχετε redirect loop.

Η διόρθωση είναι συνήθως μια αλλαγή ρύθμισης: πείτε στην εφαρμογή να εμπιστεύεται το X-Forwarded-Proto header ή πείτε στο CDN να σταματήσει να κάνει redirect requests που είναι ήδη HTTPS. Αλλά δεν μπορείτε να το διορθώσετε μέχρι να δείτε τον βρόχο, και ο browser δεν θα σας δείξει περισσότερα από λίγα redirects πριν εγκαταλείψει.

Τι να ελέγξετε πρώτα

Όταν κάτι σπάει στην παραγωγή, ελέγξτε τα παρακάτω με τη σειρά:

1. Status code: Είναι αυτό που περιμένατε; Ένα 301 είναι permanent, ένα 302 είναι temporary, ένα 307 διατηρεί το HTTP method. Αν βλέπετε λάθος code, το πρόβλημα βρίσκεται στη ρύθμιση των redirects σας.

1. Location header: Δείχνει στο σωστό σημείο; Είναι απόλυτο URL ή σχετικό; Τα σχετικά URLs επιλύονται με βάση το τρέχον URL, κάτι που μπορεί να παράγει απροσδόκητα αποτελέσματα αν το base URL δεν είναι αυτό που νομίζετε.

1. Cache headers: Κάνει ο browser caching το redirect; Ένα 301 redirect γίνεται cached από προεπιλογή, πράγμα που σημαίνει ότι ένα λάθος ρυθμισμένο redirect μπορεί να χαλάσει το site σας για ώρες ακόμη και αφού το διορθώσετε. Ελέγξτε τα Cache-Control και Expires headers για να δείτε πόσο καιρό θα θυμάται ο browser το redirect.

1. CORS headers: Αν το request είναι cross-origin, στέλνει ο server το σωστό Access-Control-Allow-Origin header; Αν όχι, ο browser θα μπλοκάρει το request και θα δείτε ένα CORS error στην κονσόλα. Τα response headers του server είναι το μόνο σημείο όπου μπορεί να διορθωθεί αυτό — δεν μπορείτε να το παρακάμψετε στον browser.

1. Timing: Πόσο χρόνο πήρε το request; Αν είναι αργό, πρόκειται για network latency ή server processing; Τα DevTools του browser και το WebPageTest δείχνουν και τα δύο timing breakdowns που σας λένε πού πήγε ο χρόνος.

Για μια βαθύτερη ματιά στο πώς έχει αλλάξει η συμπεριφορά των browsers γύρω από το privacy και τα headers, δείτε τι άλλαξε για τα cookies το 2026 και τι να κάνετε γι’ αυτό, όπου καλύπτονται οι επιπτώσεις πρόσφατων ενημερώσεων browser στα headers και στη συναίνεση.

Βασικά συμπεράσματα

• Το curl -L -v σας δείχνει την πλήρη αλυσίδα redirect και όλα τα headers, χωρίς ερμηνεία από browser
• Η καρτέλα Network του browser σας δείχνει τι έκανε ο browser με το response, συμπεριλαμβανομένων αποφάσεων για caching και CORS
• Το mitmproxy σας δείχνει τι έστειλε ο browser, συμπεριλαμβανομένων των headers που προσθέτει αυτόματα
• Το WebPageTest σας δείχνει τι βιώνουν οι πραγματικοί χρήστες, συμπεριλαμβανομένων της συμπεριφοράς CDN και των περιφερειακών διαφορών
• Τα redirect loops και τα αντικρουόμενα headers είναι τα πιο συνηθισμένα προβλήματα παραγωγής, και είναι αόρατα χωρίς επιθεώρηση ακατέργαστου HTTP

FAQ

Q: Γιατί το curl δείχνει διαφορετικά headers από τον browser;

A: Επειδή ο browser προσθέτει αυτόματα headers (User-Agent, Accept, Cookie) και ακολουθεί τους δικούς του κανόνες για caching και CORS. Το curl στέλνει μόνο ό,τι του λέτε να στείλει. Για να δείτε τι στέλνει πραγματικά ο browser, χρησιμοποιήστε mitmproxy ή τα DevTools του browser.

Q: Πώς αποσφαλματώνω ένα redirect που συμβαίνει μόνο για ορισμένους χρήστες;

A: Ελέγξτε αν το redirect εξαρτάται από headers που στέλνει ο χρήστης: User-Agent, Accept-Language, Cookie ή IP address (μέσω X-Forwarded-For). Χρησιμοποιήστε curl για να στείλετε τα ίδια headers που έστειλε ο χρήστης ή χρησιμοποιήστε WebPageTest για να φορτώσετε τη σελίδα από την τοποθεσία του χρήστη.

Q: Ποια είναι η διαφορά μεταξύ redirects 301 και 302;

A: Ένα 301 είναι permanent και λέει στον browser να κάνει cache το redirect (μερικές φορές για πάντα). Ένα 302 είναι temporary και λέει στον browser να μην το κάνει cache. Αν δεν είστε σίγουροι ποιο να χρησιμοποιήσετε, χρησιμοποιήστε 302 — μπορείτε πάντα να το αλλάξετε σε 301 αργότερα.

Q: Γιατί το redirect μου λειτουργεί στο curl αλλά όχι στον browser;

A: Πιθανότατα επειδή ο browser κάνει cache ένα παλιό redirect ή επειδή ο browser μπλοκάρει το redirect λόγω κανόνων CORS ή mixed content. Ελέγξτε την κονσόλα των DevTools του browser για errors και ελέγξτε τα Cache-Control headers για να δείτε αν ο browser χρησιμοποιεί cached response.

Q: Πώς βλέπω τα headers που προσθέτει ένα CDN;

A: Χρησιμοποιήστε curl για να χτυπήσετε το CDN URL και μετά χρησιμοποιήστε ξανά curl για να χτυπήσετε απευθείας τον origin server (παρακάμπτοντας το CDN). Συγκρίνετε τα headers. Όσα εμφανίζονται μόνο στο πρώτο response προήλθαν από το CDN.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Όταν αναζητάτε προβλήματα ανακατεύθυνσης, το Redirect Checker ανιχνεύει ολόκληρη την αλυσίδα και εμφανίζει τους κωδικούς κατάστασης και τις κεφαλίδες σε κάθε βήμα.

<!-- tool-cta:end -->

Sources

• curl documentation — Επίσημη αναφορά για τις επιλογές γραμμής εντολών και τη συμπεριφορά του curl
• HTTPie documentation — Οδηγός για τη σύνταξη και τις δυνατότητες του httpie
• MDN Web Docs: HTTP redirections — Αναλυτική εξήγηση των HTTP redirect status codes και της συμπεριφοράς τους
• WebPageTest documentation — Πώς να ερμηνεύετε τα αποτελέσματα και τα headers του WebPageTest