Điểm:0

Yêu cầu ủy quyền 401 trên Apache 2.2 khi cuộn tròn dẫn đến lỗi 500 véc ni

lá cờ cn
[centos@staging03 ~]$ sudo netstat -plnt
Kết nối Internet đang hoạt động (chỉ máy chủ)
Proto Recv-Q Send-Q Địa chỉ cục bộ Địa chỉ nước ngoài Trạng thái PID/Tên chương trình   
tcp 0 0 127.0.0.1:80 0.0.0.0:* NGHE 3600/httpd          
tcp 0 0 127.0.0.2:80 0.0.0.0:* NGHE 1574/véc ni       
tcp 0 0 172.31.22.60:80 0.0.0.0:* NGHE 1539/nginx          
tcp 0 0 0.0.0.0:22 0.0.0.0:* NGHE 1251/sshd           
tcp 0 0 127.0.0.1:25 0.0.0.0:* NGHE 1501/chính         
tcp 0 0 127.0.0.1:443 0.0.0.0:* NGHE 3600/httpd          
tcp 0 0 127.0.0.1:6082 0.0.0.0:* NGHE 1573/varnishd       
tcp 0 0 127.0.0.1:9000 0.0.0.0:* NGHE 3468/php-fpm        
tcp 0 0 127.0.0.1:11211 0.0.0.0:* NGHE 1229/memcached      
tcp 0 0 127.0.0.1:6379 0.0.0.0:* NGHE 1061/redis-server 1 
tcp 0 0 :::22 :::* NGHE 1251/sshd           
tcp 0 0 :::3306 :::* NGHE 1383/mysqld 

Tôi đã kiểm tra để điều tra vấn đề với máy chủ của mình và khi tôi thực hiện:

cuộn tròn 127.0.0.1:80

Tôi đã nhận:

Authorization Required

Máy chủ này không thể xác minh rằng bạn được phép truy cập tài liệu yêu cầu. Hoặc là bạn đã cung cấp sai thông tin đăng nhập (ví dụ: mật khẩu không hợp lệ) hoặc thông tin đăng nhập của bạn trình duyệt không hiểu cách cung cấp các thông tin xác thực được yêu cầu.


Trên một máy chủ khác nơi mọi thứ đang hoạt động, tôi nhận được phản hồi trống. Vì vậy, tôi nghĩ đây là lý do tại sao tôi nhận được lỗi 500 véc ni từ Apache.

Trong nhật ký Apache, tôi không thực sự nhận được gì khi cuộn tròn, nhưng trước đó tôi đã nhận được:

[Thứ 4 ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] SIGTERM bị bắt, ngừng hoạt động
[Thứ Tư ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] đã bật cơ chế suEXEC (trình bao bọc: /usr/sbin/suexec)
[Thứ Tư ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] Thông báo: tạo bí mật để xác thực thông báo ...
[Thứ tư ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] Thông báo: xong
[Thứ Tư ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] FastCGI: đã khởi chạy trình quản lý quy trình (pid 3602)
[Thứ Tư ngày 27 tháng 10 17:02:25 năm 2021] [thông báo] Apache/2.2.15 (Unix) DAV/2 mod_fastcgi/2.4.6 đã định cấu hình -- tiếp tục hoạt động bình thường

Vì vậy, có vẻ như FastCGI được định cấu hình đúng cách và sự cố tôi gặp phải từ Apache là sự cố xác thực khá kỳ lạ. Tôi có thể làm gì khác để xác định vấn đề là gì không?

Varnish đưa ra những điều sau đây:

   12 TxHeader b X-Véc ni: 1537309960
   12 Giao thức Rx b HTTP/1.1
   12 RxTrạng thái b 500
   12 RxResponse b Lỗi Máy chủ Nội bộ
   12 RxHeader b Ngày: Thứ tư, ngày 27 tháng 10 năm 2021 21:14:18 GMT
   12 Máy chủ RxHeader b: Apache/2.2.15 (CentOS)
   12 RxHeader b Hết hạn: Thứ tư, ngày 11 tháng 1 năm 1984 05:00:00 GMT
   12 RxHeader b Kiểm soát bộ đệm: không có bộ đệm, phải xác thực lại, max-age=0

Tuy nhiên, tôi không có cách nào để kiểm tra Lỗi 500 Máy chủ Nội bộ là gì, vì nhật ký lỗi cho php dường như trống.

Điểm:1
lá cờ in

TODO Apache

  1. Tăng cấp độ nhật ký trong Apache
  2. Kiểm tra sự khác biệt giữa lệnh gọi HTTP tới tệp tĩnh trong Apache và lệnh gọi tới PHP
  3. Theo dõi nhật ký lỗi của Apache với mức độ chi tiết tăng lên

Mục tiêu là lấy HTTP 200 ra khỏi Apache bằng cách chạy cuộn tròn http://127.0.0.1, trên trang chủ hoặc một số tệp tĩnh.

sơn bóng TODO

  1. Nâng cấp Varnish lên phiên bản được hỗ trợ và bảo trì
  2. Thêm đầu dò phụ trợ trong VCL của bạn
  3. Theo dõi tình trạng phụ trợ thông qua VSL

Dựa trên đầu ra VSL mà bạn đã chia sẻ, tôi có thể thấy rằng bạn đang chạy phiên bản cũ của Varnish. Nhìn thấy https://www.varnish-software.com/developers/tutorials/installing-varnish-centos/ để tìm hiểu làm thế nào bạn có thể cài đặt Véc ni 6.0 LTS trên CentOS.

Bạn không chỉ có một phiên bản Varnish an toàn, mà các công cụ VSL của bạn (như dầu bóng) cũng vượt trội hơn nhiều so với phiên bản bạn đang chạy.

Đây là một ví dụ về chương trình phụ trợ có đầu dò sức khỏe:

phụ trợ mặc định {
    .host = "127.0.0.1";
    .port = "8080";
    .thăm dò = {
        .url = "/";
        .thời gian chờ = 2s;
        .khoảng cách = 5s;
        .cửa sổ = 10;
        .ngưỡng = 5;
   }
}

Điều này sẽ cho phép bạn liên tục theo dõi tình trạng của phần phụ trợ của mình. Bạn có thể làm điều này với lệnh sau:

Sudo varnishlog -g raw -i Backend_health

Đầu ra sẽ giúp bạn hiểu hoạt động của phần phụ trợ và mã trạng thái HTTP nào mà phần phụ trợ trả về Varnish.

Kết hợp điều này với nhiệm vụ của bạn để lấy mã trạng thái HTTP 200 từ Apache và bạn sẽ tiến khá gần đến giải pháp cuối cùng.

haher avatar
lá cờ cn
Không phải lỗi 500 có thể là do php và chúng tôi cũng có thể ghi lại các lỗi php không?
Thijs Feryn avatar
lá cờ in
Điều đó có thể sẽ xuất hiện trong nhật ký lỗi của máy chủ web nếu tất cả được định cấu hình đúng. Đảm bảo rằng báo cáo lỗi thời gian chạy PHP của bạn được bật và các lỗi được ghi lại đúng cách.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.