Naprawa uszkodzonych obrazów w CloudPanel (Nginx)

Uszkodzone przesłane obrazy na stronie testowej CloudPanel w podkatalogu (na przykład domain.com/staging/) prawie zawsze mają jedną przyczynę: domyślna konfiguracja Nginx w CloudPanel zawiera reguły przepisywania (rewrite) przeznaczone dla WordPress Multisite, które usuwają prefiks /staging/ z żądań i szukają nowych obrazów w folderze witryny produkcyjnej. Rozwiązaniem jest szybka zmiana dwóch reguł przepisywania w pliku Vhost Twojej witryny, a cała operacja zajmuje około dwóch minut.

Dlaczego nowo przesłane obrazy są uszkodzone na stronie testowej CloudPanel?

Gdy tworzysz stronę testową w podkatalogu, jej adresy URL wyglądają jak domain.com/staging/. CloudPanel dostarcza domyślną konfigurację Nginx z regułami przepisywania przeznaczonymi dla WordPress Multisite. Reguły te przechwytują żądania do folderu /staging/, usuwają prefiks i rozwiązują ścieżkę względem katalogu Twojej witryny produkcyjnej. Nowo przesłane obrazy istnieją tylko w folderze testowym, więc Nginx ich nie znajduje i zwraca uszkodzony link lub błąd 404 — mimo że samo przesyłanie się powiodło.

Przyczyna leży wyłącznie w regułach przepisywania Nginx. Z WordPressem, biblioteką mediów ani przesłanymi plikami nie ma żadnego problemu.

Jak naprawić uszkodzone obrazy w CloudPanel i Nginx?

Dodaj wyjątek do konfiguracji Nginx swojej witryny, aby reguły przepisywania Multisite pomijały folder testowy. Całą zmianę wprowadza się w edytorze Vhost w CloudPanel i zajmuje ona około dwóch minut.

Krok 1: Otwórz edytor Vhost swojej witryny

  1. Zaloguj się do panelu CloudPanel.
  2. Kliknij witrynę, na której przesyłanie nie działa.
  3. Otwórz kartę Vhost w górnym menu.

Krok 2: Zastąp reguły przepisywania Multisite

Przewiń do sekcji plików statycznych. Zaczyna się ona od wiersza podobnego do:

location ~* ^.+.(css|js|jpg|jpeg|gif|png...)$

Wewnątrz tego bloku usuń te dwa domyślne wiersze przepisywania:

  # WordPress Multisite Subdirectory
  rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 break;
  rewrite ^/[_0-9a-zA-Z-]+(/.*.php)$ $1 break;

W ich miejsce wklej te zaktualizowane wiersze:

  # WordPress Multisite Subdirectory (Excluding WP Staging)
  rewrite ^/(?!staging)[_0-9a-zA-Z-]+(/wp-.*) $1 break;
  rewrite ^/(?!staging)[_0-9a-zA-Z-]+(/.*.php)$ $1 break;

Negatywne wyprzedzenie (?!staging) nakazuje Nginx zastosować przepisywanie Multisite do każdego folderu z wyjątkiem staging, dzięki czemu żądania dotyczące obrazów testowych są rozwiązywane poprawnie.

Krok 3: Zapisz i przeładuj Nginx

Kliknij przycisk Save w prawym dolnym rogu. CloudPanel automatycznie przeładuje Nginx, a nowo przesłane obrazy testowe zaczną działać natychmiast.

Co, jeśli mój folder testowy nie nazywa się „staging"?

Jeśli Twoja strona testowa znajduje się w folderze o innej nazwie — dev, test lub dowolnej innej — zmień słowo staging w obu wierszach przepisywania tak, aby pasowało do rzeczywistej nazwy folderu. Reszta reguły pozostaje bez zmian.

Czy ta poprawka zostanie nadpisana?

Tak, jeśli klikniesz przycisk Reset to Default na karcie Vhost. Ten przycisk przywraca standardową konfigurację CloudPanel i usuwa wyjątek, więc trzeba będzie ponownie zastosować te dwa wiersze. Zwykłe aktualizacje CloudPanel i WordPressa nie naruszają zapisanego pliku Vhost.

Najczęściej zadawane pytania

Czy ta zmiana wpływa na moją witrynę produkcyjną?

Nie. Wyjątek (?!staging) zmienia tylko sposób, w jaki Nginx kieruje żądaniami w obrębie podkatalogu testowego. Żądania do witryny produkcyjnej nadal pasują do oryginalnej reguły Multisite, bez zmian.

Dlaczego uszkodzone są tylko nowo przesłane obrazy, a nie starsze?

Domyślne reguły wysyłają żądania testowe do folderu produkcyjnego. Obrazy przesłane po utworzeniu strony testowej istnieją tylko w folderze przesyłania strony testowej, więc Nginx nie znajduje ich tam i zwraca błąd 404.

Używam Apache, a nie Nginx. Czy to mnie dotyczy?

Nie. CloudPanel obsługuje witryny za pomocą Nginx, więc ta poprawka jest specyficzna dla Nginx. Pokazana tutaj składnia przepisywania nie działa w pliku .htaccess Apache.

Czy po zapisaniu muszę coś ponownie uruchamiać?

Nie. CloudPanel przeładuje Nginx za Ciebie po kliknięciu Save. Poprawka zaczyna działać, gdy tylko zakończy się przeładowanie.

Powiązane artykuły

Updated on 8 czerwca, 2026

Alaa Salama

Autor: Alaa Salama

Od ponad dekady pracuję w obszarze wsparcia technicznego, ponieważ naprawdę cenię ludzki wymiar technologii. Niezależnie od tego, czy rozwiązuję złożony problem związany z WordPressem, czy tworzę niestandardowe wtyczki i fragmenty kodu usprawniające przepływy pracy, moim celem jest zawsze ograniczanie tarć i pomaganie ludziom w mądrzejszej pracy. Dla mnie nie ma nic bardziej satysfakcjonującego niż widok rozwiązania, które stworzyłem i które poprawia komuś dzień.

Kiedy jestem offline, zazwyczaj i tak nadal zaglądam „pod maskę” czegoś. Pasjonuję się optymalizacją serwerów i elektroniką DIY, a wolny czas często poświęcam projektom smart home i naprawom sprzętu. Szczególnie cenię czas spędzany w moim domowym warsztacie z dziećmi. Wspólnie zajmujemy się wszystkim, od domowych napraw po kreatywne projekty, rozwijając zamiłowanie do budowania rzeczy, które przetrwają próbę czasu.