有时由于网络问题, 我们需要在命令行下设置代理. Ubuntu 上, 我常用需要联网的命令有
通常, Linux 的环境变量均为大写, 但是代理选项有些特殊, 一般情况下大小写均可, 不过有些命令不能识别某些大写的代理环境变量,
no_proxy 外, 这些环境变量设置的格式为
no_proxy 的格式为以逗号分隔的主机名 (域名) 列表.
ssh 并不使用这些环境变量, 配置代理有自己的方式.
http_proxy外使用大小写均可, 不过小写优先. 使用环境变量设置
NO_PROXY <comma-separated list of hosts>不走代理的主机名列表 (comma-separated list of hosts). 如果仅设置为
— 翻译自 Curl Manual, Version 7.58.0.
从 git-config 的手册中可以看出, git 可以和 curl 一样使用环境变量中定义的代理, 也可以通过
注意 git 并没有
url 有效, 若通过
ssh 访问相应的库, 需要通过
~/.ssh/config 中添加以下内容 (该文件的读写权限应该为 644)
Host github.com User git ProxyCommand nc -X connect -x 127.0.0.1:10809 %h %p
-X connect 表示该代理为
socks5 代理， 去掉参数
-X connect, 其他协议请参考
core.gitProxy A "proxy command" to execute (as command host port) instead of establishing direct connection to the remote server when using the Git protocol for fetching. If the variable value is in the "COMMAND for DOMAIN" format, the command is applied only on hostnames ending with the specified domain string. This variable may be set multiple times and is matched in the given order; the first match wins. Can be overridden by the GIT_PROXY_COMMAND environment variable (which always applies universally, without the special "for" handling). The special string none can be used as the proxy command to specify that no proxy be used for a given domain pattern. This is useful for excluding servers inside a firewall from proxy use, while defaulting to a common proxy for external domains. http.proxy Override the HTTP proxy, normally configured using the http_proxy, https_proxy, and all_proxy environment variables (see curl(1)). In addition to the syntax understood by curl, it is possible to specify a proxy string with a user name but no password, in which case git will attempt to acquire one in the same way it does for other credentials. See gitcredentials(7) for more information. The syntax thus is [protocol://][user[:password]@]proxyhost[:port]. This can be overridden on a per-remote basis; see remote.<name>.proxy http.<url>.* Any of the http.* options above can be applied selectively to some URLs. For a config key to match a URL, each element of the config key is compared to that of the URL, in the following order: 1. Scheme (e.g., https in https://example.com/). This field must match exactly between the config key and the URL. 2. Host/domain name (e.g., example.com in https://example.com/). This field must match between the 3. config key and the URL. It is possible to specify a * as part of the host name to match all subdomains at this level. https://*.example.com/ for example would match https://foo.example.com/, but not https://foo.bar.example.com/. 4. Port number (e.g., 8080 in http://example.com:8080/). This field must match exactly between 5. the config key and the URL. Omitted port numbers are automatically converted to the correct default for the scheme before matching. 6. Path (e.g., repo.git in https://example.com/repo.git). The path field of the config key must 7. match the path field of the URL either exactly or as a prefix of slash-delimited path elements. This means a config key with path foo/ matches URL path foo/bar. A prefix can only match on a slash (/) boundary. Longer matches take precedence (so a config key with path foo/bar is a better match to URL path foo/bar than a config key with just path foo/). 8. User name (e.g., user in https://firstname.lastname@example.org/repo.git). If the config key has a user name 9. it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none), but at a lower precedence than a config key with a user name. The list above is ordered by decreasing precedence; a URL that matches a config key’s path is preferred to one that matches its user name. For example, if the URL is https://email@example.com/foo/bar a config key match of https://example.com/foo will be preferred over a config key match of https://firstname.lastname@example.org. All URLs are normalized before attempting any matching (the password part, if embedded in the URL, is always ignored for matching purposes) so that equivalent URLs that are simply spelled differently will match properly. Environment variable settings always override any matches. The URLs that are matched against are those given directly to Git commands. This means any URLs visited as a result of a redirection do not participate in matching. remote.<name>.proxy For remotes that require curl (http, https and ftp), the URL to the proxy to use for that remote. Set to the empty string to disable proxying for that remote.
Wget supports proxies for both HTTP and FTP retrievals. The standard way to specify proxy location, which Wget recognizes, is using the following environment variables: http_proxy https_proxy If set, the http_proxy and https_proxy variables should contain the URLs of the proxies for HTTP and HTTPS connections respectively. ftp_proxy This variable should contain the URL of the proxy for FTP connections. It is quite common that http_proxy and ftp_proxy are set to the same URL. no_proxy This variable should contain a comma-separated list of domain extensions proxy should not be used for. For instance, if the value of no_proxy is .mit.edu, proxy will not be used to retrieve documents from MIT.
wget 命令和 proxy 相关的选项
--proxy-user=user --proxy-password=password Specify the username user and password password for authentication on a proxy server. Wget will encode them using the "basic" authentication scheme. --no-proxy Don't use proxies, even if the appropriate *_proxy environment variable is defined.
通过下面摘录文档的内容看出, apt-get 识别
THE ACQUIRE GROUP The Acquire group of options controls the download of packages as well as the various "acquire methods" responsible for the download itself (see also sources.list(5)). http https The options in these scopes configure APTs acquire transports for the protocols HTTP and HTTPS and are documented in the apt-transport-http(1) and apt-transport-https(1) manpages respectively. ftp ftp::Proxy sets the default proxy to use for FTP URIs. It is in the standard form of ftp://[[user][:pass]@]host[:port]/. Per host proxies can also be specified by using the form ftp::Proxy::<host> with the special keyword DIRECT meaning to use no proxies. If no one of the above settings is specified, ftp_proxy environment variable will be used. To use an FTP proxy you will have to set the ftp::ProxyLogin script in the configuration file. This entry specifies the commands to send to tell the proxy server what to connect to. Please see /usr/share/doc/apt/examples/configure-index.gz for an example of how to do this. The substitution variables representing the corresponding URI component are $(PROXY_USER), $(PROXY_PASS), $(SITE_USER), $(SITE_PASS), $(SITE) and $(SITE_PORT). The option timeout sets the timeout timer used by the method; this value applies to the connection as well as the data timeout. Several settings are provided to control passive mode. Generally it is safe to leave passive mode on; it works in nearly every environment. However, some situations require that passive mode be disabled and port mode FTP used instead. This can be done globally or for connections that go through a proxy or for a specific host (see the sample config file for examples). It is possible to proxy FTP over HTTP by setting the ftp_proxy environment variable to an HTTP URL - see the discussion of the http method above for syntax. You cannot set this in the configuration file and it is not recommended to use FTP over HTTP due to its low efficiency. The setting ForceExtended controls the use of RFC2428 EPSV and EPRT commands. The default is false, which means these commands are only used if the control connection is IPv6. Setting this to true forces their use even on IPv4 connections. Note that most FTP servers do not support RFC2428.
URI SPECIFICATION The currently recognized URI types are: http (apt-transport-http(1)) The http scheme specifies an HTTP server for an archive and is the most commonly used method. The URI can directly include login information if the archive requires it, but the use of apt_auth.conf(5) should be preferred. The method also supports SOCKS5 and HTTP(S) proxies either configured via apt-specific configuration or specified by the environment variable http_proxy in the format (assuming an HTTP proxy requiring authentication) http://user:pass@server:port/. The authentication details for proxies can also be supplied via apt_auth.conf(5). Note that these forms of authentication are insecure as the whole communication with the remote server (or proxy) is not encrypted so a sufficiently capable attacker can observe and record login as well as all other interactions. The attacker can not modify the communication through as APTs data security model is independent of the chosen transport method. See apt-secure(8) for details. https (apt-transport-https(1)) The https scheme specifies an HTTPS server for an archive and is very similar in use and available options to the http scheme. The main difference is that the communication between apt and server (or proxy) is encrypted. Note that the encryption does not prevent an attacker from knowing which server (or proxy) apt is communicating with and deeper analyses can potentially still reveal which data was downloaded. If this is a concern the Tor-based schemes mentioned further below might be a suitable alternative. ftp The ftp scheme specifies an FTP server for an archive. Use of FTP is on the decline in favour of http and https and many archives either never offered or are retiring FTP access. If you still need this method many configuration options for it are available in the Acquire::ftp scope and detailed in apt.conf(5). Please note that an FTP proxy can be specified by using the ftp_proxy environment variable. It is possible to specify an HTTP proxy (HTTP proxy servers often understand FTP URLs) using this environment variable and only this environment variable. Proxies using HTTP specified in the configuration file will be ignored.
ssh 并不能使用上面的环境变量, 如果 ssh 连接需要使用代理, 须单独设置:
~/.ssh/config, 该文件的读写权限应该为 644.
ProxyCommand /usr/bin/nc -X connect -x 127.0.0.1:8080 %h %p
Host github.com User git ProxyCommand nc -X connect -x 127.0.0.1:10809 %h %p
-J [user@]host[:port] Connect to the target host by first making a ssh connection to the jump host and then establish‐ ing a TCP forwarding to the ultimate destination from there. Multiple jump hops may be specified separated by comma characters. This is a shortcut to specify a ProxyJump configuration direc‐ tive. -L [bind_address:]port:host:hostport -L [bind_address:]port:remote_socket -L local_socket:host:hostport -L local_socket:remote_socket Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side. This works by allo‐ cating a socket to listen to either a TCP port on the local side, optionally bound to the speci‐ fied bind_address, or to a Unix socket. Whenever a connection is made to the local port or socket, the connection is forwarded over the secure channel, and a connection is made to either host port hostport, or the Unix socket remote_socket, from the remote machine. Port forwardings can also be specified in the configuration file. Only the superuser can forward privileged ports. IPv6 addresses can be specified by enclosing the address in square brackets. By default, the local port is bound in accordance with the GatewayPorts setting. However, an explicit bind_address may be used to bind the connection to a specific address. The bind_address of “localhost” indicates that the listening port be bound for local use only, while an empty address or ‘*’ indicates that the port should be available from all interfaces. -R [bind_address:]port:host:hostport -R [bind_address:]port:local_socket -R remote_socket:host:hostport -R remote_socket:local_socket -R [bind_address:]port Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side. This works by allocating a socket to listen to either a TCP port or to a Unix socket on the remote side. Whenever a connection is made to this port or Unix socket, the connection is for‐ warded over the secure channel, and a connection is made from the local machine to either an explicit destination specified by host port hostport, or local_socket, or, if no explicit desti‐ nation was specified, ssh will act as a SOCKS 4/5 proxy and forward connections to the destina‐ tions requested by the remote SOCKS client. Port forwardings can also be specified in the configuration file. Privileged ports can be for‐ warded only when logging in as root on the remote machine. IPv6 addresses can be specified by enclosing the address in square brackets. By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)). If the port argument is ‘0’, the listen port will be dynamically allocated on the server and reported to the client at run time. When used together with -O forward the allocated port will be printed to the standard output.
ssh(1) obtains configuration data from the following sources in the following order: 1. command-line options 2. user's configuration file (~/.ssh/config) 3. system-wide configuration file (/etc/ssh/ssh_config) For each parameter, the first obtained value will be used. The configuration files contain sections sep‐ arated by Host specifications, and that section is only applied for hosts that match one of the patterns given in the specification. The matched host name is usually the one given on the command line (see the CanonicalizeHostname option for exceptions). Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end. The file contains keyword-argument pairs, one per line. Lines starting with ‘#’ and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes (") in order to represent arguments containing spaces. Configuration options may be separated by whitespace or optional whitespace and exactly one ‘=’; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option. The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive): ProxyCommand Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed using the user's shell ‘exec’ directive to avoid a lingering shell process. Arguments to ProxyCommand accept the tokens described in the TOKENS section. The command can be basically anything, and should read from its standard input and write to its standard output. It should eventually connect an sshd(8) server running on some machine, or execute sshd -i some‐ where. Host key management will be done using the HostName of the host being connected (default‐ ing to the name typed by the user). Setting the command to none disables this option entirely. Note that CheckHostIP is not available for connects with a proxy command. This directive is useful in conjunction with nc(1) and its proxy support. For example, the fol‐ lowing directive would connect via an HTTP proxy at 192.0.2.0: ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p ProxyJump Specifies one or more jump proxies as [user@]host[:port]. Multiple proxies may be separated by comma characters and will be visited sequentially. Setting this option will cause ssh(1) to con‐ nect to the target host by first making a ssh(1) connection to the specified ProxyJump host and then establishing a TCP forwarding to the ultimate target from there. Note that this option will compete with the ProxyCommand option - whichever is specified first will prevent later instances of the other from taking effect. ProxyUseFdpass Specifies that ProxyCommand will pass a connected file descriptor back to ssh(1) instead of con‐ tinuing to execute and pass data. The default is no. ProxyCommand accepts the tokens %%, %h, %p, and %r. %% A literal ‘%’. %C Shorthand for %l%h%p%r. %d Local user's home directory. %h The remote hostname. %i The local user ID. %L The local hostname. %l The local hostname, including the domain name. %n The original remote hostname, as given on the command line. %p The remote port. %r The remote username. %u The local username.