# 安装inotifywait 





inotifywait 工具通常随着 inotify 包的一部分提供。这意味着您需要安装 inotify 包，以便在系统上使用 inotifywait。

如果您使用的是基于 Debian 或 Ubuntu 的 Linux 发行版，您可以使用以下命令安装 inotify 包：

```bash
sudo apt-get update
sudo apt-get install inotify-tools
```

如果您使用的是基于 CentOS、RHEL 或 Fedora 的发行版，您可以使用以下命令安装 inotify 包：

```bash
sudo yum install inotify-tools
```

安装完 inotify 包后，inotifywait 工具就会包含在其中。

# 脚本set_gradio_permissions.sh

使用 inotify 工具监视 `/tmp/gradio` 目录，并在其中创建新文件夹时自动应用所需的权限。编写一个简单的脚本来实现这一目标。

以下是一个使用 inotifywait 和 bash 脚本的示例。


`vim /root/set_gradio_permissions.sh`
```bash
#!/bin/bash
# 监视/tmp/gradio目录中的新文件夹创建
inotifywait -m -e create --format '%w%f' /tmp/gradio | while read new_dir
do
    # 设置新文件夹的权限为777
    chmod 777 "$new_dir"
done
```

将此脚本保存为一个文件（例如 `set_gradio_permissions.sh`），然后通过以下命令使其可执行：

```bash
chmod +x set_gradio_permissions.sh
```

然后，您可以在后台运行此脚本，以便在 `/tmp/gradio` 中创建新文件夹时自动设置权限：

```bash
./set_gradio_permissions.sh &
```

现在，每当在 `/tmp/gradio` 中创建新文件夹时，都会自动将其权限设置为 777。

# 开机自启动服务

要将脚本设置为一直处于服务的状态，并在系统启动时自动启动，您可以使用系统的服务管理工具（如 systemd）来管理您的脚本。下面是一个简单的示例来创建一个 systemd 服务：

首先，创建一个服务文件 `vim /etc/systemd/system/gradio_permissions.service`，内容如下：

```plaintext
[Unit]
Description=Set permissions for /tmp/gradio
After=network.target
[Service]
Type=simple
ExecStart=/root/set_gradio_permissions.sh
Restart=always
[Install]
WantedBy=multi-user.target
```

请确保将 `/root/set_gradio_permissions.sh` 替换为您实际的脚本路径。

接下来，重新加载 systemd 配置并启动服务：

```bash
sudo systemctl daemon-reload
sudo systemctl start gradio_permissions
```

`sudo systemctl daemon-reload` 是一个 systemd 命令，用于重新加载 systemd 管理的所有单元（unit）的配置文件。这包括服务、套接字、挂载点等。当您修改了任何 systemd 单元的配置文件后，需要运行 `daemon-reload` 命令，以便 systemd 重新加载配置文件，使新的配置生效。


要在系统启动时自动启动服务，您可以使用 `enable` 命令：

```bash
sudo systemctl enable gradio_permissions
```

现在，您的脚本将作为一个服务在系统启动时自动运行，并且会持续监视 `/tmp/gradio` 目录以设置新文件夹的权限。


![在这里插入图片描述](/static/img/images/03638.png)

# 服务脚本含义

这是一个 systemd 服务单元文件的示例，用于描述一个名为 `gradio_permissions` 的服务。现在我们来逐行解释每个部分的含义：

1. `[Unit]`

   - 这一部分声明了服务单元的基本信息。

   - `Description=Set permissions for /tmp/gradio`：描述了这个服务的简要说明，说明了服务的功能。

   - `After=network.target`：指定了服务应该在网络目标之后启动。这意味着系统将在网络连接可用后才启动这个服务。

2. `[Service]`

   - 这一部分定义了服务的运行方式。

   - `Type=simple`：指定了服务的类型。在这里，它指定为简单类型，表示 systemd 将启动该服务并等待其终止。

   - `ExecStart=/root/set_gradio_permissions.sh`：指定了服务启动时要执行的命令或脚本。在这里，它指定为 `/root/set_gradio_permissions.sh`，这是您要运行的设置权限脚本的路径。

   - `Restart=always`：指定了服务在终止时是否应自动重启。`always` 表示无论服务是如何终止的（正常终止还是非正常终止），都应该重新启动。

3. `[Install]`

   - 这一部分定义了如何安装这个服务。

   - `WantedBy=multi-user.target`：指定了这个服务应该被添加到哪个目标中。在这里，它指定为 `multi-user.target`，表示这个服务应该在多用户模式下运行。

综上所述，这个 systemd 服务单元文件描述了一个名为 `gradio_permissions` 的服务，其目的是在系统启动时设置 `/tmp/gradio` 目录的权限，并且它将在网络目标之后启动，以确保网络连接可用，同时它会在终止时自动重启，并在多用户模式下运行。

【运维】监视新增文件，对/tmp/gradio文件夹的新增文件自动设置权限为777

我执行这个指令被打断了：





```bash
scp -r -P 2022 xd@home.elvisiky.com:/data/xd/fooocus_tensorRT/TensorRT/demo/Diffusion/ ./
```

现在我想执行rsync同步还没有传完的文件



要使用rsync命令来同步还没有传完的文件，你可以按照以下步骤进行操作：

1. 打开终端，输入以下命令：

```bash
rsync -av --partial --progress -e "ssh -p 2022" xd@home.elvisiky.com:/data/xd/fooocus_tensorRT/TensorRT/demo/Diffusion/ ./Diffusion/
```


   这将使用rsync通过SSH连接到指定主机和端口，并尝试同步文件夹。

2. rsync命令中的选项解释：

   - `-av`: 保持文件属性，并以递归方式同步文件夹。

   - `--partial`: 如果文件传输被中断，保留部分文件。

   - `--progress`: 显示传输进度。

   - `-e "ssh -p 2022"`: 指定SSH端口。

3. 执行命令后，rsync将开始同步文件夹，并在终端显示传输进度。完成后，文件将被同步到当前目录。

rsync如何指定端口进行文件同步？

### 优化算法服务：从单进程到并行化





在实际应用中，单个算法服务的并发能力可能无法满足需求。为了提高性能和并发处理能力，我们可以使用Gunicorn和Docker来实现算法服务的并行化部署。

#### 单个服务架构

首先，让我们来看看单个服务的架构：

```python
from fastapi import FastAPI
app = FastAPI()
alg_model = xxxx()  # Initialize your algorithm model
@app.post("/alginfer")
def alginfer(xxxx):
    # Perform inference using alg_model
    result = alg_model.predict(xxxx)
    return result
```

在这个架构下，服务拓扑图如下：

![单个服务拓扑图](/static/img/images/03646.png)

#### 多并行服务架构

为了提高服务并发能力，我们可以使用Gunicorn来启动多个并行的算法服务。以下是如何使用Gunicorn进行多并行服务的部署：

```bash
pip install gunicorn 
```

```bash
gunicorn -w 2 -b 0.0.0.0:7860 -k uvicorn.workers.UvicornWorker sdxl_app:app
```

在这个架构下，服务拓扑图变为：

![多个并行服务拓扑图](/static/img/images/03647.png)

#### Docker化并指定并行服务数量

通过Docker容器化算法服务，并通过环境变量来指定并行服务的数量，可以进一步简化部署和管理。以下是实现这一目标的步骤：

首先，创建一个`gunicorn_config.py`文件：

```python
import os
bind = '0.0.0.0:7860'  # Listen address and port
workers = int(os.environ.get('GUNICORN_WORKERS', '1'))  # Number of workers
worker_class = 'uvicorn.workers.UvicornWorker'  # Worker type
```

然后，编写Dockerfile：

```Dockerfile
FROM kevinchina/xxxx:xxxx
EXPOSE 7860
ENTRYPOINT gunicorn -c /workspace/gunicorn_config.py sdxl_app:app
```

最后，通过`docker run`命令启动容器，并指定环境变量来设置并行服务的数量：

```bash
docker run -e GUNICORN_WORKERS=2 -p 7860:7860 -d --gpus all kevinchina/xxxx:tttt
```

通过这些优化，我们可以轻松地实现算法服务的并行化部署，提高系统的性能和可伸缩性。



# 扩展知识 

当你使用 Gunicorn 启动服务时，`-k` 参数用于指定使用的 worker 类型。不同的 worker 类型适用于不同的场景和需求。以下是一些常见的 worker 类型以及它们的用途：

- `sync`：同步 worker，每个请求都会在一个独立的线程或进程中处理。适用于开发环境或者对并发要求不高的场景。

- `eventlet`：基于事件驱动的并发库，可以实现高并发。适用于 I/O 密集型的应用程序。

- `gevent`：基于 libev 的并发库，也是事件驱动的。与 eventlet 类似，适用于 I/O 密集型的应用程序。

- `uvicorn.workers.UvicornWorker`：使用 Uvicorn worker，适用于 ASGI 应用程序。

你可以根据你的应用程序类型和需求选择合适的 worker 类型。例如，如果你的应用程序是基于 ASGI 的，你可以使用 Uvicorn worker。以下是一个使用 `-k` 参数指定 worker 类型的示例：

```bash
gunicorn -w 4 -b 0.0.0.0:7860 -k uvicorn.workers.UvicornWorker sdxl_app:app
```

在这个示例中：

- `-w 4` 指定了 4 个 worker 进程。

- `-b 0.0.0.0:7860` 指定了绑定的主机和端口。

- `-k uvicorn.workers.UvicornWorker` 指定了使用 Uvicorn worker。

根据你的实际情况选择适合的 worker 类型，并根据需要调整其他参数。

【Docker】【深度学习算法】在Docker中使用gunicorn启动多个并行算法服务，优化算法服务：从单进程到并行化

# 使用Nginx反向代理2个web接口服务





在Ubuntu上安装Nginx并配置使其生效是相对简单的过程。以下是一步一步的指南：

### 步骤 1：安装 Nginx

打开终端，并执行以下命令来安装 Nginx：

```bash
sudo apt update
sudo apt install nginx
```

### 步骤 2：启动 Nginx 服务


安装完成后，Nginx 已经自动启动了。你可以通过以下命令检查 Nginx 服务的状态：

```bash
sudo systemctl status nginx
```

如果状态显示为"active (running)"，表示 Nginx 已经成功启动。

没有启动可以用

```bash
sudo systemctl start nginx
```


对于 SysVinit，你可以使用 service 命令来管理服务。尝试使用以下命令来检查 Nginx 服务状态：


```bash
sudo service nginx status
```

如果 Nginx 没有启动，你可以使用以下命令启动它：

```bash
sudo service nginx start
```


### 步骤 3：配置 Nginx

Nginx 的主要配置文件是 `/etc/nginx/nginx.conf`，但是推荐的做法是在 `/etc/nginx/sites-available/` 目录下创建一个新的配置文件，并在 `/etc/nginx/sites-enabled/` 目录下创建该配置文件的符号链接。这样做可以更好地组织和管理配置文件。

下面是一个简单的示例配置文件 `mywebsite`：

```nginx
upstream backend {
    server 127.0.0.1:7885;
    server 127.0.0.1:7886;
}
server {
    listen 7860;
    client_max_body_size 100M;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection \"upgrade\";
        proxy_connect_timeout 300s;
        proxy_read_timeout 300s;
    }
}
```

将上述配置内容保存为一个文件，例如 `mywebsite`，并将其放置在 `/etc/nginx/sites-available/` 目录下。

### 步骤 4：启用配置

在 `/etc/nginx/sites-enabled/` 目录下创建一个指向 `/etc/nginx/sites-available/mywebsite` 的符号链接，使用以下命令：

```bash
sudo ln -s /etc/nginx/sites-available/mywebsite /etc/nginx/sites-enabled/
```

### 步骤 5：检查配置


执行以下命令检查 Nginx 配置是否正确：

```bash
sudo nginx -t
```

自己也要先确保自己写的服务是打开了的，我这里这web接口服务都是打开了的：

    server 127.0.0.1:7885;

    server 127.0.0.1:7886;

    



如果输出中没有错误，表示配置文件有效。

![在这里插入图片描述](/static/img/images/03648.png)


### 步骤 6：重启 Nginx

最后，重启 Nginx 以使新的配置生效：

```bash
sudo systemctl restart nginx
```

或者这个指令：

```bash
sudo service nginx restart
```

### 步骤 7：访问网站



现在，你可以通过在浏览器中输入你的域名来访问你的网站了。

以上是在 Ubuntu 上安装 Nginx 并配置使其生效的基本步骤。根据你的实际需求，你可能需要进一步调整配置文件，以满足你的特定要求。


#  proxy_set_header  含义

```bash
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
```

这些指令是在 Nginx 中用于设置代理请求头部信息的。它们的作用如下：

1. `proxy_set_header Host $host;`：设置代理请求的 Host 头部字段为客户端请求的 Host 头部。这个指令确保了向后端服务器发送的请求中包含了客户端请求的目标主机信息。

2. `proxy_set_header X-Real-IP $remote_addr;`：设置代理请求的 X-Real-IP 头部字段为客户端的真实 IP 地址。当 Nginx 作为反向代理时，它接收到的请求的远程 IP 地址是客户端连接的 IP 地址，而不是最初请求的客户端的真实 IP 地址。这个指令将客户端的真实 IP 地址传递给后端服务器，方便后端服务器获取客户端的真实 IP 地址。

3. `proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;`：设置代理请求的 X-Forwarded-For 头部字段为客户端 IP 地址和原始的 X-Forwarded-For 头部字段值。X-Forwarded-For 头部用于标识请求经过的代理服务器列表，这个指令将客户端的 IP 地址添加到已有的 X-Forwarded-For 头部字段值中。

4. `proxy_set_header X-Forwarded-Proto $scheme;`：设置代理请求的 X-Forwarded-Proto 头部字段为客户端请求的协议（HTTP 或 HTTPS）。这个指令用于传递客户端请求的协议信息给后端服务器，通常用于处理 HTTPS 反向代理时的重定向和链接生成。

这些指令通常在 Nginx 配置中用于反向代理和负载均衡场景，以确保后端服务器能够正确获取客户端的真实 IP 地址和其他相关信息。

# 配置一些端口转发

要实现将当前服务器的8000到8050端口请求转发到另一台服务器（IP 为 `101.150.72.28`）的相应端口，你需要使用 `ngx_http_map_module` 或 `ngx_http_split_clients_module` 这样的模块来处理端口映射，但通常我们可以通过编写一个通配的 `location` 配置来匹配所有这些端口请求并正确地转发它们。

你可以参考以下 `nginx` 配置：

```nginx
server {
    listen 8000-8050;  # 监听当前服务器的 8000 到 8050 端口
    client_max_body_size 100M;

    # 使用正则表达式来捕获端口号，并将其动态传递到目标服务器的相应端口
    location / {
        set $target_port $server_port;  # 将请求的端口保存在 $target_port 变量中
        proxy_pass http://101.150.72.28:$target_port;  # 转发到目标服务器的相应端口

        # 保持客户端的请求头信息
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_connect_timeout 300s;
        proxy_read_timeout 300s;
    }
}
```

### 解释：
1. `listen 8000-8050;`：监听当前服务器的8000到8050端口。
2. `set $target_port $server_port;`：将当前请求的端口（即 `server_port`）赋值给变量 `target_port`。
3. `proxy_pass http://10.150.72.28:$target_port;`：根据请求的端口，转发到 `10.150.72.28` 的相应端口。

这样，每当访问当前服务器的8000到8050端口时，`nginx` 会将这些请求转发到 `10.150.72.28` 的相应端口。


# 选择负载均衡方法

手册说明：[https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)

NGINX Open Source 支持四种负载均衡方法，而 NGINX Plus 添加了两种额外的方法：

1. **Round Robin（轮询）**：请求被均匀地分配到服务器上，考虑到服务器的权重。这是默认的方法（没有指令来启用它）：

```nginx
upstream backend {
    # 没有指定负载均衡方法，采用轮询
    server backend1.example.com;
    server backend2.example.com;
}
```

2. **Least Connections（最少连接）**：将请求发送到当前活动连接数最少的服务器上，同样考虑到服务器的权重：

```nginx
upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}
```

3. **IP Hash（基于 IP 的哈希）**：根据客户端的 IP 地址确定发送请求的服务器。在这种情况下，使用 IPv4 地址的前三个八位组或整个 IPv6 地址来计算哈希值。此方法确保来自相同地址的请求被发送到同一台服务器，除非它不可用。

```nginx
upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}
```

如果需要暂时从负载均衡轮转中移除某个服务器，可以使用 down 参数，以保留客户端 IP 地址的当前哈希值。对该服务器的请求将自动发送到组中的下一个服务器：

```nginx
upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}
```

4. **Generic Hash（通用哈希）**：根据用户定义的键来确定发送请求的服务器，该键可以是文本字符串、变量或其组合。例如，键可以是成对的源 IP 地址和端口，或者是 URI，如下所示：

```nginx
upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}
```

哈希指令的可选 consistent 参数启用了 ketama 一致性哈希负载均衡。根据用户定义的哈希键值，请求被均匀地分配到所有上游服务器上。如果向上游组中添加或删除了一台服务器，则只会重新映射一些键，从而在负载均衡缓存服务器或其他积累状态的应用程序的情况下最小化缓存未命中。

5. **Least Time（仅适用于 NGINX Plus）**：对于每个请求，NGINX Plus 选择具有最低平均延迟和最低活动连接数的服务器，最低平均延迟基于以下参数之一来计算，这些参数包括 least_time 指令中包含的：

- header：从服务器接收第一个字节的时间

- last_byte：从服务器接收完整响应的时间

- last_byte inflight：从服务器接收完整响应的时间，考虑到未完成的请求

```nginx
upstream backend {
    least_time header;
    server backend1.example.com;
    server backend2.example.com;
}
```

6. **Random（随机）**：每个请求将被随机选择的服务器处理。如果指定了 two 参数，则 NGINX 首先随机选择两个服务器，考虑到服务器的权重，然后使用指定的方法选择其中一个服务器：

- least_conn：最少活动连接数

- least_time=header（NGINX Plus）：从服务器接收响应头的最短平均时间（$upstream_header_time）

- least_time=last_byte（NGINX Plus）：从服务器接收完整响应的最短平均时间（$upstream_response_time）

```nginx
upstream backend {
    random two least_time=last_byte;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}
```

应该将除轮询之外的任何方法配置在 upstream {} 块中的服务器指令列表之前。

# 日志



NGINX 在代理过程中可以生成日志。通过配置 NGINX 的日志功能，你可以记录代理请求的详细信息，包括请求的来源、目标服务器、响应时间等等。

通常情况下，NGINX 的日志文件位于 `/var/log/nginx/` 目录下，你可以在配置文件中指定日志格式和日志文件的路径。下面是一个示例配置，用于配置 NGINX 的访问日志：

```nginx
http {
    log_format custom_format '$remote_addr - $remote_user [$time_local] '
                            '"$request" $status $body_bytes_sent '
                            '"$http_referer" "$http_user_agent" '
                            '$request_time';
    access_log /var/log/nginx/access.log custom_format;
}
```

在上面的示例中，我们定义了一个名为 `custom_format` 的日志格式，然后将访问日志写入到 `/var/log/nginx/access.log` 文件中，并使用我们定义的 `custom_format` 格式来记录日志。

如果你想记录更多的细节信息，你可以调整日志格式，以包含更多的变量。在NGINX的官方文档中，有详细介绍了可以在日志格式中使用的变量，你可以根据自己的需求进行调整。

除了访问日志外，NGINX 还可以生成错误日志，用于记录 NGINX 服务器运行时的错误信息。默认情况下，错误日志会记录在 `/var/log/nginx/error.log` 文件中。

如果你没有对 NGINX 进行任何配置，那么 NGINX 默认的日志将会在系统默认的日志路径中。通常情况下，在 Debian 和 Ubuntu 等系统中，NGINX 的错误日志默认会被记录在 /var/log/nginx/error.log 文件中，而访问日志则默认记录在 /var/log/nginx/access.log 文件中。


# 日志转发工具


### 1. Dockerize

Dockerize 是一个简单的工具，用于等待容器中的某个服务启动完成后，执行其他操作，比如启动应用程序或者进行日志转发。

使用 Dockerize 来实现 NGINX 日志的实时输出到 Docker 日志中的步骤如下：

1. 在 NGINX 的配置文件中，将日志输出到标准输出和标准错误输出：

    ```nginx
    error_log /dev/stderr;
    access_log /dev/stdout;
    ```

2. 在 Dockerfile 中，安装 Dockerize，并将 NGINX 配置文件和 Dockerize 复制到容器中：

    ```Dockerfile
    FROM nginx:latest
    # 安装 Dockerize
    RUN apt-get update && apt-get install -y dockerize
    # 将 NGINX 配置文件复制到容器中
    COPY nginx.conf /etc/nginx/nginx.conf
    # 将 Dockerize 复制到容器中
    COPY dockerize /usr/local/bin/
    CMD ["dockerize", "-stdout", "/usr/sbin/nginx", "-g", "daemon off;"]
    ```

3. 构建 Docker 镜像并运行容器：

    ```bash
    docker build -t my-nginx .
    docker run -d my-nginx
    ```

### 2. Logspout

Logspout 是一个用 Go 编写的轻量级容器日志路由器，它可以捕获容器的标准输出和标准错误输出，并将日志发送到各种目的地，比如本地文件、远程服务器等。

使用 Logspout 来实现 NGINX 日志的实时输出到 Docker 日志中的步骤如下：

1. 在 Docker 容器中运行 Logspout：

    ```bash
    docker run -d --name="logspout" --volume=/var/run/docker.sock:/var/run/docker.sock gliderlabs/logspout
    ```

2. 在 NGINX 的容器中，将日志输出到标准输出和标准错误输出：

    ```nginx
    error_log /dev/stderr;
    access_log /dev/stdout;
    ```

### 3. Fluentd

Fluentd 是一个开源的数据收集器，它可以将日志从各种来源收集起来，并将它们发送到各种目的地，比如文件、数据库、消息队列等。

使用 Fluentd 来实现 NGINX 日志的实时输出到 Docker 日志中的步骤如下：

1. 在 NGINX 的容器中，将日志输出到 Fluentd 的 TCP 或 UDP 输入插件：

    ```nginx
    access_log fluentd.example.com:24224;
    ```

2. 在 Fluentd 的配置文件中，配置输入插件和输出插件，将接收到的日志输出到 Docker 的日志中。

这些是使用 Dockerize、Logspout 和 Fluentd 这三种工具实现 NGINX 日志实时输出到 Docker 日志中的基本步骤。你可以根据自己的需求和环境选择合适的工具来实现日志转发。

【Nginx】Ubuntu如何安装使用Nginx反向代理？

即使设置了清华源：





```bash
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
```

pip 安装包不能配置清华源，出现报错:

Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)': /simple/pip/

看起来你正在尝试升级 pip，并已配置索引 URL 以使用清华大学的一个镜像。然而，在升级过程中，你遇到了一个 SSL 错误。这种错误通常发生在 SSL 证书验证出现问题时。

以下是一些建议，希望能解决这个问题：

1. **更新 CA 证书：**

   - 确保你的系统上的 CA 证书是最新的。通常可以通过安装 `ca-certificates` 软件包来实现。在 Ubuntu 上，你可以运行以下命令：

     ```bash
     sudo apt-get update
     sudo apt-get install ca-certificates
     ```

2. **使用默认索引 URL 升级 pip：**

   - 暂时删除或注释掉 pip 配置中的自定义索引 URL，尝试使用默认索引 URL 升级 pip：

     ```bash
     pip config unset global.index-url
     pip install --upgrade pip
     ```

3. **检查系统日期和时间：**

   - 确保机器上的系统日期和时间准确。SSL 证书具有到期日期，不准确的系统时间可能会导致 SSL 验证问题。

4. **验证 SSL/TLS 支持：**

   - 确保你的 Python 安装包含 SSL/TLS 支持。你可以运行以下命令进行检查：

     ```bash
     python -c "import ssl; print(ssl.OPENSSL_VERSION)"
     ```

   - 如果没有 SSL/TLS 支持，可能需要重新安装带有 SSL 支持的 Python。

5. **使用不同的镜像：**

   - 如果问题仍然存在，考虑使用不同的镜像。可以切换回默认的 PyPI 镜像，运行：

     ```bash
     pip config unset global.index-url
     pip install --upgrade pip
     ```

6. **在虚拟环境中升级 pip：**

   - 使用 `venv` 或 `virtualenv` 创建一个虚拟环境，然后在该环境中尝试升级 pip。这样可以将 pip 升级与全局系统隔离开来。

尝试这些步骤后，你应该能够顺利升级 pip，而不会遇到 SSL 错误。

![在这里插入图片描述](/static/img/images/03651.png)

pip 安装出现报错 SSLError(SSLError(“bad handshake

我是一个专注技术分享的博主,尤其爱搞深度学习和单片机电子。你现在看到的是我的个人博客网站。