Why Running set-proxy.sh Doesn't Change Your Terminal

Your script contains the right export https_proxy=... line. You run it, then the next command still sees the old proxy. The script may have worked perfectly inside its own process.

Executing a script starts a separate shell. It can pass variables to commands it starts, but it cannot replace the environment of the parent terminal shell after it exits.

./set-proxy.sh
. ./set-proxy.sh

These are different operations. The second uses the shell's dot builtin to read the file in the current shell. Bash also calls this source; see its builtin reference.

Only source a file you trust, because all its shell commands run in that current context. If the proxy is needed solely for commands inside the script, ordinary execution is the correct boundary instead. For a single external command, a command-scoped proxy assignment avoids changing the current shell.

Keep variable assignments literal. Backticks mean command substitution, not quotation. A line assigning a proxy should not accidentally try to execute its URL. For values intended to select a public endpoint, the free proxy list supplies candidates whose protocol must match the client. Finally, verify the variable names that the actual network client reads; fixing shell scope does not make an unsupported variable effective.