من الطلب إلى الاستجابة: أين تنتهي مسؤولية التطبيق وأين يبدأ السيرفر

Configuration في الويب: الفرق بين إعدادات التطبيق، Nginx، و .htaccess

كثير من المشاكل اللي تصير في مشاريع الويب ما تكون بسبب الكود نفسه، بل بسبب سوء فهم طبقة الإعدادات. تكتب كود ممتاز… لكن السيرفر يتصرف بشكل مختلف عن المتوقع. ترفع مشروعك من بيئة إلى أخرى… فجأة الروابط ما تشتغل. تضيف حماية… لكنها ما تطبق.

السبب غالبًا إنك ما تفصل بين:

• إعدادات التطبيق (Application Config)
• إعدادات السيرفر (Nginx أو Apache)
• إعدادات المسار (مثل .htaccess)

---

أولاً: إعدادات التطبيق (Application Configuration)

هذه الطبقة تخص الكود نفسه. في Laravel مثلًا تكون داخل مجلد config/ أو ملف .env.

أمثلة:

• DB_HOST
• APP_ENV
• CACHE_DRIVER
• QUEUE_CONNECTION

هذه الإعدادات:

• لا تتحكم في كيفية استقبال HTTP Request
• لا تتحكم في SSL
• لا تتحكم في إعادة التوجيه 301/302

هي فقط تخبر التطبيق كيف يعمل داخليًا.

خطأ شائع: محاولة حل مشكلة Rewrite أو 404 من داخل التطبيق، بينما المشكلة في طبقة السيرفر.

---

ثانيًا: Nginx Configuration

Nginx هو Reverse Proxy و Web Server. هو أول شيء يستقبل الطلب قبل ما يصل إلى التطبيق.

ملف الإعداد عادة يكون داخل:

/etc/nginx/nginx.conf
/etc/nginx/sites-available/example.com

مثال إعداد بسيط لتطبيق Laravel

server {
    listen 80;
    server_name example.com;

    root /var/www/project/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

وش يسوي هذا الإعداد فعليًا؟

• root يحدد نقطة الدخول (لازم تكون public في Laravel)
• try_files يعيد توجيه أي طلب غير موجود إلى index.php
• location ~ \.php$ يمرر ملفات PHP إلى PHP-FPM

لو نسيت try_files:

• الروابط الديناميكية تتكسر
• تحصل 404 رغم أن التطبيق سليم

Nginx لا يستخدم .htaccess. كل شيء مركزي داخل ملفات الإعداد. وهذا يعطي أداء أعلى لأن الإعداد لا يُقرأ في كل طلب.

---

ثالثًا: .htaccess في Apache

.htaccess ملف إعداد خاص بـ Apache. يُقرأ في كل مجلد عند كل طلب.

مثال شائع لإعادة توجيه الطلبات إلى index.php:

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

وش الفرق عن Nginx؟

• Apache يسمح بإعدادات لكل مجلد عبر .htaccess
• Nginx يرفض هذا المفهوم ويستخدم إعداد مركزي فقط
• .htaccess أبطأ لأنه يُقرأ مع كل طلب

لهذا في المشاريع عالية الأداء غالبًا يُفضل Nginx.

---

إعادة التوجيه (Redirects) — أين تضعها؟

مثال تحويل HTTP إلى HTTPS:

في Nginx

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

في .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

المبدأ:

• إعدادات البروتوكول والـ SSL تكون في السيرفر
• لا تضع منطق HTTP داخل التطبيق إلا إذا كان له علاقة بالـ Business Logic

---

أخطاء شائعة في إعدادات السيرفر

• توجيه root إلى مجلد المشروع بدل public
• نسيان تمرير QUERY_STRING
• تعطيل PHP-FPM بدون ملاحظة
• تعارض بين Cloudflare و إعدادات SSL المحلية
• إضافة rewrite داخل التطبيق بدل السيرفر

---

الفرق المفاهيمي بين الطبقات

يمكن تقسيم المسؤوليات بهذا الشكل:

• Web Server (Nginx/Apache): استقبال الطلب، SSL، Static Files، Proxy
• PHP-FPM: تنفيذ ملفات PHP
• Application: منطق النظام، قواعد العمل، التعامل مع البيانات

كل طبقة يجب أن تبقى ضمن مسؤوليتها. خلط الطبقات يؤدي إلى تعقيد يصعب تتبعه لاحقًا.

---

متى تختار Nginx؟ ومتى Apache؟

• لو تحتاج أداء أعلى وتحكم مركزي واضح → Nginx
• لو تحتاج مرونة إعداد لكل مجلد بدون صلاحية root → Apache
• لو تعمل على استضافة مشتركة → غالبًا Apache مع .htaccess
• لو تعمل على VPS خاص بك → Nginx خيار عملي أكثر

---

خلاصة عملية

أي مشكلة Web غالبًا تكون في واحدة من ثلاث طبقات:

• Config التطبيق
• Config السيرفر
• DNS / SSL

إذا فهمت حدود كل طبقة، تقل الأخطاء، وتصير قادر تتبع المشكلة بسرعة بدل التخمين.