优化更新中英文文档-排障指南
This commit is contained in:
Kris
Regular → Executable
+20
-8
@@ -1,9 +1,21 @@
|
||||
## Why the IP displayed in the admin panel and the actual IP of the Agent are not the same?
|
||||
Please check [Dashboard - Why the IP displayed in the admin panel and the actual IP of the Agent are not the same?](/en_US/guide/dashboardq.html#why-the-ip-displayed-in-the-admin-panel-and-the-actual-ip-of-the-agent-are-not-the-same)
|
||||
|
||||
## Error on one-click script installation
|
||||
### curl: Failed to connect to raw.githubusercontent.com...
|
||||
Please check if your server can connect to Github, try again, or check [Other ways to install Agent](/en_US/guide/agent.html#other-ways-to-install-agent)
|
||||
|
||||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
## The IP Displayed in the Admin Panel is Different from the Actual Agent IP?
|
||||
|
||||
Please refer to [Dashboard Related - Why is the IP Displayed in the Admin Panel Different from the Actual Agent IP?](/en_US/guide/dashboardq.html#why-is-the-ip-displayed-in-the-admin-panel-different-from-the-actual-agent-ip). This will not be repeated here.
|
||||
|
||||
## Errors During One-Click Script Installation
|
||||
|
||||
### curl: Failed to connect to raw.githubusercontent.com......
|
||||
|
||||
This mostly occurs on servers in mainland China. Currently, the one-click script fetches the installation script directly from Github. You may try several times, or [manually install the Agent](/en_US/guide/agent.html#other-ways-to-install-agent). Additionally, you can find third-party Github acceleration services or mirrors and set them in the one-click installation script.
|
||||
|
||||
### sudo: command not found
|
||||
Please install sudo first
|
||||
|
||||
Please manually install sudo first, for example, in Ubuntu:
|
||||
|
||||
```shell
|
||||
apt install sudo
|
||||
```
|
||||
Regular → Executable
+58
-36
@@ -1,54 +1,76 @@
|
||||
## Why the IP displayed in the admin panel and the actual IP of the Agent are not the same?
|
||||
First of all, explain how the IP displayed in the admin panel is gotten: the Agent will request the IP-API every once in a while, get the IP information and report it to the Dashboard, the IP-API currently used can be viewed here: [myip.go](https://github.com/nezhahq/agent/blob/main/pkg/monitor/myip.go)
|
||||
If you find that the IP displayed in the admin panel is not the same as the IP provided to you by the service provider, the biggest possibility is that the service provider gave you the **entry IP**, but the Agent tested out your **exit IP**. This problem may also occur in BGP servers and Leased line.
|
||||
::: tip
|
||||
To take a simple and very common example, the service provider to provide you a anti-DDoS server, in order to meet the goals of both DDoS protection and low network disruption rate, the IP provided to you may be the mapped anti-DDoS IP and not the real exit IP of your server
|
||||
:::
|
||||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
## Why is the IP Displayed in the Admin Panel Different from the Actual Agent IP?
|
||||
|
||||
First, let's explain how the IP displayed in the Admin panel is obtained: The Agent periodically requests IP-API to get IP information and reports it to the Dashboard. The currently used IP-API can be viewed here: [myip.go](https://github.com/nezhahq/agent/blob/main/pkg/monitor/myip.go).
|
||||
If you find that the IP displayed in the Admin panel is different from the IP provided by your service provider, it is most likely that the service provider has given you an **entry IP**, but the Agent is testing your **exit IP**. This issue can also occur with multi-line servers and IPLC private lines.
|
||||
|
||||
::: tip
|
||||
For example, a common scenario is that the service provider gives you a high-defense server. To meet both high defense and low network interruption rate goals, the IP provided may be a mapped high-defense IP rather than your server's real exit IP.
|
||||
:::
|
||||
|
||||
You can also test the exit IP on the Agent server by running the following commands:
|
||||
|
||||
You can also test the exit IP by running the following command in the Agent server:
|
||||
```shell
|
||||
curl https://ipapi.co/ip/
|
||||
curl ip.sb
|
||||
curl ip-api.com
|
||||
```
|
||||
```
|
||||
|
||||
## Forgot or Deleted Viewing Password
|
||||
|
||||
## Forgot your access password or deleted your access password
|
||||
Please view or edit the `/opt/nezha/dashboard/data/config.yaml` file.
|
||||
The password is located in the site-viewpassword item.
|
||||
The password is located under the `site-viewpassword` item.
|
||||
|
||||
## Dashboard Installation/Restart/Update Failure: iptables ......
|
||||
|
||||
First, try restarting Docker before proceeding:
|
||||
|
||||
## Dashboard install/restart/update failed: iptables ......
|
||||
First, try restarting docker and retrying again
|
||||
```shell
|
||||
systemctl status docker
|
||||
systemctl restart docker
|
||||
systemctl status docker
|
||||
```
|
||||
Restart and try to reinstall the Dashboard.
|
||||
If you still get iptables... etc. errors, then consider simply closing iptables or even removing it.
|
||||
This issue may also be kernel related, try replacing the official kernel as well.
|
||||
```
|
||||
|
||||
## Dashboard reboot failed: Invalid hostPort: nz_site_port etc.
|
||||
Usually this does not occur, if it does, you can modify the configuration through the installation script or edit `/opt/nezha/dashboard/docker-compose.yaml` directly.
|
||||
After restarting, try reinstalling the Dashboard.
|
||||
If iptables errors persist, consider disabling or removing iptables.
|
||||
This issue might also be related to the kernel, so switching to the official kernel can be another solution.
|
||||
|
||||
## Wrong Dashboard layout, CSS resources cannot be loaded
|
||||
If the Dashboard page has an incorrect layout, the usual reason is that the CSS file is missing or cannot be loaded.
|
||||
When such an issue occurs, you can first try `Reboot and update the Dashboard`.
|
||||
If the problem is not resolved after updating the Dashboard, then there may be an unsuitable configuration within your vhost configuration file. You can edit the vhost file or within the Aapanel to:
|
||||
1. Find the site you configured when installing Dashboard in `Website` and click `Conf` on the right side
|
||||
2. Select `Config` and delete the following from the config file:
|
||||
````nginx
|
||||
location ~ .*\.(js|css)?$
|
||||
{
|
||||
expires 12h;
|
||||
error_log /dev/null;
|
||||
access_log /dev/null;
|
||||
}
|
||||
````
|
||||
3. Save the configuration and clear the cache in the browser, NginX, and CDN, then refresh the page and it should return to normal.
|
||||
## Dashboard Restart Failure: Invalid hostPort: nz_site_port
|
||||
|
||||
If this issue occurs, you can modify the configuration via the installation script or directly edit the `/opt/nezha/dashboard/docker-compose.yaml` file.
|
||||
|
||||
## Dashboard Layout Error, CSS Resources Not Loading
|
||||
|
||||
If the Dashboard page layout is incorrect, it's usually due to missing or inaccessible CSS files.
|
||||
To resolve this, try `restarting and updating the Dashboard` first.
|
||||
If the problem persists after updating, the issue may be due to inappropriate configurations in your vhost file. You can edit the Nginx vhost file or use the aaPanel to:
|
||||
|
||||
1. Find the site configured during Dashboard installation in `Websites` and click `Settings` on the right.
|
||||
2. Select `Configuration File` and remove the following lines:
|
||||
|
||||
```nginx
|
||||
location ~ .*\.(js|css)?$
|
||||
{
|
||||
expires 12h;
|
||||
error_log /dev/null;
|
||||
access_log /dev/null;
|
||||
}
|
||||
```
|
||||
|
||||
3. Save the configuration, clear the browser, Nginx, and CDN caches, and refresh the page to see if it returns to normal.
|
||||
|
||||
## Dashboard Cannot Start: panic: Unable to find the configured DDNS provider...
|
||||
|
||||
## Dashboard cannot start：panic: 无法找到配置的DDNS提供者...
|
||||
The value entered for the DDNS provider is incorrect. Currently, only `webhook`, `cloudflare`, `tencentcloud`, and `dummy` are supported.
|
||||
|
||||
## Dashboard DDNS Update Crash: panic: interface conversion: interface {} is nil, not []interface {}
|
||||
|
||||
## Dashboard crashes when updating DDNS: panic: interface conversion: interface {} is nil, not []interface {}
|
||||
The DDNS `AccessID` or `AccessSecret` filled is incorrect.
|
||||
The entered DDNS `AccessID` or `AccessSecret` is incorrect.
|
||||
|
||||
## Network Monitoring Page Shows: server monitor history not found
|
||||
|
||||
This error indicates that no TCP-Ping or ICMP-Ping type monitoring has been set in the services page or monitoring data has not yet been generated.
|
||||
If it has been set up, wait for some time and then check again.
|
||||
+44
-27
@@ -1,41 +1,58 @@
|
||||
## Page refuses to connect or timeout after login callback
|
||||
1. Your server cannot connect to Github, consider trying several times or switching to Gitlab.
|
||||
2. You have configured the wrong callback URL, make sure your callback URL is correct and **port and protocol** are correct!
|
||||
3. An unknown error occurred in Dashboard, you can use the script to check the logs.
|
||||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
::: tip
|
||||
What is a protocol?
|
||||
In the browser, your domain name ending with `://` is the protocol, usually `http` and `https`. Since the Dashboard may be accessible by multiple protocols + domain + port combinations under normal deployment, please make sure to choose the most appropriate one as the callback.
|
||||
:::
|
||||
## Stuck Page/Connection Refused/Long Response Time After Login Callback
|
||||
|
||||
### How do I check if my callback URL is wrong?
|
||||
Please make sure the protocol+domain+port displayed by your browser before login and the protocol+domain+port you jump to after login are the same.
|
||||
Please make sure your path is `/oauth2/callback`, **all lowercase**.
|
||||
These issues can manifest in various ways, but ultimately the browser cannot display correctly after login.
|
||||
|
||||
1. Your server cannot connect to Github/Gitee, which is most common when configuring Github on servers in mainland China. You may try several times or switch to Cloudflare Access.
|
||||
2. You have configured the callback address incorrectly. Ensure that your callback address is correct and that both the **port and protocol** are accurate!
|
||||
3. An unknown error occurred on the Dashboard. You can use a script to check the logs.
|
||||
|
||||
::: tip
|
||||
What is a protocol?
|
||||
In the browser, the string that ends your domain with `://` is the protocol, usually `http` or `https`. Since there may be multiple protocol+domain+port combinations available for accessing the Dashboard in a normal deployment, make sure to choose the most appropriate one as the callback.
|
||||
:::
|
||||
|
||||
### How to Check if My Callback Address is Wrong?
|
||||
|
||||
Ensure that the protocol+domain+port displayed in the browser before login and after the callback are consistent.
|
||||
Ensure that your path is `/oauth2/callback`, **all in lowercase**.
|
||||
|
||||
## Errors After Logging into the Admin Panel
|
||||
|
||||
## Dashboard errors after login
|
||||
### http: named cookie not present
|
||||
1. Clear your browser cookies and log in again, or change your browser.
|
||||
2. Check the callback address to ensure that your callback address is correct and that both **the port and protocol** are correct! The address from which the request is initiated needs to be in the same domain as the callback address, and the port, protocol, and domain name (or IP) all need to be consistent.
|
||||
|
||||
1. Clear cookies and log in again, or try a different browser.
|
||||
2. Check the callback address to ensure it is correct and that both the **port and protocol** are accurate! The address initiating the request must be in the same domain as the callback address, with the port, protocol, and domain (or IP) all matching.
|
||||
|
||||
### lookup xxx
|
||||
DNS resolution failure, in most cases, is due to iptables-related configuration changes.
|
||||
It is recommended to restart docker first, `sudo systemctl restart docker`, and then use the script to restart the Dashboard.
|
||||
If the lookup error still occurs, it is recommended to check whether there are other tools to control iptables, such as Aapanel Firewall.
|
||||
This problem may also be related to the kernel, please try to change the official kernel.
|
||||
|
||||
### The authorization method is invalid, or the login callback URL is invalid, expired, or has been revoked
|
||||
Suggest changing the authentication method to Github/Gitlab.
|
||||
The container DNS resolution failed, usually due to modified iptables configurations.
|
||||
It is recommended to restart Docker first, `sudo systemctl restart docker`, then restart the Dashboard using the script.
|
||||
If the lookup error persists, check if there are other tools controlling iptables, such as firewall.
|
||||
This issue might also be related to the kernel, so try switching to the official kernel.
|
||||
|
||||
### Invalid authorization method, or the login callback address is invalid, expired, or has been revoked
|
||||
|
||||
This issue appears only when using Gitee login, and the reason is unclear. Switching to GitHub is recommended.
|
||||
|
||||
### oauth2: server response missing access_token
|
||||
It may be caused by a number of factors, the most likely is a network problem, we suggest to check the network and retry.
|
||||
If you can't solve it, we suggest changing the authentication method to Github/Gitlab.
|
||||
|
||||
### This user is not the administrator or cannot login
|
||||
You have logged into the wrong account or configured the wrong username, note that **username is not email**, you can use a script to modify it.
|
||||
This could be caused by various factors, most likely a network issue. Check your network and try again.
|
||||
If unresolved, switching to Github or another method is recommended.
|
||||
|
||||
### The user is not an admin of this site and cannot log in
|
||||
|
||||
You logged in with the wrong account or configured the wrong username. Note that **the username is not an email**, and you can use a script to modify it.
|
||||
For Cloudflare Access users, note that your username is not an email but a User ID.
|
||||
|
||||
### dial tcp xxx:443 i/o timeout
|
||||
If the server has network problems, you can restart docker first, `sudo systemctl restart docker`, and then use the script to restart the Dashboard.
|
||||
You can also change to another OAuth method if necessary.
|
||||
|
||||
This is a network issue. Try restarting Docker first, `sudo systemctl restart docker`, then restart the Dashboard using the script.
|
||||
If you are configuring Github login on a server in mainland China, switching to Cloudflare Access is recommended to avoid network interference.
|
||||
|
||||
### net/http: TLS handshake timeout
|
||||
Same as above.
|
||||
|
||||
Same as above.
|
||||
Reference in New Issue
Block a user