Petunjuk dan konteks yang berlaku
HTTP 511 berarti klien harus melakukan autentikasi sebelum mendapatkan akses jaringan. Kode ini biasanya berasal dari intercepting proxy atau captive portal, bukan dari target origin. Seorang backend engineer harus memastikan apakah permintaan telah mencapai origin alih-alih salah mendiagnosis masalah jaringan masuk sebagai kegagalan autentikasi aplikasi.
Hal yang dievaluasi oleh pewawancara
- Menjelaskan bahwa intercepting proxy menghasilkan 511.
- Memisahkan autentikasi jaringan, autentikasi origin, dan autentikasi proxy.
- Mengetahui bahwa respons 511 tidak boleh di-cache dan tidak boleh menyamarkan UI login sebagai halaman origin.
- Merancang penanganan yang aman untuk klien non-browser alih-alih mengikuti pengalihan secara membabi buta.
- Membuktikan lokasi kegagalan dengan log proxy, DNS, TLS, dan permintaan.
Pertanyaan klarifikasi sebelum menjawab
- Apakah pemanggil merupakan browser, aplikasi seluler, atau klien layanan headless? Kemampuan mereka untuk menangani portal berbeda-beda.
- Apakah 511 berasal dari proxy perusahaan, portal Wi-Fi publik, atau gateway aplikasi? Pengirim menentukan batasannya.
- Apakah permintaannya berupa HTTP atau HTTPS? TLS yang diintersepsi mungkin gagal dengan kesalahan sertifikat terlebih dahulu.
- Bisakah klien membuka sumber daya login dan mempertahankan sesi jaringan? Jika tidak, klien hanya dapat meminta pengguna untuk berpindah jaringan.
- Apakah kita sedang mendiagnosis gangguan proxy intermiten atau mengintegrasikan captive portal? Integrasi juga memerlukan protokol sesi.
Kerangka jawaban 30 detik
"511 adalah autentikasi masuk jaringan, bukan login pengguna origin. RFC 6585 merekomendasikan agar intercepting proxy yang menghasilkannya, menyediakan tautan sumber daya login, dan menghindari caching respons tersebut. Saya mencatat IP respons akhir, penanda proxy, dan status TLS untuk memverifikasi apakah origin melihat permintaan tersebut; browser dapat memandu pengguna ke portal, sedangkan klien layanan tidak boleh memperlakukan 511 sebagai 401 atau mengirimkan kredensial bisnis ke perantara yang tidak dikenal. Kemudian saya membedakan autentikasi origin 401 dari autentikasi proxy 407 dan memilih perbaikan jaringan, proxy, atau klien."
Pembahasan mendalam langkah demi langkah
Langkah 1: Temukan penghasil respons. Bandingkan alamat DNS target, peer TCP, Via atau header proxy, log akses origin, dan pelacakan gateway. Jika origin tidak memiliki permintaan yang cocok, kemungkinan besar perantara yang menghasilkan 511.
Langkah 2: Interpretasikan semantik protokol. 511 memberi tahu klien bahwa jaringan belum terbuka. Representasinya mungkin menautkan ke kredensial atau ketentuan, tetapi tidak boleh menampilkan formulir portal sebagai konten dari origin yang diminta semula.
Langkah 3: Pisahkan kode yang berdekatan. 401 adalah origin yang meminta autentikasi sumber daya dan umumnya menggunakan WWW-Authenticate; 407 adalah forward proxy yang meminta kredensial proxy dan menggunakan Proxy-Authenticate; 511 berkaitan dengan akses ke jaringan itu sendiri.
Langkah 4: Tentukan perilaku klien. Browser dapat menampilkan prompt login jaringan. Klien API harus melaporkan status jaringan-tidak-tersedia yang jelas, mencatat URL portal, dan menunggu pengguna atau administrator jaringan. Klien tidak boleh mengirimkan kredensial bisnis secara diam-diam ke perantara yang tidak dikenal.
Langkah 5: Tangani HTTPS dan caching. Mengintersepsi HTTPS dapat menghasilkan ketidakcocokan sertifikat; menonaktifkan verifikasi sertifikat bukanlah solusi. Respons 511 tidak boleh di-cache, atau gerbang jaringan sementara dapat bocor ke klien yang telah diautentikasi.
Langkah 6: Bangun bukti diagnostik. Pada jaringan yang sama, bandingkan probe HTTP dengan permintaan bisnis dan catat waktu, proxy, DNS, rantai sertifikat, status, dan log origin. Microsoft Learn juga mencantumkan 511 sebagai kemungkinan hasil dalam pemeriksaan konektivitas proxy.
Langkah 7: Nyatakan alternatif dan batasan. API perusahaan harus memperbaiki allowlist proxy, egress akun layanan, atau autentikasi jaringan daripada menerapkan login 511 di dalam API bisnis. Jaringan publik membutuhkan alur portal yang dapat diselesaikan pengguna dan pesan waktu habis.
Contoh jawaban
"Pertama-tama saya mengklasifikasikan 511 sebagai respons masuk jaringan: intercepting proxy menyatakan bahwa klien harus mengautentikasi jaringan, dan origin biasanya tidak pernah melihat permintaan tersebut. Ini berbeda dari autentikasi sumber daya 401 dan autentikasi kredensial proxy 407. Saya membandingkan DNS, peer TCP, header proxy, sertifikat TLS, log origin, dan pelacakan untuk menemukan penghasilnya. Browser dapat membuka tautan portal; klien API headless tidak boleh mencobanya kembali sebagai 401 atau mengirim kredensial bisnis ke proxy yang tidak dikenal. Respons tidak boleh di-cache, dan kesalahan sertifikat yang disebabkan oleh intersepsi HTTPS tidak dapat diselesaikan dengan melewati verifikasi."
Kesalahan umum
- Memperlakukan 511 sebagai 401 → menyegarkan token origin tidak dapat membuat permintaan keluar dari jaringan → temukan penghasil respons terlebih dahulu.
- Memperlakukan 511 sebagai 407 → mengonfigurasi kredensial proxy sambil mengabaikan sesi portal → pisahkan entri jaringan dari autentikasi forward proxy.
- Mengikuti tautan login yang tidak dikenal secara otomatis → kredensial dapat bocor ke portal phishing → tampilkan sumber asal dan biarkan pengguna mengonfirmasi.
- Menyimpan 511 dalam cache → klien yang terautentikasi terus melihat gerbang lama → larang caching dan periksa perantara.
- Menonaktifkan verifikasi TLS → risiko man-in-the-middle meningkat → perbaiki autentikasi jaringan atau konfigurasi kepercayaan.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Origin tidak memiliki permintaan, tetapi klien menerima 511. Apa selanjutnya?
Tangkap peer koneksi, rantai proxy, dan header respons, lalu lakukan kueri pada probe HTTP yang diketahui pada jaringan yang sama. Jika beberapa tujuan menampilkan respons yang sama, periksa egress proxy atau captive portal.
Pertanyaan lanjutan 2: Mengapa tidak mengembalikan HTML portal sebagai JSON API?
Klien non-browser dapat mengurai HTML sebagai respons bisnis dan gagal; lebih buruk lagi, mereka dapat salah mengira konten portal sebagai konten origin. Gunakan kelas kesalahan eksplisit dan titik masuk login yang dapat diverifikasi.
Pertanyaan lanjutan 3: Mengapa permintaan HTTPS sering menampilkan kesalahan sertifikat alih-alih 511?
Ketika perantara tidak dapat mengganti sertifikat TLS origin dengan aman, handshake gagal sebelum status HTTP ada. Klien tidak dapat berasumsi bahwa setiap gerbang jaringan dapat dinyatakan sebagai 511.
Pertanyaan lanjutan 4: Bisakah klien mencoba kembali setelah menerima 511?
Coba kembali permintaan awal hanya setelah autentikasi jaringan dan pembentukan sesi dikonfirmasi. Percobaan ulang yang membabi buta memperbesar lalu lintas, dan operasi penulisan bisnis tidak boleh diputar ulang secara otomatis.
Pertanyaan lanjutan 5: Bagaimana Anda membedakan false positive proxy dari portal asli?
Bandingkan jaringan, domain, pengaturan proxy, log origin, dan sesi portal. Jika hanya satu jalur egress perusahaan yang mengembalikan 511, periksa kebijakan dan allowlist-nya terlebih dahulu.
Pertanyaan lanjutan 6: Bagaimana jika aplikasi seluler tidak memiliki UI login browser?
Kembalikan status jaringan-tidak-tersedia yang dapat dibaca dan arahkan pengguna ke halaman login jaringan sistem atau jaringan lain. Sambungkan kembali setelah autentikasi; jangan mengirimkan kredensial jaringan yang tidak dikenal secara diam-diam di halaman yang disematkan.
Pertanyaan lanjutan 7: Mengapa 511 tidak boleh di-cache?
Autentikasi jaringan bersifat sementara dan spesifik untuk klien. Caching dapat membuat klien lain melihat gerbang yang sama dan dapat membuat pengguna yang sudah diotorisasi tetap terblokir.