Por qué ejecutar set-proxy.sh no cambia tu terminal

Tu script contiene la línea export https_proxy=... correcta. Lo ejecutas y el siguiente comando sigue viendo el proxy antiguo. Puede que el script haya funcionado perfectamente dentro de su propio proceso.

Ejecutar un script inicia un shell aparte. Puede pasar variables a los comandos que inicia, pero no puede sustituir el entorno del shell padre del terminal después de salir.

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

Son operaciones distintas. La segunda usa el builtin dot del shell para leer el archivo en el shell actual. Bash también lo llama source; consulta su referencia de builtins.

Carga con source solo un archivo en el que confíes, porque todos sus comandos de shell se ejecutan en ese contexto actual. Si el proxy solo se necesita para comandos dentro del script, la ejecución normal es el límite correcto. Para un único comando externo, una asignación de proxy limitada al comando evita cambiar el shell actual.

Mantén literales las asignaciones de variables. Los acentos graves significan sustitución de comandos, no comillas. Una línea que asigna un proxy no debería intentar ejecutar su URL por accidente. Para valores destinados a elegir un punto final público, la lista de proxies gratuitos ofrece candidatos cuyo protocolo debe coincidir con el cliente. Por último, comprueba los nombres de variable que lee el cliente de red real; corregir el ámbito del shell no hace efectiva una variable no admitida.